W3C home > Mailing lists > Public > public-linked-json@w3.org > February 2012

JSON-LD Telecon Minutes for 2012-02-21

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 21 Feb 2012 14:23:11 -0500
Message-ID: <4F43EF1F.4030105@digitalbazaar.com>
To: Linked JSON <public-linked-json@w3.org>
Thanks to Gregg for scribing! The minutes from today's super session are
now available here:

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

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

Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2012Feb/0014.html
Topics:
    1. ISSUE-54: Arrays of IRIs
    2. ISSUE-63: Provenance in JSON-LD
    3. ISSUE-64: Make clear how type and language coercions work
    4. ISSUE-76: Use of null in JSON-LD
    5. ISSUE-65: Handling of data that doesn't contain triples.
    6. ISSUE-69: Remove media type parameter option
       "form=compacted"
Resolutions:
    1. If a string is found in an array that is the value of the
       "@id" key, a JSON-LD Processor MUST throw an exception.
    2. Put the discussion of Provenance on hold until the RDF WG
       produces a proposal for provenance.
    3. When expanded form is used, no coercion rules apply to the
       value expressed in the expanded form.
    4. Setting @language to null in the @context clears any
       coercion rules for language for the JSON subtree.
    5. When "@context": null is specified, it clears the active
       context.
    6. If "@language": null is specified in a local context,
       language coercion is removed from the active context.
    7. If '{}' is used as a value in a JSON-LD document, then a
       blank node identifier MUST be generated for the object during
       normalization.
    8. Remove "form=compacted" from the MIMEType for JSON-LD.
Chair:
    Manu Sporny
Scribe:
    Gregg Kellogg
Present:
    Manu Sporny, Gregg Kellogg, Markus Lanthaler, David I. Lehn,
    Niklas Lindström
Audio:
    http://json-ld.org/minutes/2012-02-21/audio.ogg

Manu Sporny is scribing.
Manu Sporny:  Any additions to Agenda?
Manu Sporny:  Everything we have today is for the Syntax document

Topic: ISSUE-54: Arrays of IRIs

https://github.com/json-ld/json-ld.org/issues/54
Manu Sporny:  What do we do when @id has multiple strings in an
    array?
Manu Sporny:  We have four options...
Only use the first value in the @id array.
Only use the last value in the @id array.
Effectively do #1 or #2 by modifying the @id value to only
    contain the first/last value.
Throw an exception/error.
Manu Sporny:  Any other options?
Gregg Kellogg:  We could also say that it's implicitly a list -
    but if we add @set, that decision would be arbitrary...
Markus Lanthaler:  Then what would the output be?
Gregg Kellogg:  The value would be the value of the first item in
    the list - the first bnode. You can have a list be in the subject
    position.
Gregg Kellogg:  That is tying our hands, though.
Gregg Kellogg:  I say, probably not do that. If we want to adopt
    this syntax for something else, then we should probably throw an
    exception so we don't get b/c issues. I think it's pretty
    unlikely that we want to go this way. We probably will use
    another keyword to make it more explicit.
Manu Sporny:  I think the best option is throw an exception, buys
    us time... least dangerous option.
Gregg Kellogg:  If the value of @id is null... it should be as if
    there was no value there at all.

PROPOSAL:  If a string is found in an array that is the value of
    the "@id" key, a JSON-LD Processor MUST throw an exception.

David I. Lehn: does it complicate processors to detect this vs
    just leaving the behavior undefined?
Niklas Lindström: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Manu Sporny: +1
David I. Lehn: +1
Niklas Lindström: .. also expecting that we're moving away from
    arrays in @id for multiple subjects as well (when we come to that
    issue)
Manu Sporny:  We should be very specific in what processors
    should do, otherwise, there might be interoperability issues.

RESOLUTION: If a string is found in an array that is the value of
    the "@id" key, a JSON-LD Processor MUST throw an exception.

Topic: ISSUE-63: Provenance in JSON-LD

https://github.com/json-ld/json-ld.org/issues/63
Manu Sporny:  This has to do with how we represent graphs in
    JSON-LD.
Niklas Lindström:  I think we've confused two issues... 63 and
    68. We may be confusing "multiple graphs" with "multiple subjects
    in one graph". I think we can close this issue with a reference
    to issue 68
Niklas Lindström:  For this issue to work, we would have to have
    literal graphs... how do you use a literal graph as a subject?
Niklas Lindström:  If you have graphs, you have IDs for graphs
    and then you could use them for subjects.
Gregg Kellogg:  I think the syntax for multiple graphs is
    probably pretty well set... I don't think the RDF WG making any
    big changes to TRiG... quads aren't going to change... so RDF WG
    is working on /semantics/ behind multiple graphs.
