- From: Alexandre Passant <Alexandre.Passant@deri.org>
- Date: Tue, 28 Sep 2010 14:28:30 +0100
- To: Gregory Williams <greg@evilfunhouse.com>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
On 24 Sep 2010, at 20:51, Gregory Williams wrote: > On Sep 21, 2010, at 4:28 AM, Alexandre Passant wrote: > >> * Section 2) >> >> """ >> This service description should be made available in an RDF serialization, and may be provided embedded in HTML by RDFa, or other RDF representations by using content negotiation. >> """ >> >> Was there a decision on the should / must for "service description should be made available in an RDF serialization". >> If the description is not available in RDF, that's not really useful imo. > > Good point. The reason for this wording was that I think we didn't want to force endpoints to support service descriptions to be conformant with the Protocol. Looking at the preceding sentence, though, there's another SHOULD that I think takes care of that. So unless there are objections, I will change the text to be: > > "SPARQL services made available via the SPARQL Protocol SHOULD return a service description document at the service URL. This service description MUST be made available in an RDF serialization, MAY be provided embedded in (X)HTML by RDFa, and SHOULD use content-negotiation if available in other RDF representations." +1 > >> "embedded in HTML" -> (X)HTML > > Done. > >> "or other RDF representations by using content negotiation." => I'd suggest "and SHOULD use content-negociation if available in other RDF representation" > > Done. > >> * Section 3) >> >> """ >> The SPARQL Service Description namespace IRI is: >> http://www.w3.org/ns/sparql-service-description# >> """ >> >> Probably better as an hyperlink. > > Done. > >> It currently redirects to a plain page that links to the RDF/XML or Turtle specs, but I would expect at least an HTML description of the vocab (which is the SD doc itself) >> Could we have >> http://www.w3.org/ns/sparql-service-description# redirected to SD document (if no specific header, and keep current conneg for .ttl / .rdf) > > I don't have strong feelings on this. If there is support for this setup, I'll ask ivan if he can change the redirects to handle it. > >> "An instance of sd:Language represents a subset of the SPARQL language" => I'd suggest "An instance of sd:Language represents one of the SPARQL languages" > > I think the wording here came from a HCLS use case from ericP where we wanted a way to be able to describe not just the Query/Update distinction, but specific configurations of SPARQL w.r.t. optional features and/or extensions. I'm not sure of a better way to word this without actual examples of such configurations. Any thoughts? Ok, I See. Maybe "one of the SPARQL language, including specific configuration providing particular features or extension" ? > >> * Section 3.4) >> >> Descriptions of domain / ranges (such as "sd:defaultEntailmentRegime is an rdfs:subPropertyOf sd:feature. The rdfs:domain of sd:defaultEntailmentRegime is sd:Service. The rdfs:range of sd:defaultEntailmentRegime is sd:EntailmentRegime.") may be more readable using bullet points / several lines > > This has been brought up several times. I formatted it this way just for consistency with the syntax of the RDFS document. Is there existing list-formatting in other specs that you'd prefer, or do you think I should just try to hack up some html myself? Right, sorry, I realised I brought that up at the previous review. I'm more used to specs like FOAF (w/ domain / ranges on several lines, as in http://xmlns.com/foaf/spec/#term_mbox ) but I'm OK with the current one if no one else objects, as that's just a matter of taste. Alex. > > thanks, > .greg > -- Dr. Alexandre Passant Digital Enterprise Research Institute National University of Ireland, Galway :me owl:sameAs <http://apassant.net/alex> .
Received on Tuesday, 28 September 2010 13:29:05 UTC