- From: Axel Polleres <axel.polleres@deri.org>
- Date: Mon, 7 Jun 2010 14:17:44 +0100
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
- Cc: Chimezie Ogbuji <ogbujic@ccf.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 UTC