JSON-LD Telecon Minutes for 2012-03-06

Thanks to Niklas for scribing! The minutes from today's call are now
available here:

http://json-ld.org/minutes/2012-03-06/

Full text of the discussion follows, as well as a link to the complete
audio transcript:

--------------------

JSON-LD Community Group Telecon Minutes for 2012-03-06

Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2012Mar/0002.html
Topics:
    1. ISSUE-44: Support for @set coercion
    2. ISSUE-52: Lists of lists
    3. ISSUE-74: IRI compaction/expansion conflicts
Resolutions:
    1. Adopt the "@container": "@set" syntax when used in a
       JSON-LD context to specify that a term is associated with a set
       of values.
    2. When the "@container": "@set" syntax is used in a JSON-LD
       context for a term definition within the framing algorithm, the
       resulting term will be associated with a JSON array.
    3. Lists of lists are not allowed for JSON-LD 1.0. If a list
       of lists is detected, the JSON-LD processor MUST throw an
       exception.
Chair:
    Manu Sporny
Scribe:
    Niklas Lindström
Present:
    Niklas Lindström, Manu Sporny, Markus Lanthaler, Gregg Kellogg,
    Ted Thibodeau Jr., David I. Lehn
Audio:
    http://json-ld.org/minutes/2012-03-06/audio.ogg

Niklas Lindström is scribing.
Manu Sporny:  Issues for today are 44, 52, 74, 76 - any updates
    or changes to the agenda?
Niklas Lindström: Issue 76 now references
    https://github.com/json-ld/json-ld.org/issues/84
Niklas Lindström:  Covers support for controlled probing of
    unlinked objects
Niklas Lindström:  In short, this is a way to parse values of
    things referenced by null terms (terms that are not bound to
    anything in the context) [scribe assist by Manu Sporny]
Niklas Lindström:  This is more to allow terms to be null, but
    still allow their contents to be parsed. [scribe assist by Manu
    Sporny]
Manu Sporny:  We'll keep this in mind today but might not have
    time to discuss it (84)

Topic: ISSUE-44: Support for @set coercion

Ted Thibodeau Jr.:
    https://github.com/json-ld/json-ld.org/issues/44
Manu Sporny:  this has been having out the for quite a while
    ... josh wanted to process data structures and have a
    consistent way of parsing each item
    ... for instance, if you encounter a telephone number, you
    always want to know the value is a list
    ... we already have @container: @list, we can add @container:
    @set as well
Markus Lanthaler:  I think he initially wanted this in framing
Manu Sporny:  he found this to be wider than only for framing
Niklas Lindström:  I'm not sure if he widened it to more than
    framing, but I think this is related to general context
    definitions. [scribe assist by Manu Sporny]
Niklas Lindström:  I think it originated in framing, that's where
    he takes a graph and creates JSON from it - in his case, he
    applies a frame. In my case, I don't apply a frame, I just apply
    a context to my graph data. I have this same need. [scribe assist
    by Manu Sporny]
Niklas Lindström:  The need I have is to define a context that
    ensures that I have a predictable shape for the data. [scribe
    assist by Manu Sporny]
Niklas Lindström:  My primary data view is part of my construct -
    I have a predefinied view of a resource - I know how many nodes
    down there is. I have a limited graph. I apply the JSON-LD
    context to that limited graph. Then I know what the data looks
    like. [scribe assist by Manu Sporny]
Markus Lanthaler:  We could make it possible if we say that a
    list or a set always has to be an array. [scribe assist by Manu
    Sporny]
Manu Sporny: ack: lanthaler
Markus Lanthaler:  I think that the thing you're using @context
    for something they're not really used for. [scribe assist by Manu
    Sporny]
    ... discussion about how predictable json you can get from
    graphs
Markus Lanthaler:  I think you're translating RDF data to JSON
    using the @context - that's usually used to transform JSON to
    RDF. [scribe assist by Manu Sporny]
Niklas Lindström:  I don't need frames for this. [scribe assist
    by Manu Sporny]
Markus Lanthaler:  How do you tell your customers what the shape
    of the data is? [scribe assist by Manu Sporny]
