Re: Close to final draft of "classes as values" note

Pat,

> Comments and suggested changes added to the version at
>
> http://www.ihmc.us/users/phayes/ClassesAsValues-v3-pat.html
>

Thanks a lot again. I agree with most of your comments, and here are 
some thoughts and questions. The comments below are in the order that 
they appear in the document.

The document says:

[[
When and how to use classes as values for properties?
]]

And you point out:

> Why only values? Why not as having properties applied to them i.e. 
> more generally as individuals?

Because it is a different document. You can certainly treat the issue 
of classes as property values and the more general issue of metaclasses 
in one document, but I think that would complicate and muddle the 
former issue. I am somewhat guided by the types of questions that users 
ask on the protege mailing lists and the question "I need to use 
classes as property values but need to stay in OWL DL" comes up all the 
time. The majority of those asking teh question don't seem to care 
about the more general issue and will probably appreciate a 
(relatively) short note answering their specific question.

that said, a note on having properties applied to classes as 
individuals would make for an excellent separate note under the 
auspices of OEP. If someone else is interested, I could collaborate on 
such a note.

Under "Other Use Case Scenarios", you say:
>
> Terminology?? This reads oddly to me, and seems on a tangent. The 
> classes as individuals issue arises in many cases which have nothing 
> particularly to do with terminology.

It does, but this seems to be one of the more common cases. I would 
certainly welcome suggestions on other common scenarios. It just to 
give readers some feel for where this can be relevant.

I agree that in most examples "BookAboutAnimals" plays no role in the 
example. I replaced it with Book (just to have some type -- I hope 
that's ok). I kept BookAboutAnimals in considerations and examples 
since defining range there is an issue and an example of how to do it 
might be helpful.

What is your objection to saying that Approach 1 is "in OWL Full, but 
not in OWL DL"? You've taken out "in OWL Full, but". What's wrong with 
having it there?

I think our main disagreement is on Approach 2. Basically, to me 
approaches 2 through 5 are workarounds to stay in DL. With that in 
mind, the only relationship between LionSubject and Lion that you can 
use is indeed rdf:type Whether that is inconsistent with interpretation 
of a lion class as a class of things with claws that roar or whether we 
are simply creating an unusual instance of this class -- I don't know. 
But to me this approach is certainly different from 4, where your class 
of lions really is a class of those roaring creatures. Another 
difference with approach 4 is that here we create this "prototypical" 
for lack of a better word representative, call it a subject and refer 
to it explicitly. In approach 4 we say that the book is about some 
lions, which may extend to all lions that have ever lived. I do see 
your point though, and one can view the two solutions as very similar 
though, although at this point I am not at all convinced (but can be).

On approach 3 -- why is this an afterthought? If you want to stay in 
the DL case, that's a perfectly legal approach, with its drawbacks, of 
course. And I know at least some people who would opt for this approach 
(or in fact, the last one -- the one that uses annotation properties) 
if they must stay within OWL DL. Sure it doesn't use classes as values 
-- it can't if it is to stay in OWL DL -- but it's a workaround for 
that problem. I'd rather be non-judgmental and leave it there for 
people to look at the trade-offs and decide for themselves. The same 
goes for approach 5.

Your question on whether DL reasoners will be able to infer the 
transitive relationship between subjects in approach 3 (bullet 2) is a 
good one. Come to think of it -- I am not sure. Any DL gurus out there? 
Alan?

Your comment on the last bullet of approach 4 (why these techniques are 
not a problem in previous cases): In previous cases, we don't need to 
create the classes essentially to parallel the subject hierarchy to 
introduce the existential restrictions. Note that approach 4 doesn't by 
itself require it, but will often result in something like this.

On Approach 5, I would argue that it is just as valid as the others,, 
depending on what your requirements are. For instance, if you are 
willing to let a DL reasoner to "overlook" the subjects but want them 
to be happy with the rest of your ontology and work on it, why not use 
this approach? As long as DL reasoners refuse to take on ontologies in 
OWL Full (and I think they do now), moving things to annotation 
properties is a valid solution.

Comments?

Thanks a million again for a careful read and constructive suggestions!

Natasha

Received on Wednesday, 19 May 2004 22:31:14 UTC