Re: entailment review - part 1

2010/1/5 Andy Seaborne <andy.seaborne@talis.com>:
>
> On 05/01/2010 7:43 PM, Birte Glimm wrote:
> ...
>>>
>>> 4) "The term RDF-L denotes the set of all RDF Literals, RDF-B the set
>>> of all blank nodes in RDF graphs"
>>>
>>> Hmmm, why "in RDF graphs" and in which graphs? BTW, this question also
>>> applies to Query as well.
>>
>> That is more a query comment. I just repeat the query definitions as I
>> also state above, to remind readers. If Andy and Steve want to change
>> that, I happily use a changed definition.
>
> The reason is lost to me - RDF-B is only used to get to RDF-T anyway.
>
> (this used not to be true because at one time, you could have bnodes, as
> non-distinguished variables, in the predicate position).

To me it seems to be unnecessary, but not really hurting on the other
hand. Maybe it has historical reasons as Andy suggested.

> ...
>
>>> * Another remark which is not critical, but maybe we should re-discuss
>>> it at some point ... BGP extension says that entailment regimes must
>>> specify:
>>>  - well-formed graphs
>>>  - SG must be unitquely specified
>>>  - entailment relation
>>>  - finiteness condition for answers
>>>  - handling of inconsistent graphs
>>>
>>> It doesn't *actually* say that it should define restrict "which qeries
>>> are legal", does it? I anyway don't think that the definition of BGP
>>> extension
>>> does preclude such restrictions, but it isn't actually required by the
>>> original definition.
>>
>> True. The closest to that is "An entailment regime specifies 1) ... 2)
>> an entailment relation between subsets of well-formed graphs and
>> well-formed graphs". and "2 -- For any basic graph pattern BGP and
>> pattern instance mapping P, P(BGP) is well-formed for E". I am not
>> sure whether I can interpret that as a possibility of defining what
>> legal/supported queries are. I think I once discussed that with Andy
>> and he suggested that all queries are legal, but some queries might
>> have empty answers. In particular for OWL Direct Semantics, I would
>> prefer to restrict not only the queried graphs but also the queries
>> themselves. If a query BGP cannot be parsed into ontology structures
>> then Direct Semantics entailment is just not defined. In that case I
>> would prefer to raise an error instead of giving an empty answer.
>> The other problem are update queries. Here we decided, I think, that
>> we put a note somewhere that the entailment regimes document does not
>> define the behaviour of systems for update queries. Once there is more
>> implementation experience one can then specify what implemented
>> systems do, which is most likely to use standard simple entailment for
>> update queries. I can add a note in this direction.
>>
>>> 6) This remark might be overshooting (at leat for this WD), but:
>>>
>>> "The scoping graph, SG, corresponding to any consistent active graph
>>> AG is uniquely specified and is E-equivalent to AG."
>>> [...]
>>> "All entailment regimes specified here use the same definition of a
>>> scoping graph as given in SPARQL 1.0. Thus, the required equivalence
>>> is immediate."
>>>
>>> I am a bit worried that *actually* the definition of the scoping graph
>>> as given in SPARQL 1.0 is *NOT* uniquely specified, since it obviously
>>> doesn't
>>> uniquely determine the blank nodes. Not sure whether this is really an
>>> issue, but it seems a bit awkward.
>>>
>>> Maybe the condition should be weakened to something like
>>>
>>> "The scoping graph, SG, corresponding to any consistent active graph
>>> AG is uniquely (except blank node identifiers) specified and is
>>> E-equivalent to AG."
>
> IIRC It's not supposed to uniquely specify it in the query spec but to give
> the framework - the entailment regime should specify the scoping graph in a
> compatible manner.

I agree that the Query spec says an extension to BGP matching has to
uniquely specify the SG. That seems to me a bit over the top or maybe
I am interpreting that too strictly? You have to pick one of a number
of equivalent scoping graphs. The ones you can choose from are the
ones that differ in bnode names and the only requirement is that
bnodes are suitably named apart, i.e., the query and the SG should not
share any bnodes. I would just leave it as that unless there are
complaints. It would be hard to specify it so that it is more unique,
not knowing the given inputs. The result would not differ either way.

>>> Not really ideal either, but better than before?
>>> If we agree on that change, we can include that with a remark to ask
>>> for comments?
>>
>> That is again a comment for Query and I agree it is a valid comment.
>> Several of the given conditions/definitions are not ideal IMO, that
>> being one of them. I would also prefer to use a skolemized scoping
>> graph directly, but that is also not possible, so I define this kind
>> of work around to meet the Query conditions. We further violate
>> already against the condition that the scoping graph must be
>> consistent according to the conditions in the Query spec, which we
>> cannot guarantee with the current RDFS entailment regime definition. I
>> would prefer to be more consistent, i.e., either remove the
>> consistency requirement everywhere or have it throughout.
>
> I think we have more latitude with the defns here because they exist for the
> purposes of extension and so are less tested by the spec as published as the
> REC.  I don't have the bandwidth to work on it before the upcoming
> publications.  We need wider review than just the WG can currently manage -
> maybe we need to seek out explicit reviews.

What I could do is to put in an editorial note into the entailment
regimes doc that mentions that the SG is only unique up to bnode names
and that the SG is not necessarily consistent (well that's already in
an ed note) explicitly asking for feedback on whether that is seen as
problematic given the requirements from the Query spec. Is that a good
idea?

Birte

>        Andy
>



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529

Received on Wednesday, 6 January 2010 14:00:02 UTC