Markus Lanthaler:  How do you tell your customers what the
    structure of the JSON-LD document is? Are they really using
    JSON-LD or are they just using the JSON part of JSON-LD? [scribe
    assist by Manu Sporny]
Niklas Lindström:  They're just using the JSON I give them.
    [scribe assist by Manu Sporny]
Markus Lanthaler:  So, there is external documentation? [scribe
    assist by Manu Sporny]
Niklas Lindström:  There isn't - the customers just look at the
    service and use the record - if properties are missing, there is
    no problem - if they see a list, they know it's a list. If they
    see one value, they see one value. [scribe assist by Manu Sporny]
Markus Lanthaler:  If you don't specify that in JSON-LD, but you
    generate the JSON-LD in a particular way, then it would be
    compliant to the spec, right? [scribe assist by Manu Sporny]
Niklas Lindström:  Yes. However, it would be nice to just
    generate this from the JSON-LD processor. [scribe assist by Manu
    Sporny]
Manu Sporny:  You could just use a JSON-LD frame for this, right?
    [scribe assist by Manu Sporny]
Niklas Lindström:  Going from a simple context to JSON-LD frames
    would require me to write some 20-odd frames.... It would be more
    complexity for me to handle. We could just use @container: @set
    and be done with it. [scribe assist by Manu Sporny]
Gregg Kellogg:  I do see value in "@container": "@set" in
    JSON-LD. [scribe assist by Manu Sporny]
Gregg Kellogg:  It's not clear where other than in framing
    @container: @set would be applied
Manu Sporny:  if @container: @set is specified in the context,
    key values in the document that match that term much be given in
    an array
Gregg Kellogg:  It's not clear to me where the proposal is - we
    could look at expansion/compaction - the only place we could
    really apply this is framing. My RDF to JSON-LD translator could
    frame the data with that algorithm - where do we want this?
    [scribe assist by Manu Sporny]
Manu makes a proposal... introduce @set, it only has an effect
    during compaction. If used in compaction in the context, the
    result is an array.
Niklas Lindström:  If you use @container: @set - you should use
    an array to encapsulate the data. [scribe assist by Manu Sporny]
Niklas Lindström:  I see no harm in parsing it anyway... [scribe
    assist by Manu Sporny]
Markus Lanthaler:  Would it be possible to say @container: @set
    maps to empty frames? [scribe assist by Manu Sporny]
Niklas Lindström:  You mean that @container: @set would only be
    meaningful in frames? [scribe assist by Manu Sporny]
Markus Lanthaler:  Yes... [scribe assist by Manu Sporny]
Niklas Lindström:  I think that solves it for me. [scribe assist
    by Manu Sporny]
Manu Sporny:  that would mean that any algorithm should through
    an exception if single values for container-set terms are
    encountered?
    ... we don't want to put unnecessary restrictions on regular
    JSON-LD with @set
Gregg Kellogg: I agree, we should keep constraints on @container:
    @set to Framing.
Manu Sporny:  the other option would be to add a new API call,
    e.g. "jsonld.listify()", which would turn every value in a
    document into a list
Niklas Lindström:  Just want to make sure that if you have this -
    "references": {"@container" :"@set"}
Niklas Lindström:  Then this - "references": "iri-1"
Niklas Lindström:  Will be turned into this - "references":
    ["iri-1"]
Manu Sporny:  it seems we have consensus on adopting @set in this
    manner. The other question is if we like this syntax proposed by
    Markus:
"@context": {
"property1": { "@id": "something1", "@type": "@list" },
"property2": { "@id": "something2", "@type": [ "@list",
    "xsd:date" ] }
}
    ... this context only applies when we frame the data
Gregg Kellogg:  we have discussed this before, and came to the
    conclusion that @container was more consistent with the rest of
    json-ld
Markus Lanthaler:  so @type cannot take arrays in contexts?
Manu Sporny:  yes, remember that @type means something different
Manu Sporny:  @type in the context is used to set the datatype of
    the property
Ted Thibodeau Jr.: perhaps put them onscreen?
    … discussion on if framing has to go normalization

PROPOSAL:  Adopt the "@container"; "@set" syntax when used in a
    JSON-LD context to specify that a term is associated with a set
    of values.

