JSON-LD Telecon Minutes for 2012-01-31

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

http://json-ld.org/minutes/2012-01-31/

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

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

JSON-LD Community Group Telecon Minutes for 2012-01-31

Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2012Jan/0102.html
Topics:
    1. ISSUE-43: Use of IRIs and CURIEs as @context keys
    2. ISSUE-56: JSON keys that are not terms
    3. ISSUE-52: Should we support lists of lists?
Resolutions:
    1. When processing keys in a JSON-LD document, ignore keys and
       do not process the subtree for keys that do not have a mapping in
       the @context. When compacting and expanding, drop keys that do
       not have mappings from the output.
    2. Mapping a key to _null_ removes a mapping for that key
       in the active context
    3. A term can only be redefined, never partially reconfigured
Chair:
    Manu Sporny
Scribe:
    Niklas Lindström
Present:
    Niklas Lindström, Manu Sporny, Gregg Kellogg, Markus Lanthaler,
    David I. Lehn

Niklas Lindström is scribing.
Manu Sporny:  any updates to the agenda?
Gregg Kellogg: ISSUE-43 and ISSUE-53 -
    https://github.com/json-ld/json-ld.org/issues/43
Markus Lanthaler:
    https://github.com/json-ld/json-ld.org/issues/53
Gregg Kellogg:  we need to discuss issue 43 and 53
    … 43 we resolved it last week, but we came into problems with
    compaction
    … with so many different options, choosing the compaction is
    tricky; e.g. some value sets might have to be split into two,
    with different keys based on coercion
Issue 53 is normalization and the consequences of splitting it
    off into a different spec - based on RDF specifics
Manu Sporny:  Let's focus on the syntax spec first; api spec
    needs more work

Topic: ISSUE-43: Use of IRIs and CURIEs as @context keys

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/43
Gregg Kellogg:  the consequences of having multiple mappings to a
    single [property] iri
    … with different coercion rules, you use different terms with
    the same IRI depending on object value
    … upon expansion, these two value lists are merged
    … if you've got a date and an integer value, you need to
    compact into two different keys or ...
    … this is beyond what we intend to do
Manu Sporny:  so the way we've defined the context is more
    complex; before the mapping was simple (iri - definition (term,
    opt coercion)
    … now, the mapping is from term to iri and coercion combined;
    and we do a string check for term (lexical first)
    … there's no ambiguity though; only more complex?
Gregg Kellogg:  before, when you process the context, you used
    the expanded IRI, not the lexical value of the "term"
Markus Lanthaler:  I don't think it was really that clear before
    … that issue didn't come up now, it was there before
    ... but from a syntactic level, we can't handle it; we can
    only specify rules to prevent ambiguity
Niklas Lindström:  I'm not sure if I'm following - clarification
    - the problem here is not that there can be different terms for
    different coercion values w/ the same IRI. [scribe assist by Manu
    Sporny]
Gregg Kellogg:  The problem comes when you apply that to
    expansion and compaction algorithms. [scribe assist by Manu
    Sporny]
Gregg Kellogg:  if you specify two mappings that both map to the
    same IRI, it's ambiguous which one you pick. [scribe assist by
    Manu Sporny]
Niklas Lindström:  I'm willing to defend this complexity - it is
    complex when you have very diverse data. [scribe assist by Manu
    Sporny]
Niklas Lindström:  When you have different objects for the same
    property - when you want to express JSON - you want to shield
    people from the details of the object values, which is why we
    have coercion. [scribe assist by Manu Sporny]
Niklas Lindström:  When these two goals collide, there will be a
    complex situation, regardless. [scribe assist by Manu Sporny]
Niklas Lindström:  I think this is defendable - the value gained
    by the ability to have different terms for the combination of a
    different property/datatype is greater than not being able to
    handle potentially varied object data. [scribe assist by Manu
    Sporny]
Niklas Lindström:  If you have that situation, your data is very
    complex. [scribe assist by Manu Sporny]
Niklas Lindström:  I don't think this in and of itself creates
    any ambiguity - you won't find any specific term for the value
    type... you have to use the full IRI or generate a CURIE for the
    prefix defined. [scribe assist by Manu Sporny]
