JSON-LD Telecon Minutes for 2012-03-13

The minutes from today's call are now available here:

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

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-13

Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2012Mar/0006.html
Topics:
    1. ISSUE-76: Use of null in JSON-LD
    2. ISSUE-79: Define how empty arrays are handled
Resolutions:
    1. Unless otherwise specified, when 'null' is used in the
       @context, it removes any definition associated with the key.
    2. If @context is set to 'null', then the active context is
       cleared or set to the initial context (depending on the
       resolution to ISSUE-80)
    3. Unless otherwise specified, if 'null' is associated with a
       key in the body of a JSON-LD document, then the JSON-LD processor
       MUST act as if the key-value pair was never declared. If @value
       or @list is set to null in expanded form, then the entire JSON
       object is ignored.
    4. If an empty array ([]) used as a value is not subject to
       @list coercion, then the value MUST be removed from normalized
       output. The empty array MUST be preserved in compacted and
       expanded output.
    5. When normalizing, anything that is not coerced to a @list
       container type that has an empty array for its value is removed
       from the normalized output.
    6. When compacting and expanding, anything that is coerced to
       a @set or a @list container type that has an empty array for its
       value is preserved in the compacted and expanded output.
    7. Unless otherwise specified, when performing the expansion
       algorithm all values must be contained in a JSON array structure.
       This does not apply to values for syntactic keys such as @value,
       @language, @id, and @type when used to specify a datatype.
    8. When compacting, anything that is coerced to a @set or a
       @list container type has its values put into an array in the
       compacted output, even if there is only one value.
Chair:
    Manu Sporny
Scribe:
    Manu Sporny
Present:
    Manu Sporny, Niklas Lindström, Markus Lanthaler, Gregg Kellogg,
    David I. Lehn
Audio:
    http://json-ld.org/minutes/2012-03-13/audio.ogg

Manu Sporny is scribing.
Manu Sporny:  Any changes to the Agenda?
Niklas Lindström:  I got a question over e-mail... regarding
    ISSUE-44
Niklas Lindström:  Using "@container": "@set" in framing - Josh
    Mandel asked me if the consequence is if this didn't have any
    effect in compaction.
Manu Sporny:  I think we said that the only place it matters is
    in framing.
Markus Lanthaler:  I think that's the last issue we're discussing
    today.
Niklas Lindström:  I asked Josh to comment, if he doesn't - I'll
    put something in that issue. It might be useful to support the
    list via @list and @set construct in compaction.
Markus Lanthaler:
    https://github.com/json-ld/json-ld.org/issues/84
Manu Sporny:  We've had reviews by Oracle and W3C staff, they
    have some minor comments but are happy with the documents
    overall. We need to change the feedback into issues and discuss
    them - nothing major, mostly minor questions on JSON-LD usage.

Topic: ISSUE-76: Use of null in JSON-LD

https://github.com/json-ld/json-ld.org/issues/76
Manu Sporny:  There are two ways null can be used in JSON-LD...
    in the @context and in the body of the document. I think we found
    consensus last time by stating that if 'null' is used in the
    value position in the body of the document, then a processor must
    ignore the key-value pair. If null is used in the @context, it
    has a number of different effects:
Manu Sporny:  Clear the active context: "@context": null and
    "@context:" [null, ...]
Manu Sporny:  Clear a term/prefix declaration: "term": null,
Manu Sporny:  Clear the datatype associated with a term: "term":
    {"@id": "http://example.org/term", "@type": null}
Manu Sporny:  Clear the language associated with a term: "term":
    {"@id": "http://example.org/term", "@language": null}
Manu Sporny:  Clear the container type associated with a term:
    "term": {"@id": "http://example.org/term", "@container": null}
Niklas Lindström:  I believe that the last 3 mean the same thing
    is if you define a term w/o a @type/@language/or @container.
Gregg Kellogg:  Yes, I think so.
Niklas Lindström: People might want to use @language to do
    "title_en" and "title_sv"
Niklas Lindström:  Should language mean something there? We've
    never used it in a @term definition before, right?
Gregg Kellogg:  Why don't we create an issue for this and discuss
    it later.
Markus Lanthaler:  "@id": null: clear the whole term declaration.
    What if that it's in the body? (see also #84)
