Re: [TF-ENT] Entailment Regimes telecon

Birte Glimm wrote:
>>> The doodle poll suggests Friday 13th 14.00-15.00 UK time (15.00-16.00
>>> rest of europe, I think tht is 09:00-10:00 EST, Sandro is that where
>>> you are?). IRC channel sparql-ent.
>>> I hope the dial in numbers are the same as usual...
>> I am not sure this is fully possible. Rather: I will invite zakim from
>> the irc channel and ask for an ad-hoc call. The dial in code will be on
>> irc then, or you will be able to say
>> zakim, code?
> ok, Zakim is my friend ;-)

That is for sure! :-)

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

I guess we are saying the same thing. If we forget entailments
altogether for a moment, simple entailment rules for SPARQL both for
query and update. What you say (and I think what I says) that remains
valid for UPDATE even if entailments are around...



> Birte
>>>     * [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,
>>> 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.
>> Thanks for taking this on Birte!
>> Ivan
>> --
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home:
>> mobile: +31-641044153
>> PGP Key:
>> FOAF:


Ivan Herman, W3C Semantic Web Activity Lead
mobile: +31-641044153
PGP Key:

Received on Wednesday, 4 November 2009 12:27:53 UTC