W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2011

ACTION: 551 - Review of SPARQL 1.1 Service Description

From: Chime Ogbuji <chimezie@gmail.com>
Date: Tue, 6 Dec 2011 23:30:17 -0500
To: SPARQL Working Group <public-rdf-dawg@w3.org>, Gregory Williams <greg@evilfunhouse.com>
Message-ID: <BEC04D9FA90D4959B3ACC098237A0D90@gmail.com>
This review (of http://www.w3.org/2009/sparql/docs/service-description-1.1/xmlspec.xml) dispatches ACTION 551.

Overall the document is well-written, concise and straight to the point and all of my comments are minor in the grand scheme of things with the exception of the two general comments below

A general comment I have is that if we have decided to have this document be only about the SPARQL protocol then we should remove all references to the Graph store protocol (sd:inputFormat, for instance) since they will only add additional uncertainty beyond what we already have by deciding to not synchronize these two specifications. Better to not specify at all than to partly specify.

The other general comment is that the vocabulary provides a means to talk about the SPARQL Update "subset" but still uses the term 'dataset' (sd:Dataset). I don't have any changes to suggest that would not be substantive other than to use the term Graph store (sd:GraphStore) instead since (per the Update specification) it can be considered a mutable RDF dataset, and thus the term would cover both. 

Otherwise, this will certainly be a source of confusion for clients consuming service descriptions of endpoints supporting SPARQL Update.

= Abstract =

"SPARQL service description, a method for discovering, and" => "SPARQL service description, a method for discovery and"

In General, it is not clear if you are trying to say that SPARQL service description *is* comprised of a method for discovery and a vocabulary or that the document is comprised of a method for discovery and a vocabulary.

= SOTD / Introduction = 

This document is missing the standard boiler plate listing of the other specifications

= 2. Accessing a Service Description =

"serialization, may be provided embedded in (X)HTML by RDFa [RDFA]," => "serialization, may be embedded in (X)HTML by way of RDFa [RDFA],"

= 3.2.1 sd:endpoint = 

The text here stands out from the pattern of the following sections that describe properties by saying "Relates an instance of ____" etc. It should follow the pattern of the others and say: "Relates an sd:Service [...] with a SPARQL endpoint"

= 3.2.11 sd:propertyFeature = 

"Relates an instance of sd:Service to a resource representing an implemented feature of the SPARQL Query or Update language that is accessed by using the named property."

I couldn't make sense of this sentence. In particular, after reading this, it is not clear what a client that consumes an SD document using this term would understand about this feature. Is this an example of a 'special predicate' ala list:member, for instance? I would suggest text, but I don't know what the intention of this feature is.

= 5 Conformance = 

"The use in the returned RDF content of the vocabulary defined in this document must be used in accordance with the usage specified in section 3 Service Description Vocabulary." => "The RDF content returned MUST make use of the vocabulary defined in this document in accordance with ..."

As it is, it is hard to read.

-- 
Chime Ogbuji
Sent with Sparrow
Received on Wednesday, 7 December 2011 04:30:53 GMT

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