Markus Lanthaler:  Perhaps we should also define what happens if
    something like { "@value": null, "@language": "de" } is in the
    document.. I assume we just discard the wholetyped/language-tagge
    d literal.
Markus Lanthaler:  The same for lists? Or should "@list": null"
    result in an empty list? (this is probably related to #79)
Gregg Kellogg:  @set is not used in the body, only the @context.
Markus Lanthaler:  Maybe we should discuss that as well - another
    issue.
Gregg Kellogg:  my opinion - @id: null causes the object to be
    ignored - in @context should be equivalent to term null.
Gregg Kellogg:  Within the body, if you use @id: null - then the
    object has no definition.
Manu Sporny:  I think @id: null should mean "no id", not "no
    object" - it should generate a bnode.
Niklas Lindström:  If you use @id: null for a term, we have an
    open question on whether or not that term should be possible to
    use in ISSUE-84.
Manu Sporny:  I think we should discard the whole object for {
    "@value": null, "@language": "de" }
Markus Lanthaler:  yes
Markus Lanthaler:  @list: null should discard everything as well.

PROPOSAL:  Unless otherwise specified, when 'null' is used in the
    @context, it removes any definition associated with the key.

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

RESOLUTION: Unless otherwise specified, when 'null' is used in
    the @context, it removes any definition associated with the key.

Niklas Lindström: (.. I've created
    https://github.com/json-ld/json-ld.org/issues/85 about using
    @language in term definitions.)
Discussion about how this applies to @context
Discussion about initial context - what should we have in there?
Markus Lanthaler:  Can you override those values in the initial
    context?
Gregg Kellogg:  yes.
Gregg Kellogg:  I think the key is to treat this uniformly... I
    think @type taking and @id.
Markus Lanthaler:  Well @id and @type are special cases, we don't
    need them in the initial context.
Gregg Kellogg:  My processor would pay attention to this.
Niklas Lindström:  I think that @id has an intricate meaning,
    @type when it's used as datatype is fine... but @type as it is
    used as rdf:type could be in the initial context. It is an alias
    for rdf:type. We may want to raise an issue about @type - I think
    Josh Mandel asked that now we have @container: @set - if you
    could define @type to always be of type @container: @set.
Niklas Lindström:  Another case - if you don't want rdf:type to
    have @coerce @id on them, which we have now, you may want to have
    a plain object w/ a URI for the type... or label for the type.
    There are certain use cases that warrant this. You might want to
    define a term for @type. It might be good to clear the default
    definition by setting "@type": null in initial context.
Markus Lanthaler:  That would change JSON-LD completely.
Niklas Lindström:  If we don't go in this direction we can't
    support all of RDF.
Manu Sporny:  A bit confused...
Niklas Lindström: { "@type": null, "type": {"@id": "rdf:type",
    "@container": "@set"} }
Niklas Lindström:  That is in the context definition - if you
    want to redefine @type.
Niklas Lindström: { "@type": {"@id": "rdf:type", "@type": "@id"}
    }
Niklas Lindström:  That is the initial context definition.
Markus Lanthaler:  You wouldn't need to reset @type.
Niklas Lindström:  If you don't reset @type, then we don't know
    what compaction would do.
Manu Sporny:  Let's tackle this initial context issue later, we
    already have an issue for it...

PROPOSAL:  If @context is set to 'null', then the active context
    is cleared or set to the initial context (depending on the
    resolution to ISSUE-80)

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

RESOLUTION: If @context is set to 'null', then the active context
    is cleared or set to the initial context (depending on the
    resolution to ISSUE-80)

PROPOSAL:  If 'null' is associated with a key in the body of a
    JSON-LD document, then the JSON-LD processor MUST act as if the
    key-value pair was never declared. If @value or @list is set to
    null in expanded form, then the entire JSON object is ignored.

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

RESOLUTION: Unless otherwise specified, if 'null' is associated
    with a key in the body of a JSON-LD document, then the JSON-LD
    processor MUST act as if the key-value pair was never declared.
    If @value or @list is set to null in expanded form, then the
    entire JSON object is ignored.

Topic: ISSUE-79: Define how empty arrays are handled

https://github.com/json-ld/json-ld.org/issues/79
Gregg Kellogg:  Last time I spoke about this, I mis-spoke - empty
    arrays should be removed from normalization if they are not a
    @set or @list.
Gregg Kellogg:  How do we preserve it if we're a set.

PROPOSAL:  If an empty array ([]) used as a value is not subject
    to @list coercion, then the value MUST be removed from normalized
    output. The empty array MUST be preserved in compacted and
    expanded output.

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

RESOLUTION: If an empty array ([]) used as a value is not subject
    to @list coercion, then the value MUST be removed from normalized
    output. The empty array MUST be preserved in compacted and
    expanded output.

Discussion around whether we should support the preservation of
    [] for @set.
Gregg Kellogg:  I don't see a compelling reason here - it's
    incompatible with RDF, we'd have to invent something new to
    preserve it. If we create something new, then we'd have an issue
    when we went down to triples.
Markus Lanthaler:  Is an empty set different from an empty list?
    From a developers point of view?
Manu Sporny:  I think developers that know RDF will see a
    difference between empty set and empty list, those that don't -
    won't.
Gregg Kellogg:  I think framing is what they use this stuff for.
Markus Lanthaler:  All of this applies to lists as well - why
    should they be any different.
Niklas Lindström:  An empty set of triples is nothing.
Niklas Lindström: s/is/says/ really. :)
Gregg Kellogg:  We have a graph model - that is one of the
    limitations of graphs - they can't represent the absence of
    information.
