JSON-LD Community Group Telecon

Minutes for 2012-06-26

  1. Transition of documents to the RDF WG
  2. ISSUE-120 recap - Expansion and @type
  3. .objectify() vs. .frame()
Manu Sporny
Niklas Lindström
Manu Sporny, Gregg Kellogg, Niklas Lindström, Markus Lanthaler, Dave Longley, Josh Mandel, François Daoust, David I. Lehn
Audio Log
Manu Sporny: Anything else we should discuss today? [scribe assist by Manu Sporny]
Gregg Kellogg: Let's discuss .objectify() vs. .frame() [scribe assist by Manu Sporny]
Gregg Kellogg: Markus wanted to look at ISSUE-120 again - expansion and @type [scribe assist by Manu Sporny]
Manu Sporny: i also spoke with linclark, some of that info is in the jsonld irc channel [scribe assist by Dave Longley]
Manu Sporny: I spoke w/ Lin Clark - she has an interesting use case that we should discuss. [scribe assist by Manu Sporny]
Manu Sporny: let's discuss some of the issues that have come up before the w3c publication in the rdf working group [scribe assist by Dave Longley]
Niklas Lindström is scribing.

Topic: Transition of documents to the RDF WG

Manu Sporny: we're pretty much set to go
... bug the publication tool is buggy, so we can't get the FPWD out just yet...
Manu Sporny: then we need everyone to do their IPR coverage
Manu Sporny: https://dvcs.w3.org/hg/json-ld
... we don't have a hg repo, but the W3C staff is ok with us mirroring the github repo into the w3c hg for the time being (specs, tests, website)
Manu Sporny: the IPR stuff means a blanket statement that one has no issues regarding patents when going forward
... the editors/auhors in the community group must be ok with this from a copyright pov
Manu Sporny: we must use the tool for this for the legal stuff to become valid
Discussion about the w3c membership process...
Manu Sporny: any other questions re. W3C FPWD publication
No questions.
Manu Sporny: markus, you had a question re #120?

Topic: ISSUE-120 recap - Expansion and @type

