JSON-LD Telecon Minutes for 2011-12-06

The minutes for yesterday's call are now available here, thanks to 
Niklas for scribing:

http://json-ld.org/minutes/2011-12-06/

Full text of the discussion follows:

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

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.


-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
Standardizing Payment Links
http://manu.sporny.org/2011/payment-links/

Received on Wednesday, 7 December 2011 07:01:50 UTC