JSON-LD Working Group Telco — Minutes

Date: 2020-01-17

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Ivan Herman, Gregg Kellogg, Dave Longley, Pierre-Antoine Champin, David I. Lehn, Benjamin Young, Manu Sporny, Harold Solbrig, Tim Cole, Adam Soroka

Regrets:

Guests:

Chair: Rob Sanderson

Scribe(s): Gregg Kellogg, Rob Sanderson

Content:

Adam Soroka: going to be about 15 minutes late

1. Approve minutes of previous call

Rob Sanderson: PROPOSAL Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2020/2020-01-10-json-ld

Rob Sanderson: +1

Gregg Kellogg: +1

Dave Longley: +0

Pierre-Antoine Champin: +1

Resolution #1: Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2020/2020-01-10-json-ld

2. Syntax #323

Rob Sanderson: link: https://github.com/w3c/json-ld-syntax/issues/323

Ivan Herman: This is really pchampin’s area, but there is a problem with how we define the JSON datatype (value space) is that we convert the JSON text into a datatypes defined in XSD and are used in RDF.
… There are some funny situations that come up, where for example “1”^^rdf:JSON and “1”^^xsd:integer are the same, which is wrong.
… THe rdf:HTML datatype uses the DOM, which doesn’t revert to primitive types. We don’t have anything like that in JSON land.
… I think the only correct way to do it is to say that the value space is a JSON string. This seems odd, but really it’s just a JSON string per the spec.
… Then we have a way to compare two values, as defined by JSON. We do indeed have a mixture of data in JSON for which we have no control.
… I think that such a change might be substantial and we’d need to go through a more formal CR update.

Pierre-Antoine Champin: I agree with ivan; I’m not sure we can take your solution, as the JSON RFC may not describe the semantics of equality.

Ivan Herman: We do have in our space a way to compare two JSON literals.

Pierre-Antoine Champin: We had to do this because the RFC doesn’t. The most natural thing was to refer to other types. Hence the confusion.

Ivan Herman: The comparison process goes into converting to the internal representation for comparison. Otherwise, the value space is a string.

Rob Sanderson: The question is whether “1”^^xsd:integer === “1”^^rdf:json ?

Ivan Herman: The way we define the value space is sort of a union of integers, booleans and and so forth. That’s wrong.

Rob Sanderson: There is no expectation that the syntax of the JSON is comparable to the semantics of other datatypes. You don’t need to understand that “true” is a valid boolean in JSON to implement the rdf:JSON datatype.

Pierre-Antoine Champin: I didn’t think it was “wrong”, but it opens a Pandora’s block regarding other specs. It could be expected that OWL processors recognize this value, which could be a problem.
… There might be issues with numbers which might make it actually wrong, as numbers are not very clear.

Dave Longley: +1

Rob Sanderson: +1 to Ivan

Dave Longley: +1 rdf:JSON is opaque

Benjamin Young: +1

Ivan Herman: The whole reason we went into this is because we want some portion of the JSON-LD to be opaque for RDF processing; our intention was that, but by turning it into an active datatype, we do something that wasn’t intended.

Gregg Kellogg: I’ll echo ivan’s point. Point was not to make a literal that should be compared with other things, but is simply JSON

Dave Longley: just a way for JSON to travel in RDF

Gregg Kellogg: because of normalization, which is not normative, every processor would create the same literal representation. Should have said that the value space is the string representing that serialization
… and to compare as strings.

Dave Longley: +1 to ivan

Ivan Herman: In an ideal world where there was a canonical JSON spec, we could say that the value space is a canonical version of the JSON serialization.

Dave Longley: +1 to “value space is a canonical version of the JSON serialization”

Ivan Herman: We do define a canonicalization.
… Then we could be a bit more precise based on our C14N description.

Proposed resolution: Change the definition of the value space of rdf:JSON datatype to remove the reference to the internal datatypes and replace with a string which is the canonical form of the serialization of the JSON (Rob Sanderson)

Dave Longley: Seems like the right thing to do to me.

Dave Longley: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Harold Solbrig: +1

Gregg Kellogg: +1

Tim Cole: +1

Rob Sanderson: +1

Benjamin Young: +1

