Protocol specification of entailment level (was Re: The Entailment bit (was Re: thoughts from Tuesday telecon))

On Sep 27, 2005, at 5:28 AM, Seaborne, Andy wrote:

> Bijan Parsia wrote:
>> On Sep 26, 2005, at 8:41 AM, Seaborne, Andy wrote:
>>> Bijan Parsia wrote:
[snip]
>> Each endpoint has its own URI. If I understand the proposal, this 
>> would necessitate a distinct endpoint for each semantics offered by 
>> the service and the semantics must be(?) uniform over the dataset. I 
>> don't think that's the most useful only configuration (e.g., I might 
>> want the background graph to be with RDFS semantics containing info 
>> about the possible semantics offered by component graphs; a different 
>> issue would be being willing to drop down in the presence of a 
>> timeout,
>
> [I can't tell here if you are pointing out that there are other 
> configurations or actively arguing for the DAWG design to include 
> these cases.]

I'm pointing out that there are other configurations. I am currently 
neutral with regard to this overall design space.

> In earlier WG discussions, DanC point out that a graph and its RDFS 
> closure are not the same and would be expected to have different URIs 
> as graphs to query.

That's another reasoner for me to prefer an entailment view. The graph 
queried under rdf entailment and rdfs entailment *are* the same, 
although the answers they give are different. I have no desire to have 
a URI for the closures of any kind of any document.

>   Similarly, the same base graph can be put into a dataset with 
> different entailment semantics under different URIs.

I thought the design was to set entailment homogenously for a endpoint. 
Thus, every uri in a dataset accessed from a certain endpoint would be 
queried under the same semantics. I recognize that if you are going to 
treat e.g., "The rdfs closure" of a document as a "real thing" that 
should be addressable, that you can wriggle around that. But I firmly 
regard that as a bad way to go at it.

> Given we have a mechanism in SPARQL [+] already,

For?

>  having a specialised one for just entailment specification when there 
> may be all sorts of other charactistics that matter, seems confusing.

Entailment/semantics affects result sets for the same data. It is 
central, not peripheral.

>  (Other charactistics might be data coverage, up-to-date-ness - 
> nothing to do with entailment settings.)

These are, IMHO, peripheral *in the sense* that they don't affect the 
number of results *for a given graph*.

> This would allow the case you describe and put the onus of the 
> description of the URI as to its entailment status.

I dont' understand this.

> As I see it, the contrast is between designs put some kind of 
> parameter in the client request (query/protocol somewhere) and designs 
> that make this part of the description of the service.

Or somewhere inbetween. The service describes the range of things it 
can do. The client indicates what it would like done.

>  I don't see that one class of designs can express something the other 
> can't - in a service-centric design [*], it seems more natural to do 
> it as part of the descriptions of service and datasets.

Perhaps, though I don't see it (I do want a service description 
element...but there needs to be some client control too, I think).

>   As descriptions are going to be vocabulary-based they are more 
> naturally extensible.

Well, a parameter that is extensible (that is Must Understand so you 
fault if you don't handle the value) is equi-naturally extensible, I 
think.

Cheers,
Bijan.

Received on Tuesday, 27 September 2005 15:07:28 UTC