JSON-LD Working Group Telco — Minutes
Date: 2019-01-11
See also the Agenda and the IRC Log
Attendees
Present: Ivan Herman, Rob Sanderson, Gregg Kellogg, Pierre-Antoine Champin, Simon Steyskal, Benjamin Young, David I. Lehn
Regrets: Adam Soroka, David Newbury, Jeff Mixter
Guests:
Chair: Benjamin Young
Scribe(s): Pierre-Antoine Champin
Content:
- 1. Approve minutes
- 2. 2019 Winter Face-to-Face - February 7-8 in Washington, DC
- 3. Issues
- 4. Misc.
- 5. Resolutions
1. Approve minutes
Benjamin Young: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-01-04-json-ld
Benjamin Young: +1
Gregg Kellogg: +1
Proposed resolution: approve last week’s minutes (Benjamin Young)
Ivan Herman: +1
Simon Steyskal: +1
Rob Sanderson: +0 (absent)
Pierre-Antoine Champin: +1
Benjamin Young: +1
Resolution #1: approve last week’s minutes
Rob Sanderson: thanks to adam and benjamin for excellent scribing last week
2. 2019 Winter Face-to-Face - February 7-8 in Washington, DC
Rob Sanderson: regarding the upcoming F2F in Washington DC, and the admin shutdown in the US,
… since people already have their travel booked,
… I reached out to 4 people for an alternative location.
… One option is the Folger Shakespeare library, near the library of Congress.
… The other option is oalition for Networked Information
… A little further away from the Smithonian than Folger.
Ivan Herman: are both of them easy to get to via public transport or foot?
Rob Sanderson: yes
Ivan Herman: then, Rob, you are in the best position to make the decision.
Rob Sanderson: Folger is closer to the Smithonian. Dupont Circle probably is 30’ walk.
… So I’d suggest the Folger.
Gregg Kellogg: what if the gov shutdown is resolved by then?
Ivan Herman: I think Adam suggested that we go the secure way.
Rob Sanderson: 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.”
Rob Sanderson: (in an email to Benjamin, me and Ivan)
Proposed resolution: move F2F location to Folger due to US government shutdown (Benjamin Young)
Ivan Herman: The Folger does us a real favor. It would not be good to accept and then decline the others.
Rob Sanderson: +1
Ivan Herman: +1
Benjamin Young: +1
Gregg Kellogg: +1
Pierre-Antoine Champin: +0 (won’t attend)
Simon Steyskal: +0
Ivan Herman: for people that will not attend, will there be a possibility to dial in,
… or are we on our own?
Rob Sanderson: if only a few people are to dial in, we can make do with the local wifi.
… I can ask the Folger if we can have a dedicated laptop for dial in.
Resolution #2: move F2F location to Folger due to US government shutdown
Rob Sanderson: we are not totally off the hook until the Folger confirms. That should be on Monday.
3. Issues
3.1. HTTP parameters for specifying context or frame (round 2!)
Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/8
- syntax - https://github.com/w3c/json-ld-syntax/pull/111 (open)
- framing - https://github.com/w3c/json-ld-framing/pull/34 (merged)
- api - https://github.com/w3c/json-ld-api/pull/56 (ready for review)
Benjamin Young: the framing PR is already merged — mostly clerical, regarding IANA registration.
Gregg Kellogg: the PR is about the possibility for a client to specify the contex with which it wishes the retrieved data to be processed.
… Last week, we discussed this, and realized that dereferencing the value of the profile attribute is something that we don’t want to do.
… I had to rewrite this part. This information is now to be conveyed with a Link header.
… A consequence is that the context URL can no more be used for content negotiation.
Rob Sanderson: my understanding about the move away from the profile parameter is about the dereferencability?
Gregg Kellogg: not exactly. The RFC indicates that the URI used as profile parameter can be dereferencable, for documentation.
… But the execution should not be determined by derefencing it.
Rob Sanderson: Why not simply specify that, if a server receives a profile URI that it does not know,
… it just answers with 406?
… We should not specify how the server does the serialization.
… That’s implementation detail, not specification.
… Given that, I don’t think there is any expectation that the server should dereference;
… but it may do that if it thinks that’s a good thing.
Benjamin Young: the spec last week was explicitly specifying that the profile parameter should be dereferenced.
… Going away from this lead us away from the profile parameter all together.
… But I see where you are going.
Gregg Kellogg: We should have both mechanisms: one to query a well known profile,
… and one to provide a previously unknown context, to be processed by the server.
Rob Sanderson: we can’t prevent the profile from the accept header; it is part of the media-type.
… We should embrace what people are going to do anyway,
… which is a profile parameter in the accept header.
Benjamin Young: I’m concerned we are defining a server API for JSON-LD, which is not what we are meant to do.
Rob Sanderson: +1 to bigbluehat to steer away from JSON-LD-REST
Rob Sanderson: (not because it’s a bad thing, but because we’re not chartered to do that!)
Benjamin Young: We should provide a list of profile URI that we recommend.
… Whatever else people use as profile URIs is their business.
… The Links header is more an API spec, which would be LDP2’s job, not ours…
Gregg Kellogg: there was always a problem for the profile parameter for, e.g., compacted
… there was no way to convey the context against which compaction was done [not sure I got it right]
… This has been long discussed in the CG.
… The Link header was a way to address that.
Benjamin Young: Is this purely an IANA registration and suggesting good practices?
… I fear that too much HTTP matter in the spec and/or the test,
… will feel like a MUST or a SHOULD for any JSON-LD implementation.
Gregg Kellogg: that’s a way to ensure that people using it know how to use it.
… The bit about the Link header could go in a different (REST?) spec or a best practices doc.
Rob Sanderson: +1 to best practices tests
Gregg Kellogg: We should remove any normative discussion about the Link header,
… and replace it with a more vague mention to “header fields, to be described elsewhere”.
… And move the current test elsewhere, probably a new spec.
Proposed resolution: remove normative discussion of use of Link header usage for response augmentation–move to best practice for now (Benjamin Young)
Ivan Herman: +1
Rob Sanderson: +1
Gregg Kellogg: +1
Benjamin Young: +1
Simon Steyskal: +1
Pierre-Antoine Champin: +1
Resolution #3: remove normative discussion of use of Link header usage for response augmentation–move to best practice for now
Gregg Kellogg: Do we want to create new spec for server behaviour, or a best practices document?
… And then should we create a different repository?
Ivan Herman: I prefer many small repos, but I know not everyone agrees.
… Wherever the editors feel it more conformable.
… Should we close the issue?
Gregg Kellogg: I still have a few changes to make.
… After a small period for people to concur,
… I’ll merge the changes.
Ivan Herman: and then close the issue at the same time.
3.2. Allow relative IRIs for @vocab
Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/72
Gregg Kellogg: when we decided to satisfy the need for using the base as the @vocab,
… I came up with the idea of using an empty string as @vocab.
… When I implemented it, what I ended up doing was resolve @vocab as a relative URI against the base.
… So why not allow that in the spec…
Ivan Herman: ship it! :-)
Gregg Kellogg: It is uncontroversial, as it does not change past behaviour.
… Now you can simply use @vocab: “#”, to use relative URIs everywhere.
Rob Sanderson: –> https://github.com/w3c/json-ld-syntax/issues/72#issuecomment-433597475
Rob Sanderson: is this the issue we discussed this during TPAC?
… if you set vocab to ../#
and you had example.org/ns
then you get example.org/ns../#
Gregg Kellogg: I have to improve the text to indicate when standard URI resolution is used, and when string concatenation is used
Proposed resolution: address security concerns related to relative URIs for @vocab in current PRs before closing #72 (Benjamin Young)
Ivan Herman: +1
Benjamin Young: +1
Ivan Herman: please close issue 72 when you clarify that and merge it.
Gregg Kellogg: +1
Rob Sanderson: +1
Ivan Herman: Let’s reduce the number of open issue
Pierre-Antoine Champin: +1
David I. Lehn: +1
Resolution #4: address security concerns related to relative URIs for @vocab in current PRs before closing #72
Simon Steyskal: +1
3.3. HTML baseURI and @context?
Benjamin Young: https://github.com/w3c/json-ld-api/issues/53
Benjamin Young: please look at this before our next call,
4. Misc.
Ivan Herman: we should discuss which are the major issues we want to put on the agenda for the next F2F.
… From the top of my head, there are the issues raised by danbri that we started discussing in Lyon.
Gregg Kellogg: Move issues into Discuss-F2F in the JSON-LD Management project
5. Resolutions
- Resolution #1: approve last week’s minutes
- Resolution #2: move F2F location to Folger due to US government shutdown
- Resolution #3: remove normative discussion of use of Link header usage for response augmentation–move to best practice for now
- Resolution #4: address security concerns related to relative URIs for @vocab in current PRs before closing #72