Re: Review of SD document (ACTION-318)

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