- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 05 Jul 2011 19:05:12 +0100
- To: public-linked-json@w3.org
On 7/5/11 6:12 PM, Gregg Kellogg wrote: > 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. Linked Data is about de-referencable URIs. You cannot have a Linked Data variant where URIs don't resolve to Referent Representations. > This would seem to also include URNs. TimBL's meme focuses on HTTP URIs, but you can have resolvers for other URI schemes. For instance, via Webfinger (which leverages Hammer Stack) you can have resolvable mailto: acct: scheme URIs. Only problem is that when you place those URIs in the Address bars of browsers they won't resolve, but you can flip the script by providing a URL which is how you trigger the custom resolver. > I don't think it's appropriate to limit JSON-LD to use only de-referencable URIs. I assume "LD" means "Linked Data" if it does, then de-referencable URIs are mandatory. The issue here is that we are conflating graph construction with linked data. These matters are distinct. > However, I do believe that a best practice (where feasible) is to use de-referencable URIs, where a suitable representation is returned. Yes, but Linked Data != best practice. Its about the use of hyperlinks (with specific de-reference / indirection behavior) as mechanism for "whole data object representation" via eav/spo based directed graphs. > Otherwise, can you suggest a re-wording of the LD points in [1] that would be more accurate? Linked Data Definition: Use of hyperlinks (resolvable or de-referencable URIs) as mechanism for "whole data object representation" via eav/spo based graph pictorials. If you don't like the definition above, you can use TimBL's original meme modulo "(RDF* and SPARQL)" since this is ultimately the only issue that irks me re. the revised meme. What's so irksome about RDF and SPARQL re. original meme? It takes implementation details and slaps them into a concept that already somewhat tricky for most to grasp at first pass. Adding RDF and SPARQL to that just make matters more confusing while pulling in RDF baggage. To conclude, you have a choice of two Linked Data definitions, both insist on de-referencable URIs, they only differ re. status, role, and importance of RDF and SPARQL. If the mission of JSON-LD is clear i.e., it doesn't make the fatal mistake of seeking to be "all things to all men" we can get past this vital matter re. Linked Definition. Note, there's nothing wrong with your position re. graphs where de-referencable URIs are optional, the only issue is calling that Linked Data just muddies the waters further re. Linked Data. How about separating JSON based directed graphs from the linked data variant? Kingsley > 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 >> >> >> >> >> >> > > -- 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 18:05:36 UTC