16:17:33 <RRSAgent> RRSAgent has joined #json-ld
16:17:33 <RRSAgent> logging to https://www.w3.org/2019/01/11-json-ld-irc
16:17:34 <ivan> rrsagent, set log public
16:17:34 <ivan> Meeting: JSON-LD Working Group Telco
16:17:34 <ivan> Chair: bigbluehat
16:17:34 <ivan> Date: 2019-01-11
16:17:34 <ivan> Regrets+ ajs6f
16:17:34 <ivan> Agenda: [https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0003.html](https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0001.html)
16:17:35 <ivan> ivan has changed the topic to: Meeting Agenda 2019-01-11: [https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0003.html](https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0001.html)
16:28:47 <pchampin> pchampin has joined #json-ld
16:30:51 <azaroth> azaroth has joined #json-ld
16:52:51 <gkellogg> gkellogg has joined #json-ld
16:58:00 <azaroth> regrets+ workergnome
16:58:10 <azaroth> regrets+ adam_soroka
16:58:52 <simonstey> simonstey has joined #json-ld
16:59:48 <ivan> present+
17:00:02 <azaroth> present+ Rob_Sanderson
17:00:26 <gkellogg> present+ Gregg_Kellogg
17:00:28 <pchampin> present+
17:00:48 <simonstey> present+
17:01:01 <gkellogg> zakim: who’s here?
17:01:14 <simonstey> Zakim, who's here?
17:01:14 <Zakim> Present: ivan, Rob_Sanderson, Gregg_Kellogg, pchampin, simonstey
17:01:16 <Zakim> On IRC I see simonstey, gkellogg, azaroth, pchampin, RRSAgent, Zakim, ivan, dlehn, dlongley, bigbluehat, ChristopherA, fr33domlover
17:01:30 <azaroth> regrets+ jeff_mixter
17:02:01 <bigbluehat> present+
17:02:23 <bigbluehat> bigbluehat has changed the topic to: Meeting Agenda 2019-01-11: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0003.html
17:04:15 <bigbluehat> Topic: scribe selection
17:04:35 <bigbluehat> scribenick: pchampin
17:04:45 <bigbluehat> Topic: Approve minutes
17:04:46 <bigbluehat> https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-01-04-json-ld
17:04:52 <bigbluehat> +1
17:04:58 <gkellogg> +1
17:05:03 <bigbluehat> PROPOSAL: approve minutes
17:05:05 <ivan> +1
17:05:12 <simonstey> +1
17:05:15 <azaroth> +0 (absent)
17:05:15 <pchampin> +1
17:05:18 <bigbluehat> +1
17:05:24 <bigbluehat> RESOLVED: approve minutes
17:05:53 <bigbluehat> Topic: Announcements / Reminders
17:06:03 <bigbluehat> Subtopic: 2019 Winter Face-to-Face - February 7-8 in Washington, DC
17:06:09 <pchampin> azaroth: thanks to adam and benjamin for excellent scribing last week
17:07:21 <pchampin> azaroth: regarding the upcoming F2F in Washington DC, and the admin shutdown in the US,
17:07:50 <pchampin> ... since people already have their travel booked,
17:08:05 <pchampin> ... I reached out to 4 people for an alternative location.
17:08:45 <pchampin> ... One option is the Folger Shakespeare library, near the library of Congress.
17:09:01 <pchampin> ... The other option is XXX
17:09:18 <gkellogg> s/XXX/Coalition for Networked Information/
17:09:19 <azaroth> s/XXX/Coalition for Networked Information/
17:09:46 <azaroth> https://www.google.com/maps/place/Dupont+Circle,+Washington,+DC+20036/@38.901612,-77.0447075,15z/data=!4m5!3m4!1s0x89b7b7c7b54fb65b:0xa016e28f09dff7d2!8m2!3d38.9095778!4d-77.0434415
17:10:09 <pchampin> ... A little further away from the Smithonian than Folger.
17:10:43 <azaroth> https://www.google.com/maps/place/Folger+Shakespeare+Library/@38.8907816,-77.0137334,16z/data=!4m13!1m7!3m6!1s0x89b7b7c7b54fb65b:0xa016e28f09dff7d2!2sDupont+Circle,+Washington,+DC+20036!3b1!8m2!3d38.9095778!4d-77.0434415!3m4!1s0x89b7b82ee3c52dcd:0x71e5b5ff42284ef4!8m2!3d38.8892959!4d-77.0027554
17:10:45 <pchampin> ivan: are both of them easy to get to via public transport or foot?
17:11:01 <pchampin> azaroth: yes
17:11:42 <pchampin> ivan: then, Rob, you are in the best position to make the decision.
17:12:16 <pchampin> azaroth: Folger is closer to the Smithonian. Dupont Circle probably is 30' walk.
17:12:25 <pchampin> ... So I'd suggest the Folger.
17:13:05 <pchampin> gkellogg: what if the gov shutdown is resolved by then?
17:13:19 <azaroth> Adam said: " I strongly urge you to accept one of the generous offers from other institutions of cultural heritage in D.C. to host the February face-to-face. "
17:13:26 <pchampin> ivan: I think Adam suggested that we go the secure way.
17:13:29 <azaroth> (in an email to Benjamin, me and Ivan)
17:14:01 <bigbluehat> PROPOSAL: move F2F location to Folger due to US government shutdown
17:14:02 <pchampin> ... The Folger does us a real favor. It would not be good to accept and then decline.
17:14:08 <azaroth> +1
17:15:05 <ivan> +1
17:15:07 <bigbluehat> +1
17:15:10 <gkellogg> +1
17:15:10 <pchampin> +0 (won't attend)
17:15:12 <simonstey> +0
17:15:55 <pchampin> ivan: for people that will not attend, will there be a possibility to dial in,
17:16:01 <pchampin> ... or are we on our own?
17:16:52 <pchampin> azaroth: if only a few people are to dial in, we can make do with the local wifi.
17:17:08 <pchampin> ... I can ask the Folder if we can have a dedicated laptop for dial in.
17:17:12 <bigbluehat> RESOLVED: move F2F location to Folger due to US government shutdown
17:17:18 <gkellogg> s/Folder/Folger/
17:17:53 <dlehn> present+
17:18:19 <bigbluehat> Topic: Issues
17:18:23 <pchampin> azaroth: we are not totally off the hook until the Folger confirms. That should be on Monday.
17:18:26 <bigbluehat> Subtopic: HTTP parameters for specifying context or frame (round 2!)
17:18:35 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/8
17:18:58 <bigbluehat>      syntax - https://github.com/w3c/json-ld-syntax/pull/111 (open)
17:18:58 <bigbluehat>      framing - https://github.com/w3c/json-ld-framing/pull/34 (merged)
17:18:58 <bigbluehat>      api - https://github.com/w3c/json-ld-api/pull/56 (ready for review)
17:19:51 <pchampin> bigbluehat: the framing PR is already merged -- mostly clerical, regarding IANA registration.
17:20:36 <pchampin> gkellogg: the PR is about the possibility for a client to specify the contex with which it wishes the retrieved data to be processed.
17:21:14 <pchampin> ... Last week, we discussed this, and realized that dereferencing the value of the profile attribute is something that we don't want to do.
17:22:01 <pchampin> ... I had to rewrite this part. This information is now to be conveyed with a Link header.
17:22:12 <bigbluehat> q+
17:22:18 <azaroth> q+
17:22:20 <bigbluehat> ack bigbluehat
17:22:25 <pchampin> ... A consequence is that the context URL can no more be used for content negociation.
17:23:14 <bigbluehat> ack azaroth
17:23:55 <pchampin> azaroth: my understanding about the move away from the profile parameter is about the dereferenceability?
17:24:10 <bigbluehat> q+
17:24:35 <pchampin> gkellogg: not exactly. The RFC indicates that the URI used as profile parameter can be derefenceable, for documentation.
17:24:47 <pchampin> ... But the execution should not be determined by derefencing it.
17:25:27 <pchampin> azaroth: Why not simply specify that, if a server receives a profile URI that it does not know,
17:25:29 <bigbluehat> ack bigbluehat
17:25:35 <pchampin> ... it just answers with 406?
17:25:54 <gkellogg> q+
17:26:26 <pchampin> ... We should not specify *how* the server does the serialization.
17:26:46 <pchampin> ... That's implementation detail, not specification.
17:27:02 <pchampin> ... Given that, I don't think there is any expectation that the server should dereference;
17:27:18 <pchampin> ... but it may do that if it thinks that's a good thing.
17:28:00 <azaroth> q?
17:28:57 <pchampin> bigbluehat: the spec last week was explicitly specifying that the profile parameter should be dereferenced.
17:29:06 <bigbluehat> ack gkellogg
17:29:19 <pchampin> ... Going away from this lead us away from the profile parameter all together.
17:29:23 <azaroth> q+ to also note we can't *prevent* it, as it's valid in the Accept header
17:29:24 <pchampin> ... But I see where you are going.
17:30:14 <pchampin> gkellogg: We should have both mechanisms: one to query a well known profile,
17:30:57 <pchampin> ... and one to provide a previously unknown context, to be processed by the server.
17:31:24 <bigbluehat> ack azaroth
17:31:24 <Zakim> azaroth, you wanted to also note we can't *prevent* it, as it's valid in the Accept header
17:32:03 <pchampin> azaroth: we can't prevent the profile from the accept header; it is part of the media-type.
17:32:23 <bigbluehat> q+ to ask if Link header usage needs its own issue
17:32:29 <pchampin> ... We should embrace what people are going to do anyway,
17:32:45 <pchampin> ... which is a profile parameter in the accept header.
17:35:50 <pchampin> bigbluehat: I'm concerned we are defining a server API for JSON-LD, which is not what we are meant to do.
17:35:52 <azaroth> +1 to bigbluehat to steer away from JSON-LD-REST
17:36:13 <azaroth> (not because it's a bad thing, but because we're not chartered to do that!)
17:36:26 <pchampin> ... We should provide a list of profile URI that we recommend.
17:36:35 <bigbluehat> q?
17:36:37 <bigbluehat> q-
17:36:44 <pchampin> ... Whatever else people use as profile URIs is their business.
17:37:07 <gkellogg> q+
17:37:25 <pchampin> ... The Links header is more an API spec, which would be LDP2's job, not ours...
17:37:26 <bigbluehat> ack gkellogg
17:37:52 <pchampin> gkellogg: there was always a problem for the profile parameter for, e.g., compacted
17:38:45 <pchampin> ... there was no way to convey the context against which compaction was done [not sure I got it right]
17:39:02 <bigbluehat> q+
17:39:04 <bigbluehat> ack bigbluehat
17:39:10 <pchampin> ... This has been long discussed in the CG.
17:39:18 <pchampin> ... The Link header was a way to address that.
17:39:59 <pchampin> bigbluehat: Is this purely an IANA registration and suggesting good practices?
17:40:12 <pchampin> ... I fear that too much HTTP matter in the spec and/or the test,
17:40:14 <gkellogg> q+
17:40:21 <bigbluehat> ack gkellogg
17:40:25 <pchampin> ... will feel that a MUST or a SHOULD for any JSON-LD implementation.
17:41:20 <pchampin> gkellogg: that's a way to ensure that people using it know how to use it.
17:42:13 <pchampin> ... The bit about the Link header could go in a different (REST?) spec or a best practives doc.
17:42:38 <azaroth> +1 to best practices tests
17:42:50 <pchampin> s/will feel that/will feel like/
17:43:22 <pchampin> ... We should remove any normative discussion about the Link header,
17:44:01 <pchampin> ... and replace it with a more vague mention to "header fields, to be described elsewhere".
17:44:04 <bigbluehat> PROPOSAL: remove normative discussion of use of Link header usage for response augmentation--move to best practice for now
17:44:14 <ivan> +1
17:44:14 <azaroth> +1
17:44:15 <gkellogg> +1
17:44:16 <bigbluehat> +1
17:44:17 <pchampin> ... And move the current test elsewhere, probably a new spec.
17:44:17 <simonstey> +1
17:44:23 <pchampin> +1
17:44:45 <bigbluehat> RESOLVED: remove normative discussion of use of Link header usage for response augmentation--move to best practice for now
17:45:50 <pchampin> gkellogg: Do we want to create new spec for server behaviour, or a best practices document?
17:46:09 <pchampin> ... And then should we create a different repository?
17:46:29 <pchampin> ivan: I prefer many small repos, but I know not everyone agrees.
17:46:54 <pchampin> ... Wherever the editors feel it more confortable.
17:47:17 <pchampin> ... Should we close the issue?
17:47:27 <pchampin> gkellogg: I still have a few changes to make.
17:47:36 <pchampin> ... After a small period for people to concur,
17:47:57 <pchampin> ... I'll merge the changes.
17:48:07 <pchampin> ivan: and then close the issue at the same time.
17:49:03 <bigbluehat> Topic: Allow relative IRIs for @vocab
17:49:11 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/72
17:49:50 <bigbluehat>      syntax - https://github.com/w3c/json-ld-syntax/pull/114
17:49:50 <bigbluehat>      api - https://github.com/w3c/json-ld-api/pull/58
17:50:33 <pchampin> gkellogg: when we decided to satisfy the need for using the base as the @vocab,
17:50:48 <pchampin> ... I came up with the idea of using an empty string as @vocab.
17:51:16 <pchampin> ... When I implemented it, what I ended up doing was resolve @vocab as a relative URI against the base.
17:51:38 <pchampin> ... So why not allow that in the spec...
17:51:47 <ivan> ship it! :-)
17:52:06 <pchampin> ... It is uncontrersial, as it does not change past behaviour.
17:52:38 <pchampin> ... Now you can simply use @vocab: "#", to use relative URIs everywhere.
17:53:03 <azaroth>  --> https://github.com/w3c/json-ld-syntax/issues/72#issuecomment-433597475
17:53:28 <pchampin> azaroth: is this the issue we discussed this during TPAC?
17:55:22 <azaroth> Rob Sanderson: if you set vocab to ../# and you had example.org/ns then you get example.org/ns../#
17:56:07 <pchampin> gkellogg: I have to improve the text to indicate when standard URI resolution is used, and when string concatenation is used
17:56:33 <bigbluehat> PROPOSAL: address security concerns related to relative URIs for @vocab in current PRs before closing #72
17:56:37 <ivan> +1
17:56:39 <bigbluehat> +1
17:56:41 <pchampin> ivan: please close issue 72 when you clarify that and merge it.
17:56:42 <gkellogg> +1
17:56:45 <azaroth> +1
17:56:51 <pchampin> ... Let's reduce the number of open issue
17:56:55 <pchampin> +1
17:57:00 <dlehn> +1
17:57:04 <bigbluehat> RESOLVED: address security concerns related to relative URIs for @vocab in current PRs before closing #72
17:57:18 <simonstey> +1
17:57:25 <bigbluehat> Subtopic: HTML baseURI and @context?
17:57:26 <bigbluehat> https://github.com/w3c/json-ld-api/issues/53
17:57:44 <ivan> q+
17:57:50 <bigbluehat> ack ivan
17:58:20 <pchampin> ivan: we should discuss which are the major issues we want to put on the agenda for the next F2F.
17:58:42 <gkellogg> Move issues into Discuss-F2F in the JSON-LD Management project
17:59:05 <pchampin> ... From the top of my head, there are the issues raised by danbri that we started discussing in Lyon.
18:00:42 <ivan> rrsagent, draft minutes
18:00:42 <RRSAgent> I have made the request to generate https://www.w3.org/2019/01/11-json-ld-minutes.html ivan