- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 30 Aug 2012 15:11:43 -0400
- To: public-rdf-wg@w3.org
- Message-ID: <503FBAEF.4040509@openlinksw.com>
On 8/30/12 2:56 PM, Gregg Kellogg wrote: > On Aug 30, 2012, at 11:47 AM, Kingsley Idehen <kidehen@openlinksw.com> wrote: > >> On 8/30/12 2:33 PM, Markus Lanthaler wrote: >>> http://dvcs.w3.org/hg/json-ld/raw-file/default/spec/ED/json-ld-syntax/201208 >>> 30/index.html#linked-data >> A problematic excerpt from the document referenced above: >> >> "A Linked Data document does not necessarily need to be expressed in JSON-LD. The notion of Linked Data is a concept independent of any given serialization format. In particular, any document based on an RDF serialization format is a Linked Data document." >> >> It isn't accurate to assert that any RDF document is a Linked Data document, and here's why: >> An RDF document doesn't have to be comprised of triple based content where each URI is dereferencable. There's nothing in the RDF spec that mandates that. >> >> Linked Data, as per TimBL's meme, mandates de-referencable URIs. >> >> RDF doesn't lose anything by being loosely coupled to the Linked Data concept. In a nutshell, loose coupling will suffice while mutually benefiting both RDF and Linked Data re., comprehension, appreciation and adoption. > Short of creating a separate document on exactly what Linked Data _is_, and whether RDF is Linked Data or not, I fear that this section could get out of hand. In discussions, it seems clear to me that much Linked Data can also contain BNodes (for instance an address of an person who is identified by an IRI). Even if true, but extremely debatable re. Linked Data as opposed to RDF (where bnodes are part of the spec), that doesn't constitute a Linked Data definition that's reconciles to TimBL's meme. Bnodes are a minefield deftly dodged by the meme. They aren't banned or encouraged, hence the deft dodge via silence. > Any example of this is Microdata, which _can_ be used to define Linked Data, but given the examples in schema.org, tends to prefer BNode identifiers (the absence of @itemid within many examples). Here a little breakdown that shows how EAV, RDF, and Linked Data are related: 1. EAV -- basic model has implicit semantics (i.e., assumptions are made about the entity, attribute, value slots) and no there no specifics about denotation mechanism 2. RDF -- basic model has explicit semantics and IRIs are expressly outlined as the denotation mechanism (this is also why, for the R-D-F reflux community, you can talk about RDF via EAV + URIs style narratives) 3. Linked Data -- builds on RDF or EAV by adding specific URI de-reference behavior that facilitates critical indirection used to implicitly associate an IRI with its description . > > The truth is that any format can be used property or abused. Yes, but the truth here is that we are trying to be as clear as possible to avoid confusion. We already have enough history in hand re., ill effects of confusion etc.. > If there's a simple paragraph we can add consistent with the context of this section which clarifies this, I'm fine with it, otherwise, we risk conflating the purpose of defining JSON-LD with the definition of Linked Data itself. RDF != Linked Data. Never has been. Its an optional (preferred by W3C, naturally) route to the destination. Conflating RDF and Linked Data hasn't benefited either endeavor, to date. Kingsley > > Gregg > >> -- >> >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software >> Company Web: http://www.openlinksw.com >> Personal Weblog: http://www.openlinksw.com/blog/~kidehen >> Twitter/Identi.ca handle: @kidehen >> Google+ Profile: https://plus.google.com/112399767740508618350/about >> LinkedIn Profile: http://www.linkedin.com/in/kidehen >> >> >> >> >> > > > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 30 August 2012 19:12:05 UTC