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
Audio Log
audio.ogg
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