Re: Naming the graph in the container. (Was: Re: [GRAPH] graph deadlock?)

I did not participate in the g-snap, g-box discussion, which I realize 
is my loss and no reason to reopen it.
However, I am a little confused how an RDF Graph can be a representation?
A representation, as I understand is something that can be the result of 
a Web GET
An RDF Graph is an abstraction.

A RDF/XML document, or a turtle document, is a representation (of an RDF 
Graph?), and a TRIG document is a representation (of several RDF Graphs?)

Hmmm, oh I see, you use the term "Graph Serialization" for that.
The model does seem to have an extra layer in, perhaps motivated by TRIG 
that contains multiple graphs.

I doubt this matters much, it seems to be that philosophical thing, 
where we can easily get hung up, while agreeing on the mechanics of how 
the technologies should interoperate.

Jeremy


On 12/23/2011 7:56 AM, Pat Hayes wrote:
> On Dec 22, 2011, at 12:06 PM, Andy Seaborne wrote:
>
>>
>> On 21/12/11 20:47, 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.
>>>
>>> To me, the RDF/XML document is the representation, and the graph is the
>>> resource.
>> This isn't to be picky as such but to reflect the matter of being precise and consistent. At RDF F2F2, we resolved:
>>
>> [[
>> In our documents, we'll use the terms "RDF Graph" for g-snap, "Graph Container" for g-box, and "Graph Serialization" for g-text
>> ]]
>>
>> The resource is the "Graph Container" that can be poked with GET to return the current state which is an RDF graph.
>>
>> The representation is the "Graph Serialization" that encodes that RDF graph.
> Agreed about being precise with terminology. But I would like to push back on the implicit assumption here that the resource must be a graph container. Why can a URI not be a name for an RDF graph directly, not via HTTP GET of course, but simply a name *for the graph itself*? So an RDF graph can indeed be a resource, seems to me, at least if we acknowledge the possibility of attaching a name to one of them.
>
> This was the idea of the original 'named graph' proposal, and there were reasons for this choice. In particular, we paid considerable attention to the idea of signing and authenticating secure RDF data. If I am putting my signature to some RDF content, I want it to be attached to the actual graph, not to a labile graph container that others can later modify. Failing this, I want to have secure, locked graph containers, but this is not a topic we have yet tackled. It is simpler and I think more conceptually correct to speak of naming the graph itself.
>
> Pat
>
>> In the above text, "the graph is the resource" mixes things up a little.  The resource is a Graph Container that can produce an RDF Graph (a value; the container's state) on demand.
>>
>> I read
>>>>> I am advocating that the IRI denotes the graph
>> as
>>>>> I am advocating that the IRI denotes the RDF graph
>> The "denotes a graph container" is a common, but different, usage pattern.
>>
>> 	Andy
>>
>>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>

Received on Saturday, 24 December 2011 01:06:46 UTC