Gregg Kellogg:  It would be one more syntax in a growing set...
Markus Lanthaler: agree to put on hold for now
Gregg Kellogg:  This is about provenance - an application of
    multiple graphs - we can hold off discussion on the provenance
    issue. We should hold until there is some consensus around
    expressing provenance on multiple graph syntaxes.
Gregg Kellogg:  We could provide support for multiple graphs, but
    may want to discuss a syntax for multiple graphs. Provenance goes
    further than a particular serialization.
Niklas Lindström:  I agree w/ what Gregg said, I also comment on
    that in the issue - what the issue speaks of can be done w/o
    named graphs at all.
Niklas Lindström:  If you use triples talking about provenance,
    you don't need named graphs... you can do that today. Provenance
    can be done w/o named graphs. When you start to describe a graph,
    you create another graph describing that graph.
Niklas Lindström: .. provenance information can be given for
    information resources (e.g. an rdf document); *if* you want to
    describe graphs themselves, that requires graph literals, which
    is in #68

PROPOSAL:  Put the discussion of Provenance on hold until the RDF
    WG produces a proposal for provenance.

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

RESOLUTION: Put the discussion of Provenance on hold until the
    RDF WG produces a proposal for provenance.

Topic: ISSUE-64: Make clear how type and language coercions work

https://github.com/json-ld/json-ld.org/issues/64
Manu Sporny:  The question is - does expanded form override
    coercion rules?
Manu Sporny:  So, if you do "foo": {"@value": "bar"}
Manu Sporny:  Then no coercion rules apply to the value of "bar"
Gregg Kellogg:  If I had a list with an array of strings, the
    strings in that list would be subject to coercion?
Manu Sporny:  Yes.
Gregg Kellogg: {"@id": "foo"}
Gregg Kellogg: {"foo": {"@id": "bar"}}
Gregg Kellogg:  Since I'm expressing it explicitly, coercion
    isn't applied to @id, even if "foo" has a coercion rule for
    @language or @type.
Niklas Lindström: ... Compact: {"@context": {"@language": "en",
    "name": {"@type": "xsd:string"}, "name": "value with no lang",
    "title": "Mr."}; Expanded: {"name": "value with no lang",
    "title": {"@value": "Mr.", "@language": "en"}}
Gregg Kellogg:  Do we have a more generic way to express how
    'null' is treated in JSON-LD?

PROPOSAL:  When expanded form is used, no type coercion rules
    apply to the value expressed in the expanded form.

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

RESOLUTION: When expanded form is used, no coercion rules apply
    to the value expressed in the expanded form.

Manu Sporny:  Next proposal is what happens when you set
    @language to null

PROPOSAL:  Setting @language to null in the @context clears any
    coercion rules for language for the JSON subtree.

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

RESOLUTION: Setting @language to null in the @context clears any
    coercion rules for language for the JSON subtree.

Niklas Lindström: .. a value of null outside of the context has
    the same effect as if there is no key/value present at all.
Niklas Lindström:  Should we add an issue for that, or resolve it
    now?
Manu Sporny:  yes, resolve it now.

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

https://github.com/json-ld/json-ld.org/issues/76
Manu Sporny:  How is null interpreted?
Gregg Kellogg:  We should keep things a bit open on how we
    specify this...
Gregg Kellogg:  Unless otherwise specified, the use of null as a
    value MUST be treated as if the value was never specified; i.e.,
    it has no effect.
Gregg Kellogg:  Unless otherwise specified, the use of null as a
    key is treated as if the key/value was never specified, and
    values of that key are not processed.
Manu Sporny:  Is null allowed as a key?
Niklas Lindström:  Not in JSON...
Manu Sporny:  Yes, confirmed, it changes it to "null" when you
    serialize, we don't need the second statement.
Markus Lanthaler:  What if you do "@context": null ?
Gregg Kellogg:  "@context": null should clear the current
    context, useful when used in an array
Niklas Lindström:  What does that mean? If you clear the context?
Gregg Kellogg:  When "@context": null is specified, it clears the
    active context.
Markus Lanthaler:
    http://json-ld.org/spec/latest/json-ld-api/#appendix-b
Gregg Kellogg:  What about an initial context?
Gregg Kellogg:  That may be useful
"@id"}}
Niklas Lindström:  What happens when you use "@context": null in
    a subtree?
Manu Sporny:  It nukes the subtree, effectively - nukes the
    terms, but leaves full IRIs behind.
