- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 21 Feb 2012 14:23:11 -0500
- 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 UTC