Resolution #2: Change the definition of the value space of rdf:JSON datatype to remove the reference to the internal datatypes and replace with a string which is the canonical form of the serialization of the JSON

Rob Sanderson: This is normative text that changes how the datatype is defined/interpreted, I’d have a hard time arguing that it’s an editorial issue.

Pierre-Antoine Champin: As we’re nit-picking, we should not define it as a subset of xsd:string representations, but as a separate value space.

Rob Sanderson: +1

Ivan Herman: I wasn’t suggesting we republish now.

Rob Sanderson: But, we do think it’s significant enough to re-enter CR.

Ivan Herman: What gkellogg said, when kasei has “finished”, we can do a republication.

Proposed resolution: Above resolution is a significant change, and that we will need to re-start CR. Re-publication would when current commenters issues have been addressed. (Rob Sanderson)

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Dave Longley: +1

Rob Sanderson: kasei is using PERL to start with, and will port to a more modern language later.

Benjamin Young: +1

Gregg Kellogg: +1

Tim Cole: +1

Harold Solbrig: +1

Resolution #3: Above resolution is a significant change, and that we will need to re-start CR. Re-publication would when current commenters issues have been addressed.

Ivan Herman: Is there a minimum period of implementation? Do we have to delay based on that limitation?

Dave Longley: i think you can do a really short CR, especially if changes are not significant

Rob Sanderson: From process 2019:

Rob Sanderson: > Revising a Candidate Recommendation … must specify the deadline for further comments, which must be at least 28 days after publication, and should be longer for complex documents,

Rob Sanderson: https://www.w3.org/2019/Process-20190301/#revised-cr

Ivan Herman: 28 days is not that bad. Our original deadline was end-of-February.
… We’d need to postpone the deadline until mid-March if we miss that.
… We’re still well within our window.
… We could, in theory, republish syntax without API, but probably best until review is finished.

Rob Sanderson: We can probably consolidate our changes into something simpler.

Ivan Herman: Let’s make them clean.

3. DID WG and JSON-LD

Manu Sporny: It;s again that time of year when a W3C WG is going to re-do JSON-LD :)
… The DID WG adopted the WG spec some time ago; more recently, there’s a group from the Identity Foundation that says they don’t need JSON-LD, that it adds complexity and security issues and the extensibility model is to complex, etc.

Manu Sporny: https://github.com/w3c/did-core/pull/142

Manu Sporny: There all have rational answers, and they don’t really understand JSON-LD to start with.
… As an example, this PR makes processing more explicit, and it has over 103 comments.

Manu Sporny: https://lists.w3.org/Archives/Public/public-did-wg/2020Jan/0013.html

Manu Sporny: We built the spec so you don’t need to run a JSON-LD processor.
… (Note summary is issues).
… It’s sort of like “XML namespace are bad” and JSON-LD is don’t the same, and the spec (DID) doesn’t need it.
… In the past, we try to address concerns one by one in the WG, but that takes time.
… This means that going into feature freeze in March will be difficult, as there are other things to spend time on.
… It comes up time and time again. (activity pub, credentials, now DiD).
… I don’t think there’s a clean solution, it’s more social than technical.
… For example, if you stick to a subset, you don’t need to run through processing.
… But, that doesn’t seem to be “good enough”.
… The DiD WG meeting is in 2 weeks, and we’ll discuss there.

Benjamin Young: There’s also another call today, and then there’s another call to discuss JSON-LD before F2F.
… If you could give us a link to those issues, it would help.
… I wanted to bring this up as it’s a perennial issue, but it’s always a big time sink.

Dave Longley: (we’ve explained to the group that by using @protected and an unchanging core @context JSON-only software can hard-code checking the @context field for a specific string and then just use the JSON keys they know like usual, but this isn’t “taking” or isn’t good enough at the moment)

Dave Longley: (either because it isn’t understood or it isn’t “believed”)

Benjamin Young: There’s a myth that none uses namespaces in JSON, but it’s really done all the time.

Ivan Herman: +1 to bigbluehat

Benjamin Young: We need something that can be used to counter such claims. Going down the pure JSON path create it’s own problems.

Gregg Kellogg: My observation is one thing that keeps coming up is the remote loading of contexts. A profile that did not allow that might satisfy a lot of those issues.
… it strikes me that something necessary is a note that can encapsulate these various things. A common profile that might be more normative than a note

