W3C home > Mailing lists > Public > public-linked-json@w3.org > May 2012

JSON-LD Telecon Minutes for 2012-05-01

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 01 May 2012 16:54:36 -0400
Message-ID: <4FA04D8C.6020805@digitalbazaar.com>
To: Linked JSON <public-linked-json@w3.org>
Thanks to Markus for scribing! The minutes from today's call are now 
available here:

http://json-ld.org/minutes/2012-05-01/

Full text of the discussion follows, the audio transcript will be
uploaded later today:

--------------------

JSON-LD Community Group Telecon Minutes for 2012-05-01

Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2012Apr/0057.html
Topics:
    1. ISSUE-96: Should framing results be object or array
    2. ISSUE-97: Frame expansion
    3. ISSUE-80: Remove initial context from API spec
    4. ISSUE-107: Fragment identifier interpretation
    5. ISSUE-98: Datatype coercion of native types
    6. RDF WG and JSON-LD
Resolutions:
    1. The result of framing MUST be an object with a @context and
       @graph property. The value of @graph is always an array
       containing zero or more results.
    2. For framing, use a combination of @preserve and @null,
       which are replaced in post-processing to avoid the problem of
       them disappearing during expansion or compaction.
    3. If JSON-LD has an initial context, it MUST be specified
       external to the JSON-LD Syntax specification at a well-known
       location.
    4. In JSON-LD a fragment identifier MAY identify a node in the
       linked data graph expressed in the document. This idiom, which is
       also used in RDF [RDF-CONCEPTS], gives a simple way to "mint"
       new, document-local IRIs to label nodes and therefore contributes
       considerably to the expressive power of JSON-LD.
    5. When round-tripping xsd:boolean values from JSON-LD through
       expansion and back through compaction, a JSON-native boolean
       value with xsd:boolean datatype coersion will remain a
       JSON-native boolean value.
    6. @value supports native JSON datatypes such as number,
       boolean, string.
    7. During expansion, a native JSON value with type coercion
       applied gets expanded to the expanded object form where the value
       of @value is still in the native JSON form and @type is the type
       in the type coercion rule.
    8. When compacting, if there is a direct match for @type for
       the property and @type for the property in the context, then the
       value of the property is replaced with the value of @value.
    9. Introduce a 'useNativeTypes' flag for the fromRDF algorithm
       which, when set, attempts to convert xsd:boolean, xsd:integer,
       and xsd:double to native JSON values. If the conversion fails the
       value will be converted to the expanded object notation form.
Chair:
    Manu Sporny
Scribe:
    Markus Lanthaler
Present:
    Markus Lanthaler, Manu Sporny, Gregg Kellogg, Dave Longley, David
    I. Lehn

Markus Lanthaler is scribing.
Manu Sporny:  Any updates or changes to Agenda? [scribe assist by
    Manu Sporny]
Markus Lanthaler:  Let's start with the easy ones - let's start
    with 96 and 97 [scribe assist by Manu Sporny]

Topic: ISSUE-96: Should framing results be object or array

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/96
Manu Sporny:  I believe you guys resolved this already on the
    issue tracker
Gregg Kellogg:  previously framing always returned an array where
    each object contained an context embedded which didn't make sense
    for me and Markus

PROPOSAL:  The result of framing MUST be an object with a
    @context and @graph property. The value of @graph is always an
    array containing zero or more results.

Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
Dave Longley: +1 (via issue tracker)

RESOLUTION: The result of framing MUST be an object with a
    @context and @graph property. The value of @graph is always an
    array containing zero or more results.


Topic: ISSUE-97: Frame expansion

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/97
Gregg Kellogg:  this had to do with default values and null
    values in framing as nulls would have been removed
Gregg Kellogg:  we use the @preserve and @null keyword now with a
    postprocessing step.
Manu Sporny:  This is something the implementers figured out
    between themselves and we're happy with the solution, so let's
    just resolve this as done since nobody seems to disagree with the
    current direction.

RESOLUTION: For framing, use a combination of @preserve and
    @null, which are replaced in post-processing to avoid the problem
    of them disappearing during expansion or compaction.

Gregg Kellogg:  I already closed the issue

Topic: ISSUE-80: Remove initial context from API spec

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/80
Gregg Kellogg:  Markus outlined that updating @type e.g. with
    @container by relying on the initial context is problematic
