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

> 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.

I agree. I'll expand the reference to the medical terminologies in the 
"other use case scenarios" section, to include the information above.

>> [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.

Good.

>>> 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
> yourself.
>
> [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.

On a second though, I am still not sure. I think your wording dilutes 
the point (even though ultimately conveys the same information). The 
important point is _not_ that it is compatible with OWL Full, but 
rather that it is compatible with OWL DL.

>>
>>> 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.
>
>
>>> 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?

Yes, it would be good to point this out. Will do.

Natasha

Received on Friday, 4 March 2005 19:39:17 UTC