JSON-LD Working Group Telco — Minutes

Date: 2019-03-15

See also the Agenda and the IRC Log

Attendees

Present: Benjamin Young, Adam Soroka, Rob Sanderson, Ruben Taelman, Pierre-Antoine Champin, Dave Longley, David I. Lehn, Gregg Kellogg, Ivan Herman, Harold Solbrig, Jeff Mixter

Regrets: David Newbury, Tim Cole

Guests: Kazuyuki Ashimura, Victor Charpenay

Chair: Rob Sanderson

Scribe(s): Adam Soroka

Content:

1. Announcements

Rob Sanderson: DST is upon us, and the call is based on time in Boston, US

2. The Berlin Graph Data workshop

Gregg Kellogg: three tracks, different attendance at all
… general sense of JSON-LD’s importance
… general acclamation for Olag Hartig’s RDF* (and SPARQL*)

Pierre-Antoine Champin: rdf* paper: http://olafhartig.de/files/Hartig_AMW2017_RDFStar.pdf

Gregg Kellogg: Blazegraph, Stardog, others implement this
… a syntax for reification in JSON-LD might work better
… perhaps work for the CG
… moves to create a W3C Business Group for this effort
… which can hopefully draw in some vendors of property graph systems

Ivan Herman: we could have ended with a dog fight between us and property graph people
… remember the fights with Topic Maps folks?
… but that didn’t happen. Much good will instead and desire for cooperation
… JSON-LD clearly considered to be an important player
… how that could converge with PG? we shall see.

Pierre-Antoine Champin: agreed with gkellogg and ivan

Rob Sanderson: other announcements?

3. TPAC in Japan

Rob Sanderson: we intend to be in CR before TPAC
… so do folks think a F2F @ TPAC would be valuable?
… Japan is a long way for many participants, so expensive, but we would need a reasonable number of attendees
… but then, people need longer lead time for farther travel

Ivan Herman: +1

Rob Sanderson: +1

Harold Solbrig: -1

Pierre-Antoine Champin: +0

Gregg Kellogg: +1, but some form of funding would help!

Ruben Taelman: +0

Adam Soroka: +0 (hard to say, given all the things that could happen to the Federal gov’t between now and then)

Benjamin Young: +1 (certainly if other groups I’m in are meeting)

Dave Longley: -0.5 (more likely not)

David I. Lehn: -0.5

Jeff Mixter: -1

Rob Sanderson: probably below zero total
… would it be valuable to meet in Japan at all?
… since we intend to be in CR.

Adam Soroka: -0.5

Rob Sanderson: +0

Ivan Herman: +1

Benjamin Young: besides our own plans, we have groups from which we need horizontal review
… e.g. WoT
… so some people have multiple groups to attend
… then there’s the question of whether we can effectively rep JSON-LD to other groups

Rob Sanderson: yes, that’s a separate question
… we certainly do need representation there, but do we need a full-on meeting?

Benjamin Young: +0 wrt to CR…since we can’t do much without our WG’s membership

Gregg Kellogg: 1) CR doesn’t mean we’re done.
… and we have other docs for which we are responsible

Rob Sanderson: +1 to gkellogg

Gregg Kellogg: and for the purposes of reserving space, we could indicate that we intend to meet, at least at this early stage

Rob Sanderson: how about we put in a “YES”, assuming that all the +0s will attend
… then we have the space if we need it

Ivan Herman: +1

Adam Soroka: +1

Jeff Mixter: +1

Pierre-Antoine Champin: +1

Gregg Kellogg: +1

Harold Solbrig: +1

Benjamin Young: +1

4. issues

Gregg Kellogg: might we briefly discuss framing issue 43 “embed first”?

Rob Sanderson: okay, five minutes for that

4.1. @embed @first issue

Dave Longley: https://github.com/w3c/json-ld-framing/issues/43

Gregg Kellogg: implemented as well as accompanied by tests
… seems straightforward

Dave Longley: or @once (which is a historical name)

Gregg Kellogg: another alternative would be to remove first and last and go back to all or none

Dave Longley: there is an important use case for having at least one of @first or @last
… frame docs where you don’t care where something appears but it must appear
… or certain properties must appear in certain places
… historically the name for this was @once
… the change was mostly for testing purposes

