Re: Re 2: [TF-ENT] Querying datasets with default plus named graphs

On Oct 18, 2009, at 4:00 PM, Birte Glimm wrote:

>> - Do we all need to extend SD here? Should it allow to declare  
>> different
>> entailment
>>  regimes for different graphs in the default dataset of the service?
>
> If we go that way, then I think we would need something like a default
> entailment regime (which could be the one as specified currently in
> the SD doc). For example, if I query
> SELECT ?t FROM <http://example.org/a.rdf> FROM
> <http://example.org/b.rdf> WHERE { ex:x a ?t . }
> then I need to know which entailment will be used. We cannot assume
> that this is neccessarily simple entailment. So what we have in the SD
> document is necessary. We might want to additionally allow systems to
> declare that they use another entailment regime for certain (named)
> graphs to cover Andy's use case. I don't see that this causes
> problems, but is an addition to the service description document.

>> Before closing the issue,  I'd like to solicit a few more opinions/ 
>> examples
>> for that.
>> (Birte? Greg? Others?)
>> I am not entirely sure at this point whether this is actually a new  
>> issue
>> and 43 as
>> it was raised is indeed done.
>
> It is done if we agree that SD should be extended to cover per graph
> entailment regimes. If we have time during the next telecon, we can
> have a strawpoll on that.

I think that the way the current SD stuff has taken shape this  
probably won't be included. I'm open to feedback on this, but the  
direction we're heading now is punting on the exact mechanism for  
describing a dataset (some combination of a vocab to describe graphs  
like voiD, and some glue terms to connect those together into a SPARQL  
dataset). Without the "glue terms" in the spec, I think it would be  
strange to add a term to describe the entailment of a graph, since the  
graph in question isn't described with the SD vocabulary (it'll be  
something like a void:Dataset).

I agree that something like this is important, but not sure it belongs  
in the SD spec (but perhaps could be included in the WG note that  
we've discussed that can show how to use voiD to describe a sparql  
dataset). Or, this might even be something that could be included in  
the in-progress next iteration of voiD (though might only make sense  
for cases where the entailment has led to a fully materialized dataset).

.greg

Received on Sunday, 18 October 2009 20:17:27 UTC