Re: Review of Service Description Draft

My take below...

On 1/14/2011 5:19 PM, Gregory Williams wrote:
> Nico,
>
> Thanks for the review. I've made some changes based on your feedback,
> and will make more as described below. However, I'm unsure of some of
> the issues you raise. I've commented on some of them inline.
>
> On Jan 13, 2011, at 4:18 AM, Nico Michaelis wrote:
>
>> I noticed some issues, although I have not yet found anything
>> serious.
>>
>> Major issues: * There is no comment on vendor specific extensions
>> to the description. Maybe they should be encouraged, noting that
>> orthogonal namespaces must be used?
>
> Do you think this is necessary, or is extension an implicit feature
> of the service description being encoded in RDF? I'm not sure how
> "vendor-specific" extensions would be any different than any other
> extensions, but the example service description already shows the use
> of extending the description with terms from voiD and SCOVO (as you
> noticed). If you believe such a comment is necessary I can work on
> some text. (Also, as described below, I'll add text to the example SD
> about the specific use of scovo/voiD.)

I think the fact that the example uses scovo and voiD is sufficient here.

>
>> * There is no way to characterise parameters taken by a function
>> described by sd:extensionFunction .
>
> There are other vocabularies that might be used for this (e.g. SPIN),
> but I think it's outside the scope of the current service description
> vocabulary.

Agreed.

>> * Introduction @1st sentence and many times throughout the
>> document: "made available via the SPARQL Protocol" ->  Isn't that
>> superfluous? I think we can drop that phrase most of everywhere.
>
> I don't think it's superfluous as SPARQL is used in ways other than
> through the HTTP protocol. This document specifies how to retrieve a
> service description from a SPARQL endpoint that is made available via
> the HTTP-based protocol. It doesn't specify how you'd retrieve a
> similar description if, for example, you were using a native API.

The use of "via the SPARQL Protocol" didn't seem out of place to me when 
I did my review. I'd be happy to keep it around -- people can still use 
SDs without the protocol, but the 2 specifications do somewhat go hand 
in hand.

Lee

Received on Friday, 21 January 2011 17:50:08 UTC