MIME Type for Annotation Model

shepazu commented 8 years ago

Should we have a dedicated MIME type (media type) for an annotation? Or should we just use a generic JSON-LD media type? And if there is a dedicated MIME type, should we define a file extension for an annotation (or collection of annotations), such as .anno?

Here are some pros and cons for consideration. Please add additional pros and cons.

Specific MIME Type

Pros:

annotation client immediately knows that the content is meant to be handled as an annotation, especially for UAs that handle multiple media types (e.g. browsers)
allows for user registration of preferred annotation handler (especially for locally-created or downloaded annotations, if there's a file extension)
may foster ecosystem of "annotation handlers", with annotations as first-class type on Web and desktops
Cons:
Possibly not recognizable as JSON-LD from MIME type alone, for generic JSON-LD processors \ (…but could be negotiated to be sent with JSON-LD MIME type, right?)
Generic JSON MIME Type

Pros:
Immediately recognizable as JSON-LD from MIME type alone, for generic JSON-LD processors
Cons:
doesn't identify annotations as unique from other JSON-LD content
Proposals

There are 3 likely proposals for a MIME type:

Generic JSON-LD: application/ld+json
Annotation-only: application/anno (and .anno)
Possible JSON-LD and annotation: application/ld+json+anno (and .anno)

Option 3 might be processable by JSON-LD processors, but it is long and clumsy; and it only applies to the JSON serialization (which might be okay).

Thoughts?

shepazu commented 8 years ago

Another con for generic JSON MIME type:

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

azaroth42 commented 8 years ago

:-1: 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.

shepazu commented 8 years ago

:-1: 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.

shepazu commented 8 years ago

See also @iherman's thoughts on #30: https://github.com/w3c/web-annotation/issues/30#issuecomment-165180831

shepazu commented 8 years ago

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.)

azaroth42 commented 8 years ago

As @iherman says here https://github.com/w3c/web-annotation/issues/30#issuecomment-165180831, 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.

iherman commented 8 years ago

On 16 Dec 2015, at 18:59, Doug Schepers notifications@github.com 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

shepazu commented 8 years ago

@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.

azaroth42 commented 8 years ago

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

akuckartz commented 8 years ago

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

Yes, with profile.

iherman commented 8 years ago

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.

azaroth42 commented 7 years ago

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

BigBlueHat commented 7 years ago

👍 Yes, please.

w3c / web-annotation