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

JSON-LD Telecon Minutes for 2013-05-21

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 21 May 2013 12:41:50 -0400
Message-ID: <519BA3CE.7080201@digitalbazaar.com>
To: Linked JSON <public-linked-json@w3.org>
CC: RDF WG <public-rdf-wg@w3.org>
The minutes from this week's telecon are now available.


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

JSON-LD Community Group Telecon Minutes for 2013-05-21

   1. RDF-ISSUE-132: JSON-LD/RDF Alignment
   2. RDF-ISSUE-128: Mandatory profiles
   3. Gmail JSON-LD Implementation Concerns
   4. RDF WG resolutions
   1. Adopt the language for content negotiation above where the
      server should try to comply with the request MIME type and
      profile from the client.
Action Items:
   1. Manu to officially respond to David Booth.
   2. Gregg to convert all issue markers in the JSON-LD specs
      into RDF WG issues and request that the RDF WG resolves the
      issues so that we can go to CR/PR/REC.
   Manu Sporny
   Manu Sporny
   Manu Sporny, Gregg Kellogg, Dave Longley, Luca Matteis,
   Clay Wells, Stian Soiland-Reyes, Paul Kuykendall

Manu Sporny is scribing.
Manu Sporny:  any changes to the agenda?
Gregg Kellogg:  We should talk about David Booth's issue:
   JSON-LD/RDF Alignment

Topic: RDF-ISSUE-132: JSON-LD/RDF Alignment

Gregg Kellogg: Conversation here:
Gregg Kellogg:  I think he's not entirely satisfied to define
   JSON-LD as an RDF syntax. In particular, we were going to
   normatively reference RDF Concepts.
Gregg Kellogg:  I think he was looking for something like that,
   and a series of other suggestions, including referencing RDF when
   we're describing Linked Data.
Manu Sporny:  It's been difficult for me to understand what he
   wants, exactly. Many of his points are philosophical vs.
   technical. In general, I don't see what technical problems we
   address by making the changes he is requesting.
Gregg Kellogg:  He's got some very specific changes in the
   e-mail. Some of his concerns I don't quite understand.
Dave Longley:  yeah, let's go down the list he has, maybe that
   will help.
1. Insert "based on RDF" to the definition of Linked Data, as
   explained above.
Dave Longley:  This is at odds with all of the other discussions
   we've had. Maybe there is another way to satisfy #1 w/o deviating
   with all of the other fixes we've had to do w/ that definition.
Manu Sporny:  Yeah, we have a problem with #1 - we've worked on
   that definition a lot. We have considered the text he wants
   before. If we add it, they'll be backlash from the folks that
   didn't want to conflate Linked Data with RDF.
Manu Sporny:  Making a normative reference to RDF Concepts would
   be problematic - going to REC at a different time than JSON-LD.
Gregg Kellogg:  I thought we had agreed to do that?
Manu Sporny:  I don't think we agreed to do that - we don't want
   to be blocked by RDF Concepts.
Manu Sporny:  My general concern with david booth's comments are
   that he's taking a hard line stance with JSON-LD having to fall
   in line with RDF ... in that his arguments seem to be
   philosophical arguments, not technical, it's more about
   messaging. I don't want to get this group stuck in the mud when
   the changes to the spec that are mostly philosophical, not
   technical, in nature. [scribe assist by Dave Longley]
Gregg Kellogg:  What about the skolemization concerns? Those are
   technical, right?
Gregg Kellogg:  The other place would be bnodes as properties.
Manu Sporny:  I thought those issues were things that processors
   need to deal with those sorts of things when translating to RDF.
Gregg Kellogg:  I think David Wood wants this to be a WG
Manu Sporny:  So, JSON-LD CG has made these resolutions, we need
   RDF WG to do the same.
Manu Sporny:  I'm concerned that we are going to work on these
   secondary issues, thinking that it's what David Booth wants, and
   they're not going to resolve David Booth's concerns.
Gregg Kellogg:  Then we should point to the decision on the
   Linked Data definition. If he still doesn't agree, we need a
   papertrail to validate the decision that we've made in the event
   that there is a Formal Objection to the definition of Linked
Manu Sporny:  Does anybody want to include RDF language in the
Luca Matteis: Why not have intro on RDF? Seem the lingua franca
   of Linked Data. Yes, I think there should.
Dave Longley:  We already had this discussion - let's point to
Dave Longley: Luca, we already had a long discussion about this a
   while back... we're going to link to that discussion
Gregg Kellogg:  The issue of whether RDF Concepts is
   normative/informative was something that I thought we had
   resolved to do that.
Luca Matteis: ok but what's the outcome of that discussion?
Dave Longley: Luca, the outcome of that discussion was to mention
   RDF a little as possible to avoid bringing in baggage/false
   equivalency/conflation of RDF w/Linked Data
Luca Matteis: If you're calling it Linked Data, seems weird not
   to have RDF - since LD is strictly about RDF
Gregg Kellogg:  Regarding our use of bnodes - which could have
   been resolved w/ the RDF WG to have bnodes in graphs, we need a
   resolution on this as well from the RDF WG.
