- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 30 Nov 2009 17:01:34 -0500
- To: Peter Ansell <ansell.peter@gmail.com>
- CC: pedantic-web@googlegroups.com, public-lod@w3.org
Peter Ansell wrote: > 2009/12/1 Hogan, Aidan <aidan.hogan@deri.org>: > >> Hi Kingsley, >> >> >>> For the sake of others. >>> >>> How do you describe and information resource via an RDF graph that is >>> supposed to play well with Linked Data principles? >>> >> If I understand the intent of your question, you are asking how an >> information resource should be identified -- i.e., what's a suitable >> URI? To clarify first: what's wrong with -- e.g. -- simply [1]? For me, >> this fits well with [2]. How does it not play well with Linked Data >> principles? Referring back to earlier: >> >> >>> using [1] as the information-resource URI to represent the document >>> returned is perfectly okay according to linked data principles: >>> >>> 1. Use URIs as names for things [yep] >>> 2. Use HTTP URIs so that people can look up those names. [yep] >>> 3. When someone looks up a URI, provide useful information, using >>> the standards (RDF, SPARQL) [yep] >>> 4. Include links to other URIs so that they can discover more >>> >> things. >> >>> [not directly applicable] >>> >> Cheers, >> Aidan >> >> [1] http://johnbreslin.com/blog/index.php?sioc_type=site >> [2] http://www.w3.org/TR/webarch/#id-resources >> >> >> > > My impression of the entire debacle is that it is designed to make > sure that every document has at least two identifiers so that > reasoning systems do not have to distinguish between details about the > delivery of the document, and details contained in the document. Some > rdf harvesting engines want to be able to say <URL> > <retrievedWithhttpStatusCode> "200", for example, and the flow on > effect is that you now apparently can't use the documents URL for any > other purpose because the extra httpStatusCode triple may get added > into the RDF store without a different graph URI. If the statements > are merged in a single graph, there is no way to separate it after > that point because reasoning engines, in this case description logics, > weren't designed with this multiplicity in mind. Interestingly, > everyone is okay with adding <URL> <retrievedWithhttpStatusCode> > "303", because that particular magic value is judged to be immaterial > to the nature of the URL. > > That is just my impression of the underlying cause for this entire > debacle without any of the philosophical details about the nature of > the document etc., that always pop up. > Peter, My real grip comes down to the fact that there seems to be an unwritten rule re. Documents i.e., they aren't material data objects (entities, data items, resources) re. RDF. Proof of this rule is demonstrated by the plethora of RDF files that don't assert any relationship between the RDF file (Data Container) and its structured content (Data Items). In addition, re. the HTTP system that drives the Web, when you issue an HTTP GET against a resource (i.e. a file; I don't buy the Information Resource moniker one bit), a server issues a 200 OK to indicate its ability to serve a User Agent the resource it requested. Naturally, this isn't how a Data Identifier works, since Identifiers are independent of: location, values, structure (this are very old Identity principles from way before the Web), you have a 303 if the Identifier looks like a normal resource URL or you leverage the Fragment Identifier component of the URL by taking the remainder of the URL as the address of the document containing the description of the HTTP URIs referent. Thus, as I've stated before (elsewhere), in my world view, all data objects are equal i.e., if something is worth describing (e.g. a Document or Data Container or File), it deserves an Identifier, and in the context of HTTP based data networks -what Linked Data is about - it means: a Generic HTTP scheme URI. I assume you've noticed the dearth of RDF examples that include descriptions of RDF files that are distinct, but connected, to the file contents. > Cheers, > > Peter > > > -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President & CEO OpenLink Software Web: http://www.openlinksw.com
Received on Monday, 30 November 2009 22:02:12 UTC