JSON-LD Telecon Minutes for 2012-02-28

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

http://json-ld.org/minutes/2012-02-28/

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

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

JSON-LD Community Group Telecon Minutes for 2012-02-28

Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2012Feb/0017.html
Topics:
    1. ISSUE-82: How are non-JSON-LD values in @context processed?
    2. ISSUE-68: Multiple graphs syntax
Resolutions:
    1. For non-JSON-LD values in @context, in general, they are
       ignored by JSON-LD processors. When compacting, the non-JSON-LD
       values can be removed. When expanding, the entire @context is
       removed and thus the non-JSON-LD values are removed.
    2. Override part of the decision made in ISSUE-56 - When
       performing expansion, non-JSON-LD values are not dropped from the
       document, but are ignored.
    3. The @graph keyword is used to express a collection of one
       or more JSON objects (to express a graph which may or may not be
       fully connected)
Chair:
    Manu Sporny
Scribe:
    Markus Lanthaler
Present:
    Markus Lanthaler, Niklas Lindström, Manu Sporny, Gregg Kellogg,
    David I. Lehn
Audio:
    http://json-ld.org/minutes/2012-02-28/audio.ogg

Markus Lanthaler is scribing.
Niklas Lindström:  Have we ever discussed if we allow arbitrary
    data in the term definitions in the context?
Manu Sporny:  What we do now is to just ignore it.. We should
    create an issue for that... created:
    https://github.com/json-ld/json-ld.org/issues/82
Niklas Lindström:  Will aliasing also apply to subsequent
    contexts?
Niklas Lindström:  We should just allow the use of aliased terms
    in the body and not in the context
Niklas Lindström: … {"@id": …, "@type": … }
Niklas Lindström:  If you look at something like this in the
    document it means somethings different than when it is in the
    context
Gregg Kellogg:  So?
Niklas Lindström:  Term def. are already special.. So we could
    handle it differently
Manu Sporny:  I think we should keep the number of special cases
    for these rules to a minimum, thus, I don't think we should
    handle this differently.
Manu Sporny:  Niklas, could you please create a separate issue
    for this?

Topic: ISSUE-82: How are non-JSON-LD values in @context processed?

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/82
Gregg Kellogg: As per the existing processor rules, they are
    ignored.
Manu Sporny:  They are removed when compacting and normalizing
    but remain intact when extending

PROPOSAL:  For non-JSON-LD values in @context, in general, they
    are ignored by JSON-LD processors. When compacting, the
    non-JSON-LD values can be removed. When expanding, the entire
    @context is removed and thus the non-JSON-LD values are removed.

Manu Sporny: Clarification: ... where non-JSON-LD is anything not
    recognized by a JSON-LD processor)
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +1

RESOLUTION: For non-JSON-LD values in @context, in general, they
    are ignored by JSON-LD processors. When compacting, the
    non-JSON-LD values can be removed. When expanding, the entire
    @context is removed and thus the non-JSON-LD values are removed.

Markus Lanthaler:  Well actually they are also removed in
    expansion as the whole context is removed.
Markus Lanthaler:  What about the decision we made to remove
    unknown keys from expansion?
    https://github.com/json-ld/json-ld.org/issues/56
Gregg Kellogg:  I don't think we need normalization for
    compaction or framing.
Manu Sporny:  I agree in the case of compaction, I don't think
    that is possible for framing... we'll have to chat with Dave
    Longley to figure out why he required normalization for both
    compaction and framing.
. . . discussion about whether compaction should depend on
    normalization or not . . .

PROPOSAL:  Override part of the decision made in ISSUE-56 - When
    performing expansion, non-JSON-LD values are not dropped from the
    document, but are ignored.

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

RESOLUTION: Override part of the decision made in ISSUE-56 - When
    performing expansion, non-JSON-LD values are not dropped from the
    document, but are ignored.

Topic: ISSUE-68: Multiple graphs syntax

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/68
Manu Sporny:  This is really a discussion about whether we want
    to have an array-form for @id or if we want to be more specific
    about how we express graphs that are not fully connected.
