Re: [OEP] "Classes as values" first draft


> Regarding the approaches covered, I have an additional approach (a 
> variant
> of approach 2) that seems reasonably intuitive to me. So in the current
> document, we define 'LionImage' as an Instance of Class 'AnimalImage' -
> why not make it a subclass of 'AnimalImage' instead? (i.e. define a 
> set of
> all images that have Lion as subject) and instead of having a separate
> subject hierarchy (approach 2, option 2), have an image hierarchy where
> the subjects are restricted accordingly

Yes, interesting example -- I haven't thought of this one. Perhaps, I 
should make it clear in the document that when I talk about LionImage 
individuals, I really mean specific individual images.

I think your suggestion though assumes that each subject can have a 
specific instance, as in the Lion case. While this is true for animal 
subjects, it won't be true for subjects of PhD Theses, for example (you 
can't have an individual instance of Artificial Intelligence). I think 
the subject in the sense of dc:subject is something more general than 
what your example implies. I would say that in your example, the 
specific individual Lion that is shown in the image is not really the 
value of the dc:subject property but rather of some other property like 

I do agree with you though that if we do take your approach we can take 
the advantage of the reasoning as you outlined.

I would be a bit reluctant to add this approach as another approach in 
the note though since it's really more specific to subjects that have 
specific individuals associated with them and uses a somewhat different 
interpretation of subject.

Should we use some other example that doesn't raise this ambiguity in 
the interpretation of subject? Any suggestions? I must admit that I 
started with subjects for PhD Theses (as in Bernard's original example) 
but dropped the idea because putting those subjects in a subclass 
hierarchy is actually questionable: is it correct to say that AI is a 
subclass of CS? I doubt it (even though subclass definition in RDFS is 
given in terms of individuals and there are probably no individuals in 
any of these classes -- they are used just as terminology). I guess I 
am opening a Pandora's box here..... But others have these questions as 
well and we will need to address them at some point (perhaps in a 
different document)

> Also, I'm not entirely clear on the third point of consideration for
> approach 2 - why would creating an instance of class lion be 
> 'inconsistent with the
> interpretation'? If the 'Lion' class is completely defined by what is 
> stated in the document, then maybe
> that holds, however, given that the complete ontology would have other 
> properties of 'Lion' and
> other classes that point to it, why would I need a separate Lion class 
> to
> represent a specific lion at a zoo?

It's hard for me to imagine a reasonable set of restriction of a class 
Lion that would allow a subject Lion (something that is used purely as 
a term and doesn't have paws and doesn't refer to a specific roaring 
creature) and specific lions at the zoo to be its instances at the same 

> Finally, maybe we should mention somewhere in the document that using
> 'allValuesFrom' restriction on property 'dc:subject' in the cases shown
> ensures that an 'AnimalImage' can only have its subject as 'Animal'
> and nothing else..hmm, makes me wonder if someValues is a better 
> option -
> since it covers photos where we need to describe something more than 
> just
> the animals in it (such as surroundings etc) - which would typically 
> be the case?

The implication of someValuesFrom vs allValuesFrom is probably out of 
scope of this document, but should probably be addressed in some other 
note. People are often confused by it (and there is a current thread on 
the protege-owl mailing list [1] followed by [2] on exactly that 
subject) and we will help others by producing something here. Probably 
under a later Education TF rather that OEP. I will add a footnote to 
the document to point this out.



Received on Monday, 19 April 2004 15:52:34 UTC