JSON-LD Working Group Telco — Minutes

Date: 2019-11-01

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Ivan Herman, Pierre-Antoine Champin, Dave Longley, Gregg Kellogg, Benjamin Young, David I. Lehn

Regrets: Jeff Mixter

Guests: Ted Thibodeau Jr, Markus Sabadello

Chair: Rob Sanderson

Scribe(s): Pierre-Antoine Champin

Content:

1. Approve minutes of previous call:

Proposed resolution: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-10-25-json-ld (Rob Sanderson)

Rob Sanderson: +1

Dave Longley: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Resolution #1: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-10-25-json-ld

Rob Sanderson: welcome to markus_sabadello and TallTed from the DID WG
… let’s have a round of introduction
… I’m co-chair of this WG, previous chair of the Annotation WG, where we used JSON-LD

Ivan Herman: staff contact on both group, everyone knows me

Dave Longley: also a member of both groups

Gregg Kellogg: JSON-LD editor, I was at the last DID F2F

Markus Sabadello: founder of a startup in Vienna, co-editor of the DID specification
… not an expert in JSON-LD, but have used it in several projects in the past

Ted Thibodeau Jr: OpenLink software since 2000, and W3C since 2001

Benjamin Young: co-chair of the JSON-LD WG, and previously of the Annotation WG
… lurked in the DID CG previously

2. Announcements?

Ivan Herman: next week, back to usual time in Europe

3. Media Types for JSON-LD

Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/287

Ivan Herman: See related DID issue

Rob Sanderson: the DID WG is looking for how to have a media-type, with a specific file extension
… which would be recognized as a subtype of JSON-LD
… What would happen with multiple + signs, like application/did+ld+json ?
… Or should it be application/did+jsonld
… Or could an extension be registered with a profile of application/ld+json?

Gregg Kellogg: did anyone consider application/did-ld+json? Does it satisfy any of the concern?

Ivan Herman: that was one of the options.

Markus Sabadello: we want a specific mime-type, in order to have a file extension,
… and also to be able to specify the semantics of fragments in our format.
… Problem seems to be that we are defining a subtype of a subtype.

Dave Longley: potential options: application/did-ld+json, application/did+ld+json application/ld+json;profile=URI, application/did+jsonld, application/did+json

Markus Sabadello: The hyphen or the multiple-plus solutions would work I think.