Manu Sporny:  I see what gregg is getting at
    … if you have a compacted form with terms foo1 and foo2
Markus Lanthaler:
    https://github.com/json-ld/json-ld.org/issues/43
Gregg Kellogg: {
Gregg Kellogg: "@context":
Gregg Kellogg: {
Gregg Kellogg: "a": {"@id": "http://example.com/foo", "@type":
    "xsd:integer"},
Gregg Kellogg: "b": {"@id": "http://example.com/foo"}
Gregg Kellogg: },
Gregg Kellogg: "a": "1",
Gregg Kellogg: "b": "1"
Gregg Kellogg: }
Manu Sporny:  the ambiguity is which term to pick
    … if you have two terms pointing to the same @id
Manu Sporny:  always pick the lexically smaller value
    … I agree with both of you; gregg: this is definitely a
    complexity; niklas: this is manageable and we're trying to show
    that JSON-LD can handle really complex RDF
Manu Sporny:  the alternative, to strip this functionality out,
    or saying that it's undefined is hard; we have use cases for
    this, and undefined is bad
Manu Sporny:  we should turn how conflicts are resolved into a
    separate issue
Manu Sporny:  it does impact the syntax, so we need to discuss it
    soon
Manu creates the issue...
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/74
Gregg Kellogg:  with some more syntax spec changes we can close
    issue 43

Topic: ISSUE-56: JSON keys that are not terms

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/56
Markus Lanthaler: I think this is closely related to
    https://github.com/json-ld/json-ld.org/issues/68
Niklas Lindström:  I believe this issue conflates different
    things - it talks about disjoint graphs, drop the subtree during
    processing, and how we handle @ids with lists of IRIs. [scribe
    assist by Manu Sporny]
Manu Sporny:  These are three separate issues, yes. [scribe
    assist by Manu Sporny]
Manu Sporny:  in the beginning of JSON-LD, lists of iris in @id
    was a syntax "macro" to say same things to different subjects
Markus Lanthaler:  I don't see how lists of IRIs in @id and
    disjoint graphs are related. [scribe assist by Manu Sporny]
Manu Sporny:  there are three different issues. we make issue 56
    to only be about unknown terms. to allow for "raw" json in
    json-ld
    … the initial thought was to drop the entire subtree
    … we wanted to support richer stuff; but to dive in and deep
    process data might be very complex
Gregg Kellogg: IMO, ignore sub-tree
Niklas Lindström:  This is where the conflation may have begun.
    When I discussed this, I did it from my use cases' perspective -
    I have @rev to represent reverse relations... it's a magic key,
    the value is a JSON object which has what looks like normal terms
    pointing to resources. [scribe assist by Manu Sporny]
Niklas Lindström:  They demonstrate the inverse - if we drop the
    entire subtree, then I can put this data in and the data in the
    subtree looks like JSON-LD, but nobody has to care about that.
    It's tempting to me to say that I want to keep the subtree, but I
    realize that if want @rev, then we have this problem where we
    have keys that mean nothing... we have a two step path down, and
    that's too complex... [scribe assist by Manu Sporny]
Manu Sporny: ...to handle.
Manu Sporny:  I agree
    … the other thing that marcus said is that the spec currently
    states that terms without mappings are relative iris
    … this was never our intent
Gregg Kellogg:  the spec's been updated to fix that
Niklas Lindström:  Ivan suggested that instead of allowing "@id"
    : [{}, {}, {}] - we should use "@data": [{}, {}, {}] to represent
    a disjoint graph. [scribe assist by Manu Sporny]
Niklas Lindström:  if we allow processors to deep-dive into
    unknown terms, we don't have to define @data... deep dive
    processors would just find the data... as we just discussed, this
    is too complicated. [scribe assist by Manu Sporny]
Markus Lanthaler:  Can you explain why this is complicated?
    [scribe assist by Manu Sporny]
Gregg Kellogg:  we need to be able to ignore contexts
    … if we want to allow deep diving; we should create semantics
    to do that
    … we should ignore unknowns and their values
Niklas Lindström:  If I do something like rev.partOf, it creates
    an issue - I don't want that to be processed. [scribe assist by
    Manu Sporny]
