JSON-LD Working Group Telco — Minutes

Date: 2019-07-19

See also the Agenda and the IRC Log

Attendees

Present: Gregg Kellogg, Adam Soroka, Pierre-Antoine Champin, Tim Cole, Dave Longley, Rob Sanderson, David I. Lehn, Harold Solbrig, Jeff Mixter

Regrets: Ivan Herman, David Newbury, Ruben Taelman, Benjamin Young

Guests:

Chair: Rob Sanderson

Scribe(s): Dave Longley, Rob Sanderson

Content:


Dave Longley: https://w3c.github.io/vc-data-model/#base-context

1. Scribe Selection

2. Approve minutes of previous call

Proposed resolution: Approve the minutes: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-07-12-json-ld (Rob Sanderson)

Rob Sanderson: +1

Gregg Kellogg: +1

Dave Longley: +1

Pierre-Antoine Champin: +1

Tim Cole: +1

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

3. Announcements / Reminders

Rob Sanderson: Weekly reminder to register for TPAC and book travel if you haven’t already. Any other announcements or reminders?

Dave Longley: https://w3c.github.io/vc-data-model/#base-context

Dave Longley: The VC model is going to PR shortly. This is short notice, but please do give feedback on it if you can
… either today or monday please
… send that to me, or to the WG. Quicker to send to me (dlongley) directly :)

Gregg Kellogg: Regarding that, you pointed to the appendix within the spec where you’ve put the context, which does limit your ability to change that later on.
… As we’ve seen sometimes they do need to be changed downstream – and the time…

Dave Longley: We need to lock everything in due to the way that the model and implementations work
… So any new context would require a new URL. We’re looking to lock it in for v1 credentials. Most people won’t actually process it, just by reading human readable spec

Rob Sanderson: We also did that in the Annotations WG which has been a little bit counterproductive at times but we did it for exactly the same reason that we wanted to lock everything down.
… Have the same pattern in other spaces as well, only for major versions though. The context will be backwards compatible for all of those changes, if it produces exactly the same output that’s fine.
… That has worked for us.

4. Privacy HR

ref: https://github.com/w3c/json-ld-wg/issues/88

Rob Sanderson: We have some feedback from PING.
… Would be good to discuss now and send the answers we get back to the group.
… Q1. I don’t see a point where the described API touches the Web API. How is this intended to be used by applications running in the browser?
… To me, the answer is that it’s just data and it’s intended to be loaded into browser apps rather than the browser directly. Is that a reasonable response or do we need to say more?

Gregg Kellogg: I’d say that’s right. There is no model currently how a JSON-LD script block is intended to interact with HTML and that would seem to be the responsibility of some other spec or possibly another group.

Rob Sanderson: Q2. What privacy relevant information is sent with calls to the documentLoader end point? Cookies or similar? If so, pulled from what origin (and single or double keyed), etc? In general more explanation of how this interacts with the browser is needed.
… They’d like more information about how the document loader interacts with the browser. This follows on from the first one, applications within the browser will use XmlHttpRequest [or fetch, etc.].
… They specifically ask about the document loader. Is there anything in particular that is different for document loaders compared to anything else?

Gregg Kellogg: There’s nothing sent along – there’s no cookies or anything like that, it’s an HTTP GET request. There’s HTTP headers, considerations for cross origin access, things like that that are outside of the scope of this. We only describe the behavior of a document loader – that there is such a thing that is used to fetch and could provide a hook for in browser implementations to do that.
… Most of the description of the document loader is what you do with the response.
… It does imply access to the returned HTTP headers, for example a link header.

Dave Longley: I was going to add that our spec doesn’t create any new headers or behaviors to implement, we provide an API that you can implement however you want. Can use fetch or XHR, and all the privacy implications of those
… it doesn’t let you do anything new, beyond what those APIs already do

