JSON-LD Working Group Telco — Minutes

Date: 2018-07-27

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Simon Steyskal, Adam Soroka, David Newbury, Jeff Mixter, Dave Longley, Ivan Herman, Gregg Kellogg, David I. Lehn, Tim Cole

Regrets: Benjamin Young

Guests:

Chair: Rob Sanderson

Scribe(s): Dave Longley

Content:

Rob Sanderson: minutes link: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-07-20-json-ld

Rob Sanderson: Any objections to the minutes?

Dave Longley: +1 to the minutes

Simon Steyskal: +1

Proposed resolution: Approve the minutes from last week (Rob Sanderson)

Rob Sanderson: +1

Jeff Mixter: +1

David Newbury: +1

Gregg Kellogg: +1

Resolution #1: Last week’s minutes Accepted

1. Announcements / Reminders

Rob Sanderson: This is the last call before the early bird rate runs out for TPAC. If you haven’t registered and are intending to come please register urgently. I’m happy to answer questions about TPAC if you have any.

Adam Soroka: Do you know off the top of your head what the story is with hotel arrangements?

Rob Sanderson: First come, first serve basis. I don’t know what the status is.

Adam Soroka: Oh, can’t know without calling the hotel.

Rob Sanderson: Yes. It’s quite likely that there are still rooms.

Rob Sanderson: Any other questions/comments about TPAC?

Dave Longley: Verifiable Claims WG meeting at the same time as JSON-LD WG, so members might miss one or the other meeting or have to pop in/out.

2. Issues proposed to be closed

Rob Sanderson: link: https://github.com/w3c/json-ld-syntax/issues?q=is%3Aissue+is%3Aopen+label%3A%22propose+closing%22

Rob Sanderson: I propose working down from the topic. First issue is #31.

2.1. Coerce node types

Dave Longley: https://github.com/w3c/json-ld-syntax/issues/31

Gregg Kellogg: Ivan has suggested that the term type coercion might be confusing. And he has been confused by what it meant by it in JSON-LD. The commenter who raised the issue is of the opinion that because we can specify the datatype of a value in a @context that we should be able to add @type for a node (a class type).

Gregg Kellogg: That’s not currently the case. The purpose of @type in the context [in a term definition] is to either say that the @type is an ID/URL or a literal value of some datatype. To distinguish strings from other values.

Gregg Kellogg: We have proposed closing this; I think there may be some call to change the language.

David Newbury: Having run into this issue back in the early days with playing with JSON-LD. When I was trying to take existing APIs and convert them into JSON-LD, this was the most difficult thing to wrap my head around and to do. Adding in a type is an important part of RDF but no existing APIs I’d worked with included that data. There was no obvious place to put this.

David Newbury: That being said, I’m not saying we should necessarily increase scope for JSON-LD, just bringing up what the problem was.

Rob Sanderson: We made this exact same mistake in early implementations and adding @type and having compaction fail using filtering, etc. and it failed. I’m +1 for closing this one because adding additional RDF triples via a @context is a terrible idea because those triples will disappear again.

Rob Sanderson: I’m a +1 on the editorial issue. To be clearer that this is exclusively for setting datatypes not for classes.

Gregg Kellogg: I’d suggest then that we’ve seen this before where the purpose of the issue morphed through discussion … this is an example where rather than trying to keep this issue open to describe an editorial issue, we should close this and open a new one.

Dave Longley: +1

Proposed resolution: Close #31 wontfix, and create a new editorial issue to change the language around type coercion (Rob Sanderson)

Simon Steyskal: +1

Dave Longley: +1

Ivan Herman: +1

Adam Soroka: +1

Rob Sanderson: +1

Gregg Kellogg: +1

Tim Cole: +1

David Newbury: +1

David Newbury: Do we feel that adding data via @context is out of scope for JSON-LD 1.1?

Jeff Mixter: +1

Gregg Kellogg: We looked at a more comprehensive mechanism in the CG for adding boilerplate content via, I think @content, and the body of that value could be added to something. Then you could add @type in there and add type to the thing. That went down in flames.

Gregg Kellogg: People were misconstruing the purpose of @context – it is to provide context to the data, not supplemental data.

Gregg Kellogg: Ivan brought up in a comment that this is the role of RDFS/OWL reasoning and we’re sort of overstepping … if we were to add something to say explicitly add the type of an object we’d be repurposing something you’d do through reasoning instead and it would complicated things from an RDF perspective.

