JSON-LD Telecon Minutes for 2011-11-15

Thanks to Markus for scribing! Minutes are now available here:

http://json-ld.org/minutes/2011-11-15/

Full text follows. Audio will be uploaded later.

JSON-LD Community Group Telecon
Minutes for 2011-11-15
Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2011Nov/0022.html
Chair:
   Gregg Kellogg
Scribe:
   Markus Lanthaler
Present:
   Gregg Kellogg, Markus Lanthaler, Niklas Lindstr�m, David I. Lehn

Markus Lanthaler is scribing.

Topic: ISSUE-35: JSON Vocabulary / Data Round-tripping

Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues/35
Markus Lanthaler:  http://www.w3.org/TR/turtle/#abbrev
   ... Decimal floating point double/fixed precision numbers may 
   be written directly and correspond to the XML Schema Datatype 
   xsd:double in both syntax and datatype IRI.
   ... Decimal floating point arbitrary precision numbers may be 
   written directly and correspond to the XML Schema Datatype 
   xsd:decimal. in both syntax and datatype IRI.
Gregg Kellogg:  I think there were some JavaScript issues 
   motivating this conversation
Niklas Lindstr�m:  If you wanna keep precision you should 
   explicitely coerce to type
Niklas Lindstr�m: "age": "xsd:double"
Niklas Lindstr�m: "age": 33
Gregg Kellogg: 33.0e1
Niklas Lindstr�m: "33.0"^^xsd:double
Gregg Kellogg: 3.3e1
Gregg Kellogg: {"foo": "3."}
Niklas Lindstr�m: "3"^^xsd:integer
Gregg Kellogg:  The problem is JSON could be ambigous
Gregg Kellogg:  Depends on parser
Niklas Lindstr�m: "foo": {"@literal": "3.", "@datatype": 
   "xsd:decimal"}
Niklas Lindstr�m: :foo 3
Niklas Lindstr�m:  If you would like have a explicit RDF output 
   you would have to use the above form
Niklas Lindstr�m: foo: 3
Niklas Lindstr�m: foo: 3.0
According to http://jsonlint.com/ that's translated to foo: 3
Markus Lanthaler:  I think if we would make JSON-LD work as 
   Turtle in automatic typing I think it would solve our problems
http://json-ld.org/spec/latest/json-ld-syntax/#automatic-typing
Markus Lanthaler:  We currently automatically type to integer, 
   double or boolean
   ... Why don't we distinguish between double and decimal
Niklas Lindstr�m: denormalized JSON | normalized JSON or Turtle 
   short form | explicitly typed Turtle
Niklas Lindstr�m: 3.3e10 | 3.3e1 | "3.3e1"^^xsd:double
Niklas Lindstr�m: 1.10 | 1.1 | "1.1"^^xsd:decimal
Niklas Lindstr�m: 1.0 | 1 | "1"^^xsd:integer
Niklas Lindstr�m: 3.30e1 | 3.3e1 | "3.3e1"^^xsd:double
Markus Lanthaler:  3.3e10 | 3.3e1 | "3.3e1"^^xsd:double
   ... 3.31e1 | 3.31e1 | "3.31e1"^^xsd:double
Gregg Kellogg: 3.3e20
Gregg Kellogg: 3.3e-20
David I. Lehn: i'm not sure what we're discussing here!  the 
   differences in json parsers and serializers are going to cause 
   pain anyway you look at it unless you use explicit typing.
David I. Lehn:  yes, we're looking into if there is any 
   "baseline" in JSON or if we have to specify it all [scribe assist 
   by Niklas Lindstr�m]
PROPOSAL:  no change to spec

Niklas Lindstr�m: +1
Gregg Kellogg: +1
David I. Lehn: +1
Markus Lanthaler: +1
RESOLUTION:  no change to spec


Topic: ISSUE-40: Merge @coerce with @context https://github.com/json-ld/json-ld.org/issues/40

Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues/40
Gregg Kellogg:  We had agreed to change @coerce
Gregg Kellogg: "@context": {
Gregg Kellogg: "title": "http://purl.org/dc/terms/title",
Gregg Kellogg: "description": 
   "http://purl.org/dc/terms/description",
Gregg Kellogg: "identifier": 
   {"http://purl.org/dc/terms/identifier": "xsd:string"},
Gregg Kellogg: "publisher": 
   {"http://purl.org/dc/terms/publisher": "@iri"},
Gregg Kellogg: "created": {"http://purl.org/dc/terms/created": 
   "xsd:dateTime"},
Gregg Kellogg: "authorList": 
   {"http://purl.org/ontology/bibo/authorList": ["@list", "@iri"]}
Gregg Kellogg: }
Gregg Kellogg:  The key is the IRI and the value is the type
Gregg Kellogg: "authorList": 
   {"http://purl.org/ontology/bibo/authorList": { "@list": "@iri" }}
Gregg Kellogg: "created": { "@iri" : 
   "http://purl.org/dc/terms/created", "@coerce": "xsd:dateTime"}