Rob Sanderson: Q3. If this is intended to be implanted in browsers, have any vendors implemented it? Generally W3C prefers at least two independent implementations of functionality before standardizing / recommending.
… It could be implemented by browsers. Chrome could have a JSON-LD specific thing…

Dave Longley: Agree there’s no intention to be implemented, there’s nothing to prevent it
… Chrome has put it in lighthouse. THey’re using a JSON-LD processor which ships with the browser, but not otherwise aware of native code

Rob Sanderson: Given that there’s one browser implementation – is that going to cause given that there isn’t two?

Gregg Kellogg: I think they think we’re trying to do more than we are. We are just describing the format of a data block that can appear in HTML without describing its interactions or how you get that the contents of that data block. The action of a browser directly interacting with these blocks is outside the scope of our specification.
… The fact that vendors are experimenting with it – does not imply that we’re setting a bar that requires multiple implementations of that.
… There might be future specifications that talk about how JSON-LD interacts with the DOM or marks it up – we’re not trying to specify that.

Dave Longley: I think Gregg covered it :)

Pierre-Antoine Champin: To add something – I see the in browser implementation as a convenience as something different from an external JavaScript implementation.
… That comes back to what Gregg was saying, there’s no particular value other than convenience [or speed] to having it in the browser directly.
… There are other ways to use the API.

Rob Sanderson: Q4. How does the contextUrl interact with other URL / origin specific privacy features in the browser (same origin policy, CORS, etc?)
… As above, the answer is that it’s identical. The only way you get access to the context is via those already implemented and specified features in the browser.
… It interacts in exactly the same way as all other URLs.

Dave Longley: +1

Rob Sanderson: I will take an action to type up the notes as answers and put them into the issue and send them to PING.

Action #1: collate answers and send to PING (Rob Sanderson)

Rob Sanderson: And hopefully get a response that all the boxes are checked and carry on, but we’ll see.

5. Issues

5.1. Link header for HTML / JSON-LD

ref: https://github.com/w3c/json-ld-syntax/issues/204

Gregg Kellogg: This was brought up because we were anticipating possibly removing the ability of having a context embedded in HTML. And that being the case – speaking for what Google’s desires were here around content negotiation (looking for some other means).
… The link header support for JSON came to mind but in thinking about it it’s entirely different. In that case, there might be a link header with a context in our namespace that would give the location of the context file to load.
… That’s not something that helps you if you have JSON-LD that points to http://schema.org that points you to something else. Possibly rel-alternate might help.
… Really maybe the solution for them is to … I’m not sure what the solution is. In how link headers might be used to provide information to processors that are requesting context at a certain location to redirect them to another location using something other than content negotiation.

Dave Longley: Haven’t looked closely to see if there’s a good way to put it in, as conneg is the mechanism designed to do this
… there might be a way to put it in link header … very much like a redirect without a redirect!

Gregg Kellogg: I suspect that there’s too much inventing from whole cloth – and without Dan Brickley being here to champion this to have it go anywhere, if they truly care about it that much they’ll show up.

Rob Sanderson: One minor advantage would give us another way, via the meta head tag to put the equivalent into the HTML doc such that it could be relatively easily extracted by an HTML processor.
… If you didn’t have access to do conneg or didn’t like it and you needed to declare where to go then putting it in the headers might be tricky, but if you have a system that doesn’t let you do that you could put it into the DOM.
… That would be another minor advantage.

Pierre-Antoine Champin: If I understand Dan’s concern that they would like to lower the demand on the server by having static web pages. That’s a way of floating the burden of conneg to the client rather than the server. I think that’s a relatively straightforward and webby way to do it so why not?

Gregg Kellogg: Yeah, I think if we imagine what it would take to make something work on gh-pages… if we wanted w3c.github.io/foo to serve a context, how could we do that?
… If we put an HTML file in there right now … using a meta tag, I don’t know that appreciably solves the problem. If your concern is needing to parse the HTML and it’s easier to parse a meta tag than a script tag … I’m not sure that passes muster.

Dave Longley: +1 it doesn’t, it’s still a problem

