JSON-LD Working Group Telco — Minutes

Date: 2018-08-17

See also the Agenda and the IRC Log

Attendees

Present: Adam Soroka, Ivan Herman, Simon Steyskal, Gregg Kellogg, David Newbury, Rob Sanderson, David I. Lehn, Alejandra Gonzalez Beltran, Jeff Mixter, Benjamin Young

Regrets: Tim Cole, Dan Brickley, Dave Longley

Guests:

Chair: Rob Sanderson, Benjamin Young

Scribe(s): Adam Soroka, Rob Sanderson

Content:

1. Approve minutes of previous call

Rob Sanderson: link: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-10-json-ld

David Newbury: +1

Adam Soroka: +1

Ivan Herman: +1

Rob Sanderson: +1

Simon Steyskal: +0

Alejandra Gonzalez Beltran: +0

Benjamin Young: +1

Gregg Kellogg: +1

David I. Lehn: +1

Resolution #1: Approve minutes of previous call

2. Announcements

Rob Sanderson: TPAC, as usual.

Ivan Herman: Face-to-face planning documents are currently practically empty

Rob Sanderson: link: https://www.w3.org/2018/json-ld-wg/Meetings/F2F/2018.10.Lyon

Ivan Herman: link: https://docs.google.com/document/d/1qTLztv7nqbYuUsZbwhPhOyG5tHTJrTt9tGKWnD5Xa5A/edit#

Ivan Herman: we have a Google doc waiting for ideas to discuss
… add whatever you think, chairs will prioritize and sort
… our problems will not be culinary
… do register if you are coming, so that organizers can get the logistics right (meeting rooms, etc.)
… ten or twelve registered now, more would be good

Rob Sanderson: many requests for observer status

Ivan Herman: up to us how to play that (observer status)

Ivan Herman: Only two months away!

3. Introductions

Rob Sanderson: new folks here, so we can do introductions

Rob Sanderson: co-chair w/ bigbluehat, long-standing involvement with cultural heritage domain, many specs

Ivan Herman: Ivan Herman, W3C team contact for this WG, was once Semantic Web activity lead, now doing more digital publishing. part of RDF WG when JSON-LD 1.0 came out

Simon Steyskal: with WU of Economics and Business, SHACL and other groups

Adam Soroka: Adam Soroka, Apache Software Foundation (Jena) also another hat of the Smithsonian Institution, interested in cultural heritage

gkellog: edited the 1.0 doc, into JSON-LD from the beginning, and editor for CG specs

David I. Lehn: with Digital Bazaar

David Newbury: also from J. Paul Getty Trust, interested in consuming JSON-LD

Alejandra Gonzalez Beltran: Coming from Oxford, uses JSON-LD and other SW tools, involved with W3C Dataset Exchange WG

Benjamin Young: with John Wiley, co-chair with Rob, also part of Web Publications WG,

Jeff Mixter: with OCLC, interested in participating in various LD WGs

4. Issues

4.1. @type related issues

Benjamin Young: https://github.com/w3c/json-ld-api/issues/4

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

Benjamin Young: The issue is “Relax the colliding keywords constraint for @type #4”. No obvious reason has been raised not to do this.

Gregg Kellogg: this was wrapped up in the general issue of multiple aliases for keywords
… use case: set the container for @type to @set
… which would allow it to always compact to an array
… wouldn’t want to reassign @type to something other than IRI

Rob Sanderson: related to #34
… the coverage example in the issue could be solved by allowing @type to be aliased w/i scoped contexts but not at the top level
… having it aliased “one step down” not globally would make the resolution deterministic

Gregg Kellogg: that wouldn’t resolve the collision unless the original alias was also removed

Rob Sanderson: +1 to gkellogg

Gregg Kellogg: we have no other case where the rules for scoped contexts are different than general rules for contexts

Rob Sanderson: {“type”: null, “profile”: “@type”}

Adam Soroka: g+

Adam Soroka: Quickly agree and emphasize that if we do that, we’re making a change to treat scoped contexts differently from others
… that’s a big thing!
… suddenly changes a lot of implementations. So should be very conscious of what we’re doing.

Gregg Kellogg: is also worth revisiting the idea of multiple aliases on keywords

Gregg Kellogg: its a judgement call– relaxing doesn’t introduce incompatibility with 1.0
… 1.0 has a prohibition on multiple aliases to keywords
… if we relax that, we aren’t invalidating any extant 1.0 material
… we’re just not complaining in places where we previously would have

