Re: Issue: Add hasValue to OWL Lite

At 6:19 PM +0000 12/11/02, Jeremy Carroll wrote:
>>Sorry Ian, but all I've seen from you is pointers to work about 
>>computational complexity -- and I just don't see that as a 
>>compelling reason not to include an easy to implement, important 
>>feature that our users are requesting.
>>
>
>
>
>A test case:
>
>s subclassof <rest onProperty p, hasValue x>
>owl:Thing subclassof s
>q type owl:ObjectProperty
>p type owl:InverseFunctionalProperty
>
>entails
>
>q type owl:TransitiveProperty.
>
>(Reason let a and b be two members of owl:Thing,
>then a and b are both of type s, hence
>
>a p x
>b p x
>
>hence
>
>a sameInstanceAs b
>
>i.e. the universe has cardinality 1).
>Hence q is either the empty property or the complete property, and 
>is transitive.
>
>Parka doesn't do this (I assert without looking ...)

wrong, this is exactly the sort of thing Parka did right - the 
inversefunctional property is a key, and the database handles this 
just fine - or I should say "sort of"

What we are not able to do is the full class reasoning (parka mainly 
reasons about instances) - so in this case the Parka query 
corresponding to the above would only pull out instances where a and 
b were the same, and the algorithm would be enforcing that in a join. 
Parka had no mechanism by which it could be explicitely queried for 
sameInstanceIs, but it is not hasValue that causes any sort of 
problem.

Parka is not complete for OWL Lite, but one of the things in Owl Lite 
it does right is hasValue.  That is where my claim that this is an 
easy function comes from.

Nere's my compelling use case for why we need hasValue in OWL Lite.
The National Cancer Institute vocabulary that they want to release in 
OWL, and they've made it clar they'd like to be in Owl Lite if at all 
possible (because their assumption is same as ours - it will be 
easier for them to implement).  They have a class called an 
"OncoGene" and then they use restricted subclasses for particular 
genes.  The definer of those subclasses is that a particular value is 
set to a particular value
  i.e. the oncogene is MYR if the associatedGene is 8q24
and they are happy to have iff semantics associated.


In short - there's two claims I am questioning:
  1 - that hasValue is hard to implement
  2 - that Owl Lite including hasValue is MORE complex to implement 
than the current OWL Lite (without hasValue)

I don't believe the first, and I've seen no evidence of the second 
(in fact see my question below) -- if adding this doesn't INCREASE 
the complexity (theoretical or implementational) vs. some features we 
already have in there, than I see no argument against adding it.


>
>Using similar techniques the cardinality of the universe can be 
>fixed as any finite number, and then complex reasoning about 
>properties in finite sets is needed to work out which properties are 
>transitive, symmetric etc.
>
>Jeremy

Question - I may be misunderstanding some of the OWL semantics, but 
if I say that something is restricted to be an owl:oneOf (which is in 
Lite), and then only give the list a single element - isn't that the 
same as doing a hasValue?  If we can already do that in Lite, why 
adding hasValue be worse?

that is, doesn't the follow hold:

s subclassof <rest onProperty p, OneOf (x)> )
owl:Thing subclassof s
q type owl:ObjectProperty
p type owl:InverseFunctionalProperty

entails

q type owl:TransitiveProperty.

(Reason let a and b be two members of owl:Thing,
then a and b are both of type s, hence

a p x
b p x

hence

a sameInstanceAs b


-- 
Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)
http://www.cs.umd.edu/users/hendler

Received on Wednesday, 11 December 2002 14:54:24 UTC