Simon Steyskal: I was wondering if you’d add this RDF range information in the @context and it’s giving context… one could argue it’s adding context that you have to interpret the property this way, not adding the property. If someone was using reasoning they could use this context information. One could argue that adding RDFS range is adding context not data.

Gregg Kellogg: The practice I use when creating @context documents is to include the RDFS data in the [context] document. I’ve created vocabularies that have done that in WGs. Where do we stop? Are we turning the @context into an alternative way to specify RDFS … maybe there should be more called out ways to achieve these types of goals and best practices for publishing the RDFS definition along with the @context.

Rob Sanderson: +1 to ajs6f

Adam Soroka: I’m very much in agreement with Ivan and Gregg’s general sense. I wanted to offer one concrete, pragmatic point, someone like me who are assembling systems where RDF is the meta model between components and JSON-LD is just a serialization. The possibility that using JSON-LD in another context would introduce more triples is horrifying. From one point of view inside a message triples could just appear and that’s really surprising.

Adam Soroka: That’s not something that should happen in that way, the reasoning/inference, any new kind of triple coming into the world should be carefully distinguished from what we do with contexts.

Rob Sanderson: We’re in agreement.

Rob Sanderson: Before the charter was approved this was one of Google’s concerns. The level of new functionality in 1.1 should be as tightly scoped as possible and not do things like introduce new triples. For the reason Adam said, if you try and interpret a @context you found on the Web, like schema.org’s… and then it starts to add in additional data that’s not in the document without very strong versioning on the @contexts so you could reproduce where

Dave Longley: those triples came from, when you interpret the same data in your cache you get different triples.

Rob Sanderson: I am also quite firmly of the opinion that this is out of scope for @contexts, it might not be about of scope for the WG, but it doesn’t go in a @context.

Dave Longley: +1 from the peanut gallery

Resolution #2: Close #31 wontfix, and create a new editorial issue to change the language around type coercion

2.2. Lax IRIs

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

Gregg Kellogg: This came about as an effort to quash something where someone has a poor understanding of JSON-LD and was trying to recreate it … and had this notion that creating IRIs is difficult. Creating any sort of string as an identifier is not a good idea. There has been some discussion of using URLs as a replacement for IRIs which does except a broader syntax and that has been common in a number of different groups.

Rob Sanderson: Does anyone want to speak up to allow more lax IDs?

Proposed resolution: Close #14 wontfix. (Rob Sanderson)

Adam Soroka: +1

Dave Longley: +1

Ivan Herman: +1

Gregg Kellogg: +1

David I. Lehn: +1

David Newbury: +1

Simon Steyskal: +1

Jeff Mixter: +1

Tim Cole: +1

Rob Sanderson: +1

Resolution #3: Close #14 wontfix.

Tim Cole: I do think that putting an issue in about URLs rather than IRIs might be worthwhile. Sometimes the objection to IRIs means you can’t use an URL even though the URL would qualify as an IRI. People who are not RDF-inclined sometimes think that IRIs are more complicated than they are used to.

Rob Sanderson: That’s a very good point, one we ran into Annotation WG/CG as well. The complication of using Japanese characters in IRIs/URLs.

Ivan Herman: issue on IRI vs URL: https://github.com/w3c/json-ld-syntax/issues/25

2.3. 2.0 v. 1.1

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

Rob Sanderson: There was some discussion last year at TPAC that adding any new feature would cause 1.0 processors to break and we should go to 2.0 not 1.1.

Rob Sanderson: The charter is pretty explicit after dealing with objections and resolutions to those, that we aren’t going to introduce incompatibilities. A JSON-LD 1.0 processor should know not to process a 1.1 document. We’re not forward compatible but backwards.

Rob Sanderson: I feel like this issue has been decided by the charter and we can close.

Ivan Herman: I agree with the resolution, just one more thing to make clear. One thing that came up during chaptering. You referred to this in your discussion with Dan Brickley. We should try to minimize the changes vs. 1.0. The naming has a psychological effect (2.0 vs. 1.1). 2.0 suggests radical changes, 1.1. doesn’t mean that. It’s not just bug fixes but keeping changes to a minimum. Messaging also justifies keeping it 1.1.

Dave Longley: +1

Proposed resolution: Close #10, wontfix. Not going to introduce breaking changes, per charter. (Rob Sanderson)

Gregg Kellogg: +1

Ivan Herman: +1

Rob Sanderson: +1

Adam Soroka: +1

Jeff Mixter: +1

Dave Longley: =1

Tim Cole: +1

Dave Longley: +1

David I. Lehn: +1

Simon Steyskal: +1

