Re: [TF-ENT] Entailment Regimes telecon

>>> Issues to discuss:
>>>     * [ISSUE 28]: Entailment regimes vs. update?
>>> This obviously also relates to update. I am not sure it is compatible
>>> with the conditions on extensions to BGP matching, but one way to go
>>> would be to always apply simple entailment semantics to update
>>> queries. That would be a bit of a burden for OWL Direct Semantics
>>> application because you have to implement data structures to keep an
>>> RDF graph that you use to do the updates and after each update you
>>> have to convert from the triples into the OWL logical constructs.
>>> Another option would be to say that update is not yet defined for use
>>> with entailment regimes and leave that open to future versions of
>>> SPARQL.
>>
>> I would not be shocked if we say that there is no relation. Ie, that the
>> entailment regimes are valid for query only. This could be a way out if
>> we feel there are too many mines hidden on this subject. I guess your
>> proposal of applying simple entailment semantics to update is more or
>> less similar, isn't it?
>
> Well, as I understand it, you consider leaving it undefined, whereas
> my suggestion is to treat updates always with simple entailment
> semantics, i.e., you delete/modify a triple only if it is matched by
> simple entailment and the triple that is to be deleted/modified is
> actually in data and not just an inferred triple. So, if you say
> DELETE { :something a :D }
> and your data has the triples
> :something a :C . :C rdfs:subClassOf :D.
> your delete would have no effect and if you then query
> SELECT ?x WHERE { ?x a :D }
> you would still get :something as answer.
> Since we want to keep it as simple as possible for now, I would be
> happy to say entailment regimes are only valid/defined for query.

Simple entailment matches uses subgraph so this does not make difference?

No (simple) entailment is certainly a possibility but before we go
that way, we ought to consider cases where the "query" pattern (the
WHERE clause in an update) matches on one graph and the triples are
inserted into another.

e.g.

INSERT { ?s subClassOf ?o } WHERE { GRAPH <g> { ?s subClassOf ?o } }

which materialises the subClass transitivity into the target graph.
Of course, you also NOT want to do that as well.

    Andy

>>>     * [ISSUE 34]: How do entailment regimes interaction with
>>> aggregates, grouping, and blank nodes?
>>> I think that is clear now from the definition of the semantics,

I think it's clear - algebra operates over the results of BGP matching.

>>> although we might have to make it clearer to readers?
>>>
>>>     * [ISSUE 40]: How can other entailment regimes plug in their
>>> semantics to SPARQL/Update?
>>> see issue 28
>>>
>>>     * [ISSUE 42]: TF-ENT What should happen for RDFS entailment in the
>>> face of inconsistencies?
>>> Are we all happy with the current solution?
>>>
>>>     * [ISSUE 43]: should entailment-regimes be declared over the whole
>>> dataset or individual graphs?
>>> This relates to service descriptions as well. Andy is in favour of
>>> being able to declare entailment regimes per graph and I am slightly
>>> in favour of that too. If the majority thinks so, we should probably
>>> asks for an extension in this direction in the service description
>>> doc.

Received on Wednesday, 4 November 2009 14:37:58 UTC