Another con for generic JSON MIME type:

• doesn't allow for annotation file type (I think?)

👎 to multiple media types.

All of the pros listed are possible with a profile, and we can have an annotation file type associated with the profile (Verified with IETF already, following on from TPAC).

The proposals miss the actual current proposal of using a profile: the media type would be application/ld+json;profile="http://www.w3.org/ns/anno.jsonld"

Proposal 3 is an illegal media type, as there MUST NOT be more than one + according to the RFC.

👎 to multiple media types.

I wasn't proposing multiple media types, I was proposing a single media type that isn't application/ld+json.

All of the pros listed are possible with a profile, and we can have an annotation
file type associated with the profile (Verified with IETF already, following on from TPAC).

The proposals miss the actual current proposal of using a profile: the media type
would be application/ld+json;profile="http://www.w3.org/ns/anno.jsonld"

Interesting. That's pretty clumsy, but maybe it will work. How well are MIME Type profiles understood by the average developer (this is the first I've heard of them)? What's the rationale to use a profile rather than a dedicated MIME type?

Proposal 3 is an illegal media type, as there MUST NOT be more than one + according to the RFC.

Okay, thanks. That suggestion was by Manu in a hallway conversation, but I should have researched it better.

See also @iherman's thoughts on #30: #30 (comment)

The proposals miss the actual current proposal of using a profile: the media type
would be application/ld+json;profile="http://www.w3.org/ns/anno.jsonld"

Where was this proposal made? Is it implicit in #30? If so, then it should be made more explicit. (During the telcon, the response to my question was that the MIME type is orthogonal to the profile suggestion in #30.)

As @iherman says here #30 (comment), the media type for JSON-LD is application/ld+json. Our representation is JSON-LD, and hence we cannot prevent anyone from using that media type. The addition of a profile lets the JSON-LD media type be more specific as to the structure of the JSON in the representation.

So it is orthogonal whether we want to mint another media type for it as well. And my opinion is that we should not force implementers to choose which to use, and as we have a media type already, we should just use it.

The rationale for a profile rather than yet another media type is that it is recognizable as JSON (+json), as JSON-LD (ld+json) and as an Annotation (the profile) all at the same time, without further adding to the global pool of media types. After the confirmation from IETF that we can register a file extension for a profile, I see no downside ...

... as the "clumsiness" is actually a feature. There are several other parameters on media types including charset. Any reasonable implementation will check for these on the client side, and it's just a string to add to the response header on the server side. So it's actually pretty elegant, from my perspective.

On 16 Dec 2015, at 18:59, Doug Schepers [email protected] wrote:

The proposals miss the actual current proposal of using a profile: the media type
would be application/ld+json;profile="http://www.w3.org/ns/anno.jsonld"

Where was this proposal made? Is it implicit in #30? If so, then it should be made more explicit. (During the telcon, the response to my question was that the MIME type is orthogonal to the profile suggestion in #30.)

It is proposal #30. That is what profile means, as I also explained on the call. That is what we voted on.

The question is whether there would be another mime type.

Ivan

@iherman Okay, thanks for the explanation. I didn't understand that from either the issue (which wasn't explicit about the implications on the MIME type if we have a profile) or the telcon discussion.

Given all this discussion, I'll put forward a specific proposal, then:

I propose that we define an annotation-specific MIME type, separate from application/ld+json or its profile, and a file extension to go along with it. Specifically, I suggest the MIME type application/anno, and the corresponding file extension .anno, but I'm open to other suggestions.

I suspect this won't be acceptable to the Linked-Data/SemWeb constituents in the working group, so I propose we defer this decision to v2 of the Annotation Model, when we will have more implementation experience, and hopefully have a more diverse set of viewpoints.

Indeed, 👎 (as above). Happy to defer any decision regarding further media types to some future point.

should we just use a generic JSON-LD media type?

Yes, with profile.

I propose that we define an annotation-specific MIME type, separate from application/ld+json or its profile, and a file extension to go along with it. Specifically, I suggest the MIME type application/anno, and the corresponding file extension .anno, but I'm open to other suggestions.

Just for the records, for future discussions, if we did something like that, it should be application/anno+json. Generic JSON processors should be able to handle that without further ado.

I know this is postponed, but can we close wontfix to avoid future confusion?

👍 Yes, please.