- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 23 Oct 2012 14:33:22 -0400
- To: Linked JSON <public-linked-json@w3.org>
- CC: RDF WG <public-rdf-wg@w3.org>
The minutes from this week's call are now available here:
http://json-ld.org/minutes/2012-10-23/
Full text of the discussion follows including a link to the audio
transcript:
--------------------
JSON-LD Community Group Telecon Minutes for 2012-10-23
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2012Oct/0018.html
Topics:
1. ISSUE-168: JSON-LD Syntax document MUST utilize the RDF
definitions
2. ISSUE-156: Compact API first expands without provided
context
3. ISSUE-162: Base IRI used to expand @type
Resolutions:
1. Move the optional expansion context parameter in the
.expand() call into the last JsonLdOptions parameter.
2. Process the 'expandContext' option when performing
.compact(). When expanding during the .compact() call, the
'expandContext' is applied first, followed with any other
contexts held in the document being processed.
3. When resolving IRIs for @type, first use a term/prefix if
that exists, if not use @vocab, if @vocab does not exist, use the
BASE IRI to resolve @type.
4. Do not define @vocab as base IRI but as prefix.
Chair:
Manu Sporny
Scribe:
Manu Sporny
Present:
Manu Sporny, Richard Cyganiak, François Daoust, Niklas Lindström,
Markus Lanthaler, Dave Longley, David I. Lehn, Lin Clark
Audio:
http://json-ld.org/minutes/2012-10-23/audio.ogg
Manu Sporny is scribing.
Manu Sporny: Anything that should be added to the agenda?
No new additions to the agenda.
Topic: ISSUE-168: JSON-LD Syntax document MUST utilize the RDF definitions
https://github.com/json-ld/json-ld.org/issues/168
Manu Sporny: Michael Hausenblas and Peter Patel-Schneider have
raised concerns that JSON-LD isn't aligned with RDF to a degree
that they're comfortable with. They feel that the JSON-LD data
model overlaps the RDF data model to a large degree and that
keeping that overlap is going to create incompatibilities and
confusion in the future. We have always held the position that
JSON-LD can be used to round-trip to RDF and back, in fact, most
of us use it that way. Several months ago, we had committed to
adding a section, authored by Richard, that will outline exactly
how the JSON-LD data model maps to RDF and back.
Manu Sporny: The issues seem to be more editorial than
technical. The change would limit what JSON-LD could express, and
what would be considered valid, without a compelling technical
reason for doing so. So, we need to figure out what we're going
to propose to the RDF WG tomorrow during the call.
Manu Sporny: Richard, do you have any other insight into this
issue?
Richard Cyganiak: There are two parts to this...
... perception that JSON-LD is re-inventing the wheel -
forking the RDF data model. That might decrease interoperability.
... second part is a marketing issue - JSON-LD wouldn't work
if it mentions RDF too much, people might be turned off. Not
everybody disagrees with that view.
Richard Cyganiak: So, there is the technical side and then there
is a non-technical side.
Manu Sporny: More comments from Peter. I agree they fall in
those two categories. Danger of derailing the entire discussion
in "should we define linked data?". Last time, your advice was to
back up a bit, define linked data roughly in the spec. That's
what we did, and we're relatively happy with that. We also agreed
with you about the addition of an RDF appendix. Do you know what
changes would be required now? [scribe assist by François Daoust]
Richard Cyganiak: There really isn't anything they can look at
right now that I've edited. They're just commenting on the drafts
that don't have any changes. Peter reviewed an earlier draft -
that didn't help as he came away with the wrong impression.
Richard Cyganiak: I'm not entirely sure why this discussion
about Linked Data has flared up. It's beside the point at the end
of the day. Since JSON-LD in it's latest version doesn't contain
a normative statement about Linked Data, we should be fine...
this may be just some of the WG members wrapping their mind
around the concept.
Richard Cyganiak: That part of the discussion can probably be
ignored. There is no normative definition of Linked Data in
JSON-LD anymore.
Richard Cyganiak: I expected a discussion like this to flare up
anyway - if we had the normative Linked Data definition in there
we'd have another problem... so it's good that we don't.
Richard Cyganiak: I've been thinking about what the appendix
should contain. One problem that I have is that it seems that, in
Section 3.1, that definition leaves a number of details open that
might become clear once you read through the rest of the Syntax
spec, or the API docs.
Richard Cyganiak: For example, same ID in a document means the
same node?
Manu Sporny: Yes, it does.
Richard Cyganiak: How do the datatypes and language types on
literals work?
Manu Sporny: Same way as RDF...
Richard Cyganiak: How does ordering work?
Richard Cyganiak: Order doesn't matter, right?
Manu Sporny: Yes, unordered unless it's a @list (via type
coercion or expanded value form).
Richard Cyganiak: there are a couple of these things that might
need to be cleared up. Maybe we need to make those more clear in
the data model definition.
Manu Sporny: The group would have no problem with doing that...
we should be precise in these cases.
Richard Cyganiak: Fully aligning with RDF early in the spec,
from a didactic point of view, wouldn't be so good.
Manu Sporny: Deferring to RDF data model wouldn't solve the
initial concerns, I think. [scribe assist by François Daoust]
Manu Sporny: One question: Has your position on this changed
since last time? Do you feel that we've hit the right balance,
from your standpoint? [scribe assist by François Daoust]
Richard Cyganiak: In my opinion, Section 3.1 still needs some
clarification - that's not necessarily a huge complication -
might be things like having a statement along the lines of "what
is a string?" "String can have a language tag", you can't have
two nodes that are labeled with the same IRI, etc.
Richard Cyganiak: I don't have a strong opinion on how to do
that editorially.
Richard Cyganiak: From my point of view - and an editor of the
RDF Concepts specs, I would be satisfied that the issue of the
relationship of JSON-LD and RDF would be sufficiently addressed
if those clarifications were made and if the RDF Appendix exists
(which I'm planning on writing).
Richard Cyganiak: if others feel that the alignment should be
even closer, Section 3.1 should defer to RDF Concepts directly,
I'd be prepared to argue that JSON-LD defining it's own data
model should be sufficient... we don't need changes that are that
extreme.
François Daoust: When I read the spec, I think 3.1 is pretty
clear about the JSON-LD data model. I'm all in favor for it to be
more precise.
François Daoust: I'm more on the developer side than the RDF
side - I still can't find anywhere, something says the different
between RDF data model and JSON-LD data model... maybe with
properties allowed to be blank nodes and strings? That's all I
can figure out that the differences. Could we add a section in
here about that?
François Daoust: I think that would resolve most of the concerns
on the RDF WG mailing list.
Richard Cyganiak: That's one of the goals of the appendix - how
do the data models map to each other, where are the differences?
Richard Cyganiak: I have an action to do this, have been
traveling - will do it soon.
Markus Lanthaler: Appendix Relationship to RDF:
http://json-ld.org/spec/latest/json-ld-syntax/#relationship-to-rdf
François Daoust: Will we have a bit in there about differences
between RDF data model and JSON-LD data model?
Manu Sporny: Yes, we will have that.
Niklas Lindström: Important to recognize right now that we have
general agreement on the approach. There has never been any
intent to deviate wildly from the abstract RDF data model. Maybe
we should clarify that the JSON data model, given that it's using
the JSON structure, is a concrete data model. It's explicitly
intended to express everything that is defined by the abstract
RDF data model.
Niklas Lindström: The reason we don't want to add this into the
document is that it's geared toward the developers. We want to
define something that is closed in the document, we don't want to
lead people astray... but we also don't want people to deviate
from RDF.
Niklas Lindström: Both Gregg and I use JSON-LD to work with RDF
- we don't want to deviate from that in any way. I'm not really
sure that we can express that in the relationship to RDF
appendix. To explain our intent.
Manu Sporny: This is not the first time this came to the table.
On this call, we always come to the same conclusion, which is
good. Second point, I don't think Peter and Michael picked up the
spec with the history background that we already had discussed
that in the group. The prose may need to be more clear about
that, but we have thought this through quite deeply. [scribe
assist by François Daoust]
Manu Sporny: The third thing that are a bit worrisome to me is
that both of them said that they have no interest or don't
believe that JSON-LD is the right thing to do. [scribe assist by
François Daoust]
Manu Sporny: Fundamentally, people that use the spec in
production environments should have more weight when opinions are
gathered, I feel. Not to say that feedback is not good. But we've
discussed this before, and came to the conclusion that a data
model was needed because we're building on JSON and trying to
bridge to RDF. [scribe assist by François Daoust]
François Daoust: … Let's argue that we throw away the JSON-LD
data model away for a second. If you take a JSON document with
keys that don't have entries in the context, the JSON-LD document
becomes invalid.
François Daoust: … That's something we didn't want. We don't want
JSON developers to apply a context to half of their JSON-LD
document and have an illegal JSON-LD document. Bits that are not
recognized are ignored.
François Daoust: … We're re-discussing the issue but coming to
the same conclusion. No one wants to remove the data model
entirely because it is subtly different than the RDF data model.
Is that a fair outline?
Richard Cyganiak: I disagree slightly, but not suggesting that
JSON-LD data model should be discarded and replaced with the RDF
data model.
Richard Cyganiak: However, if we do that, we'd have to find some
way to deal with keys that are not mapped to URIs - one option is
to pull them away, another is to stick them to the end of a base
URI - we could do that, might be a good idea anyway - non-URI
keys could be retained.
Richard Cyganiak: We'd also have to change quite a bit of
terminology throughout the specification - there aren't
differences that are that large - property vs. predicate is a
small one. Quite a few more occurrences of the letters "RDF" in
the spec.
Richard Cyganiak: I'm not saying it should be done, but that's
mostly for editorial reasons - the spec as it is at the moment is
simpler to digest to the alternative version that would use RDF
Concepts elsewhere. From a technical point of view, it would be
possible to express the spec in terms of RDF Concepts, but we
would lose the ability to do a few things.
Manu Sporny: You said that we could take keys and map them to
some base IRI or ignore them. We're should ignore them instead so
we don't cut ourselves off from a better model than RDF. [scribe
assist by François Daoust]
Manu Sporny: There are things that you can do in JSON-LD today
that you cannot do in RDF concepts, literals as property names,
potentially literals as @ids, etc. [scribe assist by François
Daoust]
Manu Sporny: if a better data model than RDF comes along in the
future (e.g., something like microdata, for instance), then we
don't want to be forced to map literal keys to complicated URIS
[scribe assist by Richard Cyganiak]
Niklas Lindström: From my point of view, my uses of JSON-LD,
often represent information that, from a data perspective, is
noise - either it's reified things or property paths, if you use
pure RDF you'd use OWL or CONSTRUCT - JSON carries noisy
information to provide easier access to data for Web developers.
That's a good thing, and it doesn't always map to RDF.
Niklas Lindström: When I annotate a JSON document with a
context, turning it into JSON-LD - I say that certain keys are
relevant and certain ones are not. It's handy to do that.
Richard Cyganiak: I find that argument *somewhat* compelling.
Manu Sporny: Richard has an action to align JSON-LD data model
and RDF data model. Expected outcome is that you can round-trip
between data models. [scribe assist by François Daoust]
François Daoust: … We'll outline differences between the JSON-LD
data model and RDF data model. There aren't many but we don't
feel comfortable removing the JSON-LD Data model entirely at this
point.
Richard Cyganiak: One more thing that we should state, which
might be helpful to address some of these concerns, have a
paragraph in the introduction that says "by the way, JSON-LD has
a data model that is compatible with RDF, see appendix: RDF"
Richard Cyganiak: That might help address the concern that
JSON-LD is not a serialization of RDF (even though it is)
Topic: ISSUE-156: Compact API first expands without provided context
https://github.com/json-ld/json-ld.org/issues/156
Markus Lanthaler: You can't specify a context to the .compact()
API call.
Markus Lanthaler: Could we combine .expand() and .compact() to
be one method?
Markus Lanthaler: If you pass an empty context to .compact(),
it's basically expansion.
Manu Sporny: We could do that. I'm a bit concerned that it's
going to be difficult to pitch that to developers. [scribe assist
by François Daoust]
François Daoust: … A completely different type of operations
would be happening depending on the arguments
Markus Lanthaler: It's already happening now. Parameters are
enough to change the output completely. [scribe assist by
François Daoust]
Manu Sporny: Kind of. For compact, array removal, for instance.
What you're getting back is still a compacted document even
without context. [scribe assist by François Daoust]
François Daoust: … Two different forms of document. That's why
I'm not in favor of that. That would confuse early adopters.
François Daoust: … They're kind of polar opposite.
Markus Lanthaler: Basically, not an issue as you can already do
that with the current spec. [scribe assist by François Daoust]
Niklas Lindström: I haven't read through all the comments, but
Gregg's suggestion to detect whether there's an incoming context
and skip expansion form seems reasonable. [scribe assist by
François Daoust]
Markus Lanthaler: but you have to loop through all the document
as it could appear at the end of the document. [scribe assist by
François Daoust]
Dave Longley: there is value in explicitly naming functions after
their intended use
Markus Lanthaler: We could move some of this stuff into the
options.
Markus Lanthaler: We could add 'expansionContext' to the
options?
Dave Longley: if you skip expansion just because a context is
missing you won't normalize things like @value
Markus Lanthaler: good point dlongley
Dave Longley: doing expansion before applying our other
algorithms simplifies them
François Daoust: I was reacting to the issue of having to parse
the document twice before deciding what one should do with the
document...
François Daoust: If you start the incoming with an empty
context, that turns the document into expanded form, and the
document can't decide if it has to do the expansion?
François Daoust: { "@context": {}, "hello": "world" }
Dave Longley: the compaction algorithm (and others) assume the
data will have been normalized
Dave Longley: values like "world" -- {"@value": "world"}
Niklas Lindström: If we're going to do anything, we should avoid
expanding twice by having an option.
Dave Longley: i think we may be prematurely optimizing -- we
always do expansion first because it simplifies everything else
... both in the algorithms that must be written and in
understanding how they work
Markus Lanthaler: dlongley, we will still be doing that
Manu Sporny: Dave Longley, concerned that you don't quite
understand the issue? (having to do two
expand-compact-expand-compact calls ... vs just one?)
Markus Lanthaler: we are discussing to add a expandContext option
which would be used as "initial context" for all expansion calls
(also expand() itself)
Niklas Lindström: .. if the context needed for expansion is
provided out-of-band
compact(doc) ?
Dave Longley: that will only do one expansion and compaction
Manu Sporny: not really, no... we're trying to figure out if
it's that difficult.
Markus Lanthaler: void expand (object or object[] or IRI input,
object or IRI? context, JsonLdCallback callback, optional
JsonLdOptions? options);
Markus Lanthaler: What I'm proposing is that expand looks like
this ^^^
Markus Lanthaler: to oid expand (object or object[] or IRI input,
JsonLdCallback callback, optional JsonLdOptions? options);
Manu Sporny: change the signature of expand to this: expand
(object or object[] or IRI input, JsonLdCallback callback,
optional JsonLdOptions? options);
Markus Lanthaler: context is moved into options
Markus Lanthaler: same option available for compact()
Markus Lanthaler: void compact (object or object[] or IRI input,
object or IRI context, JsonLdCallback callback, optional
JsonLdOptions? options);
Dave Longley: it seems to me that this option only saves a single
line? (doc["@context"] = "<result of link header>";) ?
Manu Sporny: not really what we're discussing...
Dave Longley: ok
Manu Sporny: What we're discussing is this - specifying the
context in .expand() is optional...
Manu Sporny: it's not optional in .compact()
Manu Sporny: So, why not move the expansion context to options'
Dave Longley: fine by me
PROPOSAL: Move the optional expansion context parameter in the
.expand() call into the last JsonLdOptions parameter.
Manu Sporny: +1
Markus Lanthaler: +1
François Daoust: +1
Niklas Lindström: +1
RESOLUTION: Move the optional expansion context parameter in the
.expand() call into the last JsonLdOptions parameter.
Markus Lanthaler: So, next question is whether or not we want to
use the 'expansionContext' option, if it is specified, in the
.compact() call (when expanding before compacting)
Markus Lanthaler: If you add an 'expandContext' option, it would
start as if there were a wrapper around the context that has the
context... so the first context processed would be
'expandContext', then the input document contexts would be
applied on top.
Manu Sporny: Dave Longley, any input on this?
Dave Longley: i guess it's fine, i think it's unnecessary
Manu Sporny: So the proposal would be to use 'expandContext' if
it is specified in the options to .compact() as the first context
that is processed.
Dave Longley: we'd have to deal with issues where the input
document has another context
Manu Sporny: ... when the .expand() method is called internally.
Dave Longley: and specify how to handle that kind of behavior,
etc ...
Markus Lanthaler: dlongley, the input document's context is used
nevertheless
Markus Lanthaler: the expandContext is used to initialize the
active context
Markus Lanthaler: just the way the context parameter in expand()
works today
Dave Longley: what if i want to apply the options context last?
Dave Longley: not first?
Markus Lanthaler: doesn't work
Markus Lanthaler: :-)
Manu Sporny: I think the answer is - too bad :)
Dave Longley: :)
François Daoust: +1 to the proposal but make sure the option name
is the same for "compact" and "expand".
Dave Longley: seems like it would be more likely that you'd want
to apply it last than first, but i don't know.
Dave Longley: anyway, i'm not really in favor of that option
because it feels like we're trying to do too much for the
developer without knowing exactly what they want ... and then we
just cover only some portion of the cases with the option,
frustrating others....
Dave Longley: that being said, i don't feel that strongly about
it if people really want the option in there.
Markus Lanthaler: tidoust, the options are the same for all
operations, they are defined in JsonLdOptions
(http://json-ld.org/spec/latest/json-ld-api/#jsonldoptions)
Dave Longley: i think the fact that you acquired the data
externally means you should probably be combining it however you
want to externally before passing it to the API
Manu Sporny: I agree with Dave Longley, probably going to be a
+0 on this.
Dave Longley: i don't mind if we really believe that we're
designing these options to cover the most common use cases though
(i just don't know if that's true)
Manu Sporny: I don't think this is a common use case?
Niklas Lindström: Hard to determine, I've used a bunch of local
data w/ an input context... but that's for testing things out.
I've come across scenarios like this, can't say if it's common or
not. If we have these options, it seems natural to add this to
the API.
Niklas Lindström: feels more uniform.
François Daoust: I agree with Niklas.
François Daoust: It makes the API more consistent.
François Daoust: Also, doesn't seem to add a great deal of
complexity to implementations.
Dave Longley: consistency isn't always better :)
Dave Longley: it probably doesn't make things too much more
complicated, no
PROPOSAL: Process the 'expandContext' option when performing
.compact(). When expanding during the .compact() call, the
'expandContext' is applied first, followed with any other
contexts held in the document being processed.
Dave Longley: anyway, i'm +0 on it.
Markus Lanthaler: it's already implemented, just needs to be
wired together
Manu Sporny: +0
Markus Lanthaler: +1
Niklas Lindström: +1
François Daoust: +1
RESOLUTION: Process the 'expandContext' option when performing
.compact(). When expanding during the .compact() call, the
'expandContext' is applied first, followed with any other
contexts held in the document being processed.
Topic: ISSUE-162: Base IRI used to expand @type
https://github.com/json-ld/json-ld.org/issues/162
Niklas Lindström: To be clear - two sub-issues - is @type
resolved against @vocab? If there is no @vocab, do you resolve
@type against BASE document IRI?
Niklas Lindström: s/niklasl/markus/ ;)
Niklas Lindström: .. answer for above: not resolve, use @type as
string with concatenation
Manu Sporny: Is @type special? Does @vocab apply to it?
Markus Lanthaler: @vocab is special, not @type.
Niklas Lindström: Wouldn't you be able to achieve what you want
via "@vocab": "" ?
Niklas Lindström: If you do that, you use the document base IRI?
I guess you'd need a hash mark if you wanted something safe...
Markus Lanthaler: That would affect all the properties as
well...
Niklas Lindström: If I wanted to use locally defined types, I'd
use type coercion ...
Niklas Lindström: { "foo": {"@id": "http://foo.com/vocab"} }
Niklas Lindström: Then use relative paths?
Markus Lanthaler: I want a fallback to a relative IRI... I want
to test locally and remotely - use relative IRIs everywhere -
dependent on document base IRI... why shouldn't type allow
relative IRIs?
Niklas Lindström: It might confuse people - it's not thought of
that way in most cases - RDF use cases, general practice, is not
to have local types. You probably go out of the way to express
that. Think of TURTLE - you'd use an explicit IRI values.
Markus Lanthaler: I can't pass a relative IRI to type.
Niklas Lindström: There is a difference in syntax there.
Markus Lanthaler: I can pass in an absolute IRI, why can't I
pass in a relative IRI?
Niklas Lindström: Same value space as terms...
Markus Lanthaler: Terms expand in @id...
Niklas Lindström: You could use './' or use a full base IRI
there.
PROPOSAL: When resolving IRIs for @type, first use a term/prefix
if that exists, if not use @vocab, if @vocab does not exist, use
the BASE IRI to resolve @type.
Markus Lanthaler: +1
Niklas Lindström: +0
David I. Lehn: +0
Manu Sporny: +1
François Daoust: +1 for consistency
RESOLUTION: When resolving IRIs for @type, first use a
term/prefix if that exists, if not use @vocab, if @vocab does not
exist, use the BASE IRI to resolve @type.
Markus Lanthaler:
https://github.com/json-ld/json-ld.org/issues/173
François Daoust: Just wanted to raise ISSUE-166 - provide
feedback in written form.
PROPOSAL: Do not define @vocab as base IRI but as prefix.
Niklas Lindström: +1
Markus Lanthaler: +1
Manu Sporny: If you want to provide spec text for a conformance
section, that would be great.
Manu Sporny: +1
Niklas Lindström: .. to join @vocab with the suffix using textual
concatenation..
Markus Lanthaler: @vocab: http://example.org/vocab#
François Daoust: +1
Markus Lanthaler: the term 'test' would resolve to
http://example.org/test if we treat @vocab as an IRI instead of a
prefix, which is not what we want.
RESOLUTION: Do not define @vocab as base IRI but as prefix.
Niklas Lindström: note for the minutes: mlnt's last example was
what we don't want :)
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: HTML5 and RDFa 1.1
http://manu.sporny.org/2012/html5-and-rdfa/
Received on Tuesday, 23 October 2012 18:33:56 UTC