- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 20 Mar 2012 13:51:22 -0400
- To: Linked JSON <public-linked-json@w3.org>
Thanks to Gregg Kellogg for scribing! The minutes from today's call are
now available here:
http://json-ld.org/minutes/2012-03-20/
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-20
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2012Mar/0011.html
Topics:
1. Clarification of @set and expansion
2. Expansion of strings and numbers
3. ISSUE-85: Support @language in term definitions
4. How is @language applied to strings?
5. ISSUE-75: References to lists
6. ISSUE-81: Double round tripping issues due to lack of
precision
7. ISSUE-86: IRI normalization
Resolutions:
1. Using "@list" and "@set" as keys in JSON-LD values that are
expressed in expanded form is allowed.
2. During compaction "@set" expressed in expanded form MUST be
optimized away if it is not coerced to a "@list". During
expansion "@set" MUST be optimized away.
3. The use of "@container" is ignored in the body of a JSON-LD
document.
4. The value of the @value key is always transformed to a
string by the JSON-LD processor.
5. Unless there are type coercion rules in the @context that
apply, native JSON numbers and strings are not modified in
compacted or expanded form.
6. Support the use of @language in term definitions to specify
the associated @language for the term. If both @type and
@language are specified, @language is ignored.
7. If @language is specified at the top-level of a @context,
then it applies to all native strings that would be interpreted
as plain literals in the JSON-LD body. The @language can be
overridden in term definitions by specifying a different
@language value, including @language: null, or by specifying a
@type for the term.
8. Do not support the direct naming of lists using IRIs in
this revision of JSON-LD.
9. Convert all values coerced to xsd:double to strings using
the C-syntax formula of "%1.16e".
10. Conform to the requirements of RFC3986, Section 5
(Reference Resolution), when processing IRIs.
Chair:
Manu Sporny
Scribe:
Gregg Kellogg, Manu Sporny
Present:
Gregg Kellogg, Markus Lanthaler, Manu Sporny, Niklas Lindström,
David I. Lehn
Gregg Kellogg is scribing.
Topic: Clarification of @set and expansion
Manu Sporny:
http://lists.w3.org/Archives/Public/public-linked-json/2012Mar/0010.html
Markus Lanthaler: there is how @set is supposed to work, and if
we allow the shorthand syntax
Manu Sporny: "test": { "@set": [ ... ] }
Manu Sporny: The discussion is whether or not to allow the above
Gregg Kellogg: If we want to add more types of containers, we
have to add more behavior to understanding the keywords in the
body [scribe assist by Manu Sporny]
Gregg Kellogg: We might want to just use "@container" in the
@context... I'm not a fan of using @container: in the body. If we
had 4 different types of containers, we'd have 4 different
keywords - bigger impact on processor. [scribe assist by Manu
Sporny]
Manu Sporny: So, you're concerned about processor complexity.
[scribe assist by Manu Sporny]
Gregg Kellogg: We need to add things in keyword position -
adding in key position might be adding more complexity - we
should just consider it. [scribe assist by Manu Sporny]
Markus Lanthaler: Does this mean we remove "@list": [] in body?
[scribe assist by Manu Sporny]
Gregg Kellogg: Yes, for consistency's sake, I think we would.
[scribe assist by Manu Sporny]
Niklas Lindström: Basically, agree with gregg, however, by
implication this would argue for @value [], @container: @list.
… during expansion, you would never use @set explicitly, as
it's implied.
Markus Lanthaler: probably, we shouldn't have a special case for
@set.
Manu Sporny: processor complexity should be the last concern,
but it might be a sign that the language is getting too complex.
… one of the decisions was to be as explicit as possible when
using a new construct.
… what is going to be easier on authors.
… leaning towards @list: [], or @set: [].
David I. Lehn: both are awkward
Manu Sporny: not clear what authors would prefer.
Manu Sporny: expanded form is getting less and less useful
because of the flourishes we're adding.
Niklas Lindström: agreed, we've probably going too far.
… what are the other kind of containers, how would they
appear?
David I. Lehn: raw triple container? @triples:
[[s,p,o],[s,p,o],...]?
Gregg Kellogg: Well, there are other types we could add - people
are unhappy with RDF List... [scribe assist by Manu Sporny]
David I. Lehn: not sure if that makes sense or not
Manu Sporny: also raw, or @graph containers.
Manu Sporny: at this point, okay with having a different keyword
(e.g. @set) for each new type of container.
… okay to optimize away @set when expanding, as that is the
default collection type.
… at this point, leaning towards using the keyword and then
allowing an array, and keeping @value really simple.
… if you have more than a signal value, use @set, @list or
other nomenclatures.
Niklas Lindström: agreed. @set is expanded away, devolves on
expansion.
… if we introduced, e.g., @langmap, they would also go away on
expansion.
… only @list (or @orderedlist) would need to remain.
… @set should be allowed to be used explicitly, in certain
situations.
… for instance, when it's coerced to a @list, but used in some
circumstances when it is a @set.
Markus Lanthaler: you're saying we allow @set, but optimize away
in expansion.
… don't allow @container: @set construct.
PROPOSAL: Using "@list" and "@set" as keys in JSON-LD values
that are expressed in expanded form is allowed.
Markus Lanthaler: +1
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
David I. Lehn: +1
RESOLUTION: Using "@list" and "@set" as keys in JSON-LD values
that are expressed in expanded form is allowed.
PROPOSAL: During compaction "@set" expressed in expanded form
MUST be optimized away if it is not coerced to a "@list". During
expansion "@set" MUST be optimized away.
Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: +1
David I. Lehn: +1
Markus Lanthaler: +1
RESOLUTION: During compaction "@set" expressed in expanded form
MUST be optimized away if it is not coerced to a "@list". During
expansion "@set" MUST be optimized away.
PROPOSAL: The use of "@container" is ignored in the body of a
JSON-LD document.
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
David I. Lehn: +1
Niklas Lindström: +1
RESOLUTION: The use of "@container" is ignored in the body of a
JSON-LD document.
Topic: Expansion of strings and numbers
Markus Lanthaler:
https://github.com/json-ld/json-ld.org/issues/87
Manu Sporny: The question is, what does this expand to: "term1":
"v1",
Manu Sporny: and what does this expand to: "term2": 5
Manu Sporny: { "@value": "5", "@type": "xsd:integer" }
Manu Sporny: we're not being consistent, we would expand v1 into
{"@value": "v1", "@type": "xsd:string"}
Manu Sporny: however, this doesn't really buy us anything.
Manu Sporny: my thought is that we not expand "fundamental"
values. Leave it to normalization algorithm.
… strings aren't expanded into xsd:string, numbers not into
xsd:integer
Gregg Kellogg: I think the principle that we should stick to,
with expansion, is do minimum necessary to represent the data w/o
the @context. [scribe assist by Manu Sporny]
Gregg Kellogg: My original thought was that integers should not
be expanded because they don't need to. [scribe assist by Manu
Sporny]
Gregg Kellogg: xsd:integer binds us more tightly to RDF, not
necessary for JSON-LD. [scribe assist by Manu Sporny]
Gregg Kellogg: The primitive forms that can be expressed in JSON
should remain in that form during expansion and compaction.
[scribe assist by Manu Sporny]
Markus Lanthaler: I agree. [scribe assist by Manu Sporny]
Niklas Lindström: I agree
Niklas Lindström: I think I agree as well. [scribe assist by
Manu Sporny]
David I. Lehn: No opinion.
Markus Lanthaler: gkellog: lanthaler is me Markus LaNThaler :-)
PROPOSAL: The valid range of @value is a JSON string that
represents the lexical form of the literal.
Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny: +1
Markus Lanthaler: -1
Niklas Lindström: see no reason to restrict on input.
Manu Sporny: we can say that @value is always coerced to a
string through altorighms.
David I. Lehn: +0
PROPOSAL: The value of the @value key is always transformed to a
string by the JSON-LD processor.
Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny: +1
David I. Lehn: +1
Markus Lanthaler: +1
RESOLUTION: The value of the @value key is always transformed to
a string by the JSON-LD processor.
Niklas Lindström: that includes the edgcase of 5.0 that is a
double.
PROPOSAL: Unless there are type coercion rules in the @context
that apply, native JSON numbers and strings are not modified in
compacted or expanded form.
Gregg Kellogg: +1
Markus Lanthaler: { "@context": { "term" : { "@type":
"xsd:integer" } } , "term": 5 }
Markus Lanthaler: expanded: { "term" : { "@value": "5", "@type":
"xsd:integer" } }
Markus Lanthaler: or { "term" : 5 } ??
Gregg Kellogg: I prefer the latter
Niklas Lindström: double must have a non-zero fractional value.
Manu Sporny: if they specify a datatype in the context, we
should stay true to their intent.
… however, this may mean that some unexpected transformation
is happening.
Gregg Kellogg: I think we need to stick to "expansion is the
/minimum/ representation of the graph without a context" - which
means, use native JSON types. [scribe assist by Manu Sporny]
Niklas Lindström: you can always predict the how a number is
transformed. a number with no fractions is always an integer.
with a fraction, it's a double; otherwise, you must be explicit.
Manu Sporny: either be consistent with context, meaning always
expand to string form.
… otherwise, always use minimum necessary to express without a
context.
Markus Lanthaler: do we have automatic typing or not?
Manu Sporny: we do support automatic typing now, in
normalization.
Manu Sporny: least surprising thing is to do minimum necessary
representation.
… less of a surprise to the author.
Markus Lanthaler: if we have a normalized document, it's
intended to work for other RDF serializations.
Manu Sporny: correct, it end up creating an N-Triples document
with deterministic BNode naming.
...Then sort and transform back to JSON-LD.
Manu Sporny: 5 can't be represented as 5.0, as it wouldn't
survive round-tripping.
... 5, 5., and 5.0 are all the same number.
… it can't be translated into a native datatype
Markus Lanthaler: the fact that 4.9 and 5.0 are different types
is a difficult thing for users to understand.
Manu Sporny: only way to be consistent is to always expand to
full value form, and not rely on native representations.
David I. Lehn: i think some of these issues are hard and we
probably need more real world usage data to make better decisions
on what is most practical.
PROPOSAL: Unless there are type coercion rules in the @context
that apply, native JSON numbers and strings are not modified in
compacted or expanded form.
Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
Niklas Lindström: +1
David I. Lehn: +0
RESOLUTION: Unless there are type coercion rules in the @context
that apply, native JSON numbers and strings are not modified in
compacted or expanded form.
Topic: ISSUE-85: Support @language in term definitions
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/85
Niklas Lindström: The basic proposal is to allow @language in
the term definitions - so you can have multiple terms that allow
you to express the same thing in different languages. [scribe
assist by Manu Sporny]
Niklas Lindström: @language does not apply if @type is specified
in the context for a term.
… either a global language declaration, or a per-term
declaration.
Manu Sporny: we have a minor inconsistency about how @langauge
is specified.
PROPOSAL: Support the use of @language in term definitions to
specify the associated @language for the term. If both @type and
@language are specified, @language is ignored.
Niklas Lindström: +1
Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
David I. Lehn: +1
RESOLUTION: Support the use of @language in term definitions to
specify the associated @language for the term. If both @type and
@language are specified, @language is ignored.
Topic: How is @language applied to strings?
Manu Sporny: if @language is supplied at the top level of the
@context it applies to all strings in the JSON-LD document (not
subject to coercion).
… use @language: null in term definition to remove this
coercion, or a @datatype coerecion.
PROPOSAL: If @language is specified at the top-level of a
@context, then it applies to all native strings that would be
interpreted as plain literals in the JSON-LD body. The @language
can be overridden in term definitions by specifying a different
@language value, including @language
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +1
RESOLUTION: If @language is specified at the top-level of a
@context, then it applies to all native strings that would be
interpreted as plain literals in the JSON-LD body. The @language
can be overridden in term definitions by specifying a different
@language value, including @language: null, or by specifying a
@type for the term.
Topic: ISSUE-75: References to lists
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/75
Manu Sporny is scribing.
Markus Lanthaler: You normally represent lists or sets ... only
way to do that in JSON-LD is by using a linked list...
Markus Lanthaler: One proposal is to use @value for that - the
use case is referencing @list or @set which are stored in a
different resource in REST terminology.
Markus Lanthaler:
http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-list-elements
Markus Lanthaler: I think this is more or less the same.
Gregg Kellogg: This has been deprecated in RDF 1.1
Gregg Kellogg: There is an RDF translation, but no native
syntactic sugar other than RDF/XML
Niklas Lindström: …
http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-parsetype-Collection
Niklas Lindström: rdf:_1, rdf:_2 is what you end up seeing w/
lists.
Niklas Lindström: … rdf:parseType="Collection"
Markus Lanthaler: That list has an IRI, no?
Niklas Lindström: No, the list is anonymous in the example...
Markus Lanthaler: What's the IRI for the bag? Does it not exist?
Is it like a blank node?
Niklas Lindström: The value of hasFruit is the blank node that
has two properties... the first property is rdf:first, then the
link to the banana, then rdf:rest, which is another bnode...
Niklas Lindström: This is the RDF List construct.
Gregg Kellogg: The subject is http://example.org/basket, which
contains a reference to the list (which is a bnode)
Explanation of what
http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-parsetype-Collection
means
Manu Sporny: Lists are very difficult in pure RDF... which is
unfortunate.
Gregg Kellogg: They're becoming more mainstream now... with
SPARQL list values... RDFa, TURTLE, etc. have good ways of
expressing lsits.
Manu Sporny: I don't think we should name lists - nobody else
does that, really.
Gregg Kellogg: N3 kinda allows you to assing an IRI to the first
bnode, but it's done through reasoning rather than through
sytnax.
Gregg Kellogg: perhaps JSON-LD could go toward it in the future.
You may want to link to the representation of the linked list...
may be premature to do that now.
Niklas Lindström: If you want to represent RDF lists, you should
stick to how they are intended to be used.
Niklas Lindström: If you want to link to a resource that carries
a list, you can always use rdf:value to connect to a list...
MusicOntology may have added ordered list.
Gregg Kellogg: yes, it was MO.
PROPOSAL: Do not support the direct naming of lists using IRIs
in this revision of JSON-LD.
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +0
Gregg Kellogg: +1
RESOLUTION: Do not support the direct naming of lists using IRIs
in this revision of JSON-LD.
Topic: ISSUE-81: Double round tripping issues due to lack of precision
https://github.com/json-ld/json-ld.org/issues/81
Gregg Kellogg: the most precise value maintained by NTriples
tests is the second one... "2.2340000000000005",
Manu Sporny: The issue is this doesn't capture a full 64-bit
double precision float... 4.9406564584124654 x 10−324
Markus Lanthaler: Wikipedia on 64 bit doubles: This gives from 15
- 17 significant decimal digits precision (if a decimal string
with at most 15 significant decimal is converted to IEEE 754
double precision and then converted back to the same number of
significant decimal, then the final string should match the
original; and if an IEEE 754 double precision is converted to a
decimal string with at least 17 significant decimal and then
converted back to
Gregg Kellogg: I think we just have to be focused on xsd:double.
Gregg Kellogg: I think we should be consistent with other RDF
test suites... 16 decimal places.
Manu Sporny: 16 is fine with me...
PROPOSAL: Convert all values coerced to xsd;double to strings
using the C-syntax formula of "%1.16e".
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +0
RESOLUTION: Convert all values coerced to xsd:double to strings
using the C-syntax formula of "%1.16e".
Topic: ISSUE-86: IRI normalization
https://github.com/json-ld/json-ld.org/issues/86
Manu Sporny: The question is should the JSON-LD library need to
do any form of IRI normalization?
Gregg Kellogg: I don't think TURTLE does IRI normalization...
Markus Lanthaler: Well, TURTLE doesn't have any sort of API,
does it?
Gregg Kellogg: My triple store does not do IRI normalization.
Manu Sporny: It may be the applications job to do IRI
normalization.
Gregg Kellogg: If you did, you'd lose fidelity when going
through representations.
Gregg Kellogg: if we say that IRIs might be normalized, we'd
lose fidelity.
Niklas Lindström: You always have to have full IRIs in RDF.
Gregg Kellogg: Yes, but not normalized.
Gregg Kellogg: If you say http://example.com/. and
http://example.com/ - those are different IRIs... they normalize
to the same IRI, but they're different.
Niklas Lindström: Yes, but you resolve things like "../" against
base, right?
Gregg Kellogg: Yes... /resolved/ but not /normalized/.
Markus Lanthaler: base: http://example.com/test/ + ../hello ===
http://example.com/hello ??
Gregg Kellogg: My proposal is to say that we resolve the issue
by looking at the behavior of other RDF processors - my processor
does not normalize.
Markus Lanthaler: It's a bit different in those circumstances...
we rely on the full IRI - we could get IRI collisions in some
places. We could get two different values for one thing?
Gregg Kellogg: This is no different from RDFa - if you have a
term defined, it expands as a term... if you wanted it to be
relative, you would use ./ - and the resulting IRI would contain
./ in it.
Niklas Lindström: I guess the 2 hours are up.. :)
Markus Lanthaler: sorry.. back in a sec
Gregg Kellogg: So, http://example.com/foo/../ is normalized to
http://example.com
Markus Lanthaler: is http://example.com/foo/../ a valid IRI
David I. Lehn: the full rfc normalization rules are pretty
complex
Gregg Kellogg: yes, it's valid.
Gregg Kellogg: We haven't talked about escapes... expanding
UTF-8 escape sequences... rather not go there, but that is done
in TURTLE.
Gregg Kellogg: percent-escape sequences which are not expanded.
Error: (IRC nickname not recognized)[12:05] <niklasl> In Turtle
and RDFa, I think with @base: <http://example.org/foo0x1c>, given
</bar> *or* <../bar> you get <<http://example.org/bar>.
Manu Sporny: I don't think we should do anything fancy - just
copy what the author gave us.
Gregg Kellogg: Yeah, let's not go here.
Markus Lanthaler:
http://tools.ietf.org/html/rfc3986#section-5.2.4
Niklas Lindström: .. but there is no normalization within full
IRIs (so <http://example.org/foo/../bar>)
Niklas Lindström:
http://rdfa.info/test-suite/test-cases/rdfa1.1/xhtml5/0114.xhtml
Niklas Lindström: We should not resolve full IRIs, they are
opaque.
Niklas Lindström: "//"
Niklas Lindström: The question on whether or not to resolve
relative IRIs is still open, imo.
Niklas Lindström: Relative IRI resolution is common in RDF...
everything is limited to that.
Gregg Kellogg: It could be that this is the behavior of the
common libraries...
Markus Lanthaler: Well, if you didn't resolve relative
references... you would end up with something that is not a valid
IRI
Gregg Kellogg: It is a valid IRI, it's just not normalized.
Markus Lanthaler: Maybe normalization is the wrong name... it's
really just resolving relative IRIs.
Niklas Lindström: URI resolution in java: new
URI("http://example.org/foo/../").resolve("http://example.org/bar")
becomes http://example.org/bar
Gregg Kellogg: I think the behavior that we're seeing in RDFa,
appending a relative IRI to a base IRI, comes directly out of
some RFC.
Gregg Kellogg: JSON-LD may need to resolve relative IRIs against
base... we should look into this a bit more.
Markus Lanthaler: Reference resolution:
http://tools.ietf.org/html/rfc3986#section-5
Niklas Lindström: .. and for comparison: new
URI("http://example.org/foo/../").resolve("htTP://example..org//bar")
become "htTP://example..org//bar"
syntax rule of Section 3.
PROPOSAL: Conform to the requirements of RFC3986, Section 5
(Reference Resolution), when processing IRIs.
Manu Sporny: +1
Niklas Lindström: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
David I. Lehn: +0
RESOLUTION: Conform to the requirements of RFC3986, Section 5
(Reference Resolution), when processing IRIs.
Markus Lanthaler: Might be interesting:
http://www.w3.org/wiki/UriTesting
--
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, 20 March 2012 17:52:01 UTC