Gregg Kellogg:  The only way to do this would be to construct
    some meta-node... a vertex that had meaning outside of RDF.
Niklas Lindström: .. NOT EXISTS { ?s ex:term ?o }
Manu Sporny:  Is there an argument here for preserving @set [] in
    compaction?
Niklas Lindström:  I think so
Gregg Kellogg:  I'm supportive of that.
Manu Sporny:  Would we mess w/ the document structure?
Gregg Kellogg:  let's say we have a @container: @set - do we
    change to array form when compacting
Manu Sporny:  So in expansion do we keep @set?
Niklas Lindström:  I don't think so... I think @set is removed
    when expanding.
Gregg Kellogg:  The idea would be that general expansion
    algorithm, when expanding values not in array form, would put
    them into array form. When compacting, you can always count on
    the fact that values are in array form.
Gregg Kellogg:  In expanded form, all values are in an array. In
    compacted form, we compact down to whatever is the simplest.
Markus Lanthaler:  You lose the empty @set when doing
    normalization.

PROPOSAL:  When normalizing, anything that is not coerced to a
    @list container type that has an empty array for its value is
    removed from the normalized output.

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

RESOLUTION: When normalizing, anything that is not coerced to a
    @list container type that has an empty array for its value is
    removed from the normalized output.

PROPOSAL:  When compacting and expanding, anything that is
    coerced to a @set or a @list container type that has an empty
    array for its value is preserved in the compacted and expanded
    output.

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

RESOLUTION: When compacting and expanding, anything that is
    coerced to a @set or a @list container type that has an empty
    array for its value is preserved in the compacted and expanded
    output.

Niklas Lindström: .. values for syntactic keys: @value,
    @language, @id, and @type *when used for a datatype*..

PROPOSAL:  Unless otherwise specified, when performing the
    expansion algorithm all values must be contained in a JSON array
    structure. This does not apply to values for syntactic keys such
    as @value, @language, @id, and @type when used to specify a
    datatype.

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

RESOLUTION: Unless otherwise specified, when performing the
    expansion algorithm all values must be contained in a JSON array
    structure. This does not apply to values for syntactic keys such
    as @value, @language, @id, and @type when used to specify a
    datatype.

Niklas Lindström: .. should we propose:" When compacting,
    anything that is coerced to a @set or a @list container type has
    its values put into an array in the compacted output, even if
    there is only one value."?

PROPOSAL:  When compacting, anything that is coerced to a @set or
    a @list container type has its values put into an array in the
    compacted output, even if there is only one value.

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

RESOLUTION: When compacting, anything that is coerced to a @set
    or a @list container type has its values put into an array in the
    compacted output, even if there is only one value.

Manu Sporny:  I think we may want to move this to W3C...
Manu Sporny:  Maybe in a month.
Gregg Kellogg:  Lots of spec updates to make, but we should be in
    good shape.
Super-session planned for next Tuesday.
Niklas Lindström: This is interesting:
    http://www.infoq.com/news/2011/12/mongograph-qa
David I. Lehn: See all of you next week.

-- 
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, 13 March 2012 17:25:47 UTC