JSON-LD Community Group Telecon

Minutes for 2012-05-22

Agenda
http://lists.w3.org/Archives/Public/public-linked-json/2012May/0008.html
Topics
  1. JSON-LD pushed to RDF WG for review
  2. ISSUE-114: JSON-LD Grammar
  3. ISSUE-118: @graph support in framing
  4. ISSUE-119: Aggressive embedding support
Resolutions
  1. Defer @graph and, in general, value matching from the framing algorithm.
Chair
Manu Sporny
Scribe
Niklas Lindström
Present
Manu Sporny, Niklas Lindström, Gregg Kellogg, Markus Lanthaler, David I. Lehn
Audio Log
audio.ogg
Manu Sporny: Any changes to the agenda? [scribe assist by Manu Sporny]
Niklas Lindström: I have one thing I'd like to discuss - the multiple embeds issue... alternative to the RDF API... wondering if it could apply to what I'm working on. [scribe assist by Manu Sporny]
Gregg Kellogg: It might be worth talking a bit more about the JSON-LD grammar. [scribe assist by Manu Sporny]

Topic: JSON-LD pushed to RDF WG for review

Manu Sporny: http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0480.html
Manu Sporny: I sent that e-mail out to the RDF WG to request that JSON-LD be picked up in that group and be taken to REC. We should all keep a close eye on the mailing list and respond to any questions as they come in. I've asked Guus and David (RDF WG chairs) what the next steps are.
Niklas Lindström is scribing.

Topic: ISSUE-114: JSON-LD Grammar

Manu Sporny: The grammar that Markus put together was reworked slightly and put into the spec here: http://json-ld.org/spec/ED/json-ld-syntax/20120522/#json-ld-grammar
Gregg Kellogg: issue is here: https://github.com/json-ld/json-ld.org/issues/114
Manu Sporny: took markus' revision, rewrote a bit to the language of the spec
… if we express the grammar in ebnf, people may have hard to follow what's going on
… gregg mentioned that there may be some controversial stuff in the grammae
Markus Lanthaler: some minor errors
… i'll go through it in the next couple of days
Gregg Kellogg: 21 and 22 might need some more discussions (perhaps some more)
Markus Lanthaler: @type under discussion: if we really allow an object
… and are we going to allow relative iri:s?
… (e.g. in compact form)
Gregg Kellogg: my processor handles relative in subjects and object, but not in predicates and datatypes
Gregg Kellogg: and @type handled like datatype: i.e. must be absolute
Manu Sporny: but what if there is a relative iri in there?
Gregg Kellogg: treated like a term - if not resolved or it's not an absolute iri, ignore it
… just like datatype: integer (not xsd:integer) would be ignored
Manu Sporny: should we have the exact same mechanism everywhere?
…: but there's a tradeoff, we don't want to generate faulty data
… but the authors need to understand where relative are allowed and where not
Gregg Kellogg: but we already do that with properties
… so why don't we treat a relative term like a relative iri?
… we want to be consistent
Niklas Lindström: I agree with gregg, these are orthogonal value spaces (predicates and types have different roles than subjects/objects); and it's the way all other rdf serializations work
Markus Lanthaler: "@type": "relativeornot"
Gregg Kellogg: not relative
Gregg Kellogg: "@id": "relativeornot"
Gregg Kellogg: relative
Manu Sporny: the latter is relative
Gregg Kellogg: that's how it works in RDFa
Niklas Lindström: I agree, I don't think it's a problem in practice
Manu Sporny: but the group that's going to use this don't have an RDF background
Gregg Kellogg: I think it will be clear
Manu Sporny: we could have a relative ref in @type; it's frowned upon but allowed
Gregg Kellogg: but this would confuse things a lot if we e.g. reintroduced @vocab
Markus Lanthaler: "@type": "/types/Person"
Gregg Kellogg: the current spec would drop that
Manu Sporny: we should make a distinction between best practice and allowed grammar
Gregg Kellogg: we can't give simple grammar rules for determining if somethings abs/relative; that's on another level [of semantics]
Manu Sporny: that's also why I'm concerned about using EBNF
Gregg Kellogg: then we shouldn't call it a "grammar"
Manu Sporny: markus want sometning explicit about whats syntactically allowed
… we need to figure out how a processor will report back what's allowed and not
Manu Sporny: normally, if a grammar is violated, the parser quits; but this is not the case, the json-ld spec explains how to continue (and possibly recover)
Gregg Kellogg: not entirely true in all cases.
Gregg Kellogg: we can have a formal grammar plus higher-level consistency rules
Niklas Lindström: I think that the JSON-LD spec can be defined using plain language as well - we don't have to formally define a grammar, we can just say that something is ignored. [scribe assist by Manu Sporny]
Manu Sporny: markus' list is simple enough and seems to cover what we need
Niklas Lindström: I think that we can approach this in the same way as the Atom spec - they have SHOULDs and MUSTs, but everything else is ignored. [scribe assist by Manu Sporny]
Niklas Lindström: You can throw in forbidden attributes anywhere, but they're ignored. They have an informative RelaxNG specification, parsers are not supposed to use it - it's just there for teaching purposes. [scribe assist by Manu Sporny]
Manu Sporny: we could e.g. turn true into "true"
Gregg Kellogg: but we should not allow bad data
Manu Sporny: true. that also seems to support not supporting relative iri:s in properties and @type
Manu Sporny: the grammar rules should perhaps be called authoring rules
Gregg Kellogg: json-ld processors should be able to process any json
[pushing back this to the list]
Manu Sporny: deferring issue 110 (too long to discuss today)