Dave Longley: Luca, that's just it, it's not strictly about RDF,
   we'll link to the discussion.
Gregg Kellogg:

Luca Matteis: Dave, it isn't strictly RDF?
Dave Longley: Luca, no, but we do think it's important to mention
   JSON-LD is a syntax for RDF
2. Define a *normative* bi-directional mapping of a JSON profile
   to and from the RDF abstract syntax, so that the JSON profile
   *is* a serialization of RDF, and is fully grounded in the RDF
   data model and semantics.
Dave Longley: Luca, Linked Data is just URI/URLs for identifiers
   that can be dereferenced to get more data, etc.
Gregg Kellogg:  The only issue there is the ability to create
   things that are not RDF, for which these are at-risk issues.
Luca Matteis: Yikes. Dave, that's just the Web.
Dave Longley: Luca, it's a bit "higher level" than RDF
Manu Sporny:  We have a normative mapping, does he want something
Gregg Kellogg:  We do have a mapping, but it allows graphs that
   are not RDF to be created. These features are at-risk that
   relates to that, and the RDF WG needs to resolve those at-risk
Gregg Kellogg:  It leaves open the resolution of those at risk
Dave Longley:  i doubt that it's "high level". the Linked Data
   Platform strictly mentions RDF. [scribe assist by Luca Matteis]
3. Use skolemized URIs in the normative mapping to prevent
   mapping JSON syntax to illegal RDF.
Luca Matteis: alright well i don't wanna jump into the argument
Luca Matteis: but it seems like a rash decision to not mention
   RDF - the foundation of LD
Gregg Kellogg:  My concern with this is that skolemized URIs are
   for a server to do - it's not meant for encoding/transport bnodes
   between two different systems. I don't see skolemn IDs as being
   appropriate for doing that.
Manu Sporny:  I agree.
4. Make editorial changes to avoid implying that JSON-LD is not
   RDF. For example, change "Convert to RDF" to "Convert to Turtle"
   or perhaps "Convert to RDF Abstract Syntax".
Dave Longley: Luca, we had a very detailed debate about this a
   while back... we'll have to link to it, there were objections
   over what "LD" means/should mean/how it shouldn't be conflated
   with RDF itself but how RDF relates to it, etc.
Dave Longley: Luca, can't rehash right now.
Luca Matteis: hrm ok
Gregg Kellogg:  I think this is reasonable since it implies it's
   not already RDF, that's not intended to be the case.
Luca Matteis: would be nice to share the outcomes with a larger
   audience though before making a decision that could impact this
   formats future, such as public-lod@w3.org
Manu Sporny:  yeah, change to "Convert to RDF Abstract Syntax"?
Dave Longley:  Yeah, let's do that.
Dave Longley: Luca, it shouldn't technically have any impact.
Gregg Kellogg: Luca, typically, rdf-concepts is used for
   communicating discussions within the RDF WG to the outside
5. Define normative names for, and clearly differentiate between,
   the JSON serialization of RDF and JSON-LD, such that JSON-LD *is*
   a JSON serialization of RDF, with additional constraints for
   Linked Data (such as URIs use "http:" prefix, etc.). They do not
   necessarily have to be defined in two separate documents. They
   could be defined in a single document called "JSON-RDF and
   JSON-LD", for example. People that use the JSON RDF serialization
   for purposes other than Linked Data need to be able to easily and
   clearly talk about that serialization *without* wrongly implying
   adherence to the additional Linked Data requirements imposed by
   JSON-LD, and *without* having to explain that those requirements
   can be ignored in this case.
Dave Longley: Luca, it's all about messaging/philosophy/etc. (or
   rather, the actual technical impact is meant to be minimal)
Luca Matteis: the initial question was whether to have intro text
   about RDF.
Luca Matteis: it's not technical i know
Luca Matteis: but why not?
Luca Matteis: why not have intro about RDF?
Luca Matteis: or just mention RDF
Luca Matteis: it's RDF compatible... it's only positive!
Manu Sporny:  Luca, You are distracting the group from talking
   about the things on the Agenda. We have already talked this issue
   to death. Telecon time is precious, please take this up after the
   telecon, and after reading about the previous discussions we've
   had on the topic.
Luca Matteis: I can't join the conversation anymore. guess I was
   banened? ;)
Manu Sporny:  Luca, no, you're not banned. You're free to
   participate at any time, you just have to be respectful to the
   time of the group and not re-raise issues that have been resolved
   without providing new arguments that we had not previously
Dave Longley:  I think he's taking issue w/ the SHOULDs
Dave Longley:  I don't see why this doesn't cover his issue...
Clay Wells: yes, what you just said
Dave Longley:  I think he means that there should be some basic
   serialization of RDF in JSON - pure RDF in JSON.
Clay Wells: makes sense from my perspective
Gregg Kellogg:  This doesn't accomplish anything, it's busy work.
Dave Longley:  We don't prohibit people from using the subset, we
   don't do that anywhere in the spec, so it already exists. It's
   easier for people to consume/understand than if there are two
   different formats. Which format are you supposed to use as a
