- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 01 May 2012 16:54:36 -0400
- 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 UTC