- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 13 Mar 2012 13:25:05 -0400
- To: Linked JSON <public-linked-json@w3.org>
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