W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > July 2011

SPARQL 1.1 Service Description - Comments

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>
Message-ID: <1311967093.2100.5064.camel@dbooth-laptop>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 29 July 2011 19:18:37 GMT