[TF-ENT] Entailment Regimes telecon summary

Axel, Lee, others,
here is a quick summary of what we discussed in today's entailment
regimes telecon. We mainly ran through the issues related to
entailment and I'll summarize our recommendations, so the WG can
decide whether the issue can be closed or not. I hope I got everything
right, otherwise Sandro or Andy, please correct me.

The chatlog is available here:
http://www.w3.org/2009/sparql/wiki/Chatlog_2009-11-13_Ent

We also shortly discussed RIF and the current status of OWL 2 Direct
Semantics, which I also summarise below. We tentatively scheduled
another telecon for next Friday, which might be cancelled if nothing
needs to be discussed, but could be good because Axel said he could
make next Friday and RIF has still many open questions.

Birte


Issue 28: Entailment regimes vs. update?

I'll add a note to the entailment doc to say that systems that do use an
entailment regime other than simple entailment can support update
queries, but they don't have to. If they do support update queries,
then the exact behavior is not covered by the spec and implementers
can describe the system behavior in the system's documentation.

Reasonable choices include to delete only tuples matched with simple
entailment and to use inferred tuples for inserts, but in the end it
is up to the system in SPARQL 1.1.



Issue 34: How do entailment regimes interaction with aggregates,
grouping, and blank nodes?

This was initially unclear because we were not sure how blank nodes
would be handled. Since it s now clear that only blank nodes from the
originally queried graph can be returned as answers, the spec now
clearly defines how counting, aggregates, and grouping works, so this
issue could be closed.



Issue 42: What should happen for RDFS entailment in the face of
inconsistencies?

The current spec roughly says that systems MAY raise an error and
SHOULD do so if they encounter an inconsistency. Users cannot force a
consistency check and systems do not have to do one (no MUST, but
MAY). Future versions of service descriptions might be extended such
that systems can say whether they do or did a consistency check, but
for the current round, we suggest to leave things as they are and
suggest the issue to be closed.



Issue 43: should entailment-regimes be declared over the whole dataset
or individual graphs?

This issue relates mainly to service descriptions. At the moment SDs
cannot describe endpoints that have some graphs with inferences and
some graphs without. Such configurations will occur, but maybe it is
just not part of SDs for now.



RIF:
General consensus is that we would need somebody with RIF background
to co-edit since RIF is non-trivial and does not follow from what has
been done so far for entailments. We might do another telecon on
Friday, when Axel can join in on RIF.

RIF has several open questions, which were discussed shortly:
- Not all RIF dialects are based on a model-theory, so they are not really
entailments, but can be seen as such.
- Often one wants to have entailment w.r.t. a particular rule set,
i.e., there is no pre-defined entailment relation, but entailment
depends on the rule set in question. It is open whether systems offer
some rule sets or whether the user can request a rule set to be used,
which then goes into something like content/entailment
negotiation. If a user should be able to ask for particular rule sets,
this would require changes in several places. If an endpoint offers
certain rule sets, then SDs would be a place to advertise this.
- RIF is working on a note to specify a graph format for RIF, which
brings RIF at least closer to SPARQL in that RIF rule sets can be
serialised as RDF graphs.  There might also be something like
rif:import, so one can at least use named graphs that import a rule
set.
- Some RIF dialects have non-monotonic features and for RIF production
rules it is no even clear how conjunctive queries work. Having some
work on conjunctive queries first would be better.


OWL Direct Semantics:
Spec is currently being extended to cover OWL 2 Direct Semantics. Not
all axioms carry semantics, e.g., annotations, but users want to query
also for such axioms. One could split the BGP into logical and
non-logical parts and answer the logical parts with Direct Semantics
and the non-logical parts (annotations, ontology header stuff,
declarations) with simple entailment semantics. Otherwise, the user
could query a graph with simple entailment for annotations etc and
another graph to which entailment has been applied for other queries.
I'll discuss the automatic separation of BGPs into logical and non-logical
parts with Boris Motik and Peter Patel-Schneider because this has not
been done before and there could be hidden inter-dependencies.

Received on Friday, 13 November 2009 15:50:23 UTC