Rob Sanderson: why was the restriction introduced to begin with?

Gregg Kellogg: It’s gone out of my head why, at the moment
… was really thinking about the @type container @set use case

Benjamin Young: give this a bit more time?

Rob Sanderson: shall we get in touch with the original issue creator and ask whether scoped aliases would solve his problem?
… unless someone else knows of use cases for this issue?

Proposed resolution: Propose scoped contexts as solution to original use case and determine if that is sufficient (Rob Sanderson)

David Newbury: +1

Rob Sanderson: +1

Adam Soroka: +1

Benjamin Young: +1

Ivan Herman: +1

Gregg Kellogg: +1

David I. Lehn: +1

Simon Steyskal: +1

Jeff Mixter: +1

Resolution #2: Propose scoped contexts as solution to original use case and determine if that is sufficient

Benjamin Young: lots of these issues have a lot of history
… okay to delve into that
… don’t be afraid to stop the bus to make sure everyone is still on board

4.2. @type as @container:@set?

Ivan Herman: link: https://github.com/w3c/json-ld-syntax/issues/34

Gregg Kellogg: this was a reason to allow repeated aliasing for keywords
… in this case to alias the keyword @type
… not to change its identity, just the container treatment
… e.g. to @set. Of course, some values wouldn’t be valid here, like @list
… might want to constrain that. shouldn’t be a problem with other keywords

David Newbury: examples for both @type and @context are useful
… we hit this while trying to support objects that are both IIIF and CIDOC/CRM
… objects with multiple rdf:types
… then our documentation gets very complex to account for multiple possible shapes.
… the processor has to look for both a string or an array
… so this would make that work easier

Benjamin Young: CIDOC/CRM - http://www.cidoc-crm.org/

Benjamin Young: IIIF - http://iiif.io/