Niklas Lindström: +1
Markus Lanthaler: +1
Manu Sporny: +1
David I. Lehn: +1
Ted Thibodeau Jr.: +1
Gregg Kellogg: +1

RESOLUTION: Adopt the "@container": "@set" syntax when used in a
    JSON-LD context to specify that a term is associated with a set
    of values.

Clarification that at this point this is merely annotational -
    i.e. introduces the @set keyword

PROPOSAL:  When the "@container"; "@set" syntax is used in a
    JSON-LD context for a term definition within the framing
    algorithm, the resulting term will be associated with a JSON
    array.

Niklas Lindström: +1
Ted Thibodeau Jr.: +1
Manu Sporny: +1
Markus Lanthaler: +1
David I. Lehn: +1
Gregg Kellogg: +1

RESOLUTION: When the "@container": "@set" syntax is used in a
    JSON-LD context for a term definition within the framing
    algorithm, the resulting term will be associated with a JSON
    array.

Topic: ISSUE-52: Lists of lists

Ted Thibodeau Jr.:
    https://github.com/json-ld/json-ld.org/issues/52
Manu Sporny:  Dave Longley's suggestion is to disallow lists in
    lists for the time being (throw exception), and revisit this in
    the future if needed
Manu Sporny:  anyone in need of lists of lists?
Markus Lanthaler:  no, I'm fine without it
Gregg Kellogg:  we haven't found any good use cases, and it would
    add a lot of complexity

PROPOSAL:  Lists of lists are not allowed for JSON-LD 1.0. If a
    list of lists is detected, the JSON-LD processor MUST throw an
    exception.

Markus Lanthaler: +1
Niklas Lindström: +1
Ted Thibodeau Jr.: +1
Gregg Kellogg: +1
Manu Sporny: +1
David I. Lehn: +1

RESOLUTION: Lists of lists are not allowed for JSON-LD 1.0. If a
    list of lists is detected, the JSON-LD processor MUST throw an
    exception.

Topic: ISSUE-74: IRI compaction/expansion conflicts

Ted Thibodeau Jr.:
    https://github.com/json-ld/json-ld.org/issues/74
Gregg Kellogg:  the issue is if you have to terms which map to
    the same IRI, when you expand, you know have one key where there
    used to be two; when you compact, it is unclear what to do
Markus Lanthaler:  the problem can also occur since you can use
    full IRIs as keys in documents even if there is a term for it in
    the context
Markus Lanthaler:  on compaction, values with different datatypes
    should be divided between two terms with different coercion
Manu Sporny:  we can't do "last key" wins (json keys aren't
    ordered)
Manu Sporny:  we could use the more specific rule
    ... the problem is when we have e.g. one xsd:integer and one
    xsd:decimal
Gregg Kellogg:  there is no problem with e.g. xsd types; we
    already have specific types for values at this time
Manu Sporny:  we currently have a non-determinism
    ... we can make the decision based on specificity
David I. Lehn: agenda did say 120 mins :)
Manu Sporny: The intent for how IRI conflicts are resolved when
    compacting/expanding: any conflicts between terms that use the
    same IRI will use the most specific solution when compacting (for
    example, when compacting "foo": "5" and having to pick between a
    term that specifies "xsd:integer" as the type and one that
    doesn't, the one that specifies "xsd:integer" is selected)
Manu Sporny: If there is no solution that is more specific than
    the other, then a lexicographical comparison is made between the
    terms in the @context and the lexicographically least term and
    it's associated @type and other information is used to expand the
    data.
Manu Sporny: When expanding multiple keys that resolve to the
    same IRI, the expanded value will have all of the values
    associated with the IRI merged into a single JSON array.
Manu Sporny: (the order of the values in the resulting JSON array
    is undefined)
Niklas Lindström: +1 on the intent ;)
Gregg Kellogg: +1 on the intent too
Markus Lanthaler: +1
Manu Sporny: +1 on the intent
David I. Lehn:  Good call, bye.
(we should also take @container into account regarding
    specificity)
Gregg Kellogg: +1 to @container as part of selection

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/

Received on Tuesday, 6 March 2012 16:44:16 UTC