Re: ISSUE-30: How does SPARQL's notion of RDF dataset relate our notion of multiple graphs?

Pat Hayes wrote:
> On Apr 18, 2011, at 8:00 AM, Pierre-Antoine Champin wrote:
> 
>> On 04/18/2011 06:19 AM, Ivan Herman wrote:
>>> On Apr 17, 2011, at 16:49 , Pat Hayes wrote:
>>>
>>> <snip/>
>>>>> My very sketchy feeling that if we define a good old class, say,
>>>>> G-box, we can then:
>>>>>
>>>>> - say that <g> rdf:type G-box which is the identification of a
>>>>> g-box
>>>> This by itself would not attach the name to a particular g-box,
>>>> however.
>> neither does
>>
>>  <foaf.rdf#me> a foaf:Person .
>>
>> attach the name to a particular person.
> 
> Of course; but in the case of *graph* naming, we expect more than simply having a description; we expect the name to be usable to actually locate and get (a representation of) the graph. So we need a 'baptism'  syntax or convention which does the necessary attaching to the name to the graph. 

RDF Concepts already says:
[[
Given an RDF URI reference consisting of an absolute URI and a fragment 
identifier, the fragment identifer identifies the same thing that it 
does in an application/rdf+xml representation of the resource identified 
by the absolute URI component. Thus:

we assume that the URI part (i.e. excluding fragment identifier) 
identifies a resource, which is presumed to have an RDF representation. 
So when eg:someurl#frag is used in an RDF document, eg:someurl is taken 
to designate some RDF document (even when no such document can be 
retrieved).
]]

you can just swap the terminology there to something like we've been 
using to get:

[[
we assume that the absolute-IRI part (i.e. excluding fragment 
identifier) identifies a g-box, which is presumed to have a g-text. So 
when eg:someurl#frag is used in a g-text, eg:someurl is taken to 
designate some g-box (even when no such g-box can be found).
]]

There's still the ol' RDFa+HTML or Turtle-in-HTML problem there though, 
seems strange to say that it's a g-box when it merely returns a 
representation which contains a g-text.

ps: this is why I'd like to see g-text as distinct from "representation" 
(in the REST/HTTP sense), since a representation may only contain a 
g-text (where a g-text is a lexical representation of a mathematical set 
of triples).

>>> Correct. Some hand-waving may be necessary when we define g-*.
>> well, if the URI of the g-box is in the http: scheme, and it is
>> dereferenceable (with a 200 OK code), then the HTTP protocol may provide
>> that hand-waving...
> 
> Not by itself. We need to actually state (it can be as simple as a statement in the specs) that the http GET is what indeed identifies the graph being named. (And of course this statement needs to be phrased very carefully to allow for g-boxes and so forth; are we naming the box or the graph that is its state at the time of naming? What is GOT (GETted?) by a 404 error or a 303 redirect? And so on.)

that's interesting when you consider 201 Created, 301 Moved Permanently, 
410 Gone and suchlike!

Best,

Nathan

Received on Monday, 18 April 2011 13:53:37 UTC