Manu Sporny:  if we allow deep dives; when you compact the data;
    the result will look very different
    … completely different when rebuilt; will confuse people
    … therefore, we should not support deep-diving
Markus Lanthaler:  it makes sense.
    … just to make it clear: what happens on compaction/expansion
Manu Sporny:  it is dropped entirely
Gregg Kellogg:  agreed
Markus Lanthaler:  ok
Gregg Kellogg:  it needs to be clear to say when a key is
    definitively unmapped

PROPOSAL:  When processing keys in a JSON-LD document, ignore
    keys and do not process the subtree for keys that do not have a
    mapping in the @context. When compacting and expanding, drop keys
    that do not have mappings from the output.

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

RESOLUTION: When processing keys in a JSON-LD document, ignore
    keys and do not process the subtree for keys that do not have a
    mapping in the @context. When compacting and expanding, drop keys
    that do not have mappings from the output.

PROPOSAL:  Mapping a key to _null_ removes a mapping for that key
    active context

Niklas Lindström: +1 (i.e. JSON null)
Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: "name": { "@type": null }
Markus Lanthaler: +1
David I. Lehn: +0

RESOLUTION: Mapping a key to _null_ removes a mapping for that
    key active context

PROPOSAL:  A term can only be redefined, never partially
    reconfigured

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

RESOLUTION: A term can only be redefined, never partially
    reconfigured

Topic: ISSUE-52: Should we support lists of lists?

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/52
Gregg Kellogg:  we have no real use cases for it, do we?
Markus Lanthaler:  can you give a list an iri?
Gregg Kellogg:  you can have a list as the value of an @id
Markus Lanthaler: { "@id": "xxxx", "@type": "@list", "@value": [
    list values ] }
Niklas Lindström:  You can use RDF terms to create an RDF list
    with an ID and then for that value, rdf:rest the rest... it would
    look terrible, but you could do it. [scribe assist by Manu
    Sporny]
Niklas Lindström:  This is not specified currently... [scribe
    assist by Manu Sporny]
Niklas Lindström:  What about {@list: []} in a list?
Niklas Lindström:  Like this: {@list: [ {@list: [1, 2]}, {@lisr:
    [3, 4] ]} is "a list of lists". But the issue is should [[1,2],
    [3,4]] *mean* that
Niklas Lindström:  If we supported this syntax, we could support
    lists of lists. [scribe assist by Manu Sporny]
Markus Lanthaler:  I have a use case (another issue) where a list
    has an IRI and can be referenced
Niklas Lindström:  http://example.com/list-with-id a rdf:List,
    rdf:first 1, rdf:rest (2) .
Gregg Kellogg:  there is a way to do it in RDF, round-trips are
    of concern
Manu Sporny:  yes, the round-trip is of great concern
Niklas Lindström:  I agree, we are discussing something very
    complex. [scribe assist by Manu Sporny]
Niklas Lindström:  If you need to do it, you can do it - any sort
    of syntactic short-hand is an issue. [scribe assist by Manu
    Sporny]
Niklas Lindström:  Serializers for RDF which have a short-hand
    for lists stop using the short-hand if the list is described with
    other properties or the list is not a list of bnodes. The
    short-hand breaks down. [scribe assist by Manu Sporny]
Niklas Lindström:  We can use the gruesome and verbose list
    mechanism without any changes - we shouldn't try to create
    separate support for this. [scribe assist by Manu Sporny]
Niklas Lindström:  What about - [ [ … ] ]
Niklas Lindström:  That is not supported, to clarify. [scribe
    assist by Manu Sporny]
Manu Sporny: Niklas did mention this: {@list: [ {@list: [1, 2]},
    {@list: [3, 4] ]}
    … in turtle: ( (1 2) (3 4) )
General agreement that we should not support this type of very
    advanced list functionality - even if there is a use case here
    and there, it may overly complicated JSON-LD.
David I. Lehn: Good call.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: PaySwarm vs. OpenTransact Shootout
http://manu.sporny.org/2011/web-payments-comparison/

Received on Tuesday, 31 January 2012 16:59:07 UTC