W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

Re: Entailment regimes open issues

From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Date: Tue, 16 Feb 2010 10:22:31 +0000
Message-ID: <492f2b0b1002160222g29ce711bva37395609ade6acd@mail.gmail.com>
To: "Polleres, Axel" <axel.polleres@deri.org>
Cc: lee@thefigtrees.net, ivan@w3.org, public-rdf-dawg@w3.org
OK :-) I'll add some explanation/examples/discussion of alternatives then.
Birte

On 16 February 2010 09:31, Polleres, Axel <axel.polleres@deri.org> wrote:
> Birte, all, don't get me wrong... I just wanted those possible alternatives spelled out and to suggest that we add some explanations/examples that make this current behavior clear and explain why sparql does not behave like the alternatives mentioned, since I would expect that some people might find particularly variations of alternative 2 intuitive. So, I didn't mean to imply a change of direction.
>
> Best,
> Axel
>
> ----- Original Message -----
> From: b.glimm@googlemail.com <b.glimm@googlemail.com>
> To: Polleres, Axel
> Cc: Lee Feigenbaum <lee@thefigtrees.net>; Ivan Herman <ivan@w3.org>; SPARQL Working Group <public-rdf-dawg@w3.org>
> Sent: Mon Feb 15 20:45:23 2010
> Subject: Re: Entailment regimes open issues
>
> On 15 February 2010 16:29, Axel Polleres <axel.polleres@deri.org> wrote:
>>
>> Well, these (32 and 34) are definitly separate issues, but I guess we agree on that...
> Yes and 32 just is not related to entailment regimes.
>
>> As for issue-34, I agree that we can close the issue if the single goal is that the
>> behaviour is well defined... we have to be aware though, that results may not always
>> and for everybody will be intuitive: in fact, although every current implementation
>> probably treats bnodes just as constants under a kind of unique names assumption
>> in aggregates like count (does anybody do anything different?) there would
>> be alternative ways to handle bnodes in aggregates, like
>> Alternative1: ignoring bnodes for aggregates (could be viewed reasonable conceptually, IMO)
>
> That is an alternative, but I like it less. For example the OWL WG
> test results are recorded in an ontology that contains, for each test
> a bnode (anonymous individual in OWL) which is related via several
> properties to properties of the test in question, e.g., whether the
> test is a consistency or an entailment test, whether the test failed
> or passed etc. If you would ignore the bnodes/anonymous individuals,
> you couldn't count the number of tests or the number of failing tests
> etc.
> I can list it as an alternative, but I wouldn't vote for including
> this as the envisaged behavior.
>
>> Alternative2: for entaiment regimes like OWL which have an explicit notion of equality/inequality
>>              counting could be expected to just return the number of those
>>              - Alternative2a: known to be different
>>              - Alternative2b: not known to be the same
> That means, however, that aggregation is no longer an algebra operator
> as it is at the moment. E.g., if we query a graph/ontology containing:
> ex:a a ex:C .
> ex:b a ex:C .
>  (in FSS ClassAssertion(ex:C ex:a) and ClassAssertion(ex:C ex:b))
> with a query
> SELECT ?x WHERE { ?x a ex:C }
> then we get x/ex:a and x/ex:b under OWL entailment (Direct Semantics
> and RDF-Based Semantics). Aggregates are then defined on top of that
> and just sum up or count or whatever the normal matching algorithm
> provides. I really wouldn't want to mess with that.
>
> Birte
>
>> Before just closing the issue, I would at least think that a sentence or two (and maybe examples)
>> should be added that clarify that those behaviors are NOT provided by the current semantics.
>>
>> Axel
>>
>>
>> On 11 Feb 2010, at 19:05, Birte Glimm wrote:
>>
>>> Just 32 means 34 I think:
>>> [ISSUE 34]: How do entailment regimes interaction with aggregates,
>>> grouping, and blank nodes?
>>> Birte
>>>
>>> On 11 February 2010 14:16, Lee Feigenbaum <lee@thefigtrees.net> wrote:
>>> > On 2/8/2010 2:02 AM, Ivan Herman wrote:
>>> >>
>>> >> I certainly agree with closing issues #28, #32, #40, #42.
>>> >>
>>> >> I would propose to leave #43 for a while to see how the SD work evolves.
>>> >> I predict that what you write below is true, but maybe discussions on SD
>>> >> will allow for a finer granularity...
>>> >
>>> > I will close issues 28, 32, 40, and 42 if there is no concerns raised within
>>> > the next 7 days.
>>> >
>>> > Let's include issue 43 in our next TC discussion of service description.
>>> >
>>> > Lee
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Dr. Birte Glimm, Room 306
>>> Computing Laboratory
>>> Parks Road
>>> Oxford
>>> OX1 3QD
>>> United Kingdom
>>> +44 (0)1865 283529
>>>
>>>
>>
>>
>>
>
>
>
> --
> Dr. Birte Glimm, Room 306
> Computing Laboratory
> Parks Road
> Oxford
> OX1 3QD
> United Kingdom
> +44 (0)1865 283529
>



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529
Received on Tuesday, 16 February 2010 10:23:04 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:41 GMT