Gregg Kellogg: @context: [null, "http://my-new-context]
Manu Sporny:  Is there confusion to what happens? Are we okay
    with what happens w/ "@context": null?
Manu Sporny:  No confusion on my part, okay with what happens.

PROPOSAL:  When "@context"; null is specified, it clears the
    active context.

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

RESOLUTION: When "@context": null is specified, it clears the
    active context.

Markus Lanthaler: Created
    https://github.com/json-ld/json-ld.org/issues/78 for it
Manu Sporny:  What about: The use of null as a value in the
    @context MUST clear the associated term or CURIE from the active
    context.
Gregg Kellogg:  Use of 'null' could mean 'it's not there' ... or
    it could mean 'it clears the coercion rules for that definition'
Gregg Kellogg:  There are multiple uses for 'null' here...
Niklas Lindström: .. "isReferencedBy": {"@id": null,
    "@container": "@set"}
Gregg Kellogg:  You could set @id to null, you could set
    @language to null, you could set term to null, you could set
    @type to null...
Niklas Lindström:  That example - if that key doesn't mean
    anything, you should still look at the thing in the @container.
    We don't have time to think of this right now, but putting it out
    there as something that could give meaning to "@id": null
Niklas Lindström:  Let's put this discussion on the mailing list.
Manu Sporny:  You're saying, let's be specific about 'null'

PROPOSAL:  If "@language"; null is specified in a local context,
    language coercion is removed from the active context.

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

RESOLUTION: If "@language": null is specified in a local context,
    language coercion is removed from the active context.

Topic: ISSUE-65: Handling of data that doesn't contain triples.

https://github.com/json-ld/json-ld.org/issues/65
Error: (IRC nickname not recognized)[11:05]	<gkellogg>	Turtle:
    <gregg> foaf:knows [] .
David I. Lehn: about the second proposal, a top level [] is still
    valid and needs to be supported since it's representing no data
Manu Sporny:  This has to do with existential information - do we
    want to support statements like: {} and [] ?
Niklas Lindström: {"key": {}} vs. {"key": null}
Manu Sporny:  There are two proposals - If an author wants to
    express existential information and have it survive the
    compaction and expansion processes, then they MUST assign an
    identifier to it... and All empty JSON arrays and JSON objects
    MUST be optimized out of the output during compaction or
    expansion.
Niklas Lindström:  There is a difference here - JSON supports {}
    and []
Niklas Lindström:  If we support empty object, that's natural...
Gregg Kellogg:  To say it's not supported, would generate a
    special case... that's inconsistent.
Niklas Lindström:  In the general case, an empty list doesn't
    mean anything from the JSON-LD perspective... if it is a @list,
    it should be the empty list.
Markus Lanthaler:  I think in both cases, we should remove it.
Markus Lanthaler:  If it's coerced to a list or not, we should
    remove it.
Niklas Lindström:  If it is coerced to a list, the value is an
    empty list... we can't just remove it.
Markus Lanthaler:  An empty set is also an empty set... why do we
    remove that?
Niklas Lindström: owl:Nothing
Niklas Lindström:  Something coerced to a list as an empty list
    has meaning... we would be destroying data if we didn't add that.
Niklas Lindström: ()
Niklas Lindström: turtle: (), expanded JSON-LD: {"@list": []}
Manu Sporny:  So the counter-proposals are this: If we have {},
    we generate a bnode identifier for it... if we have [] (and it
    isn't coerced as a list), then it's left as-is... if we have []
    (and it is coerced to a list), then it isrdf:nil.
Gregg Kellogg:  Part of the compaction algorithm is to normalize,
    normalization goes to RDF, the result of normalizing doesn't
    generate a triple... so data is removed during normalization to
    create the empty set.
Gregg Kellogg:  When you generate RDF, no triples are generated
    for [], thus round-trip would fail.
Gregg Kellogg:  If we become inconsistent with RDF, we're in
    dangerous territory.
Gregg Kellogg:  I think empty lists w/o coercion means - remove
    it from the data, that's what RDF does. I think empty lists w/
    coercion to list meansrdf:nil - that's what RDF does... we should
    do that.
Niklas Lindström:  Agreed.
Markus Lanthaler:  But if we destroy empty sets, we're not being
    consistent.
Niklas Lindström:  I think we have to be practical about this...
Gregg Kellogg:  This may be generated automatically, compaction
    should eliminate the redundancies.
Niklas Lindström:  If I use "@container": "@set" - I have lots of
    terms that have to be multiple if they are present. Lots of terms
    for different types of objects.
Gregg Kellogg is scribing.

PROPOSAL:  If '[]' is specified as a value for a key in a JSON-LD
    document, and no "@container"

Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny:  we're pushing "@container": "@set" off for now.
Markus Lanthaler:  [] is implicitly a @set
Niklas Lindström:  conceptual trickiness is that @set does not
    imply a value, but a representation.
    … difference is between "raw" JSON and JSON-LD
    … if we had interpreted arrays as list by default, it would
    have the @list meaning. Since we don't, removing it is
    consistent.
Niklas Lindström:  multiple values in RDF can be interpreted in
    different ways (more "soft")
Manu Sporny:  if we put in support for @container: @set, what
    does [] mean in RDF?
Niklas Lindström:  it does not have an RDF representation; as if
    it wasn't there.
Manu Sporny: +1
    … if we don't explain, some people would be confused about
    @set with [].
Markus Lanthaler:  concerned that we would lose the assertion
    that there is an empty set.
Manu Sporny:  postpone for now, but personally leaning toward's
    niklas' interpretation.
    … See that JSON developers might be confused, but the fact
    that you're now in compacted JSON-LD land creates a consistent
    nuanced interpretation.
Niklas Lindström:  was going to mention that there is a small
    semantic interpretation.
    … syntactically, JSON imposes an order, but there is no way to
    specify the semantics in JSON.
Manu Sporny:  an empty object should generate a BNode identifier.
POSTPONED: If '[]' is specified as a value for a key in a JSON-LD
    document, and no "@container": "@list" is specified for the
    associated key, then the value MUST be removed from compacted
    output.
Manu Sporny:  We need to have more reflection and discussion on
    this... [scribe assist by Manu Sporny]
Manu Sporny:  But we can discuss the {} issue.... [scribe assist
    by Manu Sporny]

PROPOSAL:  If '{}' is used as a value in a JSON-LD document, then
    a blank node identifier MUST be generated for the object during
    normalization.

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

RESOLUTION: If '{}' is used as a value in a JSON-LD document,
    then a blank node identifier MUST be generated for the object
    during normalization.

Manu Sporny: Let's skip the named graphs stuff for now...

Topic: ISSUE-69: Remove media type parameter option "form=compacted"

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/69
Manu Sporny:  Markus raised the issue: does form=compacted
    actually mean anything?
    … different contexts create a different compacted form.
    … since it doesn't express anything specific, we should remove
    form=compacted.
    … counter argument, is that it is used in payswarm
    specifications, so that developers can be sure they're getting
    back something that can be directly operated upon.
    … we can say registration service at a given url, login at
    another, and is very flat.
    … If we didn't have form=compacted, there would be no way for
    the developer to know that they were getting back something that
    was already compacted.
Markus Lanthaler:  compaction works by supplying a context, but
    payswarm uses 6 different contexts.
Manu Sporny:  form=compacted might need to also pass the IRI of
    the context used for compaction.
Manu Sporny:  for payswarm, we can say that if you make a call to
    a service, you must compact with a specific context, otherwise it
    must be made explicit.
Niklas Lindström: …
    application/rdf+jsonld;context=http://purl.org/web-key/v1
Markus Lanthaler:  saying it's compacted doesn't convey enough
    information.
Niklas Lindström: … or application/rdf+jsonld;custom=web-key
Niklas Lindström: … or another vendor media-type altogether:
    application/vnd.payswarm.webkey+jsonld
Markus Lanthaler:  we start specifying too much.
Manu Sporny:  don't want to tie the syntax spec to the api spec.
Markus Lanthaler:  puts too much burden on other implementations.
Niklas Lindström:  the common case is that you define a vendor
    media type, that can define what it means, and documents that it
    is represented by JSON-LD.
    … if you want to negotiate on an explicit form, the use of a
    different media type enables this.
    … the client can be very explicit about what data it wants,
    and it's up to the service to provide it or not
Manu Sporny:  in payswarm, we want people to be able to add other
    contexts, allowing them to layer other things on top of it, as
    long as there is no conflict.
Niklas Lindström: …
    application/rdf+jsonld;context=http://purl.org/web-key/v1
Niklas Lindström: … application/rdf+jsonld
Niklas Lindström: …
    application/rdf+jsonld;context=http://purl.org/web-key/v2
Niklas Lindström:  this allows an arbitrary level of precision to
    be specified in the request.
Manu Sporny:  the context is specified in the returned document,
    so this could be redundant.
Niklas Lindström:  asking for form=compacted isn't specific
    enough.
    … a vendor media type might be more appropriate.
    … otherwise, some advisory header might be useful.
Manu Sporny:  trying to make it so that there is a way to say
    what the client expected, but now convinced that it doesn't go
    far enough.
    … Don't want it to pull back into the payswarm spec, as it
    complicates things too much.
    … clients can always use the API to do their own compaction.

PROPOSAL:  Remove "form=compacted" from the MIMEType for JSON-LD.

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

RESOLUTION: Remove "form=compacted" from the MIMEType for
    JSON-LD.

-- 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, 21 February 2012 19:23:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:36 GMT