Dave Longley:  Is the JSON-LD format always JSON-RDF, what's the
   subset? It would be more confusing to publish two different
Manu Sporny:  Agreed.
Dave Longley:  Someone was worried about having to ask for a
   specific kind of data that is serialized. So the client would
   have to say "I want JSON-LD, but with particular restraints."
Dave Longley:  I don't even know if this would solve this problem
   if JSON-RDF is a subset of JSON-LD.
Dave Longley:  I don't understand how David Booth's #5 proposal
   solves any technical issue.
Gregg Kellogg:  There is a big problem with bifurcation of the
   spec as well. Some processors may decide to do one and not the
Gregg Kellogg:  If we did that for RDFa 1.1 Lite, it would've
   been a big problem.
Dave Longley:  Do we want to create another mimetype? I don't see
   how what David Booth's proposing is a better solution.
Manu Sporny:  What about his editorial changes?
Dave Longley:  We want to get the concept across that any JSON
   document can be Linked Data via JSON-LD... but you don't need to
   move all your data over all at once.
Dave Longley:  maybe we need to change that entire sentence...
   something like "JSON-LD allows you to mark parts of your JSON as
   Linked Data"... or something like that.

ACTION: Manu to officially respond to David Booth.

Topic: RDF-ISSUE-128: Mandatory profiles

Manu Sporny:  Peter and Markus seem to agree on the change:
Manu Sporny:  We need to do some reading on it.
Gregg Kellogg:  Markus' response was that we were using SHOULD
   language, requests are advisory to the server. If the server
   doesn't have it, it could return a "similar" format.
HTTP/1.1 includes the following request-header fields for
   enabling server-driven negotiation through description of user
   agent capabilities and user preferences: Accept (section 14.1),
   Accept- Charset (section 14.2), Accept-Encoding (section 14.3),
   Accept- Language (section 14.4), and User-Agent (section 14.43).
   However, an origin server is not limited to these dimensions and
   MAY vary the response based on any aspect of the request,
   including ...
Stian Soiland-Reyes: ... information outside the request-header
   fields or within extension header fields not defined by this
Group discusses modifying the text in the JSON-LD spec to: "The
   profile parameter MAY be used by clients to express their
   preferences in the content negotiation process. If the profile
   parameter is given a server SHOULD return a document that is
   structured based on the profiles in the list which are recognized
   by the server."
Dave Longley: "If the profile parameter is given, " <-- insert

PROPOSAL: Adopt the language for content negotiation above where
   the server should try to comply with the request MIME type and
   profile from the client.

Manu Sporny: +1
Dave Longley: +1
Paul Kuykendall: +1
Gregg Kellogg: +1
Stian Soiland-Reyes: +1

RESOLUTION: Adopt the language for content negotiation above
   where the server should try to comply with the request MIME type
   and profile from the client.

Topic: Gmail JSON-LD Implementation Concerns

Manu Sporny:  Google has added JSON-LD support to Gmail, Search,
   and Google Now. I blogged about it here:
Gregg Kellogg:  The main issue is that that they've used
   'schema.org' instead of a valid @context. We could support it,
   but it's not clear why they chose to do that as adding http:// to
   the front of schema.org seems like a fairly easy thing to do.
Stian Soiland-Reyes: they manage http:// in the microdata-version
Gregg Kellogg:  It's often difficult for them to be consistent
   with marking things up - they're used to using heuristics for
   data that's provided for them. Maybe that's why they did this?
Gregg Kellogg:  We could hack in the same sort of heuristics to
   the spec... if you type see "schema.org" - the developer probably
   meant http://schema.org/
Gregg Kellogg:  Then there is this relative URI concern, how do
   we support this?
Manu Sporny:  We could do something like the RDFa initial context
   for the @context keyword, but again, it's a big hack. This is
   pretty typical of Google - launch first, ask questions later. It
   would have been nice if they had run this by us before releasing
   this sort of thing on developers. It's going to be a decent bit
   of work for us to clean this up.
Dave Longley:  What about the actual JSON-LD context? Do they
   serve one?
Manu Sporny:  Nope. There are plans to do it, but they don't have
   a timeframe... which is bad, because that means that developers
   are going to do their own thing in the meantime, leading to
Dave Longley:  The fear is that some people are going to create
   their own context... we need to talk them and make sure they
   realize the downsides to what they're doing.
Gregg Kellogg:  The fact that Google is adopting this so broadly,
   alleviates some of the concerns we had about turning developers
   off from JSON-LD being too much like RDF. Developers will be
   interested in it because Google is using it.
Manu Sporny:  We hope to have someone from Google on the call
   next week to discuss these issues.

Topic: RDF WG resolutions

Gregg Kellogg:  What do we want to accomplish there?
Manu Sporny:  Anything that has an issue marker in the JSON-LD
   specs needs to have a final resolution in the RDF WG. Do you mind
   taking that work on, Gregg?
Gregg Kellogg:  Sure.

ACTION: Gregg to convert all issue markers in the JSON-LD specs into RDF
WG issues and request that the RDF WG resolves the issues so that we can
go to CR/PR/REC.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
Received on Tuesday, 21 May 2013 16:42:19 UTC

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