W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

Re: Review of Service Description document

From: Alexandre Passant <Alexandre.Passant@deri.org>
Date: Sun, 27 Dec 2009 23:32:25 +0100
Cc: W3C SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <968A09CD-DD09-47B8-9421-B6AFEA18BC28@deri.org>
To: Gregory Williams <greg@evilfunhouse.com>

On 23 Dec 2009, at 23:53, Gregory Williams wrote:

> On Dec 22, 2009, at 2:54 AM, Alexandre Passant wrote:


>> * Section 3.3:
>> Some instances names start with a lowercase, should be better to use uppercase here (as done in the entailment URIs)
> Is this common for instances? I'm familiar with common practice regarding classes and properties, but not with similar practices for instances. I actually prefer the lowercase, but will change it if there's agreement on this point.

I don't think there are some given rules, but I saw that used in various places, as well as in the entailment URIs.
Ivan or Eric, is there any W3C guidelines regarding this ?

>> * Section 3.3.3:
>> "sd:dereferenceURLs" shouldn't it be "sd:dereferenceURIs" (URL / URI) ?
> Won't they necessarily be URLs if they can be dereferenced?

According to AWWW vol.1 [1] you dereference URIs, so that would make more sense to me.

>> * 3.4.8 - sd:supportedLanguage
>> Current range is sd:Language which means that people can use any sd:Language instance here, while there are some provided by the vocabulary to comply with the current SPARQL spec., i.e. sd:SPARQLQuery and sd:SPARQLUpdate. While this will be more restrictive, it could be better to have the range of sd:supportedLanguage limited to these two instances. (OK to postpone if it requires discussions that cannot be addressed quickly)
> Not sure about this. Somebody (ericP?) had an example at some point of defining a custom language as comprising the base sparql query language with a specific set of extensions and functions. Let's discuss this on a future call.

Good point, should indeed be discussed (so I guess let it open for now)

>> * Section 3.4:
>> For consistency, as for each class (in 3.3), you mention they are instances of rdfs:Class, property descriptions should mention that they are instances of DatatypeProperty / ObjectProperty.
> I'm hesitant to add lots of OWL terms, but could probably be convinced. I notice that there's already one OWL statement in declaring sd:url an IFP.

Right, as you already use IFP, I was thinking it could be useful to also use OWL to distinguish DP / OP

>> BTW, as a matter of personal taste, instead having these as sentences, esp. for long ones as for "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.", it might be better to have RDF code for each of these descriptions.
> OK. Are there any specs that do this that I could draw on for styling? Inline turtle?

Unfortunately I'm not aware of specs using this

>> * Section 4: 
>> www.example -> www.example.org
>> http://example/ -> http://www.example.org/ (appear 3 times)
>> at the URL http://www.example/sparql/ -> at the URL http://www.example.org/sparql/
> I used "www.example" to be consistent with the examples used in the SPARQL (1.0) Protocol for RDF document. I can change this if you think it's important, but if it's just a preference I might keep it the way it is for the sake of consistency.

Ok, was not aware of this - also agree that's better to be consistent between the various docs.



[1] http://www.w3.org/TR/webarch/

>> http://www.example/named-graph/
>> It's imo a bit weird to have a graph ending with a / but I guess there is no constraints about that ?

> I'll change that. I have no preference here.
>> * References:
>> Ref to voiD should also be added.
> OK. I'll add it and mention it in describing the example.
> thanks,
> .greg

Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .
Received on Sunday, 27 December 2009 22:32:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:58 UTC