Gregg Kellogg:  and we never considered to use the init. context
    for something else
Manu Sporny:  that's a mistake we made in RDFa - we could have
    gone around a lot of backwards-incompatability issues by doing so
Manu Sporny:  we could say that in JSON-LD the initial context is
    blank but this could be used to change functionality in future
    versions of JSON-LD
Gregg Kellogg:  I can't see how this helps as an existing
    processor wouldn't understand that new information
Manu Sporny:  it's not a full solution for that but it's better
    than not having it
Gregg Kellogg:  we could put prefix definitions in there
Manu Sporny:  what should we put in there?
Gregg Kellogg:  same as in RDFa?
Manu Sporny:  JSON-LD is slightly different
Manu Sporny: Discussion about whether or not xsd and rdf are
    useful to pre-define. Markus' position is that it is only
    important to RDF folks and JSON folks probably won't care about
    those types of datatypes.
Manu Sporny: Gregg's position is that xsd is used heavily in the
    spec and has a place in the initial context.
Gregg Kellogg:  There is an advantage to saying that there is a
    default context - processors MUST load it, even if it is empty.
    [scribe assist by Manu Sporny]
Gregg Kellogg:  There is a URL that we define in the spec that is
    the location of the default context - as part of expansion, all
    processors must load that context before doing any other
    processing or when resetting back to the default context. [scribe
    assist by Manu Sporny]
would that mean that a processor without network access wouldn't
    work at all?
Gregg Kellogg:  no, it would work but fall back on a build in
    initial context - meaning the processor has to be updated
    regularly
Gregg Kellogg:  We saw this as a very useful feature in RDFa - it
    would behoove us to learn from the past and put this
    future-proofing mechanism in there. [scribe assist by Manu
    Sporny]
Manu Sporny: We seem to agree that if there is an initial
    context, it should be external to the spec. Markus is still
    skeptical that we need such a feature. Both Gregg and I feel that
    it is a good future-proofing mechanism - one that we definitely
    needed in the RDFa world and one that we think we might also need
    here.

PROPOSAL:  If JSON-LD has an initial context, it MUST be
    specified external to the JSON-LD Syntax specification at a
    well-known location.

Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1 with emphasis on IF
David I. Lehn: +0

RESOLUTION: If JSON-LD has an initial context, it MUST be
    specified external to the JSON-LD Syntax specification at a
    well-known location.


Topic: ISSUE-107: Fragment identifier interpretation

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/107
Manu Sporny:  IANA and W3C and WWW-TAG groups require us to
    define what fragment identifiers mean for MIME Types. Keep in
    mind that this means what fragment identifiers mean in documents,
    not necessarily what they mean when IRIs with fragment
    identifiers are used in documents.
Manu Sporny: Markus is proposing: In JSON-LD a fragment
    identifier MAY identify a node in the linked data graph expressed
    in the document. This idiom, which is also used in RDF
    [RDF-CONCEPTS], gives a simple way to "mint" new, document-local
    IRIs to label nodes and therefore contributes considerably to the
    expressive power of JSON-LD.
Gregg Kellogg:  what I like on Markus' proposal is that it is
    about an abstract concept and not a structural element which
    could be encoded twice in a document
Manu Sporny:  I would like to be able that a browser would be
    able to jump to something
Gregg Kellogg:  for that we could say it should jump to the first
    instance.. I don't know if that's something we have to specify
Gregg Kellogg:  I prefer Markus' proposal
Manu Sporny:  I'm fine with it
Manu Sporny:  we don't need to put it in the spec
Gregg Kellogg:  in terms of locating onself in a document?
Manu Sporny:  yes
David I. Lehn:  in the example are these full IRIs that are
    encoded (foo and bar)?
Manu Sporny:  it could as well be just a fragment identifier
    which would be expanded to a full IRI by taking the document IRI

PROPOSAL:  In JSON-LD a fragment identifier MAY identify a node
    in the linked data graph expressed in the document. This idiom,
    which is also used in RDF [RDF-CONCEPTS], gives a simple way to
    "mint" new, document-local IRIs to label nodes and therefore
    contributes considerably to the expressive power of JSON-LD.

Gregg Kellogg:  the question is what a fragment identifier means
    when it references a JSON-LD document
Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
David I. Lehn: +1

