Re: [TF-ENT] Entailment Regimes telecon

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

We should probably discuss this in the telecon. Leaving it undefined
and using simple entailment does make a difference I think, but I am
not sure that is what you are referring to.

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

No. If we were to say updates use simple entailment , the where clause
would have to be applied with simple entailment, since this is not
just a read-only query. So even if <g> is a graph to which some
entailment regime other than simple entailment is applied, you would
have to keep track of original triples and inferred triples. The where
clause should only be matched to the original non-inferred triples and
only that is inserted. That's one idea of how to do it. I am open for
other suggestions or for saying that endpoints that use non-simple
entailments have no defined/specified behaviour. This can be defined
at a later stage (not within SPARQL 1.1) and until then implementors
choose what they think is reasonable or they do not offer update
possibilities at all for non-simple entailment.
Birte

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



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

Received on Wednesday, 4 November 2009 15:17:08 UTC