15:42:06 <RRSAgent> RRSAgent has joined #json-ld
15:42:06 <RRSAgent> logging to https://www.w3.org/2019/11/01-json-ld-irc
15:42:07 <ivan> rrsagent, set log public
15:42:07 <ivan> Meeting: JSON-LD Working Group Telco
15:42:07 <ivan> Date: 2019-11-01
15:42:07 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Oct/0013.html
15:42:07 <ivan> ivan has changed the topic to: Meeting Agenda 2019-11-01: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Oct/0013.html
15:42:08 <ivan> Chair: azaroth
15:42:08 <ivan> Regrets+
15:50:15 <rsanderson> rsanderson has joined #json-ld
15:50:47 <rsanderson> present+
15:50:58 <azaroth> present+
15:52:35 <TallTed> TallTed has joined #json-ld
15:53:05 <pchampin> pchampin has joined #json-ld
15:55:26 <ivan> regrets-
15:55:29 <ivan> present+
15:56:42 <pchampin> present+
15:58:47 <ivan> guests+ TallTed
15:59:00 <ivan> guests+ markus_sabadello
15:59:24 <gkellogg_> gkellogg_ has joined #json-ld
15:59:26 <markus_sabadello> markus_sabadello has joined #json-ld
15:59:57 <dlongley> present+
15:59:58 <ivan> scribejs, set markus_sabadello Markus Sabadello
16:00:11 <markus_sabadello> present+
16:00:16 <ivan> scribejs, set TallTed Ted Thibodeau Jr
16:00:29 <gkellogg> present+
16:02:07 <azaroth> scribenick: pchampin
16:02:30 <azaroth> TOPIC: Approve minutes of previous call:
16:02:43 <azaroth> PROPOSAL: Approve minutes of previous call:  https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-10-25-json-ld
16:02:45 <azaroth> +1
16:02:45 <dlongley> +1
16:02:47 <pchampin> +1
16:02:48 <ivan> +1
16:03:02 <azaroth> RESOLVED: Approve minutes of previous call:  https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-10-25-json-ld
16:03:32 <azaroth> regrets+ jeff_mixter
16:04:17 <pchampin> azaroth: welcome to markus_sabadello and TallTed from the DID WG
16:04:38 <pchampin> ... let's have a round of introduction
16:04:54 <pchampin> ... I'm co-chair of this WG, previous chair of the Annotation WG, where we used JSON-LD
16:05:28 <pchampin> ivan: staff contact on both group, everyone knows me
16:05:33 <pchampin> dlongley: also a member of both groups
16:05:49 <pchampin> gkellogg: JSON-LD editor, I was at the last DID F2F
16:06:13 <ivan> present+ bigbluehat
16:06:13 <pchampin> markus_sabadello: founder of a startup in Vienna, co-editor of the DID specification
16:06:26 <pchampin> ... not an expert in JSON-LD, but have used it in several projects in the past
16:07:06 <gkellogg_> gkellogg_ has joined #json-ld
16:07:28 <pchampin> TallTed: OpenLink software since 2000, and W3C since 2001
16:07:50 <pchampin> bigbluehat: co-chair of the JSON-LD WG, and previously of the Annotation WG
16:07:58 <pchampin> ... lurked in the DID CG previously
16:08:07 <azaroth> TOPIC: Announcements?
16:08:22 <azaroth> q?
16:08:53 <azaroth> TOPIC: Issues
16:09:00 <azaroth> SUBTOPIC: Media Types for JSON-LD
16:09:08 <pchampin> ivan: next week, back to usual time in Europe
16:09:24 <azaroth> https://github.com/w3c/json-ld-syntax/issues/287
16:10:13 <pchampin> azaroth: the DID WG is looking for how to have a media-type, with a specific file extension
16:10:34 <pchampin> ... which would be recognized as a subtype of JSON-LD
16:11:20 <pchampin> ... What would happend with multiple + signs, like application/did+ld+json ?
16:11:47 <gkellogg> q+
16:11:59 <azaroth> ack gkellogg
16:12:02 <pchampin> ... Or should it be application/did+jsonld
16:12:04 <ivan> -> https://github.com/w3c/did-core/issues/1 DID issue in question
16:12:05 <pchampin> ... Or could an extension be registed with a *profile* of application/ld+json?
16:12:17 <dlehn> present+
16:12:19 <markus_sabadello> q+
16:12:32 <pchampin> gkellogg: did anyone consider application/did-ld+json? Does it satisfy any of the concern?
16:12:43 <pchampin> ivan: that was one of the options.
16:12:50 <azaroth> ack markus_sabadello
16:13:18 <azaroth> q+ re file extensions
16:13:32 <pchampin> markus_sabadello: we want a specific mime-type, in order to have a file extension,
16:13:47 <pchampin> ... and also to be able to specify the semantics of fragments in our format.
16:14:16 <dlongley> potential options: application/did-ld+json, application/did+ld+json application/ld+json;profile=URI, application/did+jsonld, application/did+json
16:14:24 <pchampin> ... Problem seems to be that we are defining a subtype of a subtype.
16:14:35 <azaroth> q?
16:14:37 <azaroth> ack azaroth
16:14:37 <Zakim> azaroth, you wanted to discuss file extensions
16:14:42 <pchampin> ... The hyphen or the multiple-plus solutions would work I think.
16:14:44 <TallTed> q+ to talk about subtype fallbacks
16:15:15 <pchampin> azaroth: about the extension, there was a discussion in the Annotation WG;
16:15:22 <azaroth> https://github.com/w3c/json-ld-wg/issues/123
16:15:38 <pchampin> ... we checked with IETF and IANA (Mark Nottigham).
16:16:01 <dlongley> q+ to mention the problem with using profile vs. did-ld+json, did+ld+json, etc.
16:16:05 <pchampin> ... We asked if a file extension could be registered with a profile parameter,
16:16:24 <pchampin> ... without a new media-type.
16:17:06 <pchampin> ... The answer was yes, provided that the "media-type owner" acknowledge it.
16:17:13 <markus_sabadello> q+
16:17:18 <azaroth> q?
16:17:21 <pchampin> ... In this case, the "media-type owner" is us (the JSON-LD WG).
16:17:50 <pchampin> ... To me, the profile pattern is the preferable way. We should explore this first.
16:17:50 <azaroth> ack TallTed
16:17:50 <Zakim> TallTed, you wanted to talk about subtype fallbacks
16:18:23 <pchampin> TallTed: Can anyone point to a documentation of the profile suffix on mime-types?
16:18:37 <azaroth> It would look like:   application/ld+json;profile="https://w3.org/ns/did" (or whatever URI)
16:18:49 <pchampin> ... We have been discussing the "+" solution, because it allows a fallback.
16:19:04 <pchampin> ... But according to the RFC, only the final + matters for this fallback mechanism.
16:19:21 <pchampin> ... But we hope that implementations consider all + signs,
16:19:38 <pchampin> ... otherwise, application/did+ld+json would fallback directly to JSON,
16:19:41 <pchampin> ... which is not ideal.
16:19:52 <azaroth> Profile parameter:  https://www.w3.org/TR/json-ld11/#iana-considerations
16:20:25 <bigbluehat> https://tools.ietf.org/html/rfc6906 -  The 'profile' Link Relation Type
16:20:25 <pchampin> ... I would suggest that application/jsonld be declared, as an "alias" to application/ld+json,
16:20:31 <azaroth> q?
16:20:42 <bigbluehat> https://tools.ietf.org/html/rfc7284 - The Profile URI Registry
16:20:48 <ivan> -> https://tools.ietf.org/html/rfc6838#section-4.2.8 reference to the '+' descriptions
16:20:54 <azaroth> ack dlongley
16:20:54 <Zakim> dlongley, you wanted to mention the problem with using profile vs. did-ld+json, did+ld+json, etc.
16:20:55 <pchampin> ... i.e. having the same file extension.
16:21:43 <dlongley> https://www.npmjs.com/package/mime
16:21:45 <pchampin> dlongley: the JSON-LD should advertise the possibility to associate file extensions to profiles,
16:21:50 <azaroth> Profile URI registry:  https://www.iana.org/assignments/profile-uris/profile-uris.xhtml
16:22:01 <azaroth> q?
16:22:02 <azaroth> ack markus_sabadello
16:22:06 <pchampin> ... but the tooling is missing for properly working with the profile approach.
16:22:41 <pchampin> markus_sabadello: about the fragments,
16:22:48 <ivan> q?
16:22:52 <pchampin> ... the way we are using the fragments in DID should be compatible with the way they are used in JSON-LD,
16:23:01 <ivan> q+
16:23:21 <pchampin> ... so the fallback mentionned above should work to some extent.
16:23:39 <azaroth> ack ivan
16:23:53 <pchampin> ... A pure JSON-LD tool should be able to process the fragments in a DID document.
16:23:53 <dlongley> +1 we absolutely want it to process the fragment the same way
16:23:56 <bigbluehat> q+
16:24:11 <pchampin> ivan: I don't think the fragment ID is defined for the JSON format, neither for JSON-LD.
16:24:13 <azaroth> q+ to ask which options require json-ld normative change
16:24:19 <azaroth> ack bigbluehat
16:24:31 <pchampin> gkellogg: I think we say they have the same semantics as in RDF.
16:24:44 <gkellogg> Fragment identifiers used with application/ld+json are treated as in RDF syntaxes, as per RDF 1.1 Concepts and Abstract Syntax [RDF11-CONCEPTS].
16:24:51 <pchampin> bigbluehat: JSON does not have fragment identifiers.
16:26:03 <ivan> q+
16:26:06 <pchampin> gkellogg: is there inheritability of fragment identifiers across media-types?
16:26:25 <azaroth> ack azaroth
16:26:25 <Zakim> azaroth, you wanted to ask which options require json-ld normative change
16:26:25 <pchampin> ... It would be logical.
16:26:51 <pchampin> azaroth: as TallTed pointed out, there is some time pressure.
16:27:08 <TallTed> application/did-ld+json would need to echo much of application/ld+json
16:27:08 <TallTed> application/did+ld+json could inherit *if* MIME RFC made *all* + important
16:27:08 <pchampin> ... We are close to recommendation.
16:27:08 <TallTed> application/did+jsonld would inherit/fallback to application/jsonld
16:27:35 <pchampin> ... Would some of the options require a normative change in JSON-LD?
16:27:56 <pchampin> ... Consensus seems to be that we should say, in the IANA section,
16:28:13 <pchampin> ... that profile IRIs can be associated to new file extensions.
16:29:32 <pchampin> ... did[+-]ld+json would not require any change.
16:29:48 <pchampin> ... did+jsonld would require a change.
16:29:52 <dlongley> could the application/ld+json registration possibly talk about additional '+'s? or would that be too out of scope?
16:30:09 <dlongley> q+
16:30:11 <azaroth> q?
16:30:13 <azaroth> ack ivan
16:30:26 <pchampin> ... Let's focus on the options requiring some change.
16:30:52 <pchampin> ivan: the registration of did+ld+json only concerns the DID WG, won't affect the JSON-LD WG.
16:30:55 <TallTed> bigbluehat 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
16:31:11 <TallTed> s/bigbluehat//
16:31:21 <pchampin> ... re: did-ld+json, my improession is that this mime-type would be considered independant from ld+json
16:31:41 <pchampin> s/improession/impression/
16:32:13 <pchampin> ... The reason why it came up, if I'm correct, was to define the semantics of fragment identifiers.
16:32:31 <pchampin> ... We just pointed out that JSON-LD does define a semantics for fragment identifiers.
16:32:41 <azaroth> q?
16:32:45 <azaroth> ack dlongley
16:32:58 <pchampin> ... Is DID compatible with it? If not, then it should not be a subtype of ld+json,
16:33:02 <markus_sabadello> +1, in DID documents we want to use standard JSON-LD fragment behavior
16:33:09 <pchampin> ... regardless of the possibility for IANA.
16:33:25 <pchampin> dlongley: for me, they should be compatible, and I think this is the opinion of the DID WG.
16:33:34 <azaroth> q+
16:33:41 <azaroth> ack azaroth
16:34:13 <pchampin> ... I wonder if we could not just mention in the IANA declaration, that +ld+json should be considered a subtype of ld+json,
16:34:34 <pchampin> ... even despite what the RFC says about the final +.
16:34:52 <pchampin> azaroth: We can ask IANA what they would think about that if we did that.
16:35:16 <markus_sabadello> q+
16:35:17 <pchampin> TallTed: concerned about timing
16:35:21 <azaroth> ack markus_sabadello
16:35:46 <pchampin> markus_sabadello: I agree with Dave about the standard fragment semantics.
16:36:26 <TallTed> q+ to raise the question of what else is different between proposed/considered did+ld+json and ld+json -- is the only reason for the new Media Type the fragment semantics?
16:37:01 <pchampin> azaroth: dlongley, you mentioned problems with the tooling for the profile approach.
16:37:41 <pchampin> ... can tools be updated more quickly than specs?
16:38:04 <pchampin> dlongley: I'm not sure they can.
16:38:14 <pchampin> ... There are many toolchains out there...
16:38:15 <azaroth> ack TallTed
16:38:15 <Zakim> TallTed, you wanted to raise the question of what else is different between proposed/considered did+ld+json and ld+json -- is the only reason for the new Media Type the fragment
16:38:18 <Zakim> ... semantics?
16:38:55 <pchampin> TallTed: if the only concern is the fragment semantics,
16:38:56 <dlongley> q+
16:39:01 <pchampin> ... and they appear to be in synchrony,
16:39:03 <azaroth> ack dlongley
16:39:09 <pchampin> ... do we need a DID media-type in the 1st place?
16:39:29 <pchampin> dlongley: we also want a file extension.
16:39:51 <ivan> q+
16:40:02 <pchampin> TallTed: multiple file extensions can be associated with a single media-type.
16:40:23 <ivan> q-
16:40:24 <pchampin> ... Why not associate the .did extension to application/ld+json?
16:40:26 <bigbluehat> q+
16:40:41 <dlongley> q+ to say the tools would do inconsistent things
16:40:52 <pchampin> azaroth: this would be a bad precedent
16:41:06 <azaroth> ack bigbluehat
16:41:09 <pchampin> TallTed: there are lot of things out there, sharing the same media-type,
16:41:16 <pchampin> ... with very different contents.
16:41:17 <dlongley> q-
16:42:34 <pchampin> bigbluehat: I'm assuming you want a file extension so that desktop apps do the right thing (double click)./
16:42:59 <markus_sabadello> q+
16:43:09 <pchampin> ... Most application do not trust only the extension, and check the content once opened.
16:43:23 <azaroth> q+ to suggest profile registration of file extension bubble up to ld+json
16:43:25 <ivan> q+
16:43:38 <azaroth> ack markus_sabadello
16:43:41 <pchampin> ... We could register several extensions with application/ld+json, applications should still check the content.
16:43:50 <pchampin> ... The same problem exists with JSON.
16:44:22 <pchampin> markus_sabadello: we also want to be able to do content negociation
16:44:35 <pchampin> q+
16:44:38 <azaroth> ack azaroth
16:44:38 <Zakim> azaroth, you wanted to suggest profile registration of file extension bubble up to ld+json
16:44:41 <pchampin> q-
16:45:02 <pchampin> ... we want to be able to distinguish btw a DID document and another JSON-LD document.
16:45:24 <pchampin> azaroth: can we update the IANA section, saying that
16:45:33 <pchampin> ... when a file extension is associated with a profile,
16:45:46 <ivan> q+
16:45:59 <azaroth> q?
16:46:09 <azaroth> ack ivan
16:47:12 <dlongley> +1 to ivan
16:47:16 <bigbluehat> +1 to ivan
16:47:18 <gkellogg> +1 to ivan
16:47:33 <azaroth> 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.
16:47:40 <pchampin> ivan: this discussion started with the question about multiple +. Shouldn't we go back to checking this? If we can, this is the simplest solution.
16:48:19 <TallTed> did+ld+json conforms to RFC. but tools will probably fall back to json, not to ld+json. which may be OK.
16:48:19 <azaroth> q?
16:48:20 <markus_sabadello> but my understanding is that did+ld+json would NOT automatically inherit from ld+json
16:48:34 <pchampin> ... Let's check with Heather. If the answer is no, then we can look for another solution.
16:49:06 <pchampin> azaroth: the RFC says that only the last + is relevant.
16:49:15 <bigbluehat> q+
16:49:21 <pchampin> ... I agree that we should check. I'm affraid the answer is no.
16:49:44 <pchampin> ivan: Let's ask, and prepare a fallback plan.
16:49:46 <azaroth> ack bigbluehat
16:49:56 <pchampin> azaroth: I think the fallback should be profile.
16:50:30 <pchampin> bigbluehat: the did+ld+json IANA declaration could explicitly state that it inherits ld+json.
16:51:15 <azaroth> PROPOSAL: 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.
16:51:29 <gkellogg> +1
16:51:32 <dlongley> +1
16:51:32 <azaroth> +1
16:51:34 <pchampin> +1
16:51:34 <ivan> +1
16:51:36 <bigbluehat> +1
16:51:36 <dlehn> +1
16:51:43 <TallTed> +1
16:51:48 <TallTed> 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.
16:52:01 <TallTed> this should require less retooling than reliance on profile -- which doesn't work anywhere yet
16:52:30 <dlongley> q+ i think we just do did+ld+json regardless
16:52:35 <dlongley> q+ to agree... i think we just do did+ld+json regardless
16:53:00 <azaroth> RESOLVED: 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.
16:53:03 <azaroth> ack dlongley
16:53:03 <Zakim> dlongley, you wanted to agree... i think we just do did+ld+json regardless
16:53:08 <pchampin> markus_sabadello: if the answer is no in general, we can decide later if we go for the profile pattern, or something else...
16:53:17 <TallTed> s/which doesn't work anywhere yet/which currently only works in conneg/
16:53:28 <markus_sabadello> +1 to above proposal, but fallback could still be either profile, or did+ld+json
16:53:34 <azaroth> ACTION: azaroth to contact IETF about the multiple pluses in the JSON-LD registration
16:53:35 <bigbluehat> q+
16:53:55 <azaroth> ack bigbluehat
16:54:00 <bigbluehat> https://tools.ietf.org/html/rfc7231#section-5.3.2
16:54:14 <pchampin> dlongley: 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
16:54:46 <pchampin> bigbluehat: we should check JS libraries, see how they handle this
16:54:50 <azaroth> q?
16:54:52 <TallTed> JSON-LD WG could suggest that unrecognized /...+ld+json be treatable as /ld+json
16:55:02 <TallTed> (this could be non-normative at this point)
16:55:05 <dlongley> +1 to TallTed
16:55:09 <bigbluehat> +1 to TallTed
16:55:12 <markus_sabadello> +1 to TallTed
16:56:16 <pchampin> azaroth: re. TallTed suggestion, it boils down to what IETF thinks of that pattern
16:56:49 <pchampin> TallTed: even if they disagree about it in general, we can still recommend it for JSON-LD
16:56:55 <pchampin> q+
16:57:01 <azaroth> ack pchampin
16:57:47 <gkellogg> +1 to pchampin
16:57:49 <markus_sabadello> +1 to pchampin
16:57:52 <dlongley> +1
16:58:21 <pchampin> ... We could recommend that JSON-LD processors process application/*+ld+json
16:58:31 <azaroth> PROPOSAL: In IANA considerations, allow file extension registration with profile registration.
16:58:33 <azaroth> +1
16:58:38 <pchampin> +1
16:58:39 <gkellogg> +1
16:58:41 <dlongley> +1
16:58:42 <markus_sabadello> +1
16:58:48 <ivan> +1
16:58:53 <azaroth> RESOLVED: In IANA considerations, allow file extension registration with profile registration.
16:59:23 <azaroth> PROPOSAL: Conforming json-ld processors SHOULD treat *+ld+json in the same way as the application/ld+json media type
16:59:27 <dlongley> +1
16:59:29 <markus_sabadello> +1
16:59:30 <gkellogg> +1
16:59:30 <azaroth> +1
16:59:31 <pchampin> +1
16:59:33 <ivan> +1
16:59:34 <TallTed> +1
16:59:58 <azaroth> RESOLVED: Conforming json-ld processors SHOULD treat *+ld+json in the same way as the application/ld+json media type
17:00:38 <bigbluehat> +1
17:01:08 <pchampin> azaroth: I hope we get a response from IETF for next week.
17:01:08 <dlongley> +1 this works regardless
17:01:16 <azaroth> q?
17:01:18 <bigbluehat> +1
17:01:28 <pchampin> ivan: anyway, we can put in the document what we have resolved, regardless.
17:01:47 <markus_sabadello> thank you all for taking the time today!
17:02:17 <azaroth> TOPIC: Adjourn
17:02:48 <ivan> rrsagent, draft minutes
17:02:48 <RRSAgent> I have made the request to generate https://www.w3.org/2019/11/01-json-ld-minutes.html ivan
17:02:48 <ivan> zakim, bye
17:02:48 <ivan> rrsagent, bye
17:02:48 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2019/11/01-json-ld-actions.rdf :
17:02:48 <RRSAgent> ACTION: azaroth to contact IETF about the multiple pluses in the JSON-LD registration [1]
17:02:48 <RRSAgent>   recorded in https://www.w3.org/2019/11/01-json-ld-irc#T16-53-34
17:02:48 <Zakim> leaving.  As of this point the attendees have been rsanderson, azaroth, ivan, pchampin, dlongley, markus_sabadello, gkellogg, bigbluehat, dlehn
17:02:48 <Zakim> Zakim has left #json-ld