RESOLUTION: In JSON-LD a fragment identifier MAY identify a node
    in the linked data graph expressed in the document. This idiom,
    which is also used in RDF [RDF-CONCEPTS], gives a simple way to
    "mint" new, document-local IRIs to label nodes and therefore
    contributes considerably to the expressive power of JSON-LD.

Manu Sporny: NOTE: The group has discussed what graphical clients
    should do when given a JSON-LD fragment identifier and have come
    to the following conclusion: If an implementer is developing a
    client to view JSON-LD markup and wants to implement a feature
    for navigating to a fragment identifier in a JSON-LD document,
    the client software should navigate to the first definition of
    the fragment identifier in the JSON-LD document.
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
Manu Sporny: The group doesn't believe that we need to put this
    into the spec.
Markus Lanthaler:  could we talk about ISSUE-98 now?

Topic: ISSUE-98: Datatype coercion of native types

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/98
Markus Lanthaler:  This started when Gregg started to discuss
    what should happen to native types... [scribe assist by Manu
    Sporny]
Markus Lanthaler:  We had a number of discussions around this,
    but I think that Dave Longley and I said that datatype coercion
    should apply to native types - during expansion, those native
    types should be converted to strings. That should fall back on
    the JSON processors .toString() capabilities, probably. [scribe
    assist by Manu Sporny]
Markus Lanthaler:  In RDF round-tripping, native types get
    automatically type coerced to xsd:integer - they are converted
    back automatically when converting from RDF to JSON-LD. Longley
    didn't agree with that. [scribe assist by Manu Sporny]
Markus Lanthaler:  In compaction, strings are never converted to
    native types, all that happens there is the value is replaced
    with whatever value was in "@value" if the type matches. [scribe
    assist by Manu Sporny]
Markus Lanthaler:  Conversion between native types and strings
    happen automatically - so a "14"^^xsd:integer would be converted
    to 14 in JSON-LD. [scribe assist by Manu Sporny]
Markus Lanthaler:  We may want to have a flag to turn automatic
    conversion on/off since Longley doesn't agree that we should do
    the auto-conversion. [scribe assist by Manu Sporny]
Gregg Kellogg:  We have a consistency issue - any processing of
    JSON-LD requires you to expand. Any use of native types will be
    replaced with strings after doing expansion, compaction, framing
    or RDF conversion. [scribe assist by Manu Sporny]
Gregg Kellogg:  We have lost the ability to retain the native
    types. [scribe assist by Manu Sporny]
Markus Lanthaler:  Native types are retained unless you have
    coercion. If you have a numeric type and you have a numeric
    conversion, you don't need to transform the type. [scribe assist
    by Manu Sporny]
Gregg Kellogg:  native types are not transformed at all, they
    remain in their form through expansion/compaction if their
    meaning is ambiguous. [scribe assist by Manu Sporny]
Gregg Kellogg:  Type coercion only has effect for strings. It
    doesn't have an effect for something in native value form, it
    only has effect for something that is a string. [scribe assist by
    Manu Sporny]
Markus Lanthaler:  If you specify type coercion, it should always
    apply. [scribe assist by Manu Sporny]
Gregg Kellogg:  Then, as an author that wants to use native
    types, I can do so as long as I don't coerce them to an
    xsd:integer type. If I have 5, and I say xsd:integer, I can't
    express it with a number. [scribe assist by Manu Sporny]
Gregg Kellogg:  things expressed as boolean integer or double
    always compact down to their native representations when there is
    no loss involved. [scribe assist by Manu Sporny]
Gregg Kellogg:  We could depend on the 'strict' flag to tell us
    when an inconsistency is seen. [scribe assist by Manu Sporny]
Markus Lanthaler:  If you have 5, and you coerce to xsd:double -
    how would you preserve that in expansion? [scribe assist by Manu
    Sporny]
Manu Sporny:  I'm concerned that we're discussing a few different
    issues at the same time. [scribe assist by Manu Sporny]
Manu Sporny:  we could move all that automatic conversion to
    fromRDF/toRDF
Gregg Kellogg:  it's similar to Turtle which has native forms for
    integers, booleans etc.
Gregg Kellogg:  we could have a flag there to keep strings or
    convert to native types as Markus suggested
Gregg Kellogg:  the xsd types are there to describe how data is
    stored in computers.. in JSON we do the same even though JSON is
    crippled as it just has "number"
