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

JSON-LD Telecon Minutes for 2012-10-23

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 23 Oct 2012 14:33:22 -0400
Message-ID: <5086E2F2.6010808@digitalbazaar.com>
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:


Full text of the discussion follows including a link to the audio

JSON-LD Community Group Telecon Minutes for 2012-10-23

   1. ISSUE-168: JSON-LD Syntax document MUST utilize the RDF
   2. ISSUE-156: Compact API first expands without provided
   3. ISSUE-162: Base IRI used to expand @type
   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.
   Manu Sporny
   Manu Sporny
   Manu Sporny, Richard Cyganiak, François Daoust, Niklas Lindström,
   Markus Lanthaler, Dave Longley, David I. Lehn, Lin Clark

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

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
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
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:
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
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
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

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
Markus Lanthaler:  We could add 'expansionContext' to the
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
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
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
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

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
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

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:
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
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
Received on Tuesday, 23 October 2012 18:33:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:35 UTC