Re: ACTION-550: my SPARQL1.1 Service Description review

> We've decided explicitly in the past that SD only covers SPROT. I don't
> think we need to be explaining that sort of "why" in a specification, as
> long as we explain the "what".

Fair enough, but as we mention graph store protocol also  (e.g. PUT in 3.2.15 sd:inputFormat)
it might be either worth a mention, or we might think of removing the mention in Section 3.2.15 as well.

cheers,
Axel 


On 5 Dec 2011, at 01:39, Lee Feigenbaum wrote:

> On 12/4/2011 5:00 PM, Axel Polleres wrote:
> > Hi Greg, all,
> >
> > Below my comments on the Service Description doc:
> >
> >
> > 1) general question (probably not critical):
> > "This document describes SPARQL service description, a method for discovering, and vocabulary for describing SPARQL services made available via the SPARQL 1.1 Protocol for RDF [SPROT]."
> > One may ask why can actually only SPROT services be described and not endpoints supporting only the graph store protocol (at least theoretically this could be a scenario)
> > At least, should we make a mention why those services are NOT covered in this spec (with reference to the [SPARQLHTTP] spec)?
> 
> We've decided explicitly in the past that SD only covers SPROT. I don't
> think we need to be explaining that sort of "why" in a specification, as
> long as we explain the "what".
> 
> Lee
> 
> >
> > 2) general question/comment (just not to forget):
> > We need to adapt comments period (for all docs) accordingly (assuming we manage to publish by Christmas: end of Jan?)
> >
> > 3) the "Since the publication of the previous working draft of this document,..." paragraph needs to be updated.
> >
> > 4) Section 1: "A SPARQL service description lists the features of a SPARQL service made available via the SPARQL
> >       1.1 Protocol for RDF [SPROT]. "
> >    see 1)
> >
> > 5) Section 1.1: "When this document uses the words MUST, SHOULD and MAY, and the words appear as emphasized text, they must be interpreted as described in [RFC2119]."
> >    we use upper case here, whereas in other docs bold ist used,think I remember we talked about making this uniform across docs.
> >    (update uses bold, SD uses uper case, query doesn't seem to use any emphasized MUSTs, or alike)
> >    upper case seems to make sense, since it preserves, when you copy text as plain text
> >
> > 6) SPARQL Service ... again, shall we also include a mention of the Graph Store protocol (or why it is not covered herein)? again, see 1)
> >
> > 7) Section 3.1
> >
> >      s/The prefix used in this document for this namespace is sd./The prefix used in this document for this namespace is<tt>sd:</tt>./
> >
> > (just to set it apart visually a bit)
> >
> > 8) Section 3.2.3
> >
> > "This property is intended for use when a single entailment regime by default applies to all graphs in the dataset."
> >
> > s/in the dataset/in the default dataset of the service/ ?
> > otherwise maybe not 100% clear which dataset is referred to here.
> >
> > 9) 3.2.5 sd:defaultSupportedEntailmentProfile
> >
> > Stupid question: what if the sd:defaultSupportedEntailmentProfile and sd:defaultSupportedEntailmentRegime are incompatible... suppose RIF entailment regime given together with
> > OWL 2 EL Profile? I suppose SD doesn't care about that, but maybe it should be either said explicitly, that this is not part of conformance or be made part of conformance?
> >
> > Likewise for sd:supportedEntailmentProfile
> >
> > 10) 3.2.11 sd:propertyFeature "Relates an instance of sd:Service to a resource representing an implemented feature of the SPARQL Query or Update language that is accessed by using the named property."
> >
> >    I think this is not comprehensible without an example.
> >
> > 11) 3.2.12 dafault dataset "Relates an instance of sd:Service to a description of the default dataset available when no explicit dataset is specified in the query or protocol request."
> > As this doesn't cover update requests, I think this should say:
> >    "Relates an instance of sd:Service to a description of the default dataset available when no explicit dataset is specified in the query, update request or via protocol protocol parameters."
> >
> >
> > 12) 3.2.13 sd:availableGraphs
> > "Relates an instance of sd:Service to a description of the graphs that may be used in the construction of a dataset either via the SPARQL Protocol or with FROM/FROM NAMED clauses in the query."
> >
> > again, update requests not covered, suggestion:
> >
> > "Relates an instance of sd:Service to a description of the graphs that may be used in the construction of a dataset either via the SPARQL Protocol, with FROM/FROM NAMED clauses in a query, or with USING/USING NAMED in an update request."
> >
> > 13) 3.2.14 sd:resultFormat
> >
> > (non-critical) A side remark on http://www.w3.org/ns/formats/ ... shouldn't e.g. http://www.w3.org/ns/formats/SPARQL_Results_JSON have at least an RDFa triple stating:
> >
> >    <http://www.w3.org/ns/formats/SPARQL_Results_JSON>  a<http://www.w3.org/ns/formats/Format>  .
> >
> > ?
> >
> > 14) 3.2.15 sd:inputFormat
> > "Relates an instance of sd:Service to a format that is supported for parsing RDF input (for example, via a SPARQL 1.1 Update LOAD statement or an HTTP PUT as described by SPARQL 1.1 Graph Store HTTP Protocol [SPARQLHTTP])."
> >
> > suggest to also mention explicitly dereferenced URIs for dataset clauses... ie. change to
> >
> > "Relates an instance of sd:Service to a format that is supported for parsing RDF input; for example, via a SPARQL 1.1 Update LOAD statement, or when URIs are dereferenced in FROM/FROM NAMED/USING/USING NAMED clauses (see also<href="#sd-dereferencesuris">sd:DereferencesURIs</a>  below), or in an HTTP PUT as described by SPARQL 1.1 Graph Store HTTP Protocol [SPARQLHTTP])."
> >
> > 15) 3.3.4
> > "An instance of sd:Function represents a function that may be used in a SPARQL SELECT expression or a FILTER, HAVING, GROUP BY, or BIND clause."
> >
> > Hmmm, function calls are also allowed in other places e.g. in ORDER BY clauses, see: http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#rOrderClause
> > Maybe instead of a list of where function calls are allowed, just refer more generically to "built-in calls" , i.e.
> >
> > "An instance of sd:Function represents a function that may be used in a SPARQL built-in calls, besides the standard list of supported function (see<a href="http://www.w3.org/TR/sparql11-query/#rBuiltInCall">SPARQL Grammar</a>)."
> >
> > (I suppose that we assume that all those are supported by a compliant service and that this feature be used only to advertise which non-standard
> > functions are supported on top)
> >
> > 16) Note that the previous analogously applies to section 3.2.7
> >
> > 17) 3.3.5 sd:Aggregate
> > "An instance of sd:Aggregate represents an aggregate that may be used in a SPARQL aggregate query HAVING clause or SELECT expression."
> >
> > Again, I wouldn't attempt to list where aggregates can appear, but instead say:
> >
> > "An instance of sd:Aggregate represents an aggregate that may be used in SPARQL, besides the standard list of supported aggregates (see<a href="http://www.w3.org/TR/sparql11-query/#rAggregate">SPARQL Grammar</a>)."
> >
> >
> > 18) Note that the previous analogously applies to section 3.2.8
> >
> > 19) 3.3.8 sd:GraphCollection
> > "An instance of sd:GraphCollection represents a collection of zero or more named graph descriptions."
> >
> > This reads as if a GraphCollection doesn't have any unnamed or default graphs, but then sd:Dataset is defined as a subset of sd:GraphCollection, so this is probably not intended?
> >
> >
> > 20) 3.3.10
> >
> > "This document does not define properties with domain sd:Graph. Instead, such instances may be described using other appropriate vocabularies."
> >
> > (non-critical:) maybe make a reference to the example later on like "(see<a ...>example below</a>)."?
> >
> > 21)
> >
> > 3.4 Instances
> > "In addition to the instances listed here, the following documents list instances that may be used with the properties listed below:"
> >
> > Apart from that it should probably read "properties above" I find this slightly confusing anyways...
> > I'd rather move this to the end of the instance section in a separate subsection "Other instances" and reformulate as follows (adding alo
> > some specifics to the bullet list)
> >
> > "Apart from the instances listed above, custom extensions and other documents may define further
> > instance URIs usable within service descriptions; the following documents also list instance URIs that may be used with some of the
> > properties defined in the previous sections:
> > * Unique URIs for Semantic Web Entailment Regimes [ENTAILMENT] (members of the class sd:EntailmentRegime usable with
> >    the properties sd:defaultEntailmentRegime and sd:entailmentRegime)
> > * Unique URIs for OWL 2 Profiles [OWL2PROF] (members of the class sd:EntailmentProfile usable with the properties
> >    sd:defaultSupportedEntailmentProfile and sd:supportedEntailmentProfile)
> > * Unique URIs for File Formats [FORMATS] (members of the class<http://www.w3.org/ns/formats/Format>  usable with the properties sd:resultFormat and sd:inputFormat)
> > "
> >
> > 22) 3.4.4 sd:DereferencesURIs
> >
> > Analogous to the above saud, also mention USING/USING NAMED clauses from Update.
> >
> > 23) 3.4.5 sd:UnionDefaultGraph
> >
> > "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."
> >
> > also: the default graph of the graph store during the processing of update requests?
> >
> > 24) 3.4.6 sd:RequiresDataset
> >
> > Again, also mention USING/USING NAMED clauses?
> >
> > 25) Section 5: "The use in the returned RDF content of the vocabulary defined in this document MUST be used in accordance with the usage specified in section 3 Service Description Vocabulary."
> >
> > (non-critical) Strictly speaking, it is not defined here what "in accordance" means, but I don't have a better wording at hand, and this is probably not critical.
> > What usage would be *not* in accordance (the only things which seem to restrict accordance are the MUSTs in connection with the use of sd:namedGraph, sd:GraphCollection and sd:Dataset, yes)?
> >
> >
> > best,
> > Axel
> >
> >
>

Received on Monday, 5 December 2011 20:44:21 UTC