Re: SPARQL 1.1 Service Description - Comments

On Jul 29, 2011, at 3:18 PM, David Booth wrote:

> 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.  

The SPARQL 1.1 Protocol document lists the criteria for conforming protocol implementations. Protocol implementations need not implement service descriptions, and so the criteria for conforming to the service description specification can't be tied directly to conformance with the protocol spec.

> 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?

The wording in section 2 Accessing a Service Description, referenced by the conformance section, has been updated: "SPARQL services made available via the SPARQL Protocol SHOULD return a service description document at the service endpoint when dereferenced using the HTTP GET operation."

> 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.

The text of sd:endpoint has been updated to refer to IRIs instead of URI references. The working group believes that between the definition and the provided examples, the document makes clear that only the:

:service sd:endpoint <http://example/endpoint>

form is acceptable.

While fragment identifiers are obviously not useful when using endpoint IRIs to access a SPARQL service, we feel that this naturally falls out of the relevant specifications (in particular for URIs and HTTP).

> 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>
> ]]

This has been fixed.

> 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.

I assume this is a typo and what you meant was "'MAY' indicates that the ***sd:graph*** property is *not* required"? Your reading is correct, and the wording has been changed to clearly indicate that a graph name is required (MUST) and the graph description is optional (MAY).

> 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.

There is no test suite coverage of service descriptions yet. However, the SPARQL 1.1 test suite is still a work in progress, and the working group intends to include testing of service descriptions.

> 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
> ]]

This is one of many such features that might be described by an implementation. The service description mechanism is provided to allow describing such features, but we have tried to restrict the instances that are defined by the specification to a select few which describe features that are already widely implemented. We expect that many feature instances such as "requests are atomic" and "allows graph creation" will be defined by the community, and may be standardized by a working group in the future.

> 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.

This text has been updated to use "MUST NOT".

> 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
> ]]

As noted above, the extensibility of service descriptions allows features to be defined and used outside the SD spec, but the WG has decided not to define feature instances beyond those already in the document at this time.

> 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.

This change has been made in the latest editor's draft of the document.

> 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.

As with sd:endpoint, this object of a statement with this property is now described as being an IRI.

> 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.

You are correct. The sd:Graph class was added in a recent draft of the document, and the description of sd:graph wasn't updated accordingly. The correct range has now been added to the document.

> 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.

That is correct. The following text has been added to the definition of sd:Graph: "This document does not define properties with domain sd:Graph. Instead, such instances may be described using other appropriate vocabularies."

> 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

This text has been changed to "sd:UnionDefaultGraph, when used as the object of the sd:feature property, indicates that the default graph of the dataset used during query evaluation (when an explicit dataset is not specified) is comprised of the union of all the named graphs in that dataset."


We would be grateful if you would acknowledge that your comments have been answered by sending a reply to this mailing list.

Regards, Gregory Williams, on behalf of the SPARQL WG.

Received on Tuesday, 1 November 2011 14:58:00 UTC