Gregg Kellogg:  Alternative: value is object, this says @list 
   entries are of type @iri
Niklas Lindstr�m:  Really prefer first form
Niklas Lindstr�m: 
   https://raw.github.com/rinfo/rdl/1c8c6d2/packages/java/rinfo-service/src/main/resources/json-ld/context.json
Niklas Lindstr�m: 
   https://raw.github.com/gist/1340408/context-vocab-array-combined-iri-coerce.json
Gregg Kellogg:  @vocab would have to specified prior to be used 
   in the context (in a outer context)
Gregg Kellogg:  Point is when is the active context modified. I 
   think it should be modified before the currently processed 
   context has been fully processed
Niklas Lindstr�m:  Regardless if we merge coerce and prefix 
   definitions or not it can't be processed in one pass
Niklas Lindstr�m:  We should discuss: 1) if we merge @coerce into 
   term def. 2) if @list is in array orf object form
PROPOSAL:  move @coerce into term definitions

Niklas Lindstr�m: +1
Gregg Kellogg: +1
David I. Lehn: (i'm afraid i haven't put enough thought into this 
   to vote)
Markus Lanthaler: +1
RESOLUTION:  move @coerce into term definitions

Niklas Lindstr�m:  3) using @vocab to resolve right-hand value 
   expansion
Gregg Kellogg:  @vocab would have to come before it's used for 
   stream-based parsers
Niklas Lindstr�m:  that's also applies to expansion in coerce
Niklas Lindstr�m:  I found it useful to have many contexts.. 
   especially for using groups of terms
Niklas Lindstr�m:  also useful for keeping memory usage low
Gregg Kellogg:  Looking at your list of contexts in the example
Gregg Kellogg:  All the stuff in the first context like terms and 
   @vocab can be used in the second context
Niklas Lindstr�m:  I implemented it so that first @vocab is taken 
   to expand values, then term definitions are parsed
Gregg Kellogg:  That would mean processing a context would be a 
   multi-pass operation
Niklas Lindstr�m: 
   https://github.com/rinfo/rdl/blob/develop/packages/java/rinfo-base/src/main/groovy/se/lagrummet/rinfo/base/rdf/jsonld/JSONLDContext.groovy
PROPOSAL:  parsing @context is multi-pass. first to get term 
   mappings, and then to resolve @datatypes

Gregg Kellogg: +1
Niklas Lindstr�m: +1
David I. Lehn: +1
Markus Lanthaler: +1
Niklas Lindstr�m: { "foaf": "foaf:foo}
{ "a" : "b:c", "b" : "a:c" }
RESOLUTION:  parsing @context is multi-pass. first to get term 
   mappings, and then to resolve @datatypes [rescinded later -- gk]


ACTION: discuss that prefixes can't be used for expanding uris within the same context, unless they're part of @datatype portion.

PROPOSAL:  @vocab is resolved prior to term URI expansion

Niklas Lindstr�m: +1
Gregg Kellogg: +1
Markus Lanthaler: -1
David I. Lehn: +0
Niklas Lindstr�m: @context: [{foaf: �, dc: �}, {"title: 
   "dc:title", "homepage": "foaf:homepage"}]

ACTION: define prefixes required for expansion in context definitions prior to use.

Gregg Kellogg:  If we are doing it that way we could also go back 
   to single-pass processing (for datatype expansion)
Gregg Kellogg: this removes the need to do 2-pass @context 
   processing.

ACTION: rescind previous resolution: parsing @context is multi-pass. first to get term mappings, and then to resolve @datatypes

Gregg Kellogg: "created": { "@iri" : 
   "http://purl.org/dc/terms/created", "@coerce": "xsd:dateTime"}
"created": { "@iri" : "http://purl.org/dc/terms/created", 
   "@type": "xsd:dateTime"}
Gregg Kellogg: "created": {"@iri": "dc:created", "@datatype": 
   "xsd:dateTime"}
"created": [ "http://purl.org/dc/terms/created", { "@type": 
   "xsd:dateTime"} ]
"created": [ "http://purl.org/dc/terms/created", { "@coerce": 
   "xsd:dateTime"} ]
Gregg Kellogg: "created": {"dc:created": "xsd:dateTime"}
"created": {"http://purl.org/dc/terms/created": 
   "http://www.w3.org/2001/XMLSchema#dateTime"},
Markus Lanthaler:  Could we push this back to the mailing list
Niklas Lindstr�m: "created": {"@iri": "dc:created", "@datatype": 
   "xsd:dateTime", "@array": "@list"}
Niklas Lindstr�m: "created": {"@iri": "dc:created", "@datatype": 
   "xsd:dateTime", "@list": true}
Niklas Lindstr�m: "created": {"@iri": "dc:created", "@datatype": 
   "xsd:dateTime", "@rev": true, "@set": true}


Gregg

Received on Tuesday, 15 November 2011 19:12:20 UTC