W3C home > Mailing lists > Public > public-swbp-wg@w3.org > May 2004

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

From: Natasha Noy <noy@SMI.Stanford.EDU>
Date: Thu, 13 May 2004 17:42:20 -0700
Message-Id: <8EFAC9CA-A53F-11D8-93C6-000A958B5C28@smi.stanford.edu>
Cc: swbp <public-swbp-wg@w3.org>
To: "McBride, Brian" <brian.mcbride@hp.com>


here is my take on the rest of the comments in your email.

> I note that rdf/xml-abbrev examples are not being served with the RDF
> mimetype.  Is this fixable?

I have no idea what this means, but I suppose the answer is "yes", if 
you tell me how.

> Approach 2 confuses me.  It seems to say that a LionSubject is of type 
> lion,
> which I interpret to mean it's the sort of individual with claws that I
> don't want to meet close up when its hungry.

That's one interpretation. If I don't care for lions with claws, but 
have this sticky issue of having to be in OWL DL, I may define my class 
Lion as essentially a singleton, containing exactly one instance: 
LionSubject. This class has nothing to do with the class of Lions with 

I am not a big fan of this solution, but I've seen it often as a 
workaround for staying in OWL DL, and felt that it was necessary to 
bring it up, if only to discuss the trade-offs. I was hoping that the 
points in the "consideration" section make the trade-off clear. 
Perhaps, not quite.

> Approach 3:  There is presumably a relation between LionSubject and 
> Lion.
> Do we have any vocabulary to describe it?

We may or may not, depending on a particular application and domain. On 
second thought, perhaps adding rdfs:seeAlso to instances of Subject 
pointing to the classes in the hierarchy would make sense?

> Approach 4 looks like we are back to RDFS.  Again, the Owl stuff is 
> needed
> for defining classes such as BookAboutLions, but that seems to me to be
> beyond the point of the note - which I may be missing.  Do you really 
> mean
> that you are using a specific instance of the class as the value of the
> dc:subject property, i.e. you have to give it a URI, or are you using a
> b-node - in which case its inaccurate to say that you are using a 
> member of
> the class - you are using an existential variable.

what's a b-node?

>  Looking at the n3 code
> for this approach, there is no dc:subject property on the examples so I
> can't tell.

Exactly, there isn't: they are instances of a class where the value of 
dc:subject is some lion, but something we can't identify or give a URI 
to. Again, it's an approximation of a solution, but one that many 
people use.

> Approach 5 looks like a minor variation on approach 1.  Given that it
> doesn't really let one take advantage of Owl DL reasoning, I'd suggest 
> it be
> presented as such, i.e. you can make approach 1 syntactically 
> compatible
> with Owl DL, but the cost of losing the subsumption reasoning.  In rare
> cases this might be useful.

Isn't that what the last bullet point says? (And, yes, it may be useful 
if you are not going to use DL reasoners, but for one reason or another 
your ontology must check as OWL DL. One possible example is when you 
want to use DL reasoning on the rest of your ontology: many (all?) 
classifiers would reject an OWL Full ontology and not perform any 
reasoning at all. So, "faking" it with annotation properties can make 
sense in this situation.

> I don't have time to check more examples.  The one I have looked at 
> seems
> incomplete.

Could you be more specific?

>   I wonder about separating ontology examples from instance
> examples.

I am not sure what you mean here.

> When this document is described as nearly final, do we mean ready for 
> wider
> review, or do we mean final final?

Well, my view on this is that it is not going to be "final final" until 
we have more of these specific notes and write some introductory 
document/FAQ for them as the result of the TF work. As we are writing 
that document, we may find it necessary to update individual notes.

I thought the idea was to put something out to have people comment on 
it (and use it, in fact).

Received on Thursday, 13 May 2004 20:43:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:38 UTC