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

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.

Rob Sanderson: Folger: 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

Rob Sanderson: CNI: 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

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

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