Rob Sanderson: about the extension, there was a discussion in the Annotation WG;
… (-> see also a separate action https://github.com/w3c/json-ld-wg/issues/123 )
… we checked with IETF and IANA (Mark Nottigham).
… We asked if a file extension could be registered with a profile parameter,
… without a new media-type.
… The answer was yes, provided that the “media-type owner” acknowledge it.
… In this case, the “media-type owner” is us (the JSON-LD WG).
… To me, the profile pattern is the preferable way. We should explore this first.

Rob Sanderson: It would look like: application/ld+json;profile="https://w3.org/ns/did" (or whatever URI)

Rob Sanderson: Profile parameter: https://www.w3.org/TR/json-ld11/#iana-considerations

Benjamin Young: https://tools.ietf.org/html/rfc6906 - The ‘profile’ Link Relation Type

Benjamin Young: https://tools.ietf.org/html/rfc7284 - The Profile URI Registry RFC

Rob Sanderson: https://www.iana.org/assignments/profile-uris/profile-uris.xhtml - Profile URI registry:

Ted Thibodeau Jr: Can anyone point to a documentation of the profile suffix on mime-types?
… We have been discussing the “+” solution, because it allows a fallback.
… But according to the RFC, only the final + matters for this fallback mechanism.
… But we hope that implementations consider all + signs,
… otherwise, application/did+ld+json would fallback directly to JSON,
… which is not ideal.
… I would suggest that application/jsonld be declared, as an “alias” to application/ld+json,
… i.e. having the same file extension.

Ivan Herman: See reference to the ‘+’ descriptions

Dave Longley: the JSON-LD should advertise the possibility to associate file extensions to profiles,
… but the tooling is missing for properly working with the profile approach. (e.g., npm mime package)

Markus Sabadello: about the fragments,
… the way we are using the fragments in DID should be compatible with the way they are used in JSON-LD,
… so the fallback mentioned above should work to some extent.
… A pure JSON-LD tool should be able to process the fragments in a DID document.

Dave Longley: +1 we absolutely want it to process the fragment the same way

Ivan Herman: I don’t think the fragment ID is defined for the JSON format, is there one for JSON-LD?

Gregg Kellogg: I think we say they have the same semantics as in RDF.

“Fragment identifiers used with application/ld+json are treated as in RDF syntaxes, as per RDF 1.1 Concepts and Abstract Syntax [RDF11-CONCEPTS].”

Benjamin Young: JSON does not have fragment identifiers.

Gregg Kellogg: is there inheritability of fragment identifiers across media-types?
… It would be logical.

Ted Thibodeau Jr: application/did-ld+json would need to echo much of application/ld+json

Ted Thibodeau Jr: application/did+ld+json could inherit if MIME RFC made all + important

Ted Thibodeau Jr: application/did+jsonld would inherit/fallback to application/jsonld

Rob Sanderson: as TallTed pointed out, there is some time pressure.
… We are close to recommendation.
… Would some of the options require a normative change in JSON-LD?
… Consensus seems to be that we should say, in the IANA section,
… that profile IRIs can be associated to new file extensions.
… did[+-]ld+json would not require any change.
… did+jsonld would require a change.
… Let’s focus on the options requiring some change.

Dave Longley: could the application/ld+json registration possibly talk about additional ‘+’s? or would that be too out of scope?

Ted Thibodeau Jr: application/jsonld parallel to application/ld+json with the latter preferred for basic JSON-LD would work … only derivatives of JSON-LD (like DID) would use the former … but maybe did-ld should be considered as parallel to ld as derivatives of JSON

Ivan Herman: the registration of did+ld+json only concerns the DID WG, won’t affect the JSON-LD WG.
… re: did-ld+json, my impression is that this mime-type would be considered independent from ld+json
… The reason why it came up, if I’m correct, was to define the semantics of fragment identifiers.
… We just pointed out that JSON-LD does define a semantics for fragment identifiers.
… Is DID compatible with it? If not, then it should not be a subtype of ld+json,
… regardless of the possibility for IANA.

Markus Sabadello: +1, in DID documents we want to use standard JSON-LD fragment behavior

Dave Longley: for me, they should be compatible, and I think this is the opinion of the DID WG.
… I wonder if we could not just mention in the IANA declaration, that +ld+json should be considered a subtype of ld+json,
… even despite what the RFC says about the final +.

Rob Sanderson: We can ask IANA what they would think about that if we did that.

Ted Thibodeau Jr: concerned about timing

Markus Sabadello: I agree with Dave about the standard fragment semantics.

Rob Sanderson: dlongley, you mentioned problems with the tooling for the profile approach.
… can tools be updated more quickly than specs?

Dave Longley: I’m not sure they can.
… There are many toolchains out there…

Ted Thibodeau Jr: if the only concern is the fragment semantics,
… and they appear to be in synchrony,
… do we need a DID media-type in the 1st place?

Dave Longley: we also want a file extension.

Ted Thibodeau Jr: multiple file extensions can be associated with a single media-type.
… Why not associate the .did extension to application/ld+json?

Rob Sanderson: this would be a bad precedent

Ted Thibodeau Jr: there are lot of things out there, sharing the same media-type,
… with very different contents.

Benjamin Young: I’m assuming you want a file extension so that desktop apps do the right thing (double click)./
… Most application do not trust only the extension, and check the content once opened.
… We could register several extensions with application/ld+json, applications should still check the content.
… The same problem exists with JSON.

Markus Sabadello: we also want to be able to do content negotiation
… we want to be able to distinguish btw a DID document and another JSON-LD document.

Rob Sanderson: can we update the IANA section, saying that
… when a file extension is associated with a profile,

Ivan Herman: this discussion started with the question about multiple +. Shouldn’t we go back to checking this? If we can, this is the simplest solution.
… Let’s check with Heather (from IETF). If the answer is no, then we can look for another solution.

Dave Longley: +1 to ivan

Benjamin Young: +1 to ivan

Gregg Kellogg: +1 to ivan

Ted Thibodeau Jr: did+ld+json conforms to RFC. but tools will probably fall back to json, not to ld+json. which may be OK.

Markus Sabadello: but my understanding is that did+ld+json would NOT automatically inherit from ld+json

Rob Sanderson: We could require that the registration of a file extension be combined with the registration of a profile URI. Then there’s the express intent of the profile URI and the extension being linked. Then the registration for ld+json would explicitly inherit all of the file extensions of all of the profiles.
… the RFC says that only the last + is relevant.
… I agree that we should check. I’m afraid the answer is no.

Ivan Herman: Let’s ask, and prepare a fallback plan.

Rob Sanderson: I think the fallback should be profile.

Benjamin Young: the did+ld+json IANA declaration could explicitly state that it inherits ld+json.

Proposed resolution: Ask IETF if the JSON-LD media type registration can specify that it should be able to be used with additional +s, such as did+ld+json, with the intent to fallback to ld+json and then to json. If the answer is no, then we proceed with the profile pattern. (Rob Sanderson)

Gregg Kellogg: +1

Dave Longley: +1

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Benjamin Young: +1

David I. Lehn: +1

Ted Thibodeau Jr: +1

Ted Thibodeau Jr: worst case, did+ld+json is equivalent to did-ld+json … and things need to be explicitly and/or redundantly stated in the DID space.

Ted Thibodeau Jr: this should require less retooling than reliance on profile – which currently only works in conneg

Resolution #2: Ask IETF if the JSON-LD media type registration can specify that it should be able to be used with additional +s, such as did+ld+json, with the intent to fallback to ld+json and then to json. If the answer is no, then we proceed with the profile pattern.

Markus Sabadello: if the answer is no in general, we can decide later if we go for the profile pattern, or something else…

Markus Sabadello: +1 to above proposal, but fallback could still be either profile, or did+ld+json

Action #1: contact IETF about the multiple pluses in the JSON-LD registration (Rob Sanderson)

Benjamin Young: https://tools.ietf.org/html/rfc7231#section-5.3.2

Dave Longley: the did+ld+json is legal; even if IETF decides that it does NOT inherit ld+json in general, we can bake this inheritance in this specific media-type

Benjamin Young: we should check JS libraries, see how they handle this

Ted Thibodeau Jr: JSON-LD WG could suggest that unrecognized /…+ld+json be treatable as /ld+json
… (this could be non-normative at this point)

Dave Longley: +1 to TallTed

Benjamin Young: +1 to TallTed

Markus Sabadello: +1 to TallTed

Rob Sanderson: re. TallTed suggestion, it boils down to what IETF thinks of that pattern

Ted Thibodeau Jr: even if they disagree about it in general, we can still recommend it for JSON-LD

Gregg Kellogg: +1 to pchampin

Markus Sabadello: +1 to pchampin

Dave Longley: +1

Ted Thibodeau Jr: We could recommend that JSON-LD processors process application/*+ld+json

Proposed resolution: In IANA considerations, allow file extension registration with profile registration. (Rob Sanderson)

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Gregg Kellogg: +1

Dave Longley: +1

Markus Sabadello: +1

Ivan Herman: +1

Resolution #3: In IANA considerations, allow file extension registration with profile registration.

*Proposed resolution: Conforming json-ld processors SHOULD treat *+ld+json in the same way as the application/ld+json media type** *(Rob Sanderson)

Dave Longley: +1

Markus Sabadello: +1

Gregg Kellogg: +1

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Ted Thibodeau Jr: +1

Resolution #4: Conforming json-ld processors SHOULD treat *+ld+json in the same way as the application/ld+json media type

Benjamin Young: +1

Rob Sanderson: I hope we get a response from IETF for next week.

Benjamin Young: +1

Ivan Herman: anyway, we can put in the document what we have resolved, regardless.

Dave Longley: +1 this works regardless

Markus Sabadello: thank you all for taking the time today!

4. Resolutions

5. Action Items