- From: David Booth <david@dbooth.org>
- Date: Fri, 29 Jul 2011 15:18:13 -0400
- To: public-rdf-dawg-comments <public-rdf-dawg-comments@w3.org>
Regarding http://www.w3.org/TR/2011/WD-sparql11-service-description-20110512/ I like this! Thank you for including it! Some suggestions, mostly editorial, but some substantive: 1. Regarding this conformance requirement: http://www.w3.org/TR/sparql11-service-description/#accessing [[ 2 Accessing a Service Description SPARQL services made available via the SPARQL Protocol SHOULD return a service description document at the service endpoint. This service description MUST be made available in an RDF serialization, MAY be provided embedded in (X)HTML by RDFa [RDFA], and SHOULD use content negotiation [CONNEG] if available in other RDF representations. ]] Although this conformance requirement seems reasonable, I don't think it is in the correct specification, because the SPARQL 1.1 Service Description does not govern the behavior of a SPARQL service. The behavior of a SPARQL service is governed by the SPARQL 1.1 Protocol for RDF specification: http://www.w3.org/TR/sparql11-protocol/ So it seems to me that the above conformance requirement should be in that latter specification. 2. Also, the conformance requirement in section 2 "Accessing a Service Description" should state explicitly *how* the service description should be made available. E.g., via an HTTP GET on the service endpoint URI? 3. Clarification needed: http://www.w3.org/TR/sparql11-service-description/#sd-endpoint [[ 3.2.1 sd:endpoint The SPARQL endpoint of an sd:Service that implements the SPARQL Protocol service [SPROT]. The object of the sd:endpoint property is a URI reference. ]] How must that URI reference be supplied? For example, are all of the following acceptable? :s1 sd:endpoint "http://example/endpoint" . :s2 sd:endpoint "http://example/endpoint"^^xsd:string" . :s3 sd:endpoint "http://example/endpoint"^^xsd:anyURI . :s4 sd:endpoint "http://example/endpoint"@en . I think the acceptable form should be nailed down precisely, so that different implementations do not use different forms. 4. Why shouldn't the value of an sd:endpoint be an IRI Reference (rather than a URI Reference)? Also: (a) note that a URI Reference may have a fragment identifier. Is this permissible as part of the endpoint identifier? If so, what does it mean? Also it would be good to explicitly cite the appropriate specification, such as RFC 3986 or RFC 3987. 5. Perhaps this is a bit pedantic, but it seems to me that URIs in things like: [[ domain: sd:Service range: http://www.w3.org/ns/formats/Format ]] should be written with angle brackets: [[ domain: sd:Service range: <http://www.w3.org/ns/formats/Format> ]] 6. I just noticed this: http://www.w3.org/TR/sparql11-service-description/#sd-NamedGraph [[ 3.3.11 sd:NamedGraph An instance of sd:NamedGraph represents a named graph having a name (via sd:name) and a graph description (via sd:graph). ]] This seems to require that an instance has *both* a sd:name and a sd:graph. But when I look at this: http://www.w3.org/TR/sparql11-service-description/#sd-namedGraph [[ 3.2.17 sd:namedGraph Relates an instance of sd:GraphCollection (or its subclass sd:Dataset) to the description of one of its named graphs. The description of such a named graph MUST include the sd:name property and MAY include the sd:graph property. ]] the conformance word "MAY" indicates that the sd:name property is *not* required. It would be good to better align these statements. 7. Is there a test suite for Service Descriptions? The example in section 4 is rather minimal. It would be helpful to have some more extensive examples somewhere, though not necessarily within the spec itself. 8. I suggest adding an sd:UpdateRequestsAreAtomic feature instance to section 3.4: http://www.w3.org/TR/sparql11-service-description/#instances [[ 3.4.9 sd:UpdateRequestsAreAtomic sd:UpdateRequestsAreAtomic, when used as the object of the sd:feature property, indicates that each SPARQL Update request consisting of multiple SPARQL Update operations will be executed atomically by the SPARQL service: either all such operations will be performed (without resulting in any failure) or none will be performed. See SPARQL 1.1 Update section 2.2: http://www.w3.org/TR/sparql11-update/#updateServices type: sd:Feature ]] 9. Section 3.4.7 sd:EmptyGraphs says: http://www.w3.org/TR/sparql11-service-description/#sd-emptygraphs [[ A graph store that supports empty graphs SHOULD NOT remove graphs that are left empty after triples are removed from them. ]] I think this should be changed to a "MUST NOT", as otherwise the sd:EmptyGraphs constant would be pointless: with a "SHOULD NOT", even if this service had this feature, you still wouldn't know whether your graphs would be deleted. 10. I suggest adding an sd:AllowsGraphCreation feature instance to section 3.4: [[ 3.410 sd:AllowsGraphCreation sd:AllowsGraphCreation, when used as the object of the sd:feature property, indicates that the SPARQL service permits new graphs to be created (resources permitting). This feature is provided because some SPARQL services may only operate on a fixed set of See SPARQL 1.1 Update section 3.1: http://www.w3.org/TR/sparql11-update/#graphUpdate type: sd:Feature ]] 11. The word "Description" is included in some of the property names but not others. For example, these use it: 3.2.12 sd:defaultDatasetDescription 3.2.13 sd:availableGraphDescriptions whereas these do not: 3.2.16 sd:defaultGraph 3.2.17 sd:namedGraph 3.2.19 sd:graph It would be helpful if the spelling were consistent. I suggest dropping the word "Description" from the property names, as it is simpler to have them briefer. 12. The sd:name property http://www.w3.org/TR/sparql11-service-description/#sd-name says it "Relates a named graph to the name by which it may be referenced in a FROM/FROM NAMED clause", but it does not say how the graph name should be indicated. For example, would all of the following be acceptable? :ng1 sd:name "http://example/graph1" . :ng2 sd:name "http://example/graph2"^^xsd:string" . :ng3 sd:name "http://example/graph3"^^xsd:anyURI . :ng4 sd:name "http://example/graph4"@en . I think the acceptable form should be nailed down precisely, so that different implementations do not use different forms. 13. The sd:graph property http://www.w3.org/TR/sparql11-service-description/#sd-graph says it "Relates a named graph to its graph description", but no range is specified for this property. If the term "graph description" means an instance of sd:Graph http://www.w3.org/TR/sparql11-service-description/#sd-Graph then I think it would make sense to specify the range of this property as being sd:Graph. Otherwise, the term "graph description" needs to be defined. 14. I see that the sd:Graph class does not have any properties defined on it. (I.e., the spec does not define any properties with domain sd:Graph.) I assume this is intended as a hook to allow users to hang whatever metadata they want on it, but it would be good to clarify this. 15. The term "default dataset" is used in sec 3.4.5 sd:UnionDefaultGraph and sec 3.2.12 sd:defaultDatasetDescription, but I do not see this term defined in either this spec, the SPARQL Query spec or the SPARQL Protocol spec. I think this needs to be clarified. Note that this comment interacts with comment 1 in http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011Jul/0017.html because if the notion of a virtual graph is defined in the SPARQL spec, then there is less need to talk explicitly about RDF Datasets (since an RDF Dataset is almost like a virtual graph if the service implements sd:UnionDefaultGraph ). This comment also interacts with comment 8 in http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011Jul/0017.html Again, thanks for doing this! -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Received on Friday, 29 July 2011 19:18:37 UTC