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

Received on Monday, 15 February 2010 20:45:56 UTC