JSON-LD Community Group Telecon

Minutes for 2012-04-03

  1. ISSUE-95: Remove @graph from the spec
  2. ISSUE-84: Probing of unlinked objects
  3. ISSUE-74: IRI conflicts when compacting/expanding
  1. Do not remove @graph from the JSON-LD syntax.
  2. Do not support controlled probing of unlinked objects for this version of JSON-LD.
Manu Sporny
Niklas Lindström
Niklas Lindström, Manu Sporny, Markus Lanthaler, Gregg Kellogg, David I. Lehn
Audio Log
Niklas Lindström is scribing.
Manu Sporny: Let's move Marcus' issue 95 to the first item on the Agenda
Manu Sporny: I've heard that Drupal is looking at JSON-LD for web service stuff in drupal 8

Topic: ISSUE-95: Remove @graph from the spec

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/95
Markus Lanthaler: since @graph currently doesn't support named graphs, it's just a copy of @set, doesn't provide anything more
Gregg Kellogg: we *could* do that
… related issue regarding framing
… if we coerced a graph to @set, it would not collapse a graph (we would keep the array)
Gregg Kellogg: two arguments to keep graph: 1. forward-looking
… if we want to add support for named graphs, we need to supply the ID
… by removing graph now, we're gonna have to reintroduce it
Manu Sporny: I agree. graph has two purposes; 1. the use of @id with an array is to implicit 2; we believe that named graphs are inevitable
… if @graph and @id on the same level, @id gives the graphs name
… if you have a signature, you need to know what it applies to -- the terminologgy with @set is less obvious
… we've seen several people being confused by the overloaded @type meaning
… this removal of @graph could be too confusing, since people won't know how these things work in context
… we don't really expect people to use @set explicitly; it's a control keyword in the context
Markus Lanthaler: the way @graph currently is specified, the value is just replaced with the content, and you'll lose all the other properties
Gregg Kellogg: we must update the spec to say that if @graph is used, it is the only (currently) active keyword
... in that object
… collapsing should only be done if @graph is the only property
Markus Lanthaler: how does things work if @graph is used at lower level
Manu Sporny: the current redundance is temporary
Markus Lanthaler: even if we are going there in the future, we can always introduce it, but dropping things are more difficult
Markus Lanthaler: you don't have to add new functionality
Gregg Kellogg: a context can live in any object
Niklas Lindström: The most tricky part here is the mechanics of @set are special in so far as they currently only work in conjunction with the term or property for which it is the value. [scribe assist by Manu Sporny]
Niklas Lindström: @set just means repeat the property for each value in this array. Making @set something which can be used at the top level extends the meaning of set, but only at the top level. It would still mean repeat the property if used anywhere that is not the top-level. If @graph is used further below, it would mean something - it would create a triple to it. We don't have names for @graph, because we don't support @id paired with @graph. [scribe assist by Manu Sporny]
Niklas Lindström: There are different semantics to the way these things would work in the future. [scribe assist by Manu Sporny]
Manu Sporny: the problem is that we oversimplify to the detriment of the language
… while in principle we should avoid redundant keywords, in this context we expect the difference to be important
Markus Lanthaler: we could add the @set as a shortcut
… there is nothing more at the top-level, so the behavior isn't different...
Manu Sporny: if in the future, you want to express multiple objects at the top level, you could use either or?
Markus Lanthaler: if we add @graph now but don't add a blank node, do we have to change it?
Manu Sporny: right now, the processor should throw an exception or explicitly ignore it (probably better) if it encounters something using @graph in combination with @id or other terms
Markus Lanthaler: why not introduce named graphs?
Manu Sporny: we could, but the concern is that we might get out of line with that the RDF 1.1. WG will come up with regarding named graphs
… it would unnecessarily tie up the spec
Markus Lanthaler: but don't we introduce one half of a spec then?
Manu Sporny: we create a placeholder for an expected feature
Gregg Kellogg: we should add a design note to the spec with these thoughts on named graphs
Markus Lanthaler: but if we cannot fit it into the result of the RDF WG graph solution, do we have to add @graph2?
Gregg Kellogg: we should defer if we cannot make a decision
Markus Lanthaler: but if we use @set at the top level, it does behave like @graph?
Gregg Kellogg: yes. for consistency's sake with @list.
PROPOSAL: Do not remove @graph from the JSON-LD syntax.
Gregg Kellogg: +1
Niklas Lindström: +0.75
Manu Sporny: +1
David I. Lehn: +0
Markus Lanthaler: 0
RESOLUTION: Do not remove @graph from the JSON-LD syntax.

