JSON-LD Working Group Telco — Minutes

Date: 2018-11-09

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Gregg Kellogg, Ivan Herman, Benjamin Young, Jeff Mixter, David Newbury, David Lehn

Regrets: Tim Cole, Simon Steyskal, Adam Soroka

Guests:

Chair: Rob Sanderson, Benjamin Young

Scribe(s): Jeff Mixter

Content:

1. Minutes approval

Benjamin Young: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-10-12-json-ld

Benjamin Young: TPAC day 1: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-10-25-json-ld

Benjamin Young: TPAC day 2: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-10-26-json-ld

Proposed resolution: Approve minutes of previous discussions (call, plus TPAC) (Rob Sanderson)

Gregg Kellogg: +1

Ivan Herman: +1

Benjamin Young: +1

Rob Sanderson: +1

David Newbury: +1

Jeff Mixter: +1 to the first from 10-12

Resolution #1: Approve minutes of previous discussions (call, plus TPAC)

2. Announcements

Benjamin Young: announcements welcome Pierre-Antoine. We can do intros next week or when he he joins today. Herald is back.
… need to figure out next face to face meeting

Ivan Herman: the month that works out the best is February and possible in the middle of the month
… need to work around the Workshop in March in Berlin.
… figure it out over email
… possibly Washington
… we should try to get it on the books sooner rather than later for hotel and flights

Benjamin Young: we could also do NY if need be, hosted by Wiley

3. Issues

3.1. @type / @datatype

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

Rob Sanderson: two issue that came up as being particularly interesting.
… we should focus on them and try to come to some consensus

Rob Sanderson: related to issue 31 and the feeling at the time was that the overloading of @type was confusing
… we proposed to add a new way in 1.1 to distinguish a datatype
… that would clear up some of the confusion
… decided to use @datatype but need to discuss more
… ivan and I are on the pro side of @datatype. Ben is against it.

Gregg Kellogg: I have mixed opinions. If we had thought about this originally it would have made sense but we did not. Now we need to consider backwards compatibility
… creating an alias of datatype to @datatype might help
… we would lose the @dataype alias with expansion
… just keep in mind that it will disappear with any transformation

Rob Sanderson: Example today: {"@type": "foaf:Person", "foaf:age": {"@value": "42", "@type": "xsd:integer"}}

Rob Sanderson: Proposed additional synonymous construct: {"@type": "foaf:Person", "foaf:age": {"@value": "42", "@datatype": "xsd:integer"}}

Pierre-Antoine Champin: I assumed that @type usage had been talked about in the 1.0 dev. Wanted to hear why the decision was made to not split the hair.

Gregg Kellogg: https://json-ld.org/minutes/2011-10-18/#topic-2

Gregg Kellogg: there was an explosion of keywords back in the day and we determined that some were redundant or very similar. we did have an @datatype and decided to merge them back in 2011.
… this was decided prior to the close alignment to RDF

Gregg Kellogg: https://json-ld.org/minutes/2011-12-13/#resolution-5

Gregg Kellogg: Quote from Manu - “what convinced me most was Markus’ argument that we should make it as simple as possible without losing functionality”

Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues/31

Gregg Kellogg: From lanthaler - “I don’t think we can argue that we reduce the amount of invalid data that is created by having two different keywords. I’d argue that we increase the problem because people might put @datatype in the wrong place vs. @type.”

Benjamin Young: which camps are we making it easier or harder for. it is rare to see this type of thing in the actual data. hearing what Gregg would have to do to make it works seems a bit too much to ask. The type coercion is valid but might be a fringe use case
… concerned about the ramifications of doing this

David Newbury: when trying to learn JSON-ld and learning that @type means 2 different things. Long time to wrap my head around using the wrong keyword with different meaning.

Rob Sanderson: I had the same experience. In the IIIF world we had 5 editors and we were trying to use type coercion on classes but we found that it did not work
… also confuses a vendor we are working with
… no evidence that it is more confusing to separate them
… you could compact and expand to create valid JSON-ld. round-tripping seems like not an issue.

Benjamin Young: I agree that @type is confusing. What I am concerned about is if adding @datatype makes it any more clear
… very robust explanation would help
… this could create a new set of confusion

Ivan Herman: one thing we need to remind ourselves is that our only requirement is that a valid 1.0 is valid 1.1
… round tripping in not really an issue
… what happens in 1.1 with processing the data.
… pure JSON users will likely have issue in general. Diff between classes and literals are already somewhat confusing.
… separating @type and @datatype makes it clear that there is a distinction

Pierre-Antoine Champin: could we specify that @type is used for resources, and @datatype is used for literals, but that @type can be used as an alias for @datatype

Gregg Kellogg: we could make the move to use @datatype and allow for @type for backwards compatibility. The issue is the processor, which is currently either 1.0 or 1.1 mode.
… do we change the default processor to 1.1 and require a way to switch to change to 1.0

Benjamin Young: +1 to what Gregg was saying. The versioning is a problem outside of the problem of what is better solution. There is a risk whenever you change things.
… what is the impact on consumers of JSON-ld when the consumers are consuming pure JSON not Graph data

Rob Sanderson: sounds like there are 4 or 5 folks that are in favor and 1 against and 1 neutral (leaning against). The arguments against are significant (the 1.0 vs 1.1 processing issue)
… If Ben and Gregg come up with a clear/complete definition of @type and a further rewording around type coercion. Then we can read them over, assess the definition and see if the text of the spec is clear enough to explain what the difference is and how to implement it
… we can then decide if the documentation is sufficient or if we need to further consider splitting them

Gregg Kellogg: https://www.w3.org/TR/json-ld11/#syntax-tokens-and-keywords

Gregg Kellogg: is the current wording not clear enough? what are you looking for?
… could we raise issue about the current documentation about what is not clear enough

Rob Sanderson: nodes are meaningless to people with RDF hats on.

Gregg Kellogg: are you looking for the current docs to be improved or for something new

Rob Sanderson: 1.7 is fine. 4.2.1 needs more clarity
… it is not a technical issue it is a learning/implementation issue
… 4.2 is the problem
… splitting out @type into how to use for Classes and for Literals

Gregg Kellogg: what about further definition of other keywords

Rob Sanderson: a section in 9 about keywords and gives full definition.

Benjamin Young: more than happy to help rewording. confusion between Value instead of Literal.

Ivan Herman: we should make is more explicit that there is very clear distinction between classes and literals in JSON-ld

Rob Sanderson: +1 to Ivan

David Newbury: need a JSON person primer

Proposed resolution: bigbluehat & gkellogg to come up with rewording for 4.2, and new section for 9 for keywords, for review as to whether this will solve confusion without technical change (Rob Sanderson)

Rob Sanderson: +1

Jeff Mixter: +1

Ivan Herman: +1

Benjamin Young: +1 (noting it might include more revising elsewhere)

Gregg Kellogg: +1

David Newbury: +1

Pierre-Antoine Champin: +1

Resolution #2: bigbluehat & gkellogg to come up with rewording for 4.2, and new section for 9 for keywords, for review as to whether this will solve confusion without technical change

4. Resolutions