- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 21 Dec 2011 16:18:44 -0500
- To: public-rdf-wg@w3.org
- Message-ID: <4EF24D34.8030502@openlinksw.com>
On 12/21/11 3:47 PM, Jeremy Carroll wrote: > On 12/21/2011 8:47 AM, Kingsley Idehen wrote: >>> Jeremy: >>> I am advocating that the IRI denotes the graph >>> >>> >> Why not the Graph Container? > > In my mental model of the world, we take a URL like: > http://www.w3.org/1999/02/22-rdf-syntax-ns > > when you do a get, and ask for content type application/rdf+xml > > you get an RDF/XML document that encodes a graph. Yes. > > To me, the RDF/XML document is the representation, and the graph is > the resource. How about the Resource consisting of triples encoded in RDF/XML thereby making the resource a container of >= 1 triples ? > Thus, at least on my reading of the usual usage of RDF, there is some > preference for semantic interpretations in which > I(<http://www.w3.org/1999/02/22-rdf-syntax-ns>) is that graph <http://www.w3.org/1999/02/22-rdf-syntax-ns> is the Resource Address. It offers one level of indirection based access to the data that's ultimately streamed to a user agent. If we use another URI to increase the level of indirection we end up with a Name/Handle and > 1 level of indirection to a Resource that consists of (or bears) >= 1 triples. Encoding is negotiable. Above we used one URI as a Name and another as an Address. Example: <http://www.w3.org/1999/02/22-rdf-syntax-ns/> or <http://www.w3.org/1999/02/22-rdf-syntax-ns#> or <http://www.w3.org/1999/02/22-rdf-syntax-ns#this> pulls of the additional level of indirection with the # based examples delivering it at low cost re. HTTP message exchange. Now we have a Name and an Address that resolve to the same data (a collection of >= 1 triples). > > If I wanted to denote the RDF/XML document separately, I might in this > case, where the web server provides distinct URLs, use > http://www.w3.org/1999/02/22-rdf-syntax-ns.rdf That too is fine as an Address. Ditto <http://www.w3.org/1999/02/22-rdf-syntax-ns.rdf#this> as a cheap Name. > for the RDF/XML document, and not the graph. I am not sure what to > make of the intent behind the 302 redirect. A 303 redirect, assuming you had the Name: <http://www.w3.org/1999/02/22-rdf-syntax-ns.rdf/> or <http://www.w3.org/1999/02/22-rdf-syntax-ns/> , which simply enforces > 1 level of indirection re. data access by URI based Name reference. > At some level, I would expect that it is really for the owner of the > website to be clear in their mind as to what resource each URL they > serve actually is. Yes, re. what URIs identify. > I probably should read Web Architecture ..... isn't there some stuff > about an information resource. Yes, but its broken terminology. > I think for me then an RDF graph is an information resource, and a > graph container, such as an RDF/XML document is a distinct information > resource, but in practice web sites might blur the distinction Yes-ish. Re. Quad Stores, at least re. Anzo and Virtuoso, a Resource Address *can* serve as a Named Graph IRI which delivers some low cost lossy provenance value. Ultimately, the fidelity of said provenance and other metadata pertaining to a Named Graph boils down to additional triple based statements about said Named Graph using its IRI. As you can see, in a way, there's nothing to solve via RDF semantics re. this matter. It's more about using RDF to make better statements in the SPARQL store/dbms realm. Basically, we (users or developers of DBMS engines or stores) have to say what we mean via RDF triples. A Named Graph is a clearly Identifiable Thing with discernible properties. Thus, we make RDF based statements about the Named Subject if need be. Like beauty, it ultimately boils down to observation senses of the beholder :-) > > Jeremy > > -- 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 Wednesday, 21 December 2011 21:19:09 UTC