Topic: JSON-LD pushed to RDF WG for review

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.

… 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

Topic: ISSUE-118: @graph support in framing

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

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