- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 08 May 2012 16:50:04 -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-08/
Full text of the discussion follows including a link to the audio
transcript:
--------------------
JSON-LD Community Group Telecon Minutes for 2012-05-08
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2012May/0001.html
Topics:
1. ISSUE-115: Expanded form - expand all native types to
@value form?
2. ISSUE-114: Values space of keywords
3. ISSUE-112: Define mandatory API parameters (options)
Resolutions:
1. In general, for expansion, ensure that all property values
are expressed in expanded value form (e.g. {"@value": 5},
{"@value": "foo"}, {"@id": "http://example.com/"}) with the
exception of @id and @type.
2. In expanded form, @graph must be expressed in expanded
value form (e.g. "@graph": [{"@id":
"http://example.com/foo#graph}])
3. In general, if the author's intent is clear, we should
transform the input into proper JSON-LD (keeping the processor
mode, if any, in mind - in strict mode, throw exceptions, in lax
mode, attempt to interpret the value).
4. When converting toRDF(), any value that is a JSON number
that has a fractional value MUST be treated as an xsd:double
using the printf("%1.15E", number) representation.
5. There are no mandatory options in the JSON-LD API. Defaults
must be specified for all options passed to JSON-LD API methods.
6. The default for the base IRI for JSON-LD API methods is the
current document IRI if in a browser context, or the empty string
if there is no document context.
Chair:
Manu Sporny
Scribe:
Manu Sporny
Present:
Manu Sporny, Markus Lanthaler, Niklas Lindström, Gregg Kellogg,
David I. Lehn
Audio:
http://json-ld.org/minutes/2012-05-08/audio.ogg
Manu Sporny is scribing.
Manu Sporny: Any additions or changes to the agenda?
Markus Lanthaler: Should we address the syntax-related ones
first?
Niklas Lindström: I can only be here for one hour.
Manu Sporny: Rearrange the agenda to deal with syntax issues...
Gregg Kellogg: Let's talk about the ones that Niklas wants to
weigh in on.
Topic: ISSUE-115: Expanded form - expand all native types to @value form?
https://github.com/json-ld/json-ld.org/issues/115
Markus Lanthaler: This issue came up in IRC, discussion about
framing - there are different ways to express a value in JSON-LD
- plain literals, or a JSON number, etc. Directly as a property
value or via @value - in expanded form.
Gregg Kellogg: With regard to @graph, it was an issue with
subject references - should it be in expanded form {"@id":
"http://graph.id/foo/bar"} or just "http://graph.id/foo/bar" -
the @value issue is only one of the issues.
Gregg Kellogg: Does expanded form really mean "expanded", or do
we do some amount of compaction in expanded form?
Markus Lanthaler: I always saw expanded form in as just IRI
expansion.
Markus Lanthaler: Not just IRI expansion but primarily IRI
expansion
Manu Sporny: the intent in the beginning for expanded form was
to have a regular data structure that you could easily code
against - the more regular, the easier it is.
Markus Lanthaler: My issue with this is that we may not want to
go all the way on this - we may want to do a slight amount of
compaction.
Manu Sporny: we have two issues here 1) whether or not to expand
@graph to have a value of a JSON object with "@id" in it in
expanded form, and 2) whether or not all values get expanded to a
JSON object containing "@value" in expanded form.
Manu Sporny: one concern that you have, Markus, is the amount of
overhead expanded form has.
Markus Lanthaler: Most of the time you just deal with the native
datatypes and that is enough - that is, expanded form is not very
useful for JSON developers.
Niklas Lindström: Would regular JSON developers like to deal
with expanded form at all?
Manu Sporny: Would they want to use compact form more often?
Niklas Lindström: Yes, the shape of RDF/JSON is always
predictable - but it's illegible for anyone expecting plain old
JSON. The expanded form of JSON-LD is very similar to RDF/JSON in
expanded form.
Niklas Lindström: I don't think we should expand anything that
is predictable in a less expanded form... which kind of developer
are we catering for...
Markus Lanthaler: That's a bit difficult, everyone has their own
idea on how this is going to be used.
Niklas Lindström: Based on the shape of the expanded form, we
should expect that people want to get it into their JS and just
do something with it... this is an information exchange format
for extremely detailed info.
Markus Lanthaler: Since all IRIs are expanded, it makes it very
useful.
Niklas Lindström: Yes, but only if you want to express the RDF
description - it's middleware.
Gregg Kellogg: it's not the type of JSON that a developer would
typically expect... that's what framing and compaction are for.
Expansion is to get something in a more normal form so it can be
further processed. Every time I have a property, the value is
expressed as an array of objects - that simplifies things.
Niklas Lindström: Yes, exactly, you should always be able to
know what to look at next - normal form is good.
Manu explains the logic behind the current direction.
Markus Lanthaler: Example of how this makes things simpler?
Manu explains converting to n-triples and branching.
Gregg Kellogg: This not only applies to N-Triples - you have to
check the value of each property - is it a number, a boolean, a
string, or a JSON object? There is going to be branching, but it
does simplify the logic in the program.
Niklas Lindström: If we don't do this, but allow plain values
directly - you'd have to first check if it is an object - it's a
more complex algorithm if we mix the types.
Niklas Lindström: This is very consistent with how similar
formats work - SPARQL and RDF/JSON - there is a regularity in
their shapes.
Manu Sporny: I think there is broad agreement between Gregg,
Niklas, Dave Longley and myself on this being the proper
direction.
Markus Lanthaler: I won't block if you guys agree - still have a
hard time seeing the value in this.
Manu Sporny: We can always rewind this decision later if it
turns out to be a bad idea.
Markus Lanthaler: So, @id, @type, and possibly @graph are the
only things that are not expanded to @value form?
Gregg Kellogg: Still need to discuss @graph, but yes.
Markus Lanthaler: hmm
Manu Sporny: There hasn't been much support for literals as
identifiers over the past 10 years... mint a new IRI scheme if
you need to -myid:FooBar
PROPOSAL: In general, for expansion, ensure that all property
values are expressed in expanded value form (e.g. {"@value"; 5},
{"@value"; "foo"}, {"@id"; "http;//example.com/"}) with the
exception of @id and @type.
Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny: +1
Markus Lanthaler: +0
RESOLUTION: In general, for expansion, ensure that all property
values are expressed in expanded value form (e.g. {"@value": 5},
{"@value": "foo"}, {"@id": "http://example.com/"}) with the
exception of @id and @type.
Manu Sporny: Next question we need to address is whether or not
@graph is expanded value form in expansion.
Markus Lanthaler: Is there any reason to have graph expanded?
Manu Sporny: It's more modular code to process it if we express
it in expanded value form - and we have a clear way of supporting
literal names for graphs.
Gregg Kellogg: Postel's rule - strict in what you generate,
lenient in what a processor does.
Manu Sporny: Authors/processors must not generate this in
expanded form: "@graph": "http://foo.bar/" - but a processor must
read that as an IRI if it sees it.
Gregg Kellogg: In the case of @graph, my processor acts as if
there is a coercion to @id (it can be a relative IRI), or you
could use a fragment ID in that case.
Manu Sporny: Is this the right way to go, Markus?
Markus Lanthaler: Based on the previous train of logic, yes.
PROPOSAL: In expanded form, @graph must be expressed in expanded
value form (e.g. "@graph"; [{"@id";
"http;//example.com/foo#graph}])
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +0.5
RESOLUTION: In expanded form, @graph must be expressed in
expanded value form (e.g. "@graph": [{"@id":
"http://example.com/foo#graph}])
David I. Lehn: +0
Markus Lanthaler: When compacting what happens?
Gregg Kellogg: Act as if there is a coercion to @id
Gregg Kellogg: if we were to accept values, which we don't
currently, they would be kept in expanded form - for numbers,
booleans, (if that would ever make sense) - keep it in expanded
form.
Niklas Lindström: It's worth noticing, this doesn't result in
any RDF...
Gregg Kellogg: We have this so you could name a linked graph - a
property that references a graph with an IRI - this thing names
the reference resource using the @id of the object containing
graph.
Markus Lanthaler: Wouldn't it be easier to understand if we keep
the expanded form in this case?
Niklas Lindström: I think so - in compact form, we should keep
this shape.
Markus Lanthaler: "@graph": "http://example.com/foo#graph"
Markus Lanthaler: That is ambiguous, right?
Gregg Kellogg: It's not ambiguous, processing rules tell you
exactly how to treat that...
Markus Lanthaler: If you know the spec, then yes - but for
someone that doesn't know what's going on - they're not going to
understand that that's a graph that is elsewhere?
Markus Lanthaler: { "prop": "test", "@graph":
"http://example.com/foo#graph" }
Niklas Lindström: If I just glanced at it, I'd expect that to be
the graph identifier.
Gregg Kellogg: Yeah, I see.
Gregg Kellogg: If we want to allow a linked representation of
graphs - if I have one document that names a graph that is
identified as being in another document - having that as an IRI
is a natural way to express that, right?
Gregg Kellogg: We could make that illegal - this seems like a
HTTPRange-14 issue - you can't interpret the document w/o the
reference to it to interpret the document.
Markus Lanthaler: I'm saying that we shouldn't compact that by
default.
Gregg Kellogg: Maybe that's a named graph with no content - how
would I express that I'm not identifying an empty graph - I'm
referencing another document.
Niklas Lindström: This seems like a conflation between syntax
and semantics. I can't really see the use case for this.
Gregg Kellogg: The problem with named graphs is that there is
only one name - what is the context in which you're naming - in
WikiData, they want to name each statement with it's own
provenance - it requires the SNIK to be encapsulated inside
another object that contains provenance information.
Gregg Kellogg: Having stuff at the granularity where you're
naming makes it more difficult - you want a different dimension
on name in that case - being able to remotely reference a graph
allows you to have the same triples associated within the same
context - if you only have one dimension of naming, you can't do
that.
Niklas Lindström: I don't see why this specific construct
addresses your use case, Gregg. Seems like you need reification
to solve that.
Gregg Kellogg: reification seems like it's being obsoleted.
Gregg Kellogg: This comes back to the notion of JSON-LD being
Linked Data and the ability to link to graphs being named.
Gregg Kellogg: It's not simply an object or an array of objects,
but also potentially subject references that could be strings
that are IRIs.
Gregg Kellogg: Fundamental question is do we want to enable
linking to external documents and naming them using the named
graph syntax, or not? If not, is there some better way to express
the intention that the subject reference is intended to have the
document dereferenced.
Niklas Lindström: ... "@graph": [ {"@id":
"http://example.com/foo#graph, "@graph": [ {"@id": s, p: o} ] },
... ]
Topic: ISSUE-114: Values space of keywords
https://github.com/json-ld/json-ld.org/issues/114
Niklas Lindström: (the above is a graph of graphs, each triple in
its own named graph)
Markus Lanthaler: This is not really an issue - more of trying
to get an understanding - what's the value space of the different
keywords? Does @type support just strings, or arrays of objects?
Markus Lanthaler: I want us to all agree on the value space of
all of our keywords.
Gregg Kellogg: The case for @type and @id is if it can accept
{"@id": "http://example.com"} ?
Niklas Lindström: Given postels law coming up before - we might
want to define the value space of the keywords - but accept
something more. We allow stranger values to appear, but we turn
them back into something not awful.
Manu Sporny: The concern is making implementations more complex.
Niklas Lindström: Yes, XHTML vs. HTML5.
Manu Sporny: The goal would be to try and standardize the way
weird things are interpreted in JSON-LD.
Gregg Kellogg: There is syntactic normality and then semantic
normality - this has more to do with semantic normality.
Gregg Kellogg: Like, do we allow arrays for @id? We say it's not
valid, but then we might say that if a JSON-LD processor sees it,
pick the first item in the array.
Niklas Lindström: Yes, we could do something like that.
Gregg Kellogg: We could have a part in the API spec that states
how a processor reacts when it meets multiple values when it
expects a single value. If it expects a string and is presented
with an object, then it deals with it in another way.
Discussion about value spaces described in ISSUE-114 by Markus.
General agreement that the list generated by Markus is good,
modulo that @graph shouldn't allow "string" and @list and @set
should be expanded upon to make it more clear about the types of
permutations allowed.
Markus Lanthaler: Should we throw an exception when value space
is messed up?
Gregg Kellogg: No, we have a "recovery value space" - so, if
somebody uses {"@id": "http://schema.org/Person"} w/ @type, we
can still interpret it - exception is thrown in strict mode,
otherwise modified in lax mode.
Markus Lanthaler: If you turn of @type in fromRDF - I don't know
why we'd support coercion to @type later on.
Gregg Kellogg: We have to support coercion of keywords to other
things - normal JSON allows a context for that.
Niklas Lindström: Are you talking about coercion to type @type.
Markus Lanthaler: a JSON document won't have RDF type in there.
Gregg Kellogg: Is Postel's law built into JSON-LD - when parsing
input, are we forgiving of the form of that input?
Gregg Kellogg: Do we turn it into a more normal form or not -
that's what strict mode does - it allows you to be pedantic about
your input.
Gregg Kellogg: However, in lax mode - we should do what we can
to allow it... if the value-space is that of a subject definition
or subject reference - it's to be interpreted as an IRI.
Niklas Lindström: If it's unambiguous, we can do something about
it.
Markus Lanthaler: Yes, but implementers need to know when to
throw an exception.
Markus Lanthaler: We should discuss the most forgiving mode the
implementation has to support - we should discuss the least
forgiving case as well and what the value space there is.
Gregg Kellogg: I think we accept things that are not in array
form - that is, when the author's intention is clear then we
should support the transformation.
Manu Sporny: As a general rule - we're saying: If the author's
intent is clear, we should transform it into proper JSON-LD.
Niklas Lindström: Maybe we should call it 'preferred' form
instead of 'strict'.
Discussion about what "form" means...
Niklas Lindström: The "preferred form" is the way you should
express your form... but we read in forms that are non-preferred,
but in which the author's intent is clear.
Markus Lanthaler: My concern when I wrote this issue was to
define the input value space for a processor.
PROPOSAL: In general, if the author's intent is clear, we should
transform the input into proper JSON-LD (keeping the processor
mode, if any, in mind - in strict mode, throw exceptions, in lax
mode, attempt to interpret the value).
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1 for the first part
David I. Lehn: +0
RESOLUTION: In general, if the author's intent is clear, we
should transform the input into proper JSON-LD (keeping the
processor mode, if any, in mind - in strict mode, throw
exceptions, in lax mode, attempt to interpret the value).
Gregg Kellogg: We need a way to make the test suite set
processor mode flags.
Markus Lanthaler: What about when you expect that an exception
should be thrown?
Gregg Kellogg: nope, not yet - need to update the test suite.
ISSUE-81: Data round tripping issue (not enough precision)
https://github.com/json-ld/json-ld.org/issues/81
Gregg Kellogg: I think we agreed that when expanding, the value
is kept as-is last week. We don't convert when
expanding/compacting or framing. That moved the issue to RDF
conversion.
Gregg Kellogg: I think Dave Longley said that we should add
options that express how to deal with each of the different
primitive datatypes.
Markus Lanthaler: That was about which datatype is used -
xsd:boolean or xsd:integer - but not about %1.15E.
Gregg Kellogg: There is a normalized form for each of the XSD
types - normalized form is very close to %1.15E - trailing zeroes
in the fractional part are trimmed, extra leading zeros in
mantissa are trimmed as well. %1.15E always uses two characters
and then all 15 digitals.
Markus Lanthaler: Couldn't we just say that we rely on the
underlying toString() function to convert to decimal string?
Gregg Kellogg: if all implementations do the same thing, yes -
if not we can't do that.
Gregg Kellogg: We're going to/from the abstract syntax - the
representation of a decimal is the abstract representation - a
string with a datatype %1.15E
Gregg Kellogg: If I go to/from TURTLE, there may be no
transformation made when we turn it into the expanded form -
Markus' point is that by requiring this format transformation,
we're doing something different from other RDF representation -
why not just use toString().
Gregg Kellogg: Our tests are testing the value-space, but not
the abstract value space.
Discussion on what underlying JSON implementations use to support
doubles - 32-bit, 64-bit, or 128-bit...
Markus Lanthaler: I don't have a strong opinion about 64-bit or
128-bit conversions.
Markus Lanthaler: Why don't we express the output as a 64-bit
floating point representation?
Gregg Kellogg: Any processor should be able to express 1.15E
consistently - if we don't do that and rely upon toString() -
someone might implement tests against values and
twootherwise-conforming implementations might fail.
Gregg Kellogg: from a practicality point of view - we can't just
do JSON value-space conformance tests...
Markus Lanthaler:
https://github.com/json-ld/json-ld.org/issues/81#issuecomment-4686154
PROPOSAL: When converting toRDF(), any value that is a JSON
number that has a fractional value MUST be treated as an
xsd;double using the printf("%1.15E", number) representation.
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +0
David I. Lehn: +0
RESOLUTION: When converting toRDF(), any value that is a JSON
number that has a fractional value MUST be treated as an
xsd:double using the printf("%1.15E", number) representation.
Topic: ISSUE-112: Define mandatory API parameters (options)
https://github.com/json-ld/json-ld.org/issues/112
Gregg Kellogg: I think having mandatory options is a bit odd -
if it's an option, it's not mandatory.
Manu Sporny: We can't necessarily do that for something like
base IRI - well, I guess we could specify that the default for
base IRI is "_:"?
Gregg Kellogg: Or if the base IRI is not set, the processor
should try to use the base IRI of the document if it is known.
Gregg Kellogg: For the fromRDF() case, you may have flags like
"@boolean" - the use of that, results in a native JSON
representation.
Gregg Kellogg: There are options to control this behavior for
each native type.
Markus Lanthaler: This is fine - but we have to specify this
somewhere. The base has to be passed if the document is passed as
an already parsed object and it has IRIs in it.
Gregg Kellogg: So you're saying, if a document is parsed that
does not have a location, then the base IRI must be set to an
absolute IRI.
Markus Lanthaler: We require it all the time, or we throw an
exception when you find a relative IRI.
Gregg Kellogg: In TURTLE, it's common for the output to be
output in relative form. I don't see another RDF processor that
requires that a base IRI be provided.
Manu Sporny: Why don't we just use "_:" as the base IRI.
Markus Lanthaler: That requires us to remap all blank nodes in
expansion?
Gregg Kellogg: yeah.
Gregg Kellogg: We could say that behavior is processor-dependent
- I typically default it to example.com.
Gregg Kellogg: That allows you to take a format that you can see
- allows you to see that it's illegal.
Markus Lanthaler: If we don't expand it to a full IRI or blank
node, it's properties would get dropped.
Manu Sporny: We could set it to 'http://'
Markus Lanthaler: Is it really bad to throw an exception in this
case?
Manu Sporny: Not really, no.
Manu Sporny: I think the playground sets the base IRI
Markus Lanthaler: Why not just set it to the document IRI, and
then "http://example.com/" if that doesn't exist - I don't think
developers would have an issue with that?
Gregg Kellogg: In this case, I treat it as if it is an absolute
IRI w/o validating it as such.
Markus Lanthaler: Can a property ever be a relative IRI?
Gregg Kellogg: In my case, it's not a property - if a property
is a relative IRI, it's dropped. For subjects and objects are
expanded relative to base, but in the absence of base, they're
just used directly.
Markus Lanthaler: If you specify a relative IRI via @id in the
@context, what happens.
Markus Lanthaler: { "@context": { "term": { "@id": "relative" } }
}
Manu Sporny: It's resolved against base.
PROPOSAL: There are no mandatory options in the JSON-LD API.
Defaults must be specified for all options passed to JSON-LD API
methods.
Gregg Kellogg: +1
Markus Lanthaler: +1
Manu Sporny: +1
David I. Lehn: +0
RESOLUTION: There are no mandatory options in the JSON-LD API.
Defaults must be specified for all options passed to JSON-LD API
methods.
Gregg Kellogg: {"@id": "#foo", "@type": "bar"}
Gregg Kellogg: @prefix rdf:
<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
Gregg Kellogg: <#foo> a <bar> .
PROPOSAL: The default for the base IRI for JSON-LD API methods
is the current document IRI if in a browser context, or the empty
string if there is no document context.
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
David I. Lehn: +1
RESOLUTION: The default for the base IRI for JSON-LD API methods
is the current document IRI if in a browser context, or the empty
string if there is no document context.
-- 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, 8 May 2012 20:50:36 UTC