David Newbury: +1

Gregg Kellogg: +1 to dlongley

Resolution #4: Close #10, wontfix. Not going to introduce breaking changes, per charter.

2.4. new @label keyword

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

Gregg Kellogg: Someone wanted to add some extra syntactic sugar that you might use when describing node definitions that would replace schema label or presumably something like that. Just syntactic sugar and the @context can be purposed to do that type of thing. I think we forbid using things like keywords. We may want to revisit that.

Rob Sanderson: I think there’s an issue about raising an error or warning about that.

David Newbury: Do we want to open a separate issue about things like @contexts in frames?

Dave Longley: s/\/?/

David Newbury: If there’s not something about a desire for comments within JSON-LD in @contexts that’s worth talking about

Rob Sanderson: Someone wanting to assert the unit of a height in a comment… I forget whether that was in the CG or WG.

Ivan Herman: The problem I have … using something like that as syntactic sugar is syntactic sugar for what? We won’t have our own vocab. Maybe someone wants to use rdfs:label, there is no end to such discussions. I don’t see the reason for that.

Proposed resolution: Close #6 wontfix, no need to add syntactic sugar (Rob Sanderson)

David Newbury: +1

Rob Sanderson: +1

Jeff Mixter: +1

Ivan Herman: +1

Adam Soroka: +1

Gregg Kellogg: +1

Simon Steyskal: +1

Dave Longley: +1

Tim Cole: +1

David I. Lehn: +1

Resolution #5: Close #6 wontfix, no need to add syntactic sugar

Rob Sanderson: Issue for adding comments to contexts/frames: https://github.com/w3c/json-ld-syntax/issues/32

2.5. object-level @language

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

Rob Sanderson: Adding @language at the object level as a shorthand for doing it in @context.

