Manu Sporny: Any updates or changes to agenda?

Markus Lanthaler: We may want to discuss this: https://github.com/json-ld/json-ld.org/issues/87

Markus Lanthaler: discuss ISSUE-87 again - clarify compaction. [scribe assist by Manu Sporny]

Gregg Kellogg: We also have an issue on xsd:double... anything coerced to double will use %1.16 form - probably meant any numeric type. [scribe assist by Manu Sporny]

Markus Lanthaler: That's this: https://github.com/json-ld/json-ld.org/issues/81

Markus Lanthaler: What's the result of expansion at the top-level?

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

Gregg Kellogg: Dave Lehn specified it in the tests as array

Markus Lanthaler: OK, I think we didn't specifiy it anywhere.. fine with that

Gregg Kellogg: issue with 1.16E in Ruby:

Gregg Kellogg: "%1.16E" % 5.2 => "5.2000000000000002E+00"

Gregg Kellogg: "%1.16E" % 5.3 => "5.2999999999999998E+00"

Markus Lanthaler: http://www.w3.org/TR/xmlschema-2/#double is a 64-bit number, you lose precision after that

Gregg Kellogg: the resolution for this is to convert all native doubles to strings

Gregg Kellogg: that means everything that is coerced will always be converted to a string

Markus Lanthaler: when should that happen? expansion? normalization?

Gregg Kellogg: in expansion and normalization

Manu Sporny: we want to be consistent in how we handle xsd:integer and xsd:double

Manu Sporny: we need to specify what happes if you have a native number and coercion

Manu Sporny: and the other thing is what should happen to strings such as "foo" that have coercions

Gregg Kellogg: the other thing we could do is to revert that change and make coercion just apply to strings, not other native types such as JSON numbers or booleans

Manu Sporny: I'm worried that this would make the algorithms quite complex

Gregg Kellogg: I don't think it makes sense do apply, e.g., xsd:date to a boolean.. similar xsd:double doesn't make sense for booleans

Niklas Lindström: we have two things to consider: 1) if someone expresses something as a string with a datatype they would like to preserve that and 2) convenience.. developers should be able to work with native types where possible

Niklas Lindström: if someone has given a number in a native type they gave up on the lexical representation but you can control the datatype and will know the lexical repr. by specifying the coercion

Markus Lanthaler: Wouldn't it make sense to specify that numbers can be coerced to xsd:integer or xsd:double, and round-tripping is specified in a way that these numbers are 64-bit numbers? [scribe assist by Manu Sporny]

Niklas Lindström: "%1.16E" % 5.3 => "5.2999999999999998E+00" in Python 2.7 on OS X

Manu Sporny: "%1.15E" % 5.3 -> '5.300000000000000E+00' in Python 2.6 on Linux

Niklas Lindström: (OS X on an intel core i7 specifically)

Niklas Lindström: .. I think that's problematic since I want "age": 123 in compact form *and* coerce "age" as xsd:integer...

Manu Sporny: would it be OK to put that back to the mailing list?

Gregg Kellogg: OK, I'll create some issues for this

Gregg Kellogg: Unfortunately a lot of the recent changes made the implementation much more complex

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

Gregg Kellogg: does coercion to xsd:boolean apply to something that is not a native boolean or string?

Manu Sporny: no, we don't try to interpret "foo" as boolean e.g.

Niklas Lindström: integer("foo") => {"@value": "foo", "@type": "xsd:string"}

Gregg Kellogg: "foo"^^xsd:integer in Turtle?

Niklas Lindström: .. integer("foo") => {"@value": "foo", "@type": "xsd:integer"}

Niklas Lindström: .. just {"@value": "foo", "@type": "xsd:integer"}

Niklas Lindström: .. integer("foo") => {"@value": "foo", "@type": "xsd:integer"}

Gregg Kellogg: {"@value": "November 1", "@type": "xsd:date"}

Gregg Kellogg: when compacting we would convert it just to a native type if the value matches the lexical space

Niklas Lindström: "type": {"@id": "rdf:type", "@container": "@set"}

Niklas Lindström: What happens when somebody does this in the @context? "type": { "@id": "rdf:type", "@container": "@set" }? Do we need an issue for this? [scribe assist by Manu Sporny]

Manu Sporny: Yes, we need an issue for that. [scribe assist by Manu Sporny]

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

Manu Sporny: I think we should make it clear in the spec that we might use any @-term in the future, but don't throw an exception.

Gregg Kellogg: What if someone aliases @id to @graph and then we change the semantics of @graph? How do you future-proof?

Manu Sporny: +1

Markus Lanthaler: What if someone does this? { "language": "@language", "language": "en" }

Niklas Lindström: Double keys, can't do that.

Niklas Lindström: What does the coercion mean here? "@type": {"@id": "rdf:type", "@type": "@id"}

Manu Sporny: We need a new issue for that.

Manu Sporny: +1

Gregg Kellogg: +1

Niklas Lindström: +1

David I. Lehn: +0

Markus Lanthaler: -1 - Why don't we just allow any character for term declarations? Why limit it? Whitespace? Why not?

Gregg Kellogg: +1

Manu Sporny: +1

Niklas Lindström: +1

Markus Lanthaler: +1

David I. Lehn: +0