Feedback to some SPARQL 1.1 Working Drafts

Dear editors,

Below I send you some feedback, thoughts and observations that I made while
reading the working drafts of SPARQL 1.1. Apologies for stating obvious things
that might already have been discovered or reported. I did not check the mailing
list for previous reactions.

Kind regards,
Reto

----------------------------------------------------------------------------

SPARQL 1.1 Update
-----------------

3.2.1 : A DELETE operation may indeed remove entailed statements, but it might
also lead to the removal of statements that caused the entailment. Do you refer
to this state as being inconsistent; i.e., entailed statements that could no
longer be entailed cause the inconsistencies? Wouldn't thus any store that does
not perform consistency checking actually violate the knowledge state? And, is
it really enough to only raise an exception? Shouldn't there be at least an
option to have the store make sure that such now wrongly entailed statements are
also removed?

4 : I do not understand the claim that operations of a request are exectuted in
lexical order.

4.1.2 : the second example has two PREFIX statements, one before the DELETE, the
other before the INSERT. All other examples do not seem to require the two
PREFIXes.

4.1.4 / 4.1.6 : both sections contain the exact same example. As there is a
dedicated section 4.1.6 on DELETE WHERE, the example could be removed in 4.1.4.

4.2.1 : Why should stores that do not allow empty graphs always return SUCCESS,
although the empty graph was definitively not created?

SPARQL 1.1 HTTP Protocol
------------------------

1 : a(?) SPARQL Update

4.2 : an(?) RDF graph representation

5.3 : "... that the origin server incorporateS the RDF,..."

5.3 : in the box there are two need, "need need to know"

5.3 : there might be need for a link to the Service Description document from
within the box.

SPARQL 1.1 Federation
---------------------

2 : "For instance, an eNdpoint which..."

2 : The part about WSDL: a link to the WSDL document and section would improve
the document.

2 : "according TO the SPARQL alGebra"

3 : Could it make sense to take the same syntactical approach to BINDING
clauses, as was taken to FILTER clauses; i.e. BINDING become part of the WHERE
clause and are not a third type of clause: SELECT WHERE{FILTER} BINDING, but
rather SELECT WHERE{FILTER BINDING}?

SPARQL 1.1 Service Description
------------------------------

3.2.2 : give examples of language instances, and point to the corresponding
sections in the document.

3.2.4 : sd:Aggregate vs. sd:AggregateFunction. Being a function, wouldn't it be
useful to define sd:AggregateFunction as a subclass of sd:Function. Or, are
aggregate operations to be used in SPARQL HAVING clauses not considered to be
functions according to 3.2.3?

3.3.4 : adding internal references would help I think; e.g., a direct link to
sd:feature

3.4.1 : Assuming this is the URL of the SPARQL service that accepts HTTP calls
according to the SPARQL 1.1 Protocol, I think this would be a good spot to link
to the corresponding sections in the protocol document. Yes, I think this is an
appropriate at this point.

3.4.2 : list shortly and point back to the defined instances

3.4.3 / 3.4.4 : "Relates an instance..."

3.4.5 : "Relates a named graph...". Could this not also be used with sd:Graph
instead of only with sd:NamedGraph?

3.4.8 : The range is missing, I would assume that extensions should also be of
type sd:Language, shouldn't it?

3.4.8 / 3.4.9 / 3.4.10 / 3.4.11 / 3.4.12 : "Relates an instance..."

3.4.9 / 3.2.2 : Subset is indeed a bit confusing. Considering the instances of
sd:Language I would rather opt for something like SPARQL language version, or
SPARQL language variance. While sd:SPARQL11Query and sd:SPARQL11Update could be
considered subsets of SPARQL11, sd:SPARQL10Query does not really share any
common super-set.

3.4.10 : What is the difference between a supported feature (sd:feature) and an
implemented feature (sd:propertyFeature)? Are there any examples that could be
given for a named property?

3.4.13 : As the example in Section 4 shows, there is some overlap with VoID.
Would it make sense to relate to the suggestion of using dc:format according to
VoID in the context of sd:resultFormat?

3.4.14 : range?

3.4.15 : The text states that sd:namedGraph relates an sd:Dataset to a named
graph, the domain however is sd:GraphCollection. A dataset can thus have either
a graph plus one named graph, or a graph plus one graph collection? Still, the
wording seems to be misleading.

3.4.17 : I think there should be a paragraph about how to describe graphs. The
example points to VoID. Shall that become the standard vocabulary, or would it
be up to the service describer to use any model to describe data sets.
Effectively, there are at least some overlaps between VoiD and the Service
Description model, hence the relationship might have to be clarified; starting
with void:Dataset vs. sd:Dataset or rather sd:Graph.

3.4.1 - 3.4.17 : a bullet listing of the range and domain could improve the
readability.

Received on Tuesday, 3 August 2010 12:34:22 UTC