Topic: ISSUE-84: Probing of unlinked objects

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/84
Manu Sporny: raised by niklas. the idea is to explore if we can make the processor search for data in the values of terms which themselves have no meaning (null-terms)
… a way of doing deep processing on values
Manu Sporny: main question: are we putting this in to support @rev?
... or something more general?
Niklas Lindström: It's true that I propose this as a way of using the structure I've been using @rev for and keeping all of the data. [scribe assist by Manu Sporny]
Manu Sporny: It's the former for me - not specifically support for @rev - just a way to preserve all of the data in the shape that I would end up with if I use my own mechanics for @rev.
Niklas Lindström: There might be other use cases, but those are straw-men from my view. You might have a long path down to a set of triples. You might want easy access to this from another part of the structure. [scribe assist by Manu Sporny]
Gregg Kellogg: we need to consider things to support reusing other kinds of structures, and this is a good way of doing this
… we need to clarify how to handle unknown terms in general
… in this case, it is explicitly saying that the term represents nothing
Manu Sporny: if @rev is what's sought after, we should consider it directly, and not have a pseudo-feature with this as the ulterior motive
… I agree that gregg's point about other structures is important, but we don't know how those shapes would look nor if this would actually support it
… I have mainly come across using JSON-LD in a new fresh approach, not to retrofit legacy JSON with JSON-LD contexts
Niklas Lindström: I do support @rev in my processor, currently it is another kind of structure - it tacks on @rev as a keyword - it has an object where the keys are direct terms. I have "@rev": [REFERENCES] [scribe assist by Manu Sporny]
Niklas Lindström: When we discussed deep probing of data, there seemed to be interest in that - that's why I proposed it. [scribe assist by Manu Sporny]
Niklas Lindström: I would prefer support for @rev if there is interest in that. [scribe assist by Manu Sporny]
Niklas Lindström: Things might have changed. [scribe assist by Manu Sporny]
Niklas Lindström: Maybe we want to discuss @rev, specifically. [scribe assist by Manu Sporny]
Manu Sporny: I don't think that the need for @rev is stronger know. I do believe it might be useful, but people haven't stepped forward in favor of it yet.
Manu Sporny: most JSON structures has this reverse structure
Niklas Lindström: In support for @rev - given a subject-oriented service that has one document for each resource, this is a very nice shape for the data. The alternatives are ugly, as Markus outlined. [scribe assist by Manu Sporny]
Niklas Lindström: These ORM systems often have reverse mechanics in place - if you expose something, relevant references to that become important. Things linking to that object (publisher, creator, etc.) are important. [scribe assist by Manu Sporny]
Markus Lanthaler: You can always mint a new property for that, can't you? [scribe assist by Manu Sporny]
Niklas Lindström: No, you can't always do that - you don't want to litter your core data - there are not always reverse relations defined in the vocabulary. If you use the graph API, you have no problem traversing the properties in any direction. [scribe assist by Manu Sporny]
Niklas Lindström: This is exactly the scenario I have in the legal information system. [scribe assist by Manu Sporny]
Gregg Kellogg: Have you thought about introducing a rule regime on top of this, take a property and associate it with a rule that creates an inverse of? [scribe assist by Manu Sporny]
Niklas Lindström: There are many complex things that could be added, but I want to keep this simple. There is no need for inverse reification if my developers understood RDF. [scribe assist by Manu Sporny]
Gregg Kellogg: You could solve this problem by re-framing, right? [scribe assist by Manu Sporny]
Niklas Lindström: Not really, no. [scribe assist by Manu Sporny]
Niklas Lindström: I create extremely denormalized records which are put into Elastic Search - filtering is easier when you have these reverse relationship. [scribe assist by Manu Sporny]
Manu Sporny: we need a solid @rev proposal; niklas can you do that?
… we could reserve the keyword @rev
Niklas Lindström: yes, I can write that proposal
Gregg Kellogg: the EARL reports might have some use for it, but I don't know if I can use this directly
PROPOSAL: Do not support controlled probing of unlinked objects for this version of JSON-LD.
Manu Sporny: +1
Niklas Lindström: +0
Gregg Kellogg: +1
Markus Lanthaler: +0.5
David I. Lehn: +0
RESOLUTION: Do not support controlled probing of unlinked objects for this version of JSON-LD.

Topic: ISSUE-74: IRI conflicts when compacting/expanding

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/74
Manu Sporny: if two terms apply, they are combined
Gregg Kellogg: you can merge when you're expanding, when you're compacting, you might split, partitioning on datatype
… i.e. on terms which most specifically apply (given coercion) the given value
Gregg Kellogg: i have, in expanded form: {"http://example.com/foo": [1, "a", {@id: "/bar"}] }
… and terms defined for foo: {@context": {"foo_int": {@id "foo", @type: xsd:integer"}, … }
... the values would be split among them: {foo_int: 1, foo: "a", foo_ref: "/bar"}
Manu Sporny: I'm concerned if there is another issue here: where we have to figure out which term applies, and we have to resort to lexicographical comparison
Markus Lanthaler: for all the values or once per value
Gregg Kellogg: you can calculate how close you're at (if there is one integer, one float and value is date time)
Gregg Kellogg: when I am combining values on expansion, the orders of arrays doesn't matter, but tests care for that...
Niklas Lindström: When you're compacting and you have a term for integer and float and dateTime - could we pick either one of them? Wouldn't we just not pick any of them - use the non-compacted form? [scribe assist by Manu Sporny]
Gregg Kellogg: You can compact it - but the compacted form would have to use a @value. In general, I think we should want to use terms for properties rather than IRIs. If you had the information to mint a CURIE, you could do that. [scribe assist by Manu Sporny]
Gregg Kellogg: we probably need some informative order for combining/splitting values in compaction
Manu Sporny: Dave Longley has an algorithm for this, we should look at that