Markus Lanthaler: why do we support objects as value of @type at all?
Markus Lanthaler: the reasoning says that the value space is different, but the decision to throw away data seems contradictory
Manu Sporny: the only thing @type is looking for is a value to interpret as an @id
Manu Sporny: in order to make the algorithm more accepting, we allow an object but only keep the value of @id
Markus Lanthaler: I'm find with both ways, but not a combination
Manu Sporny: keeping the data adds lots of complexity, throwing an error is unnecessary since it's easy to get the value of @id from the object..
Manu Sporny: we need a better reason for throwing an error than that otherwise we discard the other data in the @type object
Manu Sporny: it makes the algorithm more complex than necessary if we throw an error in this corner case
Manu Sporny: we have plenty of other corner cases where we throw an error
Markus Lanthaler: we have callbacks, but we don't define what they do
Manu Sporny: do you rather see that the callback controls recovery instead of automatic recovery?
Dave Longley: that would be fine with me (explicit callback recovery)
Dave Longley: Markus makes a good point that other things have to be considered as well. if an object is there, callback controls recovery
Gregg Kellogg: in the absence of a callback, I'd like the current recovery
Gregg Kellogg: the narrow use case, having RDF data transferred over, with a type in expanded form, and when doing compaction I want to use @type, this would be beneficial default behaviour
Dave Longley: so the use case is fromRDF not using @type, but wants @type in compacted form?
Manu Sporny: the other (stronger) reason is that we don't want to err out where it's easy to recover (it's the html5 behavior)
Dave Longley: we have a similar problem with @id
Gregg Kellogg: it's different
Gregg and Dave discuss thoughts on numeric id:s and IRI templating....
Manu Sporny: there could be something like that in the future; in the mean time (going to REC) we need to work this out
Markus Lanthaler: currently there is no JSON-LD out there, so it's better to not support it until it appears
Dave Longley: to we have real data like this?
Gregg Kellogg: I think it was an observation from working with external sources
Niklas Lindström: It's hard to reason too much about this w/o looking at concrete cases - part of this discussion cropped up a few months ago when we discussed whether it was possible to represent the RDF type like a general relation, just like any other property. [scribe assist by Manu Sporny]
Markus Lanthaler: as far as I remember this came up before we allowed rdf:type not to be automatically to @type in fromRDF()
Niklas Lindström: I've seen some need for this - for example - Elastic Search - you want an IRI for the type or perhaps a keyword and /also/ some kind of label in different languages because people want to search for it. [scribe assist by Manu Sporny]
Niklas Lindström: If you declare rdf:type in your context... it may not be coerced like @type. I think this works if you create an expanded form fromRDF() and define a term forrdf:type in your context when you compact. [scribe assist by Manu Sporny]
Gregg Kellogg: rdf:type a rdf:Property .
Niklas Lindström: From my point of view - I'm fine w/ throwing an error - that we don't allow this form. There should be means for recovering. [scribe assist by Manu Sporny]
Niklas Lindström: I do think that what we have right now is enough, explicit recovery is enough in this case. [scribe assist by Manu Sporny]
Markus Lanthaler: { "@id": "rdf:type", "@type": "rdf:Property" }
.. or {"@id": "rdf:type", "rdf:type":{"@id: "rdf:Property"}}
Gregg Kellogg: perhaps if we use the expanded form in all the cases where @id isn't applicable, to not lose information

Topic: .objectify() vs. .frame()

Manu Sporny: gregg, can you write this down in the issue 120?
Gregg Kellogg: sure
Gregg Kellogg: Regarding .objectify() - I find framing very confusing to use right now
Gregg Kellogg: it's hard to predict
Gregg Kellogg: if I can use objectify instead, I have a surface type api, where everything is linked and I can access what I want in a very simple manner
Josh Mandel: (Re: potential search mechanisms, have folks seen: http://jsonselect.org/#tryit ?)
Manu Sporny: I agree that it is complex and difficult to understand how to use the complex stuff
Manu Sporny: we can't remove framing until we have a good replacement. objectify would probably be that
Josh Mandel: I (clearly) also found framing difficult to use, which is why I coded up objectify() in the js library...
Niklas Lindström: I generally agree that framing is difficult - I do have some use cases for framing. [scribe assist by Manu Sporny]
Niklas Lindström: .objectify() feels like the way to distinguish JSON-LD usage from regular JSON usage... JavaScript has all of the requirements in place to make .objectify() work well... [scribe assist by Manu Sporny]
Niklas Lindström: If you are using JSON-LD in a programmatic environment, it makes more sense to have an API that creates a graph structure of the objects within... because they are linked. It feels like a bit of a waste to not do that. This is the way I've used RDF previously in object mappers... we should be using references. The context definition is a good way to navigate Linked Data in general. [scribe assist by Manu Sporny]
Niklas Lindström: One thing - I'm not sure about the name .objectify() - it might not capture the essence... I would use .toGraph() or .graphify() - just a detail, but if we're going forward with this, I wanted to raise this. [scribe assist by Manu Sporny]
Markus Lanthaler: decode()??
Josh Mandel: Yes, I just made up the name `objectify` because it sounded cute and I needed to call it something.
Gregg Kellogg: There is an alternate meaning of Linked Data here - you're linking your data internally to create a real graph. [scribe assist by Manu Sporny]
Niklas Lindström: There is something in rdflab - my play area for code on github - I've added something that we may want to discuss - reverse relations... which makes navigating an RDF vocabulary very easy. The thing that I noticed was that this structure I got was interesting in that in-memory graphs in RDF are more triple centric. This is just linked objects in a graph, and that felt much more natural. The triple view of things could be created as an iterator. [scribe assist by Manu Sporny]
Niklas Lindström: This 'shape' felt much more natural... maybe this would fit in well with projections in the RDFa API. [scribe assist by Manu Sporny]
Niklas Lindström: To back up quickly - the case where .frame() is useful - which is the case where I mostly use JSON-LD - which is to index stuff in elastic search. In that case, I didn't use the framing algorithm (I used an expand as much as I can algorithm... always rooted in current subject resource, which I track), I have very advanced search needs. [scribe assist by Manu Sporny]
Niklas Lindström: I need to search for things linking to and from that document. [scribe assist by Manu Sporny]
Dave Longley: I agree with a lot of this - including naming - perhaps .connect()?
Dave Longley: also a query mechanism is good
Dave Longley: but we have to make sure that code don't end up cycling indefinitely (but that can probably be prevented anyway)
Dave Longley: it's important not to call e.g. expand on an "objectified" structure
Dave Longley: some of the power in framing is available with e.g. @container, but some cases might still need to be supported to adapt data to current patterns
Markus Lanthaler: is the question either or, or can they complement each other?
Dave Longley: it should be noted that non-GC languages and objectify might not work as well
Josh Mandel: http://jsonselect.org/#tryit
Josh Mandel: JSON-select could potentially be used for querying
Niklas Lindström: I used the prototype-based features to be clones of the actual objects - this makes the resulting graph object serializable by calling .toJSON() on it. [scribe assist by Manu Sporny]
Josh Mandel: Well, except for cycles. [scribe assist by Manu Sporny]
Niklas Lindström: The clones have replaced the .toJSON() message with null - it skips cycles - expands into a tree again. [scribe assist by Manu Sporny]
Dave Longley: it might be ambiguous in general though
Gregg Kellogg: flatten is the key to get it to work
Markus Lanthaler: how do you enter the graph?
Manu Sporny: we need to explore whether we can completely replace framing with objectify in usages, and if/how they complement each other
Gregg Kellogg: are we continuing in the github tracker?
Manu Sporny: yes, we can continue to use it
Gregg Kellogg: how to get github to notify the mailing list (not only the people)?
Manu Sporny: the w3c tracker doesn't either; we can create a script
Manu Sporny: it's important, and I think we can solve it
Manu Sporny: and I suspect we agree that gh:s tracker is the better one?
Gregg Kellogg: although the w3c tracker works well with irc (but there's probably a means with gh as well)
François Daoust: bye
David I. Lehn: bye