Manu Sporny: Discussion about what we're discussing - we're
    talking about how booleans, doubles and integers are
    round-tripped between compaction/expansion and to/from RDF.
Gregg Kellogg:  I'm really concerned that we could have a case
    where an author specifies true in JSON-native form, expands, then
    compacts and gets back the string "true". [scribe assist by Manu
    Sporny]
Dave Longley:  During compaction/expansion, if something is a
    native form, can we just leave it that way? Do we all agree on
    that? [scribe assist by Manu Sporny]
Gregg Kellogg:  Native types stay native types... that's good.
    [scribe assist by Manu Sporny]
Dave Longley:  If there is no type coercion rule - we keep the
    native type. [scribe assist by Manu Sporny]
Markus Lanthaler:  Do we want to use xsd:double or xsd:integer -
    do they expect it to convert to a JSON type? [scribe assist by
    Manu Sporny]
Dave Longley:  It's the closest approximation we have. [scribe
    assist by Manu Sporny]
Markus Lanthaler:  xsd:integer and xsd:double is about
    interoperability. [scribe assist by Manu Sporny]
Dave Longley:  If you don't put any type coercion information
    into your context, then anything that is a string will stay a
    string unless you do conversion toxsd:integer in the @context.
    [scribe assist by Manu Sporny]
Dave Longley:  We get into trouble if we force incoming triples
    that have xsd:integer to be converted to native type, that's a
    mistake. We could lose precision. It could make people not want
    to use it as a data transport mechanism. etc. [scribe assist by
    Manu Sporny]
Gregg Kellogg:  Let's separate this from a to/from RDF issue,
    let's just talk about compaction at this point. [scribe assist by
    Manu Sporny]
Gregg Kellogg:  If we just use compaction/expansion - if we start
    with something that is native form, I don't end up with something
    that is native form. If we don't want to get into automatic
    conversion, if something is in a native type - it stays in that
    native type. [scribe assist by Manu Sporny]
Markus Lanthaler:  What information have you lost? [scribe assist
    by Manu Sporny]
Dave Longley:  You don't know if the number is a double or not -
    you no longer know if you're working with an integer or a double.
    [scribe assist by Manu Sporny]
Markus Lanthaler:  This is an issue - 5 (xsd:double) -> expansion
    -> 5 (no way to know that it is supposed to be an xsd:double)
Markus Lanthaler:  We want to end up with this: "@value": 5,
    "@type": "xsd:double"
