JSON-LD Telecon Minutes for 2012-03-27

Thanks to Markus Lanthaler for scribing! The minutes from today's call 
are now available here:

http://json-ld.org/minutes/2012-03-27/

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

Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2012Mar/0025.html
Topics:
    1. ISSUE-81: Data round tripping issues
    2. ISSUE-87: Clarification of @set and expansion
    3. Explicit term for RDF type?
    4. ISSUE-88: Reserved keywords
Resolutions:
    1. Terms MAY be defined as any valid JSON string. Terms
       starting with an '@' character SHOULD NOT be used as they may
       createforward-compatibilit y issues.
Chair:
    Manu Sporny
Scribe:
    Markus Lanthaler
Present:
    Markus Lanthaler, Manu Sporny, Gregg Kellogg, Niklas Lindström,
    David I. Lehn
Audio:
    http://json-ld.org/minutes/2012-03-27/audio.ogg

Markus Lanthaler is scribing.
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

Topic: ISSUE-81: Data round tripping issues

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
Discussion about data round-tripping
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
That was last week's resolution: RESOLVED: 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:  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)
last week's resolution: RESOLVED: Unless there are type coercion
    rules in the @context that apply, native JSON numbers and strings
    are not modified in compacted or expanded form.
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

Topic: ISSUE-87: Clarification of @set and expansion

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"}

Topic: Explicit term for RDF type?

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]

Topic: ISSUE-88: Reserved keywords

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?

PROPOSAL:  Terms MUST have the lexical form of IRI with the
    addition of "@" being an allowed initial character. Authors
    SHOULD NOT create terms with an initial "@".

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.

PROPOSAL:  Term definitions MUST have the lexical form of an IRI
    with the addition of "@" being an allowed initial character.
    Authors SHOULD NOT create terms with an initial "@".

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?
Discussion about allowing any character that is valid in a JSON
    string, resulting in this proposal:

PROPOSAL:  Terms MAY be defined as any valid JSON string. Terms
    starting with an '@' character SHOULD NOT be used as they may
    create forward-compatibility issues.

Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +0

RESOLUTION: Terms MAY be defined as any valid JSON string. Terms
    starting with an '@' character SHOULD NOT be used as they may
    create forward-compatibility issues.

-- 
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 Wednesday, 28 March 2012 03:27:34 UTC