- 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>
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