Rob Sanderson: This just introduces more complexities and ``@language would have to be recognized within the data instead of within the @context`.

Rob Sanderson: Gregg do you recall if there was significant rationale other than cutting down the number of characters?

Gregg Kellogg: I think it perhaps hadn’t occurred to the issue proposer that you could add a per-object @context that did exactly this.

Proposed resolution: Close #5 wontfix, unnecessary syntactic sugar (Rob Sanderson)

David Newbury: +1

Dave Longley: +1

Gregg Kellogg: +1

Ivan Herman: +1

Rob Sanderson: +1

Jeff Mixter: +1

Adam Soroka: +1

Simon Steyskal: +1

Tim Cole: +1

David I. Lehn: +1

Resolution #6: Close #5 wontfix, unnecessary syntactic sugar

2.6. Pick a better keyword for @nest

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

Rob Sanderson: Can you refresh us on what @nest refers to?

Gregg Kellogg: One of the major features introduced by the CG in 1.1 is the concept of nesting where you can include the properties of an object underneath another one. So “nested” properties. We did bikeshedding. There were a number of different proposals on a vote and @nest won, but not universally loved. At TPAC there was continued lack of love, but this is bikeshedding and no better proposals. Let’s just move on is the proposal.

Ivan Herman: Or organize a dinner in Lyon. :)

Rob Sanderson: Any questions/discussion?

Dave Longley: obscurity means you won’t get it confused with anything else!

Proposed resolution: Close #3 wontfix, unnecessary painting of bikesheds (Rob Sanderson)

Gregg Kellogg: +1

Dave Longley: +1

Jeff Mixter: +1

Adam Soroka: +1

Rob Sanderson: +1

Tim Cole: +1

David I. Lehn: +0

Simon Steyskal: +1

Ivan Herman: +1

David Newbury: +1

Resolution #7: Close #3 wontfix, unnecessary painting of bikesheds

3. discuss non-substantive issues

Rob Sanderson: We hope we can get consensus around these fairly easily.

Rob Sanderson: Will need to be some discussion around the implementation and the wording and so forth, but not ones that would require a lot of changing.

Rob Sanderson: link to issues: https://github.com/w3c/json-ld-syntax/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3A%22propose+closing%22+-label%3Aspec%3Aeditorial+-label%3Aspec%3Asubstantive

Rob Sanderson: Start at the top or should we do some easier ones first, Gregg?

3.1. Is there a way to define additional metadata in JSON-LD @context?

Dave Longley: https://github.com/w3c/json-ld-syntax/issues/32

Gregg Kellogg: Issue #32 is something that we broached already… the ability to define additional metadata in the @context.
… Most RDF syntaxes do provide some mechanism for a syntax level comment.

Gregg Kellogg: JSON-LD being based on JSON does not have a syntax-level comment capability. So one of the thoughts is to create a keyword @comment that is basically syntax level and you ignore the value. The value space for that comment would a legal JSON value and it wouldn’t survive compaction/expansion/etc and it would be a way to insert comment definition within a JSON document.

Gregg Kellogg: That would allow comment like structures within term definitions, etc. Or we could allow it arbitrarily any place else in the whole JSON-LD document.

Rob Sanderson: Should we separate adding comments in contexts and frame documents from adding comments in instance documents (actual data)?

Rob Sanderson: I see different levels of agreement being possible between those two.

Adam Soroka: I wanted folks to see that link, I don’t think it should change the way we end up going on this. That’s from Douglas Crockford and I saw people were using them to hold parsing directives and that would destroy interop.

Ivan Herman: Douglas Crockford’s note on comments: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr

Adam Soroka: Let’s remember that.

Adam Soroka: I suggest that it’s immediately higher complexity. Having separate ways for putting separate data in documents and contexts/frames. I don’t know if there are additional problems with using this in keywords, etc. Initially my reaction is please don’t make me memorize more keywords to do the same thing.

David Newbury: If we’re going to do it we should use the same keyword in both places, but the question is really, within @contexts we could add comments, but more thinking required in other JSON-LD documents. I think we should do it in our processing documents is an obvious choice, elsewhere I’d like to think more.

Adam Soroka: +1 to workergnome

Ivan Herman: I am a bit torn on this, on the one hand … like everybody using JSON and not being able to comment is painful because I do that a lot. On the other hand not expanding the underlying data model with adding new triples … I have a similar feeling and we have chosen to use JSON and we’re tweaking JSON in some ways. And it looks a little bit dirty to me.

Ivan Herman: I can’t fully explain why I feel uneasy about it. Let’s not do that. We have, in a more general sense, we have decided that whatever we do in our model that we should apply to other syntaxes like YAML. Maybe the JSON syntax will add this in the future.

Dave Longley: +1

Gregg Kellogg: I’ll just note that any previous discussion

Rob Sanderson: +1 to gkellogg

Gregg Kellogg: A JSON-LD 1.0 processor that saw @comment within a @context or within a document would currently ignore it.

Rob Sanderson: If someone mapped rdfs:comment to @comment you’d want to not discard it and it could get slightly confusing.

Ivan Herman: +1 to dlongley

David Newbury: I would be perfectly happy … I notice me doing workarounds every time I do this, or putting my comments into the data which is then roundtripped … introducing a keyword that would always be ignored and let me get around this problem I would like that.

David Newbury: It’s a problem that’s real.

Tim Cole: While I agree with Ivan about not polluting JSON with data and the @context and the frame are ours. I think some way of adding meta data to that is important. I don’t think it would get superseded if there’s a more general comment method in the JSON data. I think it’s reasonable for us to consider doing. It will open up some complications I’m sure, but I’d like to see that.

Dave Longley: I’m less against putting something in @context than in the data, I’m a -1 on in the data.

Rob Sanderson: Let’s figure out where we do have consensus.

Rob Sanderson: Is it fair to say that people agree that we should not have comments in data? Leaving @contexts/frames alone for now.

Rob Sanderson: Is anyone strongly in favor of putting comments to be ignored into the data as opposed into @contexts/frames.

Adam Soroka: +!

Gregg Kellogg: +0.1

Proposed resolution: We will not add comments to instance level JSON in a special keyword (Rob Sanderson)

David Newbury: +0

Ivan Herman: +1

Rob Sanderson: +1

Adam Soroka: +1

Gregg Kellogg: +0.1

Dave Longley: +1

Jeff Mixter: +1

Tim Cole: +1

Simon Steyskal: +1 (as it’s similar to the @language issue)

David I. Lehn: +1

Resolution #8: We will not add comments to instance level JSON in a special keyword

Rob Sanderson: Let’s just get some feelings on adding something like @comment to @context/frames… not a proposal.

Tim Cole: +0.5

Rob Sanderson: +1

Ivan Herman: -0.5

David Newbury: +1

Simon Steyskal: +0

Adam Soroka: +0

Gregg Kellogg: +1

Dave Longley: +0

David I. Lehn: +0

Jeff Mixter: -0.5

Rob Sanderson: Let’s take it to the github issue.

Rob Sanderson: If you get a chance to think about how you feel on this one please add your arguments in favor/against in #32.

Action #1: Everyone to add thoughts on comments in contexts/frames to issue #32

4. Resolutions

5. Action Items