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.

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.

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.

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.

Niklas Lindström: agreed. @set is expanded away, devolves on expansion.

Markus Lanthaler: you're saying we allow @set, but optimize away in expansion.

Markus Lanthaler: +1

Gregg Kellogg: +1

Manu Sporny: +1

Niklas Lindström: +1

David I. Lehn: +1

Manu Sporny: +1

Gregg Kellogg: +1

Niklas Lindström: +1

David I. Lehn: +1

Markus Lanthaler: +1

Gregg Kellogg: +1

Manu Sporny: +1

Markus Lanthaler: +1

David I. Lehn: +1

Niklas Lindström: +1

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.

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 :-)

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

Gregg Kellogg: +1

Niklas Lindström: +1

Manu Sporny: +1

David I. Lehn: +1

Markus Lanthaler: +1

Niklas Lindström: that includes the edgcase of 5.0 that is a double.

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.

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.

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.

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.

Manu Sporny: 5 can't be represented as 5.0, as it wouldn't survive round-tripping.

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.

Manu Sporny: +1

Markus Lanthaler: +1

Gregg Kellogg: +1

Niklas Lindström: +1

David I. Lehn: +0

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.

Manu Sporny: we have a minor inconsistency about how @langauge is specified.

Niklas Lindström: +1

Manu Sporny: +1

Markus Lanthaler: +1

Gregg Kellogg: +1

David I. Lehn: +1

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).

Gregg Kellogg: +1

Manu Sporny: +1

Niklas Lindström: +1

Markus Lanthaler: +1

David I. Lehn: +1

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/75

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)

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.

Manu Sporny: +1

Niklas Lindström: +1

Markus Lanthaler: +1

David I. Lehn: +0

Gregg Kellogg: +1

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

Gregg Kellogg: +1

Manu Sporny: +1

Niklas Lindström: +1

Markus Lanthaler: +1

David I. Lehn: +0

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.

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"

Manu Sporny: +1

Niklas Lindström: +1

Gregg Kellogg: +1

Markus Lanthaler: +1

David I. Lehn: +0

Markus Lanthaler: Might be interesting: http://www.w3.org/wiki/UriTesting