Define json-ld profile URI for OA serialization context and structure

[azaroth42]

Define a profile URI for the context and recommended structure of annotations in JSON-LD.

This is needed to allow systems to content negotiate (at the protocol level) for different flavors of JSON-LD on top of the same content. Any response that follows the serialization should have the profile included to let clients know how to interpret it, and clients need to be able to send it in the request to ask for it.

See in particular:

• https://lists.w3.org/Archives/Public/public-linked-json/2014Jan/0062.html
• http://www.w3.org/TR/json-ld/#iana-considerations
• https://tools.ietf.org/html/rfc7284

[iherman]

Rob,

I would like to understand it more. Do you mean that there will be different flavors of JSON-LD using the annotation model, or that the JSON-LD used for the encoding of the annotation model is, by itself a flavor of JSON-LD and we have to allow for content negotiations to find that out?

If the latter: note that the CSVW Working Group defines a metadata format for CSV files which also restricts JSON-LD in some sense. Ie, it is a different 'flavor', so to say. The decision we took was to simply define a different media type, derived from JSON; that may be more flexible for clients that want JSON and they do not care about the relationship to JSON-LD. I am not saying this is what we should do, but it may be a data point to consider.

[azaroth42]

(Leaving this open until the profile document is actually written. The URI is at least now defined)

[akuckartz]

I dislike the solution choosen by the CSVW WG creating yet another media type application/csvm+json and prefer application/ld+json for such purposes.

[azaroth42]

Noting external discussions relevant to this issue:

• Discussion with the Social Web WG resulted in the point that AS will create its own media type (activity+json) as they want to have it be able to legitimately include information that is NOT valid in JSON-LD. An example given was list of lists, which are not possible in JSON-LD, but used in GeoJSON. The compromise (thanks to @jasnell) was to also mint a profile URI for when the content is JSON-LD
• Discussion with @manusporny confirmed that using the context document as the URI for the profile document is fine, and that documentation could be included within the body of the document as JSON-LD processors MUST ignore it.
• Discussions with IETF revealed that it should be possible to register a file extension (or other such features typically associated with full media types) when registering a profile. That we should try to do so, and work with them to ensure that the process is consistent and smooth.

[iherman]

On 4 Nov 2015, at 05:02, Rob Sanderson notifications@github.com wrote:

Noting external discussions relevant to this issue:

Discussion with the Social Web WG resulted in the point that AS will create its own media type (activity+json) as they want to have it be able to legitimately include information that is NOT valid in JSON-LD. An example given was list of lists, which are not possible in JSON-LD, but used in GeoJSON. The compromise (thanks to @jasnell https://github.com/jasnell) was to also mint a profile URI for when the content is JSON-LD
Discussion with @manusporny confirmed that using the context document as the URI for the profile document is fine, and that documentation could be included within the body of the document as JSON-LD processors MUST ignore it.
Discussions with IETF revealed that it should be possible to register a file extension (or other such features typically associated with full media types) when registering a profile. That we should try to do so, and work with them to ensure that the process is consistent and smooth.
The CSVW WG also defined its own media type for the CSV Metadata content which is, in fact, defined in JSON-LD, although that fact is only visible in the presence of a @context.

That being said, I would prefer to avoid any structure that is not valid JSON-LD.

[akuckartz]

@azaroth42 wrote:

Discussion with the Social Web WG resulted in the point that AS will create its own media type (activity+json) as they want to have it be able to legitimately include information that is NOT valid in JSON-LD. An example given was list of lists, which are not possible in JSON-LD, but used in GeoJSON.

Please note that this so far is only a proposal discussed in the Social Web WG and that I do not agree with creating a new media type. Lists of lists as such are not incompatible with JSON-LD. See w3c/activitystreams#52 (comment) and w3c/activitystreams#52 (comment)

[BigBlueHat]

[Social Web] WG decided to accept the proposal to use application/activity+json as the media type and say that implementers SHOULD treat application/ld+json; profile="http://www.w3.org/ns/activitystreams#" as equivalent.

From: w3c/activitystreams#52 (comment)

GeoJSON's "lists of lists" are indeed "not allowed" within JSON-LD 1.0 though addressing this issue in JSON-LD 1.0 is a planned discussion for the forthcoming JSON-LD 1.1 specification.

[azaroth42]

Proposal: Use the context URL as the profile for Annotations in JSON-LD, and embed a description and relevant links in the body of the graph of the context document.

[iherman]

Could work indeed

[akuckartz]

@BigBlueHat lists of lists are allowed in JSON-LD but it is not possible to use JSON-LD contexts for them so that they can be interpreted as triples.

[BigBlueHat]

@azaroth42 👍

[BigBlueHat]

@akuckartz sure, but then it's a lossy format by default--which seems bad. The creation of application/activity+json essentially "routes around the problem" by defining a JSON-LD-based format which can include GeoJSON list of lists. Regardless, though, I think this is off topic for this thread at present--especially since our plan is to use application/ld+json. 😄

[shepazu]

I'm not sure we have consensus around using application/ld+json as the MIME type. I'd prefer a specific MIME type (and file extension) for annotations, since we're trying to foster an environment of targeted annotation clients, not just to make something that's processable by generic JSON-LD processors (which this format will be anyway). Couldn't we compromise with something like application/ld+json+anno, so an annotation UA would know that it's an annotation, and it could still be handled by generic JSON-LD processors?

Raised as a separate issue, #125.

[iherman]

proposal accepted at telco http://www.w3.org/2015/12/16-annotation-irc#T16-43-00

going for profile

[iherman]

On 16 Dec 2015, at 17:05, Doug Schepers notifications@github.com wrote:

I'm not sure we have consensus around using application/ld+json as the MIME type. I'd prefer a specific MIME type (and file extension) for annotations, since we're trying to foster an environment of targeted annotation clients, not just to make something that's processable by generic JSON-LD processors (which this format will be anyway). Couldn't we compromise with something like application/ld+json+anno, so an annotation UA would know that it's an annotation, and it could still be handled by generic JSON-LD processors?

I guess it should anno+ld+json to go from the most specific to the most general. But, and somebody please correct me if I am wrong (because I would like to be wrong) the media type specifications have only a two level hierarchy. Ie, a generic JSON-LD processor will not understand ../anno+ld+json I believe, only ../ld+json. A generic JSON processor will understand ../ld+json because JSON-LD is defined as a subtype of JSON.

I think we have two, non-exclusive possibilities.

1. Add a profile to ./ld+json, which is the current proposal, works with generic JSON-LD processors, as well as JSON-LD aware Annotation processors. It also works with generic JSON processors.
2. Define a separate media type of the form ../anno+json. Generic JSON processors can of course handle that, as well as specific Annotation processors whether they are JSON-LD aware or not.

I think the present issue addresses only (1) above, and it is a good thing to have this. That has now been decided. (2) is a separate issue; I will raise it as such on the issue list. Personally, I am undecided whether we want to do (2) or not, but that can be decided later.

[azaroth42]

Done: http://w3c.github.io/web-annotation/protocol/wd/#annotation-retrieval

[akuckartz]

😄