Re: Linked Data in JSON Telecon 2011-07-26

I'll update the Requirements doc based on this.

Gregg

On Jul 26, 2011, at 2:05 PM, Manu Sporny wrote:

> TLinked Data in JSON Telecon
> Minutes for 2011-7-26
>
> Agenda:
> http://lists.w3.org/Archives/Public/public-linked-json/2011Jul/0114.html
> Chair: Manu Sporny
> Scribe: Manu Sporny
> Present: Alfonso Martin, Dave Lehn, Manu Sporny, Danny Ayers,
>          Gregg Kellogg, Nathan Rixham, Ted Thibodeau Jr.
> Audio: http://json-ld.org/minutes/2011-07-26/audio.ogg
>
> ---------------------------------------------------------------------
>
> Note: Manu Sporny is scribing.
> Alfonso Martin: Going to lurk for the call today, looking at JSON-LD for
> dbpedia project I'm working on.
>
> Topic: JSON-LD Playground
> ---------------------------------------------------------------------
>
> Dave Lehn: Here is a link to the playground - http://json-ld.org/playground/
>
> Manu Sporny: Something that we put together after the last telco. It's
> an implementation of a JSON-LD/JSON-SD processor in JavaScript.
> Playground allows you to type in any JSON-SD compatible markup -
> examples at top for Person, Place, Event, Library, Recipe, etc. You can
> click tabs for viewing different forms at bottom of the page.
>
> Danny Ayers: ooh, pretty syntax highlighting
>
> Manu Sporny: You can view compacted form, which is what most webdevs are
> going to use, expanded form, which lets you see how the JSON expands to
> IRIs, normalized form for viewing the canonical form of the data. We
> believe that the normalization algorithm works for all degenerate cases,
> as far as we can tell. Framed form tab - pick the library example -
> framed form allows you to take an arbitrary graph and force it into a
> certain JSON structure. Working with graphs is hard - framed form allows
> you to query by example. When clicking on "Library" example and "Framed"
> tab, graph is on left, frame is on right - output is below. Allows
> webdevs to just use graphs like they do any other JSON data. Last tab is
> TURTLE tab - view the data as RDF/TURTLE.
>
> Danny Ayers: manu, typical uses for Normalized?
>
> Dave Lehn: digital signatures is one use
>
> Manu Sporny: Several use cases - graph equality comparison, graph
> diffing and generate hashes for graphs and generate a digital signature
> for the graphs.
>
> Danny Ayers: oh yeah, of course - thanks manu
>
> Manu Sporny: All source for website and JSON-LD playground is available here
>
> Topic: Finalizing definition of Linked Data
> ---------------------------------------------------------------------
>
> Dave Lehn: Here is a link to the latest requirements -
> http://json-ld.org/requirements/latest/
>
> Gregg Kellogg: We pretty much have agreement on section 3.1 - item #4
>
> Gregg Kellogg: I think we could have agreement on the ISSUE between MAY
> vs. SHOULD - it should be SHOULD.
>
> Manu Sporny: Let's go through each item to see what folks think about
> it. This decision may be made easier based on the discussion we've had
> on the mailing list.
> Nathan Rixham: what is the difference between Structured and Linked Data?
>
> Manu Sporny: I think for item 4, SHOULD for LD MAY for SD
>
> Manu Sporny: Basically, there was a disagreement on mailing list on what
> Linked Data was. Kingsley and Glenn had concerns that we were calling
> things "Linked Data" when they were not Linked Data. For example, if a
> graph has a blank node in it, it shouldn't be called Linked Data.
> However, what some need are Structured Data - folks need blank nodes at
> times. Linked Data SHOULD use IRIs, and SHOULD NOT use blank nodes.
> Structured Data MAY use blank nodes. We're trying to come up with a good
> definition for Linked Data. JSON-SD /can/ do Linked Data - but it can
> also do Structured Data - which is what most people seem to want.
>
> Nathan Rixham: I find it debatable that Linked Data and Structured Data
> are different. Structured Data is just data with structure - most types
> of data. Not going to split hairs over a name I suppose.
>
> Manu Sporny: We've been splitting hairs for the last 3 weeks. Kingsley
> and Glenn feel that there has been this big mis-use of Linked Data - it
> was mistakenly tied to a technology (RDF and SPARQL) when it should not
> have been, Linked Data also should not contain blank nodes. I believe
> that is Kingsley and Glenn's position.
>
> Ted Thibodeau Jr.: I think that JSON-SD is just JSON. Because of that, I
> don't really want to go into JSON-SD vs JSON vs. JSON-LD... the
> distinction is between JSON and JSON-LD.
>
> Manu Sporny: I don't follow.
>
> Ted Thibodeau Jr.: JSON is, by its nature, structured data. Saying
> JSON-SD is different from JSON will confuse people.
>
> Manu Sporny: Maybe we need another term?
>
> Ted Thibodeau Jr.: No, we don't. JSON that is not JSON-LD is just JSON.
>
> Danny Ayers: I'm inclined to agree that JSON-SD = JSON
>
> Nathan Rixham: I agree with the basic principle of Kinglsey, that Linked
> Data is data that is linked, and shouldn't be tied to RDF/SPARLQ meme -
> but "structured data" seems like a misuse and a waste
>
> Gregg Kellogg: Personally, I'd rather stick with the JSON-LD name. Can't
> please everyone all the time.
>
> Nathan Rixham: JSON-LD is fine
>
> Nathan Rixham: even RDF doesn't have to have links in it.. Linked is th
> point of why you're using JSON-LD, doesn't mean to say all JSON-LD must
> be linked - I suggest call it JSON-LD and stick to it
>
> Ted Thibodeau Jr.: JSON is by it's nature, structured data - JSON-SD is
> redundant
>
> Manu Sporny: Right... but we have all of these processing rules that sit
> between JSON and JSON-LD. What are we calling this thing, then? We can't
> call it JSON-LD, and it's more narrow than just JSON. That was the issue
> we started off with - Kingsley and Glenn insist that we can't call
> something that contains blank nodes - Linked Data.
> Ted Thibodeau Jr.: What is the distinction between traditional JSON and
> JSON-SD in your coining?
>
> Manu Sporny: JSON-SD is JSON plus a context. JSON-SD has processing
> rules to turn it into Linked Data and/or RDF, regular JSON doesn't.
>
> Danny Ayers: manu' suggests JSON-SD = JSON + context + processing rules
>
> Danny Ayers: how does a processor know some JSON is JSON-LD? (something
> like mime type?)
>
> Manu Sporny: A processor will know that something is JSON-SD/JSON-LD
> because there will be a @context declared.
>
> Danny Ayers: aha
>
> Ted Thibodeau Jr.: Yes, but what is the difference between JSON and JSON-SD.
>
> Manu Sporny: JSON-SD has a @context. JSON does not. JSON, in and of
> itself, cannot be transformed to Linked Data.
>
> Ted Thibodeau Jr.: The @context is external?
>
> Manu Sporny: The @context can be external, or it may be declared
> in-line. Any time that you see @context as a key - it's no longer plain
> JSON - it's JSON-SD - there is extra meaning you can extract from that JSON.
>
> Ted Thibodeau Jr.: Is @context new? Has it always been used with JSON?
>
> Manu Sporny: @context has nothing to do with JSON. It's just another key
> - it's never existed in JSON.
>
> Ted Thibodeau Jr.: In this structuring, there is JSON w/o @context,
> there is JSON-SD, which adds @context and then there is JSON-LD, which
> only uses IRIs.
>
> Manu Sporny: Yes. Unfortunately, the nuance is so small that people are
> wondering why we are making the distinction. Kingsley and Glenn feel
> strongly about this.
>
> Ted Thibodeau Jr.: I feel strongly about it as well. We should not say
> blank nodes are OK in "Linked Data".
>
> Gregg Kellogg: JSON-SD is JSON-LD + BNodes. Having to call it JSON-LD,
> because it's not fully linked is like saying you can't have a
> "functional" language with any non-functional features.
>
> Nathan Rixham: there is no reason to artifically limit JSON-LD such that
> people can't mix in basic unlinked-JSON.; if I want only half of my data
> to be exposed as linked data, and the rest as boring old unlinked data
> (say debugging info), then that should be fine, surely? - all of this
> JSON/JSON-SD/JSON-LD is too complicated, JSON-LD should be a layer above
> JSON to allow Linked Data
>
> Nathan Rixham: I don't see a reason to limit JSON-LD. This is getting
> complicated - JSON, JSON-SD and JSON-LD. This just adds a layer on top
> of JSON - we don't need three levels.
>
> Ted Thibodeau Jr.: (JSON)+(JSON-LD) is not the same as (JSON-LD)
>
> Manu Sporny: We're not limiting JSON-LD, we're just talking about
> definitions - what is Linked Data (JSON-LD)... what is JSON-SD? We're
> not talking about limiting the spec - it's going to support all of the
> variations that we're talking about. Kingsley, Ted and Glenn's issue is
> that we need to be very clear about the definitions before writing the spec.
>
> Ted Thibodeau Jr.: The big difference between JSON and JSON-LD are
> IRIs... it is a limit, it is a subset with a lot more application, a lot
> easier working environment, if you know that everything that matters to
> you have a IRI - then you don't have to do a great deal of work. JSON-LD
> docs are going to use IRIs in particular places - that's a win. Regular
> JSON may use this stuff, but fewer are going to be able to work with it
> as easily as JSON-LD. Making a subset of JSON, which is what JSON-LD is,
> makes working with this data easier.
>
> Ted Thibodeau Jr.: The big difference between JSON and JSON-LD are
> IRIs... it is a limit, it is a subset with a lot more application, a lot
> easier working environment, if you know that everything that matters to
> you have a IRI - then you don't have to do a great deal of work. JSON-LD
> docs are going to use IRIs in particular places - that's a win. Regular
> JSON may use this stuff, but fewer are going to be able to work with it
> as easily as JSON-LD. Making a subset of JSON, which is what JSON-LD is,
> makes working with this data easier. You can still use JSON inside
> JSON-LD, but don't call that document JSON-LD.
>
> Gregg Kellogg: Except we need processing rules for intersection of JSON
> and JSON-LD
>
> Manu Sporny: The technical concern is that we need to be able to specify
> how you handle JSON-LD mixed in with a regular JSON document.
>
> Ted Thibodeau Jr.: The issue is with blended documents - that's hard to do.
>
> Manu Sporny: I don't think we're trying to take it that far. I'm
> certainly not interested in mixing arbitrary JSON w/ JSON-LD. We just
> want to make sure that unlabeled nodes are supported.
>
> Nathan Rixham: JSON-LD looks like a SUPERset not a subset to me; also,
> if it's a specific subset that's only "linked data" then why not just
> RDF/JSON and forget this all together?
>
> Nathan Rixham: I thought the idea was to augment JSON such that people
> can expose some bits as linked data.
>
> Danny Ayers: hmm, JSON-LD is JSON from which at least one IRI-based
> triple can be extracted from, so the rest of the JSON is MUST IGNORE or
> ERROR?
>
> Nathan Rixham: danja, I'd thought of it slightly differently, take a
> chunk of JSON, throw it through a JSON-LD parser, and see what triples
> come out
>
> Ted Thibodeau Jr.: It's when you try to step outside of the bounds of
> Linked Data that this becomes an issue.
>
> Manu Sporny: I'm trying to understand your point. We want Linked Data -
> but there are cases where it's not a good thing to require an IRI for
> everything. There are demonstrated use cases where we want Linked Data
> used for everything.
>
> Ted Thibodeau Jr.: Like what?
>
> Manu Sporny: Digital signatures... the list of payees in a financial
> contract... the name of a person that made something coupled with their
> home page... We don't want to give an IRI for everything under the sun.
>
> Ted Thibodeau Jr.: Why not?
>
> Gregg Kellogg: LD is not just IRI, but _dereferencable_ IRI. What do you
> get when you dereference the signature of a document?
>
> Nathan Rixham: define: "unlabeled node"
>
> Manu Sporny: Nathan effectively - unlabeled node == blank node. We were
> using unlabeled node to not use RDF terminology (and all of the baggage
> that brings into the discussion)
>
> Nathan Rixham: they're JSON-LD use cases, not linked data use cases,
> just as you get blank nodes in RDF, or anonymous objects pretty much
> everywhere
>
> Ted Thibodeau Jr.: A financial system like that should be vetted for
> proper operation.
>
> Ted Thibodeau Jr.: I don't think those are Linked Data use cases. If you
> want to use blank nodes, great. If you use blank nodes, you are not
> using Linked Data. It's a mixed use case - it's not a Linked Data use
> case. Since it's a mixed use case, it should be treated as such. You
> can't do everything with everything.
>
> Manu Sporny: I don't understand where you're going with this. I don't
> understand what changes are going to be made to the spec based on your
> line of argumentation. I don't know what you're proposing.
>
> Ted Thibodeau Jr.: I'm proposing that we start with clear-er diagrams of
> what these things are. This discussion is going in circles, both here
> and on the mailing list.
>
> Manu Sporny: Wait, no. JSON-LD is a subset of JSON-SD which is a subset
> of JSON. How does this impact the spec? That's what I'm concerned about.
> Ted Thibodeau Jr.: I don't know. What I see is ongoing confusion about
> the same issues.
>
> Manu Sporny: I thought we had those resolved on the mailing list. What
> you're saying is different from my read on the mailing list. I thought
> the group was in agreement on how we should define this and how we
> should go forward? Your statements are unique and new to me.
>
> Ted Thibodeau Jr.: Your statements at the beginning were confusing.
>
> Manu Sporny: Have you looked at the requirements document to see if you
> agree with the Linked Data definition?
>
> Danny Ayers: extreme case, can JSON-LD contain parser-ignored comments?
>
> Dave Lehn: Here's the URL we're looking at -
> http://json-ld.org/requirements/latest/
> Ted Thibodeau Jr.: The "according to Wikipedia" bit - wikipedia isn't a
> standards thing.
>
> Manu Sporny: I'm talking about section 3.1
>
> Manu Sporny: We agreed to the change to #4
>
> Ted Thibodeau Jr.: The definition of Linked Data in section 3.1 looks good.
>
> Manu Sporny: That's good - that means we have a definition of Linked
> Data that works for everybody. So, what is the addition item that we
> want to add to that section to make unlabeled nodes work? That's the
> only item that we need to discuss. What we did on the mailing list is
> that we called that "Structured Data" and said that the one difference
> is that Structured Data can specify unlabeled node identifiers.
>
> Danny Ayers: SHOULD in the Linked Data definition still allows for
> "Structured Data", that may be good enough. It's not it MUST be an IRI,
> so there is wiggle room.
>
> Manu Sporny: Yes, but we wanted language that was stronger. To tell
> people that it is okay to have unlabeled nodes.
>
> Danny Ayers: It's not really a big issue, but it would be nice to say
> something in the spec.
>
> Manu Sporny: Does the use case that we would like to support an
> acceptable thing to you? We need to be able to express unlabeled nodes.
> If we make people create IRIs for everything, we're going to end up with
> some nasty data out there.
>
> Ted Thibodeau Jr.: Do we have use cases any place?
>
> Manu Sporny: No, not for JSON-LD. We have the PaySwarm use cases, but
> not JSON-LD use cases.
>
> Ted Thibodeau Jr.: We should have the use cases justifying the
> Torequirements and features in the spec written down somewhere.
>
> Manu Sporny: Right.
>
> Ted Thibodeau Jr.: I personally hate blank nodes.
>
> Manu Sporny: Have you ever needed blank nodes?
>
> Ted Thibodeau Jr.: I have never find a use case where blank nodes were
> required.
>
> Manu Sporny: We're not saying they're required - we're saying that
> they'll make implementers' lives easier.
>
> Danny Ayers: would personally just ditch the SD notion, it doesn't
> really seem necessary, but not a big deal either way
>
> Gregg Kellogg: part of the problem is the _dereferancable_ nature of
> URIs in LD. BNode use-cases that could be URIs shouldn't be derferencable.
>
> Manu Sporny: Maybe we should talk about the requirements.
>
> Topic: Discuss JSON-SD Requirements
> ---------------------------------------------------------------------
>
> Dave Lehn: The URL for the requirements - section 3.2 - JSON-LD -
> http://json-ld.org/requirements/latest/
>
> Danny Ayers: I bet there are still a lot of FOAF people out there that
> are still bnodes - and I'd prefer not to mint URIs for them
> A JSON-LD document must be able to express a linked data graph.
>
> Manu Sporny: Any objections to that statement?
>
> Nathan Rixham: does that quantify to every linked data graph? some of
> them or?
>
> Danny Ayers: That is confusing
>
> Gregg Kellogg: _must_ in 3.2.1 means that 3.1.4 is MUST, not SHOULD
>
> Manu Sporny: Then how about "A JSON-SD document MUST be able to express
> a linked data graph." ? JSON-SD can also express a mixture of Linked
> Data and Non-Linked Data (aka. Structured Data). Specifically, the
> ability to express unlabeled nodes (aka. blank nodes). Any disagreement
> with that statement?
>
> Gregg Kellogg: 3.1.4 A subject MUST be labeled with an IRI.
>
> Nathan Rixham: manu, so everything that is a valid linked data graph,
> must be expressible in JSON-*D? "Linked Data" is defined as "should,
> should, may" - so then "1 1 1" would be valid.
>
> Gregg Kellogg: 3.1.4 is SHOULD, as it may be a literal.
>
> Ted Thibodeau Jr.: Still digesting the IRI comment from Gregg.
>
> Nathan Rixham: and must be able to be expressed in JSON-*D
>
> Gregg Kellogg: No, no subject literals.
> 3.1.4 A subject SHOULD be labeled with an IRI?
>
> Manu Sporny: Are we good with SHOULD?
>
> Danny Ayers: could live with MUST for 3.1.4 as long as there was an
> informative note to say that any bnodes are not considered part of the
> linked data graph (i.e. they're ok)
>
> Manu Sporny: Yes, that's interesting. So, would that means that a graph
> that has references to blank nodes is to remove any reference to a blank
> node, and what's left behind is a Linked Data graph?
> Danny Ayers: ok but not in the LD graph
>
> Nathan Rixham: or skolemize it *lol*
>
> Danny Ayers: right :)
>
> Manu Sporny: I'm fine w/ that.
>
> Ted Thibodeau Jr.: Subjects and properties are always de-referenceable.
> You can build a graph with bnodes, but that's not Linked Data.
>
> Manu Sporny: Yes, and to get to Linked Data, one can remove bnode refs,
> skolemize or do a variety of other things.
>
> Ted Thibodeau Jr.: Yes, I think that's a good direction. We have three
> nested circles - JSON (biggest), JSON-SD inside (JSON), JSON-LD inside
> JSON-SD. We need a diagram - we can say it explicitly.
> Gregg Kellogg: That leads to a disjoint graph if you have a bnode
> linking two IRI-based identifiers.
>
> Danny Ayers: - only for definition purposes, in practice you might want
> to keep the lot in your store
>
> Nathan Rixham: at the minute.. this is just RDF in JSON tbh (sorry)
> Gregg Kellogg: Since we're defining LD, I'm fine with MUST. Perhaps we
> need a "Structured Data" definition too.
>
> Manu Sporny: Ok, so we're making two changes to the Linked Data part of
> the spec. Changes to 3.1.4 (MAY->MUST) and 3.1.6 (SHOULD->MUST) - that
> is our definition of Linked Data that we're using for the spec.
>
> Nathan Rixham: so now "Linked Data" is a ground RDF graph, yeah?
>
> Gregg Kellogg: MacTed, can you provide a picture to include?
>
> Danny Ayers: good man
>
> Nathan Rixham: Linked Data == Ground RDF Graph, (contains no bnodes) ---
> Structured Data == RDF Graph (contains bnodes too) --- JSON == well...
> json... the host serialization langauge
>
> Danny Ayers: webr3, that sounds reasonable
>
> Nathan Rixham: that's how it's been defined in the call so far
>
> Danny Ayers: See the first principle in
> http://www.w3.org/DesignIssues/LinkedData.html
>
> Danny Ayers: is Use URIs as names for things
>
> Manu Sporny: I think we're in more agreement now than in the beginning
> of the call. I think we're close - we have the definition of Linked
> Data. We just need a way to talk about the requirements, use cases, etc.
> Can folks create use cases and post them to the mailing list? One use
> case per person over the next two weeks? Any volunteers?
>
> Gregg Kellogg: We need to create a Use Cases document.
>
> Nathan Rixham: I will send a couple
>
> Gregg Kellogg: I'll create a couple
>
> Danny Ayers: will try and get at least one together
>
> Manu Sporny: We'll put 4 use cases together.
>
> Manu Sporny: Great, this will help ground the discussion even further.
> That's the call - have a great week!
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Uber Comparison of RDFa, Microformats and Microdata
> http://manu.sporny.org/2011/uber-comparison-rdfa-md-uf/
>

Received on Tuesday, 26 July 2011 21:33:53 UTC