W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2010

some more comments on http-rdf-update current version ...

From: Axel Polleres <axel.polleres@deri.org>
Date: Mon, 7 Jun 2010 14:17:44 +0100
Message-Id: <45AC5E41-8006-4A76-AAE4-AD2ADC22A6E8@deri.org>
Cc: Chimezie Ogbuji <ogbujic@ccf.org>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
when reading through the doc, I had the following finding, apart from what has been discussed already anyways:


Main issues listed in the document, only one:
=============================================
i) Section 5.3:


"How would a client come to discover the URI of the network-manipulable RDF dataset?

In order for a client to be able to leverage this alternative behavior of the POST method, it would need need to know the URI of the network-manipulable RDF dataset a priori. The Service Description document provides an RDF vocabulary term (sd:Dataset) that can be used in statements about a SPARQL Dataset, however, it is not clear what URI the client can use to request such a service description that provides the URI of the network-manipulable RDF dataset (typed as an instance of sd:Dataset)





Some other details/questions:
====================================

*

"Before an IRI found in a document is used by HTTP, the IRI is first
converted to a URI." --> how? I think this is mentioned somewhere in
the RFCs, isn't it?



*

"Networked RDF knowledge - An information resource identified by a
graph IRI and managed by a server that implements this protocol. See
[WEBARCH] for further discussion on Resources."

term/definition Problematic, see mails.


*

"which (intuitively) means that a representation of these triples
should be returned."
-->
"which (intuitively) means that *an RDF document representing these triples* should be returned."

maybe rather "Networked RDF knowledge base" than "Networked RDF
knowledge"?


* 
"or the URI is not dereferencable (i.e., when dereferenced, it does
not produce a RDF graph representation)"

do you really mean dereferncable in the generic sense of
http://www.w3.org/TR/webarch/#uri-dereference here ,or specifivally
GET dereferencing?


* Section 4.3:

GET /rdf-graphs/service?graph=employee/1  HTTP/1.1
   Host: example.com

just to be clear, shall we add

GET /rdf-graphs/service/?graph=employee/1  HTTP/1.1
   Host: example.com

would resolve the Graph to 
 http://example.com/rdf-graphs/service/employee/1
 
?? is that correct?

* Section 5:

"[...] MUST parse the RDF payload according to media type specified in the
Content-Type header (if provided in the request)."

otherwise, implementation-dependent?

* 
"Note that the DROP expression is not necessary"
... how again did we agree on a DROP of a non-existent graph? hope
that wasn't an error <-> mark as "to be aligned" with protocol?

*
"If the identified networked RDF knowledge does not already exist,
then a PUT request with an empty payload SHOULD be used to indicate
the creation of an empty graph and is considered a native
implementation of the following SPARQL Update operation:"

why only "If the identified networked RDF knowledge does not already
exist"? Isn't the pre-existence covered by the DROP statement?

Suggest to jsut change to 

"A PUT request with an empty payload SHOULD be used to indicate [...]"

*
"The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully."

not entirely sure about that one, why?


* Section 5.3

"The HTTP POST method SHOULD be used to request that the origin server
incorporate the RDF payload enclosed in the request with the networked
RDF knowledge identified by the request or encoded URI."
--->
"The HTTP POST method SHOULD be used to request that the origin server
incorporate the RDF payload enclosed in the request with the networked
RDF knowledge identified by the request or encoded URI. A POST is
considered a native implementation of the following SPARQL Update
operation:"

*
"Alternatively, if the request URI identifies the underlying
network-manipulable RDF dataset, the origin server SHOULD create a new
RDF graph comprised of the statements in the RDF payload and return a
designated graph IRI associated with the new graph. The new graph IRI
should be specified in the Location HTTP header along with a 201
Created code."

Can it be the same as the request URI? That wouldn't be
REST-compliant, would it? Should we write:

"Alternatively, if the request URI identifies the underlying
network-manipulable RDF dataset, the origin server SHOULD create a new
RDF graph comprised of the statements in the RDF payload and return a
designated graph IRI associated with the new graph. The new graph IRI
should be specified in the Location HTTP header along with a 201
Created code *and be different from the request URI*."
Received on Monday, 7 June 2010 15:22:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:42 GMT