entailment review - part 2

Hi Birte, all,

thanks for your efforts and careful consideration of the comments so far!

here comes the second part. None of them would hold up publication, most of them are only to be kept in mind for the next version.

I start with those comments from part one which were still under discussion, I'd suggest to mark them with notes where appropriate.

*) 
On 5 Jan 2010, at 19:43, Birte Glimm wrote:
> > 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.

I would actually prefer to have notes in for both these aspects.

> 
> > 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."
> 

Hmmm, Andy replied here:

> 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 have to admit that I don't really understand that. My concern is that the framework 
says - in its current form - that uniqueness is required, but the only instantiation 
does not guarantee such uniqueness, strictly spoken. Anyways...

[...]
> 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,

I am not sure, actually, condition 1. doesn't require consistency of SG, it only says:
"The scoping graph, SG, corresponding to any consistent active graph AG is uniquely specified and is E-equivalent to AG."

So, hmmmm, *actually*, this wording actually doesn't limit at all what the scoping graph to an 
inconsistent graph is: In fact, this even seems to let open that the SG for an inconsistent 
graph is e.g. empty, implementation dependent, etc.

Still, the issue remains how to proceed with inconsistent graphs, since the behavior 
has to be specified for each extension:

 "The effect of a query on an inconsistent graph is not covered by this specification, 
  but must be specified by the particular SPARQL extension."

My (Axel- chairthatoff) interpretation of this is that I don't see that this implies that an 
extension has to *uniquely* define the behavior on 
inconsistent graphs, actually it could leave several options implementation-dependent (i.e. different 
for implementations that do or don't perform consistency checking.) So, the currently seemingly 
suggested path seems to be fine:
 - implementations that don't do inconsistency checking can construct SG as for a consistent graph
 - consistency-checking implementations should throw an error

That is, I think the wording in the editors note is too strong:

"[...] explicitly mentions that the scoping graph must be E-equivalent (RDFS equivalent in this case) 
 to the active graph and that AG must be consistent. "

> 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.

... indeed probably we have to collect these issues which look rather like errata 
to the query spec in opening issues. I don't intend to holding up the current drafts, 
please decide whether you want to add a note here. I will try to summarise the 
critical points in a separate mail.

*)
> 
> > 8) "Thus, also the following solution mappings are possible solutions:
> >
> >   μ4 : s -> ex:a1, o -> _:c3,"
> >
> >  Is this solution really possible? doesn't it violate (at least along
> > with &mu1;) condition 3. ?
> 
> It does violate condition 3 of query, but as I understand it, I have
> to make sure the the entailment regimes satisfy the conditions given
> in the Query spec. If I instantiate the BGP with that solution
> mapping, then the triple is RDF entailed. All solutions that lead to
> entailed triples are called possible solutions, but, the entailment
> relation alone does not guarantee that the conditions of the Query
> spec are met. I have to have extra conditions that make sure that 3
> holds, which C1 does. At some point, I have to add a proof that the
> conditions C1 and C2 guarantee the conditions given in the Query spec.
> Simple entailment uses the subgraph criterion to meet this
> restriction, but that wouldn't work well with inferences.

My "concern" would be remedied, if you'd replace: 

"Clearly, the set of possible solutions is infinite in this case, but for a possible 
solution to actually be a solution, the two conditions C1 and C2 have to be met:"
-->
"Observe, however, that for instance solution μ4 violates condition 3. 
from above and in fact clearly, the set of possible solutions is infinite in 
this case which is problematic with respect to condition 4. So, for a possible 
solution to actually be a solution, the two additional conditions C1 and C2 
have to be met:"




Now for the OWL part:


1)
"In the latter case, the system can be incomplete."

I am not sure what "the system" is... Do you mean:
"In the latter case, the answers can be incomplete."

I think this remark is anyways redundant. In fact, it has to be handled with care:
Note that, by the nonmonotonicity of NEGATION and OPTIONAL, such "incompleteness" 
can easily accumulate to "overcompleteness" thatintuitively would be understood 
as unsound answers. I'd suggest to drop that sentence...


2) 
"If the queried ontology is inconsistent under OWL 2 Direct Semantics, the system must raise an error."

It might appear strange that we do require consistency checking for OWL, but not for RDFS, at least in the final doc, 
that might need some explaining remarks.

3) 
the link behind "skolemization" points to:
http://www.w3.org/TR/rdf-mt/#prf
shouldn't it point rather to:
http://www.w3.org/TR/rdf-mt/#glossSkolemization

BTW, Skolemization should be capitalized.


4) 
"(C3) no variable occurs in the object position of a triple with the predicate owl:minCardinality, owl:maxCardinality, owl:cardinality, owl:minQualifiedCardinality,owl:maxQualifiedCardinality, or owl:qualifiedCardinality."

This is rather a condition on valid queries, than on the solution mapping... so this condition actually seems to restrict the allowed queries
rather than the solution mappings, or no?

5) 
For (C5) similar to the restrictions for RDFS axiomatic triples another alternative could be to restrict to only those (literal) values appearing in the
vocabulary of SG.

6)
I am not sure about Section 6.2 ... "The defined semantics allows for certain forms of higher order queries."
What defined semantics do you mean? Actually the example says that such queries do not give results.

7) 
Section 6.3.1 

OWL 2 Dl fragment 
-->
OWL 2 DL fragment

8)
Section 6.3.2

Endpoints that use the OWL 2 Direct Semantics entailment regime and that support the only the OWL 2 EL 
-->
Endpoints that use the OWL 2 Direct Semantics entailment regime and that support only the OWL 2 EL 

9) OWL specific comment to section 8:

Wouldn't for the datasets a semantics that would take into account owl:imports make sense?
i.e if the named graph owl:imports an ontology (graph) that is also in the named graphs, I 
would intuitively expect that the semantics of the imported ontology is taken into account. 
This does not seem to be foreseen in the current design, correct?

Received on Saturday, 9 January 2010 00:22:55 UTC