Rob Sanderson: You can’t compact to: “@type”: [“Manifest”] or “@context”: [“http://iiif.io/api/presentation/2/context.json”]

Rob Sanderson: basically, you can’t compact to @type as a single item in a list
… having the capacity for both @context and @type would be valuable
… seems very reasonable for @type

Benjamin Young: there is a config option for at least some JSON-LD processors to force things into an array when compacted
… could that be brought to an API parsing level, and not a syntactic level

Ivan Herman: feeling a bit lost!

Rob Sanderson: what we’re suggesting is not illegal in 1.0, it just can’t be compacted to

Ivan Herman: the difficulty here is when compacted, not the original syntax?
… ie, an API-level problem
… if I have an author who doesn’t know or care about the spec, what can she write down than is valid

Rob Sanderson: I agree that it is an API problem

Ivan Herman: mod’ing the context for the purpose of the APIs– I have a disconnect

Rob Sanderson: the result of the compaction algorithm has a single class in an array
… so we are really making @type be consistent with all the others

Ivan Herman: any exceptions that are not justified are WRONG!

Rob Sanderson: again, an API-level thing. you should be able to spec in the syntax which of the two options you want
… it’s a question of the compaction algo and how we signal to it which of the two possible things to do

Gregg Kellogg: compactArrays

Gregg Kellogg: If set to true, the JSON-LD processor replaces arrays with just one element with that element during compaction. If set to false, all arrays will remain arrays even if they have just one element.

Benjamin Young: +1 to adding these config options to the playground

Gregg Kellogg: the “compact arrays” option in the API: if set to false, all values will be represented as arrays
… don’t know if current algorithms do that for contexts, but arguably they should
… playground doesn’t expose these options. that’s an issue for us to take up with json-ld.org
… the reason to set @type as container @set is to make the use of arrays uniform, but if the option compactArrays already handles that
… then let’s not complicate the algorithms to do the same thing
… wrt to @type vs @context, you cannot alias @context in a JSON-LD for obvious bootstrapping reasons

Rob Sanderson: +1 to considering weight!

Rob Sanderson: if I have a bunch of triples from (say) a triplestore than describe a single class, can Gregg explain how to get to JSON-LD with an array of types

Gregg Kellogg: let’s take a single triple, set compactArrays = false, you should get that.
… not just for @type, for anything

Rob Sanderson: how does that interact with @container @set

Gregg Kellogg: if compactArrays=true (the default), then it is overridden by @container @set, if false, @container @set is irrelevant

David Newbury: is compactArrays required?

Gregg Kellogg: normative/required
… and we have good coverage in the test suite
… might be good to do a sweep and make sure we’re getting all the combinatorics
… we might not be getting every possible result in an array right now

Benjamin Young: compaction tests fwiw https://json-ld.org/test-suite/#Compaction

David Newbury: might be good to add more info about API options to the documentation
… only ever seen such docs in the docs for given impls.
… which could lead people to assume that they are impl-specific
… especially since the playground doesn’t expose them

Gregg Kellogg: I have a distiller that exposes them, could use that to expose that in the playground

David I. Lehn: the compactArrays option will cover everything, @type @container @set is much more controllled/specific
… as far as options on the playground, been thinking about that but haven’t gotten around to it… help wanted!

Rob Sanderson: compact arrays would prevent: {“property1”: “only ever one value”, “property2”: [“sometimes multiple values”]}?

Benjamin Young: the normativeness of the API has come up e.g. with Activity Streams
… one of the stones thrown in that conversation was that “JSON-LD hasn’t got a normative API”
… what I found was from the CG specs, and not connected with JSON-LD 1.0

Gregg Kellogg: the WebIDL that describes the API has been part of the docs from the beginning
… the API is written using “promises”, which is really a JS-land feature
… the processing steps for “compact” first discuss “expanding”, which isn’t even in that document
… anything passing the test suite has to make use of that aspect of the API anyway

Benjamin Young: the “promises” thing also came up in that conversation, so if there’s another way…

Gregg Kellogg: It was important that the API could be async, previously we tried a callback style
… the API has always been very JS-centric. believe that to be true of all WebIDL use at W3C

Rob Sanderson: when I first tried to do the @type stuff, I tried to use compactArrays, but when some values can be 1 or more, and some can be 0..1, compactArrays make them all into arrays
… which is not what was wanted a
… so there is still a use case here, in spite of compactArrays

Gregg Kellogg: would support a narrowly-worded resolution that specifically allows aliases for @type, for which the only thing that can be set is @container and the only value
… to which it could be set would be @set.
… and an alias of that type would have the same restrictions

Rob Sanderson: that meets the use case without overstepping

Proposed resolution: @type (or an alias of it) can be set to be only a @container, and have only the value of @set (Rob Sanderson)

Benjamin Young: +1

David Newbury: +1

Rob Sanderson: +1

Gregg Kellogg: +1

Ivan Herman: +1

Jeff Mixter: +1

David I. Lehn: +1

Resolution #3: @type (or an alias of it) can be set to be only a @container, and have only the value of @set

Ivan Herman: need to close off the question for @context
… @context is so different from anything else…
… would be very dangerous to touch it

Proposed resolution: @context will not be changed to allow specification of being always an array (Rob Sanderson)

Rob Sanderson: +1

Ivan Herman: +1

Gregg Kellogg: +1

Simon Steyskal: +1

Benjamin Young: +1

Adam Soroka: +1

David Newbury: +1

Resolution #4: @context will not be changed to allow specification of being always an array

David I. Lehn: +1 but fine to re-raise issue if there are good use cases

Ivan Herman: yes, we can reopen

4.3. Allow processing model of @type to be customized #7

Benjamin Young: https://github.com/w3c/json-ld-api/issues/7

Gregg Kellogg: @type is different, has a different processing model
… some complaints about this, requests to change that so that @type uses a diff processing model

Rob Sanderson: +1 to wontfix

Rob Sanderson: original issue has an example of what happens now
… is there an ambiguity here?

Gregg Kellogg: if you are expanding a bare word “foo”, how you expand depends on the presence of an @vocab
… but not @type
… it being common to define types themselves within the document
… so relative IRIs are really useful there
… how to process @type is defined by the spec itself, not by the context of a given doc
… opening that up could introduce injection attacks via the context,

Rob Sanderson: the result that the original requestor wanted, could be done by taking out @vocab and defining individual entries
… they just want to shorten that up

Gregg Kellogg: yep, and could also be done via scoped contexts

Adam Soroka: If we do this, we need to offer various solutions in examples in the specs

Gregg Kellogg: A best practices document

Adam Soroka: Exactly! :)

Proposed resolution: close #7 wontfix, as the use case can be accomplished with longer, scoped contexts and the precedence has other ramifications (Rob Sanderson)

Gregg Kellogg: +1

Simon Steyskal: +1

Rob Sanderson: +1

Ivan Herman: +1

David I. Lehn: +1

Jeff Mixter: +1

Adam Soroka: +1

David Newbury: +1

Resolution #5: close #7 wontfix, as the use case can be accomplished with longer, scoped contexts and the precedence has other ramifications

5. Resolutions