- From: Gregg Kellogg <gregg@kellogg-assoc.com>
- Date: Tue, 26 Jul 2011 17:32:33 -0400
- To: Manu Sporny <msporny@digitalbazaar.com>
- CC: Linked JSON <public-linked-json@w3.org>
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