Ivan Herman: I feel uneasy that we are talking about order in an environment that doesn’t inherently have order

Gregg Kellogg: that’s why the algorithms do ordering

Ivan Herman: from the user POV they have to know about the algorithms
… which is not ideal. I’m not objecting, just sharing uneasiness

Ivan Herman: can we push this to next week? It’s more than five minutes of talk.

Gregg Kellogg: ivan’s comment is not about this specific PR, but about the general point
… the existence of @last implies an @first, but the real question is should we be implying ordering at all

Dave Longley: +1

4.2. RDF Deserialization and @index

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

Victor Charpenay: not much to add to the ticket
… we are working on a Thing Description which is intended to be JSON-LD
… especially with respect to transformation into RDF
… in the TD document, we make heavy us of @index

Kazuyuki Ashimura: -> https://w3c.github.io/wot-thing-description/#note-jsonld10-processing WoT Thing Description - Transformation to JSON-LD&RDF

Victor Charpenay: we want to be able to use SPARQL against the data, or roundtrip it
… the intention of the issue is to keep the indexed values in some way
… the activity on this issue is appreciated

Rob Sanderson: to summarize the proposals:
… indexing by id is one potential solution
… but it’s possible for a term to be used in different ways within the same document

Victor Charpenay: and that’s not a theoretical problem. we had that real problem as we implemented
… oracle ran into this problem in building an API

Rob Sanderson: another proposal; use a property within the graph like “indexkey” to maintain the info
… which would afford some degree for roundtripping
… and then a lot of discussion about which way to go

Gregg Kellogg: I originally thought we might allow an arbitrary IRI to be used in @container, which would have allowed arbitrary indexing
… but pchampin suggested we reuse @index

Dave Longley: +1 for “light touch” solutions

Pierre-Antoine Champin: my concern is that compaction would be more complex, but I know realize that gkellogg could speak to this
… would it make a big change if we just looked for a specific property for indexing, and not an arbitrary one

Gregg Kellogg: I think it’s similar enough to what we’re already doing with types to not be, but we’d have to try to be sure. E.g. what if it’s a node object vs. a value object?
… so you could lose other aspects (language, etc.)

Victor Charpenay: isn’t that dealt with in the compaction algorithm?

Gregg Kellogg: literals become value objects, everything with an id becomes a node object

Benjamin Young: https://w3c.github.io/json-ld-syntax/#dfn-node-object vs. https://w3c.github.io/json-ld-syntax/#dfn-value-object

Dave Longley: error if there is no “simple value”

Ivan Herman: I come to this as a user
… I am in favor of pchampin’s proposal because the other one would make this automatic
… whether or not I want it
… but pchampin’s idea makes the creator make this thing explicit
… in this case, that’s better and cleaner
… provided that the extra work is okay by WoT

Dave Longley: +1 to pchampin’s approach as well (more natural, no extra artifacts), and doesn’t break RDF canonicalization/signature/hashing issues.

Victor Charpenay: yes, to use pchampin’s approach we just create a new predicate

Rob Sanderson: do properties of this kind have semantics?
… or can we encode them using @nest?
… which gives us JSON structure but adds no RDF/graph structure

Victor Charpenay: a constant effort in the WG has been to make everything linkable
… so the property should be representable in something (RDF?)

Victor Charpenay: a Thing Description should be serializable in RDF
… everything should be kept, nothing should be “pure JSON”

Jeff Mixter: +1 to Rob’s concern about what the semantics of the properties in relation to the Thing

Ivan Herman: so @nest is not usable?

Victor Charpenay: correct

Rob Sanderson: in the ontology, what is the range of “properties”

Victor Charpenay: a singular “propertaffordance”
… ths is NOT a representation of the properties of the thing described

Rob Sanderson: so a Thing Desc could have separate properties/predicates/values, each of which has the same key, and each could have diff meanings?

Victor Charpenay: structurally that’s not possible
… because each key should point to an object
… but in RDF, yes, that would be possible
… and we want to keep the relationship with RDF

Benjamin Young: https://w3c.github.io/wot-thing-description/#property-serialization-json

Pierre-Antoine Champin: following on azaroth’s idea, would it make sense to say that temperature and on/off resolves to predicates that are subclasses of “property”?
… so that some kind of inference would provide the affordance?
… because my gut tells me that @nest is a good candidate here

