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
- 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