Re: (Batch) Response to SPARQL WD comments

Tirsdag 17 mai 2011 15:44, skrev Chime Ogbuji:
> Please see the response above regarding changes made to improve the
> readability for developers.

OK, thanks! It looks better indeed, I'll make individual comments if there is 
something.

> On Friday 25. March 2011 Kjetil wrote:
> > Another problem with the Dataset protocol: It seems to talk about direct
> > and indirect graph identification in two different contexts. The first is
> > to distinguish between direct (i.e. GET the request-URI) and indirect
> > graph identification (i.e. use a graph query parameter). For want of a
> > better term, I think this is OK. However, in section 4.1, about direct
> > graph identification, it says "However, in using a URI in this way, we
> > are not directly identifying an RDF graph but rather the RDF graph
> > content that is represented by an RDF document, which is a serialization
> > of that graph." I must admit that I cannot se how this usage is founded
> > in Webarch. Quite to the contrary, when webarch talks about indirect
> > identification, it is something quite different:
> > http://www.w3.org/TR/webarch/#indirect-identification
>
> Please see an earlier response to a similar question:
>
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011Feb/0007.h
>tml
>
> The term indirect identification is being used in the main (English) sense
> of the word to clarify that the request URI does not identify the resource
> that is modified as a result.

No, this is not a similar question. Like I say above: "It seems to talk about 
direct and indirect graph identification in two different contexts. The first 
is to distinguish between direct (i.e. GET the request-URI) and indirect 
graph identification (i.e. use a graph query parameter). For want of a better 
term, I think this is OK." Gregg's question only concerns this issue. 

It is the other usage that is more important. It is problematic because it is 
inherited from SPARQL 1.0:  
http://www.w3.org/TR/rdf-sparql-query/#namedGraphs
so I don't know how inclined the present WG is to do anything about it.
In 1.0, you could get around any problems that may have been caused by this by 
redirecting, but now that a 200 response is required, you cannot necessarily 
do that.

So, the problem is that according to my understanding, we are bound to get URI 
collisions. Lets take a concrete example, my FOAF profile can be GET by 
dereferencing http://www.kjetil.kjernsmo.net/foaf
There, you learn that 
<http://www.kjetil.kjernsmo.net/foaf> a foaf:PersonalProfileDocument .
but now, it turns out that the same URI identifies some RDF graph content, 
especially if someone says 
SELECT * FROM <http://www.kjetil.kjernsmo.net/foaf> WHERE { ?s ?p ?o }

To me (and I may be wrong, and I would love it if anybody could explain this 
in clear terms if I am) a foaf:PersonalProfileDocument and some RDF Graph 
Content are two distinct things. And I'm sure it is possible to come up with 
many other similar examples. So, to me, it seems like there is something 
wrong that isn't right ;-)

> On Friday 14. January 2011 Kjetil wrote:
> > I've seen in SPARQL Update, section 3.2.2., a store that do not record
> > empty > graphs will always return success. Also, in 3.1.3, it says
> > "Deleting triples that are not present, or from a > graph that is not
> > present will have no effect and will result in success." It then strikes
> > me as odd that the HTTP DELETE operation SHOULD return a 404, > IMHO, it
> > would be more natural, given the above and the overhead resulting from
> > checking if a graph is present, to say that HTTP DELETE MAY result in a >
> > 404 if a DROP would have resulted in a failure.
>
> As Gregg mentioned in his followup to the thread, 404 is in reference to
> the identified resource and whether or not it exists rather than it being
> an indication of failure of the the operation as a whole (or of success of
> failure of a DROP operation). 

Yup, I can see that. So, sometimes, I'm pragmatic too. Actually, I'm mostly 
pragmatic. :-) And my concern was pragmatic, since I cannot tell whether I 
should return a 404 from doing DROP GRAPH <graph_uri>, I would like to be 
able to return a response without always doing ASK { GRAPH <graph_uri> {} }, 
because that's what this means in practice, right? 

I think interoperability is an important reason to write specs, and I think 
this is something that is likely to be widely ignored thus causing 
interoperability problems, thus I think the WG should be really certain that 
this is actually important.

Best,

Kjetil
-- 
Kjetil Kjernsmo
PhD Research Fellow, University of Oslo, Norway
Semantic Web / SPARQL Query Federation
kjetil@kjernsmo.net           http://www.kjetil.kjernsmo.net/

Received on Wednesday, 18 May 2011 15:40:09 UTC