Let me add my congratulations to the others on an excellent document.  I don't quite agree, but it lays out the options clearly enough to understand why I disagree and with what  - a high compliment.

As usual I might come in from a slightly different angle.

My first question when presented with any KR question is "What are you trying to say".

The  use case is

"We want to be able to say that an image of a Lion is also an image of a Mammal"

My italics and boldface of the indefinite articles 'a'.

We are NOT saying that this is a picture of the "species Lion" or the "class Lion."

Therefore, I would argue that the option, within OWL, that best match this transliteration in OWL is (Ia) below which is really a variant of your version 2, except that it uses A-Box expressions.

(Ia)  Express with someValuesFrom.
What we would like to say:

    LionImage dc:subject someValuesFrom Lion.

However, that's not something one can say in OWL.

What we can say is

    LionImage rdf:type  (Image and restriction(someValuesFrom dc:subject someValuesFrom Lion))

Actually 'Image' is irrelevant as a resource can be a type of two things, so assuming we already know that

    LionImage rdf:type Image,

then all we need to say is
    LionImage rdf:type restriction(someValuesFrom dc:subject someValuesFrom Lion))  (1)

That may run into problems with the range of dc:subject and using dc:subject in OWL,
so it may need an adapted property, call it "owlDc:subject" with an appropriate range.   (As I understand it, dc:subject is a string from a controlled vocabulary.  If wrong, please correct me.)

(I am assuming here "Lion" is short for the appropriate full URI reference)

Leaving the above details in parentheses aside, expression  (1) captures literally

    "LionImage is an 'Image about a Lion'"

as opposed to

    "LionImage is about 'the concept Lion'".

That's still on the edge of OWL-Full because it is an abox expression,
but the semantics capture the indefinite pronoun correctly.


Almost the same as above but produce a Skolem[1] constant for the existential quantifier.   I think that is Natasha's version II.  It has the disadvantages she describes which stem from the underspecification of the Skolem constant "LionSubject".   However, it is the case that the LionSubject is an instance of Mammal, Animal etc.  You still have to pay attention to the class rather than the other Skolem constants. However, in the context of OWL this is messy.

[1] In case people aren't familiar with the term, this is as good an example as any.  It refers to the  is the mechanism used by Logic Programming and related formalisms to cope with eliminate existential quantifiers by generating  anonymous individuals in place of the existential statement.

Version (1) in Natasha's paper translates literally as the picture referring to the class Lion - in the same way as the cladistics for recognising Lions or a statement about whether or not Lions were endangered, who had first described them, etc.  The picture is not of a concept of a lion but of an example of a Lion - i.e. of an instance of Lion.  Theoretically, you could retranslate this as saying that it was a picture of a "prototypical Lion" - but OWL makes no provisions for prototypes.

I would argue that versions three and four have serious disadvantages that outweigh their disadvantages and won't discuss them further here.

However, I would put forward a version (5) if only to rule it out, that Lion exists in one ontology completely distinct from the image which is being annotated.  The annotation is in RDF and points to the Lion, but it does not add to the ontology - indeed it says nothing about the concept Lion.  Were we to recommend it, it requires that somewhere we capture the semantics that we mean "a Lion" rather than "the class Lion".  That would require annotation properties or other "epicycles".  I think this is much clearer if we stick to variants of (I).

I hope this is clear.

In short, it is essential that we distinguish between

a) referring to a class as a value

b) referring to an arbitrary instance of a class as a value
    another way to put b) is to say
   referring to the existence of an unspecified instance of a class as a value.

The use case clearly indicates b) rather than a).  Hence the recommendation of either a version with someValuesFrom or a Skolem constant.



Natasha Noy wrote:


At the last telecon, I took an action to produce a draft note on
dealing with the issue of classes as property values. My first pass
at it is at

This is a strawman, so please feel free to and do poke holes in it! I
think the goal here is really two-fold: (1) to give some suggestions
on how to deal with  the specific issue (classes as values) and (2)
to figure out what the general format and tone of such notes and
patterns should be. (The second one being arguably more important at
this point)

I have shamelessly lifted most of the ideas from the discussion on
the mailing list a couple of weeks ago. So, thanks to everyone who
participated in that discussion. I would also like to thank Oscar for
his comments on an earlier draft.


Alan L Rector
Professor of Medical Informatics
Department of Computer Science
University of Manchester
Manchester M13 9PL, UK
TEL: +44-161-275-6188/6149/7183
FAX: +44-161-275-6236/6204
Room: 2.88a, Kilburn Building