RE: [OEP] Classes as Values - A detailed review

More inline comments... Things more or less resolved are snipped.


-----Original Message-----
From: Natasha Noy [] 
Sent: Thursday, March 03, 2005 3:33 PM
To: Uschold, Michael F
Subject: Re: [OEP] Classes as Values - A detailed review

>> This is very important, I suggest making this more prominent somehow,
>> as it is, it could easily be missed, especially since approach 2
>> refers to a hierarchy of subjects anyway (see also comments under
>> Approach 2 below).
> Any suggestions on how to do this?
> [MFU] The whole note and all the examples talk about subjects, and 
> then you have a paragraph buried that says the note is not really 
> about subjects. A way to help would be to use include some examples 
> (if not full code, then at least in text) that do NOT refer to subject 
> at all.  It would also help to mention it several times for emphasis. 
> But even so, you can say over and over "This note not just about 
> subject, it is more generally about classes as values". But frankly, 
> after going over this note in great detail, I DON'T REALLY BELIEVE 
> YOU. The note IS about subject, every single example (that I noticed) 
> is about subject. Can you convince me of otherwise?

I still don't get your point. For pedagogical purposes, it makes sense 
to use the same example throughout, hence the note uses subject. Now, 
suppose you have a hierarchy of musical genre. These genre are classes. 
You want to annotate CDs in your collection, adding a "genre" property. 
You have exactly the same problem. Another domain: in medicine, you 
have a controlled vocabulary of diseases (basically, a simple hierarchy 
of classes). You have an instance of patient-visit and want to put 
diagnosis in there. Without going in the discussion of whether 
meningitis is a class or an instance, and assuming that you have to put 
in a class from that controlled terminology so that you can bill your 
insurance correctly, isn't this an identical problem? Are you any more 
convinced now?

[MFU] well, actually YES. Good job! The medical example convinces me[aside: im still unconvinced by the music example, but that is partilly moot now] 
I think it would be good to add this example to the other scenarios paragraph so the reader has a clear example that has nothing to do with subjects, or anything vaguely similar to subjects.

> [MFU] Fair enough. It might be worth putting somewhere, in a place 
> applicable to many notes, that we use the convention of using singular 
> for classes; as well as any naming conventions in general? Are there 
> any that we want to talk about?

So, we should probably have this one place where we put the vocabulary, 
the diagramming conventions, and, say, naming conventions. Then notes 
can point there.

[MFU] Yes. Chris and I also talked about teasing out some of the criteria that are discussed in the considerations section and applying them to ALL the patterns notes. e.g. degree of semantic overloading, need for interoperability, maintainability, etc. This could go in an uber-meta-note that applied to all the notes.

>> You don't say whether this is OWL-DL or OWL-Lite.
> What does "it" refer to here?
> [MFU] I don't see an "it" anywhere you must mean the "this" :). I mean 
> to say that you don't say whether approach 1 is in OWL-Lite or just 

It's OWL Full, and the first bullet says that it is outside OWL DL or 
OWL Lite. Am I missing something here?

[MFU] ONE of us is... Its ME. Must have been sleeping when I wrote this comment... Sorry, please ignore.

>> Minor point: you say
>> "The resulting ontology is compatible with RDF Schema and OWL Lite
>> (and hence OWL DL)" I had to think for a moment about the hence
>> clause, it seemed backwards at first, but then I saw it was correct.
>> For this audience, it might be better to keep it simple. It is also
>> compatible with OWL-Full, which you do not mention. I suggest
>> rewording to:
>> "The resulting ontology is compatible with RDF Schema and all variants
>> of OWL (Full, DL, and Lite)."
>> It is not germane to this discussion that:
>> IF it is compatible with OWL-Lite,
>> THEN it is compatible with OWL-DL.
>> If you wish to give the reader this information, make it a separate
>> comment or footnote.  It would really belong in a discussion with the
>> definition of 'compatible' which is a blue term targeted for a
>> glossary definition.
> I am not sure I agree. The key point here is that, unlike the previous
> approach, it *is*compatible with OWL DL and OWL Lite
> [MFU] Precisely, which is exactly what my rewording says. I think it 
> is sufficient. I don't think making the above IF/THEN point is  
> necessary here.

Agreed -- you have the lock at the moment, so you'll have to put it in 

[MFU] oops, I forgot to do this in the revision I just sent you. 
Make a note of it, and I will do it if not done by you next time I have a go.

>> Remove last word in: "We can create a single class Subject and make
>> all the subjects to be individuals that are instances of this class
>> Subject"
> Why?
> [MFU] It is redundant, the meaning is totally clear from context.

Whatever. It's not a serious point. It's difference in writing style.

[MFU] True on both counts

