Re: [GRAPH] graph deadlock?

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

Received on Wednesday, 21 December 2011 21:19:09 UTC