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

> Maybe it
> would almost have taken you less time to just re-write the document :)
> I've posted a new draft in the location referred by Editor's draft on
> the OEP page [1]
>
> [MFU] the link below is broken, I found it from the OEP page.

Sorry -- that's the problem with my  mailer that breaks up long urls.

>> Also, it would be good for the figures to better reflect the
>> similarities and differences between the different approaches. For
>> example, approaches 1 and 5 are virtually identical. This should be
>> evident in the figures as follows: if you had two powerpoint slides
>> and showed one right after the other, the only thing the viewer should
>> see that is different is:
>> 	1.	the addition of the annotationProperty class with links
>> from the dc:subject arrows
>> 	2.	the arrow for dc:subject turned green
>> Everything else should be exactly aligned.
>
> I fixed this where I could. In some cases, trying to conform to this
> idea makes the diagrams either too strange or too cluttered. If you'd
> like to take a stab at this, please, go ahead.
>
> [MFU] Fair point. I may have over-constrained the problem. There will 
> be tradeoffs. It is a realtively minor enhnacement, which might be a 
> lot of work.  What format did you edit the diagrams in? I don't want 
> to start from scratch. If the originals were in, sa powerpoint, then I 
> could fiddle around spending minimal amounts of time.
>

You will have to start from scratch, unfortunately, if you want to 
tinker with  them -- I was using a mac-specific tool.

>
>> stray quote in: "behavior of the" African lions"
>
> Doesn't look stray to me.
>
> [MFU] Strictly, I now see that you are right. It looks a bit odd, but 
> seems correct. Does it really need to be quoted? This is a 
> femto-point.

It's a quite from the book abstract, so I guess it has to be in 
quotation marks

>> OTHER USE CASE SCENARIOS
>> 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] 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.

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

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

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

>> APPROACH 3
>> Overall, this approach is very clearly described.
>>
>> This approach assumes that there is a subject hierarchy. Is that true?
>> Is there a more general view that is not subject-specific? Can it be
>> generalized? Or do we bite the bullet and say this note IS about
>> representing subject hierarchies.
>
> No, it is not about subjects. Subjects are used as an example. Consider
> genre for annotating CDs, diseases for annotating clinical guidelines,
> others under the "Other use cases" section.
>
> [MFU] OK  I'm starting to believe you (maybe). So the classes are 
> genre, say Jazz, HardRock, etc. So you have a hierarchy of these 
> categories, and represent them as classes. What what is an instance of 
> 'Jazz'?  If you say it is a jazz cd, then you don't need classes as 
> values, you just classify the CD's dirctly as instances in the 
> hierarchy. I don't see this as an example where you are likely to want 
> classes as values. Am I missing something? Even if this is a good 
> example that you can elaborate on and convince me, it is not 
> sufficient to convince the reader in the current state. Such 
> elaboration would be necessary.

see above.

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

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

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

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

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

>> APPROACH 4
>> I found that this example was hard to grasp. Focusing on "unspecified
>> members of a class" seems very obscure, and must be missing the main
>> point, which is ??? - I'm not sure.  The main thing seems to be that
>> the
>> actual value that the property dc:subject has is an [implicit]
>> unidentified instance of the class Lion and that the relationship of
>> this [nonexistent implicit] value to the class Lion is rdf:type.  This
>> is IMHO, rather obscure and many are likely to have little idea what
>> you
>> are talking about. The main problem is that the instance DOES NOT
>> EXIST,
>> so it needs to be explained differently. You might at the end mention
>> that this representation approach corresponds to there being an
>> implicit
>> instance, but otherwise it is likely to be far to confusing.
>
> I was first tempted to change the title of the approach to include
> "implicit". But then I am not sure "implicit" is the right word here.
> We don't actually know if the instance exists or not. All we are saying
> is that for a book about lions, one value for the subject property will
> be an instance of Lion. This is enough to classify it, but we don't
> actually say anything about whether or not this instance exists and is
> named, etc..
>
> [MFU] another name to think of...

I am open to suggestions

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

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

>
>> [before the Alternatively clause, put this text in:]
>> By saying that LionsLifeInThePrideBook  is an instance of
>> BookAboutLions we are saying that it is a member of a class, all of
>> whose members have as their subject, at least one instance of the
>> class Lion. [this text might need fixed so it is strictly and
>> literally true, I might have a misreading of someValuesFrom, all the
>> more reason that these examples need English every time.]  In OWL, it
>> is not necessary to create any explicit instances of these classes.
>> In the figure, we list them as if the were explicit, and use dotted
>> lines to denote that they may not actually exist.
>
> Added - thanks! I haven't followed the rest of your suggestion here,
> since I thought it was just reiterating the point once again, perhaps
> making it a bit more confusing.
>
> [MFU] See what you think with my forthcoming new draft of this 
> approach.
>
sure.

Natasha

Received on Thursday, 3 March 2005 23:33:17 UTC