Topic: ISSUE-118: @graph support in framing

https://github.com/json-ld/json-ld.org/issues/118
Gregg Kellogg: we're sort of in the area of inventions; we need implementations to see the needs
Manu Sporny: yes, we need to allow implementations to evaluate the changes
… the other concern is that if we treat everything as flat, I don't want to paint ourselves into a corner
… to not prevent ourselves from future use cases
Manu Sporny: proposal right now is to put this in the back burner until we know what should be done (e.g. 3 different implementors tackling he situation)
Gregg Kellogg: what is really required for specific applications, and handle that in a separate framing spec...
Manu Sporny: if we make framing as complex as sparql is, it'll be hard to grasp. It should be a very basic query language.
… for right now, focus on really simple rest services; if people want to do complicated framing, they can implement it on top of the api
Markus Lanthaler: so you're arguing against e.g. value matching?
Manu Sporny: yes, for now..
Niklas Lindström: I wonder if these advanced scenarios go beyond what JSON-LD is for... aren't we just re-implementing the entire RDF stack if we support some of these more advanced use cases? [scribe assist by Manu Sporny]
Markus Lanthaler: but why did we introduce named graphs?
Manu Sporny: the reason for named graphs is more for [packaging the data] for e.g. signing
… we only need one named graph at a time in the document
Markus Lanthaler: but it's not the @graph, it's the value matching in framing that's more complex
Manu Sporny: yes, but we're adding nice-to-haves we haven't seen fully formed needs yet, and it'll add more rules for people to comprehend
PROPOSAL: defer @graph and, in general, value matching from the frame algorithm.
Niklas Lindström: +1
Manu Sporny: +1
Gregg Kellogg: +1
David I. Lehn: +1
Markus Lanthaler: +0 (want to work on a solution for this)
RESOLUTION: Defer @graph and, in general, value matching from the framing algorithm.

Topic: ISSUE-119: Aggressive embedding support

https://github.com/json-ld/json-ld.org/issues/119
Manu Sporny: how developers need to use data (looping over cycles etc.)
Manu Sporny: currently, you need to implement a "findSubjects"
… josh suggests "aggressive embedding"
… insert the same subject [and data of it] everywhere it's referenced, just cycles
Niklas Lindström: I've had this embed situation in 3 different contexts. 1) I've used a tree representation of an OWL ontology and tried to generate documentation from that, where labels need to be associated with classes - either the tree is going to be gigantic, or I have to back away from using a tree representation entirely and use a proper graph representation. [scribe assist by Manu Sporny]
Niklas Lindström: This is the general case for using Linked Data programmatically - unless I'm trying to render the tree in a flat way. Anytime I need a label for a link, or the context for a link - publisher, responsible person at publisher, etc. Any real-world situation of using this data, I need a graph in memory. Where I've found aggressive embedding useful, is when I've used a JSON-LD context... [scribe assist by Manu Sporny]
Manu Sporny: ...applied on a big chunk of data and related things and put that into Elastic Search.
Niklas Lindström: I can do very advanced filters, etc. - sort on date values for things referencing the current object - things like that. Those things invalidate the current document - need to filter on those dates. Need to see if they are active at the current time. So, I've seen both of these proposed solutions to the problem. [scribe assist by Manu Sporny]
Niklas Lindström: I think that we should actively explore both of them. [scribe assist by Manu Sporny]
Niklas Lindström: One is using JSON is indexing scenarios - very narrow usecase - but useful (MongoDB, Solr, Elastic Search). [scribe assist by Manu Sporny]
Niklas Lindström: Programmatically using Linked Data, you use in-memory graph of what you've gathered in order to walk it properly. Dereferencing the links must be easy in that case. [scribe assist by Manu Sporny]
Niklas Lindström: If I have a compact JSON-LD representation of a lot of vocabularies, I need labels for them all, it's straight-forward if I have a flat JSON-LD structure. [scribe assist by Manu Sporny]
Niklas Lindström: Properties are compacted, I have simple keys and I have @language to reduce to simple graph list - if I walk every property and put the object in place where there is a reference, that's a very simple loop and makes the data infinitely more useable in a template or programmatic usage. [scribe assist by Manu Sporny]
Markus Lanthaler: Josh Mandel has built an objectify() API call to create an in-memory graph: https://github.com/json-ld/json-ld.org/issues/109#issuecomment-5758808
David I. Lehn: https://github.com/digitalbazaar/jsonld.js/pull/15
David I. Lehn: in case you all didn't see JoshM's in memory graph experiment