Benjamin Young: the WoT is based in part on JSON Schema, so if we solve for this, we solve for the growing list of JSON Schema-based specs
… including OpenAPI, which brings a flock of JSON APIs specified in that way
… lots of collateral value

Victor Charpenay: in fact we intend to publish a vocab for describing JSON Schemas in RDF

Rob Sanderson: are there properties of the blank node that is the property’s property’s that would conflict with property’s of the thing itself

Victor Charpenay: you are suggesting to take the intermediate object as an individual

Rob Sanderson: yes. I’m trying to explore if there’s a reason that “properties” itself needs to be in there

Victor Charpenay: there is more to the Thing Desc. there are actions, there are events
… they cannot be merged
… into the root object
… conflicting keys would result

Rob Sanderson: e.g. an on/off action could be distinguished

Victor Charpenay: yes

Pierre-Antoine Champin: which is also a good reason not to use it as an @id map :)

Rob Sanderson: so we can’t use @nest? should we run with pchampin’s suggestion?
… thoughts?

Benjamin Young: the return trip from RDF is inhibited

Ivan Herman: +1 to bigbluehat

Benjamin Young: @nest would mean that you’ve lost that properties space
… you’d have to sort that out outside the compaction algo

Gregg Kellogg: @nest, because it has no semantics, can’t be used here
… so we’re back to indexing arbitrary properties, and pchampin’s idea is the cleanest

Ivan Herman: all in favor of pchampin’s idea
… but let me throw in some bikeshedding
… should we use the syntax as proposed term or not?/
… we may have to look at whether we need a fresh keyword

Pierre-Antoine Champin: I really don’t see how it is misleading… but we can discuss this later, definitely :)

Gregg Kellogg: I don’t think it’s misleading, either.

Rob Sanderson: pchampin, will you make a proposal?

Pierre-Antoine Champin: I propose adding a new keyword in the term dfns to be used with @container : @index to be used to specify an arbitrary property on which to index

Proposed resolution: Add a new keyword to be used with @container:@index to indicate the property to use instead of @index to solve WoT request (Rob Sanderson)

Rob Sanderson: +1

Dave Longley: +1

Adam Soroka: +1

Jeff Mixter: +1

Gregg Kellogg: +1

Harold Solbrig: +1

Ivan Herman: +1

Ruben Taelman: +1

Pierre-Antoine Champin: +1

Benjamin Young: +

Benjamin Young: +1

David I. Lehn: +1

Resolution #1: Add a new keyword to be used with @container:@index to indicate the property to use instead of @index to solve WoT request

Ivan Herman: q to kaz and victor: is this the only prob you have for us?

Kazuyuki Ashimura: great question!
… I was thinking about this several hours ago on the call
… if we clarify this point, there should be no big problems
… this discussion was really, REALLY, REALLY appreciated

Ivan Herman: I asked because we are planning to feature-freeze in two weeks
… so if there are other issues, we need them now!

Victor Charpenay: sebastian made some slides to summarize, one is scoped contexts

Ivan Herman: that’s an integral part of our work

Victor Charpenay: the other one was this feature we just discussed (indexing)
… we can do something ad hoc until something appears in draft
… it’s not blocking us from releasing specs

Ivan Herman: what’s the timing?

Kazuyuki Ashimura: right

Ivan Herman: what seems to work with the director is that if we as a WG make it clear that these features are stable
… so they won’t change out from under you
… we can do that, but we need to know when you need that

Kazuyuki Ashimura: WG charter goes to the end of June
… we wanted a CR by the end of March, but that’s not possible, so maybe April?
… that’s our timeline

Ivan Herman: so from our (JSON-LDs) POV, the scoped context is in the draft, has been there for a long time
… it would be good if this new feature gets into the draft soon
… pchampin, how much work does this need?
… to get it to TR?

Kazuyuki Ashimura: if you can update your draft based on this discussion, that would be great

Pierre-Antoine Champin: I could have a shot at the syntax doc by the end of next week

Kazuyuki Ashimura: sounds fine!

Pierre-Antoine Champin: I’m not as comfortable with the API doc yet, so that might take a bit longer

Kazuyuki Ashimura: I appreciate JSON-LD WG’s help!
… thank you!

Rob Sanderson: you are welcome and thanks to kaz an victor for coming!

5. Resolutions