>> Might: "using individuals as surrogates for classes" be a better name
>> for this approach? The current one may be too specific?
> I don't know. Is it?
> [MFU] Chris is going to help think of some better names, I will give 
> that some thought too.

go for it!

[MFU] stay tuned.

>> If the DL reasoner cannot infer that "a book that has LionSubject as
>> the value for dc:subject is also about Animals" then what is the point
>> of mentioning that "Most DL reasoners will be able to infer transitive
>> relations between subjects". Is this useful by itself?  If so, can it
>> be
>> factored into the requirements/criteria for evaluating the different
>> approaches?
>  Yes, if/when the document is refactored.
> [MFU] Is it useful by itself? I don't get it. Suggest either skip that 
> comment, or elaborate on it more.

I don't think you can factor it out because it is germane to this 
particular approach since you are putting subjects into a separate 
hierarchy. Thus, you want to preserve reasoning similar to what you 
have in a class hierarchy: essentially any tool supports transitivity 
in class hierarchies, support for transitivity of properties is 
slightly less pervasive. Thus the comment.

[MFU] I'm not seeing the import, but it probably is minor enough to drop.

>> What is the import of this: "The resulting hierarchy of subjects is
>> not related to or dependent on the class hierarchy representing the
>> same topics (in this case, animals), except through an annotation
>> property rdfs:seeAlso."  Is it good? helpful? Why? Relate it to one of
>> the evaluation criteria.
> It depends on the requirements for your application. As it stands, it's
> just a fact.
> [MFU] I was trying to understand why you chose this particular fact to 
> include here. Can you say more about when/why a user might need to 
> know about this. What kind of application would this be good/bad for?

It seems to be a salient consideration for the approach -- something to 
keep in mind. For instance, if the original hierarchy is going to be 
updated often, if it is important for you to stay true to it, etc. It 
seemed an important enough consideration to be left out -- it's 
directly related to the approach.

[MFU] I guess you meant "left IN". Anyway, I see your point.

>> What is the import of this consideration:
>> "This approach explicitly separates the subject terminology from the
>> corresponding ontology. Many consider this separation a good modeling
>> practice: the semantics of a subject Lion can be different from the
>> semantics of the class of lions. Having subjects in a separate
>> hierarchy, would allow us to define for example that the subject
>> Africa is a parent subject of the subject AfricanLion." Relate to one
>> or more evaluation criteria, does it relate to supporting a desirable
>> inference? does it impact on maintenance?
> Again, depends on your requirements and application.
> [MFU] Again, it would be good if this could be related explicitly to 
> something that would matter to some users.

Medical terminologies are one example -- see above.

[MFU] I don't see any medical examples that elucidate the need for keeping the subject terminology from the corresonding ontology. Am I missing something?  The medical example was one which had nothing to do with subjects.

>> Specifically, there is nothing corresponding to the following (from
>> approach 2) :AfricanLionBook
>>       a       :BookAboutAnimals ;
>>       dc:subject :AfricanLionSubject .
>> If there was, it would be:
>> :AfricanLionBook
>>       a       :BookAboutAnimals ;
>>       dc:subject :UnidentifiedAfricanLion .
> There won't be: we describe AfricanLionBook as a book where at least
> one subject is an instance of Lion (regardless of what else we know
> about that instance)
> [MFU] Precisely my point, the description does not make this very 
> clear. I will gladly re-draft this section, and you can see what you 
> think of it.

go ahead.

[MFU] Done.

>> This approach is designed to make it easy to leverage a DL reasoner to
>> infer, for example that a book whose subject is Lion also as subject
>> Animal. In this approach, we create a parallel hierarchy of types of
>> books consisting of classes such as: BookAboutAnimals, BookAboutLions,
>> BookAboutAfricanLions. We then say that various instances of Books are
>> explicit members of one or more of these subject classes.
> Actually, here we don't need to create a full parallel hierarchy:
> technically, we create only for the classes that have a book with this
> subject there. Thus, if we have no books about African Lions, we don't
> need to create the class, we can always do it on demand. This is not
> quite true for the subjects themselves in previous approaches.
> [MFU] True, my wording is not quite right, it is close though... in 
> that there is a parallel hierarchy that emerges as the user creates 
> explicit classes.  If they choose the variant of using anonymous 
> classes, then it does not exist at all. That is one reason I wanted to 
> separate out more clearly that variant.

Actually, it's still exists, and will be inferred by a classifier in 
both cases.

[MFU] My rewording fixes the error about a parallel hierarchy. I do not point out that a parallel hierarchy would be induced via inference, which is interesting. Perhaps add as a consideration?


Received on Friday, 4 March 2005 04:46:04 UTC