Gregg Kellogg: I don’t think there’s anything short of what can be done short of looking in the HTML itself.

Proposed resolution: Invite danbri representing schema.org to a call to discuss the proposed solution, and if he agrees it would be useful, accept the issue (Rob Sanderson)

Rob Sanderson: How about we invite Dan to the call and if he shows up and thinks it would be useful we can accept it, otherwise we close it.

Gregg Kellogg: +1

Rob Sanderson: +1

Jeff Mixter: +1

Tim Cole: +1

Harold Solbrig: +1

Pierre-Antoine Champin: +1

Dave Longley: +1 provided that JSON-LD processors don’t have to look at HTML, only headers

Resolution #2: Invite danbri representing schema.org to a call to discuss the proposed solution, and if he agrees it would be useful, accept the issue

Gregg Kellogg: If you were attempting to retrieve a context file and you see that header that processors must use the URL that’s provided in there instead of the resource that is returned, unless that resource is itself application/ld+json or something along those lines.
… That doesn’t solve a gh-pages scenario but it probably provides sufficient support for other static sites that can influence their HTTP headers.

Action #2: invite dan to a call (Rob Sanderson)

5.2. more compact @prefix

ref: https://github.com/w3c/json-ld-api/issues/76

Rob Sanderson: We discussed this back in May/June and we didn’t come back to it.

David I. Lehn: I had a comment in there, I don’t know if I was mixing this in with this other topic – but if we wanted as another feature of the @prefix to scope terms to a certain context so it doesn’t escape out.

Rob Sanderson: Maybe?

David I. Lehn: It seems like a feature that might fit in.

Dave Longley: Part of what I was going to say refers to what dlehn said … there’s different ways to scope the prefix. I think we should consider that, but don’t remember exactly where we were
… it should / should not escape the context, and the inbetween state where you want to use it, but it shouldn’t escape to the data
… it feels like it fits in with the idea that when defining a prefix you say where it applies

Gregg Kellogg: I guess there’s two different issues going on here. For what was originally described, this was syntactic sugar, it doesn’t provide any new functionality. But it does provide complexity. As such, I don’t think we should do this.
… Adding complexity for important new functionality is fine, but out of some sense of simplicity that isn’t really simplicity, particularly when it comes to a context file vs. the data, it doesn’t hit the bar.
… In terms of scope, certainly if you define a term with a scoped context that adds a prefix it would be used, but @prefix: true means is … is that term available for use when compacting.
… If you say @prefix: false … will you then not use that to expand things that look like CURIEs. Example “http”. I don’t know if we’ve decided that question or if that’s wrapped up in this issue or not.

Dave Longley: My view is that if you say prefix: false, we had agreed that you would not use it as a curie in any way
… the only thing that would change with a third value is for expanding in a context but not in the data
… if you say prefix it’s not a prefix. ever.

Gregg Kellogg: I don’t think the spec does that now
… The original use of this was to prevent creating CURIEs inadvertently – the example I used schema:sport or something like that.
… the original use was to prevent compacting inadvertently. e.g. schema:sportsVenue and schema:sport creates sport:sVenue
… It was intended to control [compaction]… we didn’t look at expansion. We need to implement that and I think that’s a good idea.
… so to control expansion. Don’t know if we have a resolution to control for other scenarios, but it seems a good idea

Rob Sanderson: +1 to gkellogg

Gregg Kellogg: As for controlling whether you can use that in a context but not in a body, I don’t favor that as much. The place for complexity is in the context, if you don’t want to use it in the data but in the context and I think that’s trying to aid those that write contexts and not those that write contexts.

Dave Longley: +1

David I. Lehn: Writing contexts does get kind of awkward when you have a prefix you want to use but don’t want it to leak out into your data. It becomes kind of awkward – you have to use the expanded form everywhere.
… In practice we’ve been writing some contexts like that and it seems a little weird and it would be nice to have a shortcut to make it easier to write.
… It’s complexity in a context, it gets unwieldy.
… I don’t know what the solution is – other than to write things out long form.