Dave Longley: +1 to the idea that JSON-only software/special verification software should “install” contexts locally and never load them

Gregg Kellogg: then we can refer to it once and not keep coming back to it

Dave Longley: remotely

Rob Sanderson: I could be on your next call if it would help.
… What can we do that will help?

Manu Sporny: There are a couple of things that feed into it. When you talk to each person, they have different motivations, but their solution is to just use JSON.
… They haven’t yet walked down the road to need such extensibility.
… Some people are being ignorant because they have a single simple use case, and are inflicting their “solution” on everyone else.
… Best was is to engage with that individual to expose other problems that JSON-LD solves.
… This WG could engage in those issue discussions, so it’s not just me and dlongley being “apologists”
… The other thing is to be involved more directly in the DiD working group. There is a minority of participants who understand JSON-LD.
… The people who are using it are doing so on faith. When we have breakouts there is a small minority of people that understand why we’re using JSON-LD, and it creates an awkward social dynamic.
… In the long-term, the assumptions on writing best practices is that people will read it, which they won’t.
… The fundamental issue is that there isn’t enough JSON-LD tooling. On Android, there isn’t a good Java processor, so they complain.
… Also, in RDF Dataset Normalization, those libraries don’t exist in C++/C, and so people can’t do bindings.
… As a result, they view it as being overly complex. Note that everyone uses SSL and don’t complain about the complexity, because they don’t have to think about it.
… We’re several years into JSON-LD and still don’t have pervasive implementations. The browser folks have the tooling, so it’s not an issue there.
… It’s the embedded space where we need implementations.
… Fundamentally, it’s a tooling issue.

Ivan Herman: I need to mind my dual role, but for the next DiD meeting, I don’t know if it would help if there were suddenly 3-4 more people joining the call. The call is to collect issues to be discussed at F2F.

Manu Sporny: I completely agree with Ivan, showing up on that call will help JSON-LD WG understand the concerns from the people that have them.

Ivan Herman: In the last call, we went into some technical meat, but that’s not the goal right now.
… azaroth and bigbluehat, I’d love to see you regularly attend, but maybe not just for this call.
… I agree with manu’s discussion on tooling; We had a similar duality in publishing, but it wasn’t as heavily discussed.
… We discussed some processing of the context, but ignore the heavy usage of JSON-LD.
… It turned out to be much less straightforward to use a full library as turning things into a graph resulted in another set of missing tools.
… What this group could do is to get a huge improvement in the tooling, even in JavaScript.
… Even that rdf.js is hard to use for this community.

Dave Longley: We made a couple of mistakes in naming that are hard to change. Such as “remote contexts” could have been called “shared” or “external”; maybe the spec could add some non-normative notes to show that they don’t necessarily need to be retrieved remotely.
… So, you just “npm install” the packages and they’re available to an implementation,.
… If we can change the discussion around these things it would help.

Harold Solbrig: I represent some communities that come from a very different space. For example healthcare uses FIHR, which is very much RDF/OWL focused. We’re trying to put these things together, and JSON-LD proved to be necessary to make this happen.
… We’re putting together a set of tutorials on why RDF is in your future, because if you don’t have it, you’ll need to re-invent it.

Benjamin Young: +1 to dlongley’s suggestion for something like npm install did-context – i.e. contexts can be “installed” they don’t have to be remote

Harold Solbrig: We can assign semantics to things fairly easily using JSON-LD.
… There’s a lot of enthusiasm about this, and our group is quite excited.

Rob Sanderson: Would it be valuable to be present and silent?

Manu Sporny: It would be valuable to for this WG to show up and sit and listen.

Dave Longley: +1000 to sitting and listening for this stuff and helping understand where others are coming from

Ivan Herman: In our communication there’s an under-exploited feature is that the context can be delivered to a JSON file via HTTP headers.

Dave Longley: notes that DID Documents don’t necessarily travel over HTTP

Ivan Herman: If you have a person working only in JSON a well setup server can deliver JSON easily, and we don’t talk about it.

Dave Longley: but useful in other areas

Rob Sanderson: Meaning Link headers.

4. Resolutions