Re: service description vocabulary

Hi,

On 29 Sep 2009, at 02:41, Gregory Williams wrote:

> On Sep 28, 2009, at 12:16 PM, Gregory Williams wrote:
>
>>> Let's not fixate on Void. If Void is not sufficient then the  
>>> community will come up with something more comprehensive.
>>
>> Well, I'm torn between saying "yes, absolutely," and thinking that  
>> there are people (like the voiD folks) that are working on  
>> describing RDF graphs, but that the SPARQL dataset case is specific  
>> enough to SPARQL that maybe we should be providing the handful of  
>> properties to allow leveraging graph description vocabularies in  
>> the context of SPARQL datasets.
>
> After talking a bit with Andy on irc earlier, and hearing some good  
> suggestions, I'd like to know what people think of the following  
> compromise. The service description spec will simple have a  
> sd:datasetDescription property (and an equivalent property for  
> pointing to a dereferenceable URL for the same data) that will point  
> to some sort of description of the dataset (with the specifics being  
> left to others to sort out). Subsequently, a WG or IG note can be  
> published minting new properties if necessary (such as  
> ex:defaultGraph and ex:namedGraph) and detailing how a vocabulary  
> like voiD can be used to describe a SPARQL dataset.

One question regarding the dereferencable URL for the service  
description.
I guess the main idea is to let people query the SD, so will it be a  
requirement that this information must be stored in the RDF store (in  
a particular named graph so that it can be directly queries) ?
Or could it be created on runtime (in that case, it will have to be  
queries using a third-party application, or by the current endpoint if  
it supports FROM).

>
> This would keep the core service description vocabulary small,  
> leaving the specifics of describing graphs and datasets to evolve in  
> their own time, and focusing the vocabulary on just the important  
> SPARQL-specific things. I expect some of the voiD supporters will  
> follow up on this and push for more direct support to be included,  
> but after hearing input from both sides and considering the  
> available timeline and legitimate worries about trying to  
> standardize this area too early, I think this is the best solution.

I understand that the WG does not want to advertise one vocab or  
another (especially when these are quite new), however, I think it may  
help to mention, in the SD document, the list of vocabs that have been  
investigated so far for such purposes.

Finally, what about properties to identify the particular extensions /  
entailment / etc. supported by the endpoint ?

Best,

Alex.
>
> Thoughts?
>
> thanks,
> .greg
>
>

--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .

Received on Tuesday, 29 September 2009 07:45:51 UTC