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

Re: JSON-LD Telecon Minutes for 2011-07-04

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Tue, 5 Jul 2011 13:12:12 -0400
To: Kingsley Idehen <kidehen@openlinksw.com>
CC: "public-linked-json@w3.org" <public-linked-json@w3.org>
Message-ID: <B9BEA1C4-2B92-416C-B909-FE73B765590A@kellogg-assoc.com>
Kingsley, thanks for the feedback.

If you're requiring as a basic precept that every URI used in an LD graph be de-referencable, this would leave out statements of the set of URIs that are not de-referencable. This would seem to also include URNs. I don't think it's appropriate to limit JSON-LD to use only de-referencable URIs. However, I do believe that a best practice (where feasible) is to use de-referencable URIs, where a suitable representation is returned.

Otherwise, can you suggest a re-wording of the LD points in [1] that would be more accurate?

Gregg

[1] http://json-ld.org/requirements/latest/#linked-data

On Jul 5, 2011, at 1:45 AM, Kingsley Idehen wrote:

> On 7/5/11 7:09 AM, Manu Sporny wrote:
>> Topic: Formal Definition of Linked Data
> First assertion about Linked Data reads:
> Linked Data is used to represent a directed graph .
> 
> Sorry, but that's back to front, at best.
> 
> A directed graph used to represent (describe) an object can be 
> constructed in such a way that subject name, subject attributes, and 
> subject attribute values take the form of de-referencable URIs.
> 
> In the case of Linked Data, specifically, a URI de-references to a 
> representation of its Referent. It does this because an Object has 
> Identity distinct from its Representation. Thus, an Object has a Name 
> that's distinct from the EAV/SPO graph pictorial that delivers its 
> description (representation). Naturually, on the Web (as is the case 
> with a computer's local OS), said representation exists as the content 
> of a Resource at a location (Address).
> 
> Of course, you don't have to accept my definition of Linked Data. But 
> note this, bar different turn of phrase, I've just outlined the very 
> essence of TimBL's original Linked Data meme prior to the regressive 
> tweak that added "(RDF* and SPARQL)" to its later revision. The day 
> "(RDF* and SPARQL)" are dropped from the meme or described as 
> implementation details is the day that meme returns to its GOLDEN status 
> IMO.
> 
> At this juncture, the JSON-LD definition of Linked Data is inaccurate.
> 
> You can make graphs that aren't Linked Data purveyors. Thus, don't 
> conflate graphs and linked data, let alone application of the linked 
> data concept to a global data space such as the WWW. The specific use of 
> URIs as part of graph construction is integral to what linked data is 
> about.
> 
> From RDF to JSON-LD conflation remains a problem. Conflation ultimately 
> breeds confusion.
> 
> The pieces of the puzzle:
> 
> 1. Graphs -- an effective data structure fine grained data representation
> 2. de-referencable URIs -- critical data structure tapestry (remember a 
> URI isn't implicitly de-referencable, the URL subClassOf URI is)
> 3. Resources -- data (collections of eav/spo triples) containers 
> accessible from addresses.
> 
> Current list of conflation examples:
> 
> 1. Resources -- everything is a resource meme is inaccurate since it 
> dangerous ignores perception media (WWW and Real World are related but 
> distinct media)
> 2. Graphs -- RDF is the only mechanism for graph representation or that 
> graph means RDF rather than RDF being an option for graph based data 
> representation
> 3. Linked Data -- to the RDFer Linked Data and RDF are one and the same
> 4. JSON-LD -- Linked Data is either a subset of RDF or its used to 
> represent directed graphs.
> 
> Sincerely hoping these comments are digested. I have but a single goal: 
> kill off conflation so we can make progress re. InterWeb scale Linked 
> Data without forcing syntax or data serialization formats on anyone. 
> Openness isn't as easy as folks assume. To be truly open you have to 
> invest heavily in the significant costs associated with choice.
> 
> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen	
> President&  CEO
> OpenLink Software
> Web: http://www.openlinksw.com
> Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca: kidehen
> 
> 
> 
> 
> 
> 
Received on Tuesday, 5 July 2011 17:12:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:53:17 UTC