JSON-LD Community Group Telecon

Minutes for 2011-12-06

Agenda
http://lists.w3.org/Archives/Public/public-linked-json/2011Dec/0026.html
Chair
Manu Sporny
Scribe
Niklas Lindström
Present
Niklas Lindström, Manu Sporny, Markus Lanthaler, Gregg Kellogg, David I. Lehn
Audio Log
audio.ogg
Niklas Lindström is scribing.

Topic: ISSUE-8: Optimizing Compact Form

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/8
Manu Sporny: different people believe that compact form means different things
Manu Sporny: flags to the API allows for different ways of compacting
... can use context in doc or explicitly passed context to compact as much as possible
… people (e.g. joe presby) want something else
... to modify the context based on content (adding @iri coercion etc.) to get the most compact repr. possible
Markus Lanthaler: that would mean that context would be modified?
Manu Sporny: yes, modified/optimized
Gregg Kellogg: do this in my impl.
… using prefixes… It is useful to intuit patterns which can be used in the context
... to detect useful patterns that can help compact the expression of the document.
Niklas Lindström: Haven't spent a whole lot of time looking at it, but one thought is that automatic compaction in the spec might give the impression that the various kinds of data forms are more volatile than they often are. [scribe assist by Manu Sporny]
Markus Lanthaler: from the current spec: Compaction is the process of taking a JSON-LD document and applying a context such that the most compact form of the document is generated. [http://json-ld.org/spec/latest/json-ld-api/#compaction]
Niklas Lindström: I define a context and process data to intuit a good context - that's a good thing, but once I have my context, that defines the shape of my data. I will never change it once I stabilize my API. [scribe assist by Manu Sporny]
Niklas Lindström: Not a criticism, but not sure where in the order of importance it should be placed. There may be other things that are more important to nail down and specify than this. [scribe assist by Manu Sporny]
Niklas Lindström: For example, the API [scribe assist by Manu Sporny]
Manu Sporny: agree that some things might be more important; but we're at a point where the issues have to be cleared out
… compaction is a fairly simple concept
… this is about taking that and adding some flags to control it
… one question is: do all processors have to do compaction in the same way?
… one arg: as long as triples are the same, everything's ok; counter: consumers using different processors might lead to issues
Gregg Kellogg: compaction is something of a special case
… if you need to use JSON-LD properly, you need something like frames
… compaction use cases are a little more fuzzy
… useful to provide a representation as terse as possible
… variations between processors not as important
… good comparisons should use triples or normalized forms
David I. Lehn: would compaction produce different structure depending on the data itself? i'm trying to think of cases where it might. that would be weird from a user standpoint.
Manu Sporny: so you're argument is that not all processors need to compact in the same way, as long as they take the same args/flags
... and I agree with that approach.
Niklas Lindström: Yes, I agree as well. I think that something like framing, or anchoring the data w/ a particular subject, for all but the most circular edge cases, it plays out pretty simply [scribe assist by Manu Sporny]
Niklas Lindström: That shape could be specified by frames or by example in documentation, it may be enough to get good use out of JSON-LD. This is why I'm less concerned about compaction in the specs. [scribe assist by Manu Sporny]
Niklas Lindström: I understand parts of it... what the spec includes vs. what the spec. [scribe assist by Manu Sporny]
Manu Sporny: Compaction is just an API thing... [scribe assist by Manu Sporny]
Niklas Lindström: I only need the Syntax document... only really interested in that at that time. Could we focus on that first? [scribe assist by Manu Sporny]
Gregg Kellogg: I don't think that we can do one without the other
Manu Sporny: changes in the API might affect the syntax
… we may need to put a hint of how compaction happens
Manu Sporny: that's might be a valid way to look at it
Gregg Kellogg: JSON-LD is different; the API is part of it. Compare also framing with SPARQL..
… there's a danger if we separate the two
… changing the syntax would make the API out of date
Manu Sporny: one approach is to take a hybrid approach
… if the API needs a syntax change, what to do..
… goal: syntax really stable and API fairly stable
… but we should not hold up the syntax based on the normalization algorithm
… but when it comes to compaction, we need to go through that first
Markus Lanthaler: but you could still do it even if there's no specified API
Gregg Kellogg: a syntax doc that doesn't describe how to get RDF out of it would be a waste of time
Niklas Lindström: Worried about having RDF conversion algorithm in the API document. Rather see that one in the syntax document. Syntax is about representation of data. RDF conversion articulates that. API document uses interface definitions on how to do programmatic representation. That is going too far, I think. Lots of people like to implement JSON-LD without looking at the interface definitions.... [scribe assist by Manu Sporny]
Manu Sporny: ...Syntax document isn't enough to implement RDF conversion, you need to see the normative algorithm to do so.
Manu Sporny: the API outlines all the algorithms that you have to use
... defines how to process the data
… whichever group takes this aboard need to have these three documents
… it's fine to have the syntax doc a good 6 months ahead of the API
… it's not as this stuff hasn't been implemented
… we should just focus on the issues, not where they belong
Niklas Lindström: We should go through the issues and discuss on the list if we need to change the order of this stuff. [scribe assist by Manu Sporny]
Gregg Kellogg: the RDF conversion is a little different than the rest of the API things
… the algorithm is separate from the API
... a processor not using the API should still be able to extract RDF
... back and forth
... we could extract that algorithm
Niklas Lindström: I agree
Markus Lanthaler: isn't the syntax document clear on how to view JSON-LD as RDF?
Manu Sporny: that's true, except that it's not spelled out (which is required for this to become e.g. a W3C spec)
Gregg Kellogg: no, the paragraphs in the syntax doc isn't enough
Markus Lanthaler: we removed the heavy RDF-specific stuff from the syntax; it's not a good idea to add that back
Gregg Kellogg: we do have some examples using turtle. without putting the algorithm in there, we might need some informal exposition of how to though
Manu Sporny: agree with Markus, that we did lots of work to remove the deep RDF specifics
... from the syntax doc
… back to issue 8
… we have fair consensus to allow processors to do compaction any way they see fit
… some common, specified flags are enough (a bunch of optimization parameters to an API call)
… as far as how to to it, we leave it up to the APIs
Markus Lanthaler: we shouldn't think too much about the parameters: one would be enough ('optimize')
Manu Sporny: joe have asked us to specify how to tweak the optimization
… people might want to pick and choose
Markus Lanthaler: it might prevent people to do more optimizations than we specifiy
Manu Sporny: maybe go back to joe presby and ask if an optimize flag would be enough
… or we can have a set of optimizations and say that processors can have other options as well
Markus Lanthaler: if we specify, it means we expect output from parameter settings
Gregg Kellogg: the point for the proposal is that automatic is not defined, but compaction must be done using the provided @context
PROPOSAL: JSON-LD processors MUST implement the compaction API. The algorithm for compaction optimization is not defined. There is an 'optimize' flag that can be set to true or false to enable compaction optimization.
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
David I. Lehn: +0
Niklas Lindström: +1
David I. Lehn: if optimization is undefined, people won't know that output data to expect when optimizing
Manu Sporny: order of json keys exemplifies lehn's concern
RESOLUTION: JSON-LD processors MUST implement the compaction API. The algorithm for compaction optimization is not defined. There is an 'optimize' flag that can be set to true or false to enable compaction optimization.

Topic: ISSUE-14: Remove MIME type parameter option "form=framed" from spec

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/14
Manu Sporny: it has been proposed to specify that a document is 'framed'
… this is different from saying that the doc is a frame; it says that the document is output from using a frame
… we only needed it for testing
Markus Lanthaler: completely agree. it doesn't tell us anything about the document
PROPOSAL: Remove the MIME type parameter for form="framed" from the spec.
Markus Lanthaler: +1
Niklas Lindström: +1
Gregg Kellogg: +1
Manu Sporny: +1
David I. Lehn: +1
RESOLUTION: Remove the MIME type parameter for form="framed" from the spec.

Topic: Are @subject and @iri redundant?

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/15
Gregg Kellogg: "@subject" as syntactic sugar can be accomplished by "@subject": "@iri" in the context...
Niklas Lindström: I agree
Niklas Lindström: I agree
Markus Lanthaler: @iri is not just to specify an IRI, we use it as a datatype. @iri is a special case. I don't know if it is really that clear for an author. [scribe assist by Manu Sporny]
Gregg Kellogg: Using @subject as semantic-sugar for @iri allows for the clarity of use, but may simplify processing.
Gregg and Niklas are accidentally disconnected by their VoIP provider with 5 minutes left in the telecon... the call ends. Next telecon in one week.