W3C home > Mailing lists > Public > public-linked-json@w3.org > July 2011

Linked Data in JSON Telecon 2011-07-26

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 26 Jul 2011 17:05:00 -0400
Message-ID: <4E2F2BFC.8010503@digitalbazaar.com>
To: Linked JSON <public-linked-json@w3.org>
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:07:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:34 GMT