Dave Longley:  The issue we have is JSON-LD: 4 (xsd:double) ->
    expanded 4 -> [[[long discussion about example]] [scribe assist
    by Manu Sporny]
Manu Sporny: Gregg is proposing that we can do: "@value": 5,
    "@type": "xsd:double" in expanded form.
Gregg Kellogg:  My worry is JSON-LD true -> expansion "true" ->
    compaction "true" - data doesn't round trip correctly in JSON-LD
    compaction/expansion. [scribe assist by Manu Sporny]

PROPOSAL:  When round-tripping xsd;boolean values from JSON-LD
    through expansion and back through compaction, a JSON-native
    boolean value with xsd

Manu Sporny: +1
Gregg Kellogg: +1
Dave Longley: +1
David I. Lehn: +0
Markus Lanthaler: +1

RESOLUTION: When round-tripping xsd:boolean values from JSON-LD
    through expansion and back through compaction, a JSON-native
    boolean value with xsd:boolean datatype coersion will remain a
    JSON-native boolean value.

Manu Sporny: Discussion about "principles of expected behavior" -
    there is such a thing as a native type, if they want to preserve
    a native type they must be able to do so.

PROPOSAL:  @value supports native JSON datatypes such as number,
    boolean, string.

Markus Lanthaler: +1
Manu Sporny: +1
Gregg Kellogg: +1
Dave Longley: +1
David I. Lehn: +1

RESOLUTION: @value supports native JSON datatypes such as number,
    boolean, string.

Gregg Kellogg:  The native value true should expand to {"@value":
    true, "@type": "whatever_value_they specified} [scribe assist by
    Manu Sporny]
Dave Longley:  When compacting, @value stays the same if the
    datatype matches. Or it is kept in expanded form if the datatype
    does not match. [scribe assist by Manu Sporny]

PROPOSAL:  During expansion, a native JSON value with type
    coercion applied gets expanded to the expanded object form where
    the value of @value is still in the native JSON form and @type is
    the type in the type coercion rule.

Markus Lanthaler: +1
Dave Longley: +1
Manu Sporny: +1
Gregg Kellogg: {"@value": true, "@type": "xsd:integer"}
Gregg Kellogg: +1
David I. Lehn: +0

RESOLUTION: During expansion, a native JSON value with type
    coercion applied gets expanded to the expanded object form where
    the value of @value is still in the native JSON form and @type is
    the type in the type coercion rule.

{"@value": true, "@type": "xsd:integer"} -> compaction with term
    with xsd:double -> {"@value": true, "@type": "xsd:integer"}
{"@value": true, "@type": "xsd:integer"} -> compaction with term
    with xsd:integer -> true
Manu Sporny:  In strict mode, do we raise an exception for the
    last thing Markus just said? [scribe assist by Manu Sporny]
Gregg Kellogg:  I think so, yes. [scribe assist by Manu Sporny]

PROPOSAL:  When compacting, if there is a direct match for @type
    for the property and @type for the property in the context, then
    the value of the property is replaced with the value of @value.

Gregg Kellogg: +1
Markus Lanthaler: +1
Manu Sporny: +1
David I. Lehn: +0
Manu Sporny: So, for example: This is your data: "foo":
    {"@value": true, "@type": "xsd:boolean"}, this is in the @context
    "foo": {"@id": "...", "@type": "xsd:boolean"}, then this is the
    result: "foo": true
Gregg Kellogg: +1

RESOLUTION: When compacting, if there is a direct match for @type
    for the property and @type for the property in the context, then
    the value of the property is replaced with the value of @value.


PROPOSAL:  Introduce a 'useNativeTypes' flag for the fromRDF
    algorithm which, when set, attempts to convert xsd;boolean,
    xsd;integer, and xsd;double to native JSON types. If the
    conversion fails the value will be converted to the expanded
    object notation form.

Gregg Kellogg: +1
Markus Lanthaler: +1
David I. Lehn: +0
Manu Sporny: +1
Dave Longley: one quick thought: I was thinking about how we have
    a flag in fromRDF now to decide whether or not rdf:type should
    map to @type ... maybe we just want to do the same thing for all
    of the xsd stuff. In other words, in compaction/expansion, don't
    deal with the meaning of xsd at all; just always leave things in
    their native form (but include @type information when expanding
    like we agreed, just consider it opaque). Only when
Dave Longley: converting to/from RDF, would special conversion
    rules apply (to convert natives to another form). We could use
    mappings instead of flags with defaults to xsd. We could
    introduce@double/@integer/ @boolean just for that specific
    purpose (only used as mapping options in to/from RDF), eg:
    @integer => xsd:integer and vice versa. afk.

RESOLUTION: Introduce a 'useNativeTypes' flag for the fromRDF
    algorithm which, when set, attempts to convert xsd:boolean,
    xsd:integer, and xsd:double to native JSON values. If the
    conversion fails the value will be converted to the expanded
    object notation form.

Dave Longley:  pretty much what we were discussing. [scribe
    assist by Gregg Kellogg]
Gregg Kellogg:  having a flag whose default value is true is a
    bit awkward
Gregg Kellogg:  useNativeTypes set to 'true' is a bit awkward -
    if we have a flag which is used to get to the unusual case of
    just using expanded form, it would be more intuitive - what's the
    appropriate name for the flag to trigger that. [scribe assist by
    Manu Sporny]

Topic: RDF WG and JSON-LD

Manu Sporny: I have notified the RDF WG that we think the JSON-LD
    Syntax is stable and that we introduced the concept of named
    graphs.
Gregg Kellogg: JSON-LD is stable:
    http://lists.w3.org/Archives/Public/public-rdf-wg/2012Apr/0274.html
Gregg Kellogg: JSON-LD introduced named graphs:
    http://lists.w3.org/Archives/Public/public-rdf-wg/2012Apr/0275.html
Gregg Kellogg:  We should send a response to Sandro about the
    usage of Layer instead of graph - probably don't want to use
    layer. [scribe assist by Manu Sporny]
Manu Sporny:  I'll do that. [scribe assist by Manu Sporny]


-- manu

-- 
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 Tuesday, 1 May 2012 20:55:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:36 GMT