Gregg Kellogg:  Are we talking about named graphs or bushes?
Manu Sporny:  Bushs, but this solution should also work for named
    graphs... what we're really talking about are hedges... :P
Manu Sporny: If we have a graph that is a bush - we do this:
    "@graph": [{},{},{}] instead of this: "@id": [{},{},{}]
Manu Sporny: If we want to make that graph a named graph, we do
    this: { "@id": "_:graph_name", "@graph": [{},{},{}] } ... you can
    also assign properties to that named graph and support graph
    literals with that construct.
Manu Sporny:  I don't think we should go down the named graphs
    rathole yet... let's wait for the RDF WG to figure out what they
    want to do about it.
Gregg Kellogg: This is a good example of why we need "@graph":
    http://rdfainfo.digitalbazaar.com/test-suite/manifest.json
Niklas Lindström:  Our intent at the moment is not to support
    named graphs but to ensure that the syntax of bushes supports
    named graphs in the future
Niklas Lindström:  using @set instead of @graph has some appeal
    as discussed in the issue - it requires less theoretical
    background
Niklas Lindström: … {"dc:creator": {"@set": […]}}
Niklas Lindström: .. a set of objects vs. a quoted graph
Niklas Lindström: "@many"
Niklas Lindström: I don't think a @set is the same thing as a
    @graph, we shouldn't conflate the two concepts in an attempt to
    be clever.
Manu Sporny: @set is really an alias for [], right?
Gregg Kellogg:  Yes, except for when you use it for @type
    coercion.
Markus Lanthaler:  Why is a @graph in this context different from
    having a set with an @id applied to it? [scribe assist by Manu
    Sporny]
Niklas Lindström:  Depends on what you mean by "set" [scribe
    assist by Manu Sporny]
David I. Lehn:  does rdf:Bag terminology help here?
Manu Sporny:  I don't think it does - at least, not in a way that
    would be friendly to newcomers.
. } .
http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-list-elements
Markus Lanthaler:  If we add an @id to @set, is that a named
    graph? [scribe assist by Manu Sporny]
Manu Sporny:  That's not clear - it's not clear that @id applied
    to @set is the same as @id applied to @list is the same as @id
    applied to @graph. [scribe assist by Manu Sporny]
Niklas Lindström: A similar issue arises if we allow e.g. {"@id":
    …, "@value": ...}
Manu Sporny: Right now container could be one of these -
    "@container": @set | @list | @graph
Manu Sporny: When and how we use @set is really orthogonal to
    this issue. I think it's clear that a @set with an @id is not the
    same thing as a graph with an @id - I don't know what a @set with
    an @id is... but I am sure that it's not the same thing as a
    @graph with an @id. There is a separate issue here of whether we
    should be using @ordered/@unordered vs. @list/@set - but let's
    discuss that as a separate issue.

PROPOSAL:  The @graph keyword is used to express a collection of
    one or more JSON objects (to express a graph which may or may not
    be fully connected)

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

RESOLUTION: The @graph keyword is used to express a collection of
    one or more JSON objects (to express a graph which may or may not
    be fully connected)

Manu Sporny: Clarification: This does not mean that we have a
    named graph solution, but we do believe that it is
    forward-compatible with such a solution.
Manu Sporny: One could do something like this: {"@id":
    "_:graph0", "@graph": [{},{},{}] }
Gregg Kellogg:  Can we do something like this:
Gregg Kellogg: {"foo": {"@graph": {{}}} - basically, a graph
    literal?
Manu Sporny:  In the future, probably. We've just opened a
    Pandora's box of discussion about this... it affects
    normalization in a big way. We should be careful to restrict
    discussion about this for JSON-LD 1.0. We /may/ have a JSON-LD
    1.1, but for 1.0, we may only allow @graph at the top-level.

-- manu

-- 
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, 28 February 2012 19:53:15 UTC