Rob Sanderson: Or use __internal_prefix__ or something like that.

David I. Lehn: Yeah, but I feel that’s heading towards a bad solution.

Pierre-Antoine Champin: It would still be possible to define a prefix, use it in your contexts, and then set it to null to prevent it from being used in the data.

Gregg Kellogg: I can see the point. We really don’t want to make things use CURIEs with xsd in the data … when you go to compact but we want to use it so much that we want to be able to use that in the context. That would be an example where you’d want to say @prefix: @context. The __internal_prefix__ doesn’t help. That isn’t going to affect the compaction algorithm from using that term to create a CURIE.
… Pierre-Antoine’s suggestion does address that.

Rob Sanderson: Right - it makes it less likely, but I agree is security by obscurity

Gregg Kellogg: That solves the problem but it seems a little ugly.

Dave Longley: Suggesting the arrays would run afoul of other features such as @import
… seems a bit of a hacky way to accomplish it

Rob Sanderson: Let’s take xsd as the use case. How important do we think it is to be able to express this as an in context only prefix? If we have a recommended context … like in our best practice document.
… One of our issues is to talk about pulling in a best practice context that everyone should import into their contexts.

Dave Longley: -1 to recommend everyone do that at all! :)

Pierre-Antoine Champin: Why do you want to prevent xsd from leaking into the data?

Gregg Kellogg: This is more Dave Longley and Dave Lehn concerned about having prefixes leak into the data. If you have a policy for no CURIEs and you depend on compaction for creating the data, if there’s a xsd term defined as a prefix, there’s nothing that would prevent it from then being used for compaction.
… You’d violate that policy of not using CURIEs in data.
… The array solution addresses that/solves it. The way we defined @import wouldn’t help. If you undefined a term the end definition would win and it wouldn’t work properly. It doesn’t work with that but it can work with array contexts.

David I. Lehn: This might be a scoping issue – you want to use this locally but not overwrite other things. You’re writing a context and you want to have lexically scoped variables like let/const in JavaScript.

Rob Sanderson: I think there’s the same issue in reverse. In the data we expect that a particular field always has the full URI so that the consumer can just follow it. Doing an xhr and get that piece of data. If someone defined the beginning of that URI as a prefix and in compaction you couldn’t just give that to xhr. [apologies, couldn’t follow]
… For this field, never compact IRIs. If we did that, could we say which fields shouldn’t be compacted?

Rob Sanderson: eg if there’s a property that should always have a full IRI, can we say that about the property, rather than about the prefix itself

Pierre-Antoine Champin: For me, @prefix: false for xsd would prevent compaction using the xsd prefix. Still, in the data, someone could use xsd:foo and that isn’t resolving the scoping issue, but solving the not compacting things to CURIEs with xsd. I can see the need to not generate those kinds of IRIs and the current spec addresses that problem.
… Forbidding the users from using the prefix for the sake of purity … but is it worth the added complexity?
… Or am I still missing something?

Gregg Kellogg: I propose we defer this to a future version.
… We should resolve the way that @prefix: false is interpreted when expanding things that might look at a CURIE though.

Action #3: make issue for clarifying @prefix:false (Gregg Kellogg)

Proposed resolution: Defer compact @prefix issue until a future version, pending better understanding of value of use case versus added complexity given remaining chartered time (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Dave Longley: +1

Adam Soroka: +1

Tim Cole: +1+1

Pierre-Antoine Champin: +1

David I. Lehn: +0.5, still concerned about scoping issue

Resolution #3: Defer compact @prefix issue until a future version, pending better understanding of value of use case versus added complexity given remaining chartered time

Rob Sanderson: If new information comes up we can undefer it.
… Let’s call it there, thank you everyone for joining, we’ll see you next week.

6. Adjourn

Rob Sanderson: Thanks all!


7. Resolutions

8. Action Items