CommentResponse:RK-1

(In response to RK-1)

Dear Reto,

thanks for your comments, which we tried to address as far as possible in the current round of drafts published on 2010-10-14. We'd appreciate further comments on these new drafts, to be found at

http://www.w3.org/TR/2010/WD-sparql11-query-20101014/
http://www.w3.org/TR/2010/WD-sparql11-update-20101014/
http://www.w3.org/TR/2010/WD-sparql11-http-rdf-update-20101014/
http://www.w3.org/TR/2010/WD-sparql11-entailment-20101014/
http://www.w3.org/TR/2010/WD-sparql11-update-20101014/
http://www.w3.org/TR/2010/WD-sparql11-service-description-20101014/

Note that we didn't yet publish a new version of the protocol document, so your comments on the protocol will be considered in a future publication cycle.

best regards, Axel, on behalf od the SPARQL Working group.

As for your comments on Service Description, specifically, here is how your comments have been addressed:

> SPARQL 1.1 Service Description
> ------------------------------
> 
> 3.2.2 : give examples of language instances, and point to the corresponding
> sections in the document.

Done.

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

"AggregateFunction" was a typo. Aggregates are not functions and so are not modeled as inheriting from sd:Function.

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

Done.

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

I will look at the current state of the protocol document and try to include links in the next working draft.

> 3.4.2 : list shortly and point back to the defined instances

Done.

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

No. An sd:Graph is meant to be a universal description of a graph, but entailment regimes are associated with a graph by the (local) Service. This allows several services to share graph descriptions while allowing each to associate a different entailment regime. Because of this, sd:NamedGraph is the appropriate place to indicate entailment regimes as sd:NamedGraphs are the service-local association of a graph and a name.

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

No, a "Language" would be comprised of a number of extensions. As noted below, "subset" is clearly the wrong word here, but the motivation here was for cases where an implementation implements a cohesive set of features, and identifying that set as its own language would aid interoperability.

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

Why do you think SPARQL 1.0 Query doesn't share a common superset? Every valid SPARQL 1.0 query is also valid in SPARQL 1.1.

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

I think the wording here is confusing the issue. sd:propertyFeature is a specific type of feature, namely the thing called 'property functions' or 'magic predicates' (among other names).

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

I'm not sure where voiD suggests dc(terms?):format, but that predicate seems rather more general than we've modeled it in the vocabulary for file formats. Nothing stops you from asserting the dc:format statement yourself, but the file formats modeling uses its own format:media_type property for this purpose.

> 3.4.14 : range?

Fixed.

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

The use of sd:Dataset in the description is a typo -- it should read "Relates an instance of sd:GraphCollection to ...". A sd:Dataset is a sd:GraphCollection (by subclass), so sd:namedGraph can be used to related a dataset to any number of sd:NamedGraphs.

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

The intention is that the Service Description document not choose any one vocabulary to become "the standard" way of describing graphs. voiD is certainly a valid choice to describe graphs if it fits your needs, but the service description should work with any graph description vocabulary. The inclusion of voiD in the example is merely to show where such a graph description appears in the modeling, not to suggest that voiD is the preferred vocabulary.

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

I was trying to follow the styling of the RDFS document which presents similar information, but will attempt to improve the readability of these sections.