RE: [OEP] Comments on Specified Values Note

None of the comments are substantive. Most are simple rewordings of
sentences. In one or two places, I suggest a rewrite of a paragraph,
adding a bit more explanation.  Individually, most changes are very
minor; collectively, I hope that making the changes will help fine tune
the document.


Mike


-----Original Message-----
From: Alan Rector [mailto:rector@cs.man.ac.uk] 
Sent: Sunday, March 06, 2005 11:35 PM
To: Uschold, Michael F; best-practice
Subject: Re: [OEP] Comments on Specified Values Note


Mike

If you pick up the latest version as circulated on Sat AM our time, the
diagrams are improved. I just didn't have access to the better tools
during the few days running up to and during the major event we were
putting on.

Regards

Alan

PS - I'll look at the later comments later.  My guess is that what we
should do is issue a working draft, and update the draft if the comments
are substantive.

Regards

Alan

"Uschold, Michael F" wrote:

> GENERAL comments
> Are you going to redo [some of] the figures using a nicer tool? Some 
> of the text is literally undreadable on my 1600x1200 laptop screen.  
> Contentwise, they are fine. Perhaps Natasha and her MAC-only 
> diagramming tool has set too high a standard - I'm now spoiled :-) .
>
> Below are a bunch of highly specific recommended changes, most are 
> very minor to do with fine tuning.  In a few places, I have added a 
> bit more detail.  You may disagree with some, due to different writing

> styles. Take what you like, and leave the rest.
>
> It would have been easier and faster to edit the file directly, but I 
> did not want to edit a non-latest version, in case you are also 
> working on it still. Also, it  makes it easy for you see exactly what 
> my suggestions are, and ignore the ones you don't agree with.
>
> NB: I did not check any of the referenced full code examples. Has 
> someone else done that?
>
> Do we want to have this and Natasha's note use the same naming 
> conventions? You use underscore to separate names. In one sense, it is

> a good idea to use different conventions, showing that this is real
life. It could also be confusing for folk reading more than one of our
notes.  This is a general question for the OEP TF.  I lean towards a
consistent naming convention, it would even make sense to say exactly
what it is. Also, we should point out that we are nto recommending this
as the right one, just one among variuos that work just fine. SPECIFIC
comments
> Abstract:
> Replace "officers and restricted" with "officers and be restricted"
> ---
>
> Replace "specifies the constraints on the values that the property can

> take on" with "specifies what values the property can take on"
> ---
>
> Replace "methods to represent" with "methods for representing"
> OR: replace "methods" with "ways". IMHO: 'way' is preferred, since you

> use that phrase later: "There are at least three different ways to
represent such specified collections of values"
> ---
>
> GENERAL ISSUE
> Replace "health person."   with "healthy person."
> ---
>
> You say:
> "It is a common requirement in developing ontologies to be able to 
> represent notions such as a "small man", a "high ranking officer" or a

> "health person."  There are many such "features"..."
>
> "health person" should be "healthy person". More substantively,
>
> This wording suggests that 'small man' is a feature. Is this what you 
> mean?  Later you say: "it is necessary to specify the constraints on
the values for the "feature" - e.g. that size may be "small", " This
suggests the feature is 'size'. Its the difference between the property
itself (size) and a property=value assertion (size=small).  I don't know
what you mean. I'm not sure whetehr you want to gloss over this
distinction here (with carful wording), or whether it is worth making.
As it stands, it is a bit confusing.
> ---
>
> Replace:
> *  As individuals whose enumeration makes up the parent class
representing the feature;   (See pattern 1).
>
> with:
> *  As an enumerated set [or list?] of individuals (e.g. small, medium,
large) which makes up the parent class representing the feature;   (See
pattern 1).
>
> Also, add an example to the next bullet like I did for this one.
>
> ALSO: in the phrase "representing the feature"I can't figure out which
meaning of feature you are using (size? size=large?). It seems neither.
Rather it seems to be referring to the value set of the the property
size.   Frankly, I don't know what the phrase: "the parent class
representing the feature"means. Parent of what? Do you mean "the set of
all possible values that the feature(e.g. size) can have"? This is the
feature space, which you define later. What does parent have to do with
this?
> ---
>
> Because of this terminology confusion, I think you need to either:
>         1.      move the vocabulary section much earlier in the
document.
>         2.      include a forward reference to the vocabulary section
very early in the document.
> I prefer 1.
> ---
>
> USE CASE EXAMPLES:
>
> Replace "e.g. it should be inconsistent (unsatisfiable) to be both 
> slender and obese or in good health and poor health" with
>
> "e.g. an inference engine will flag an error if an individual is 
> declared to be both slender and obese or in good health and in poor 
> health" I replaced the theorem proving lingo with everyday language to
convey the point.
> ---
>
> Replace: "The others follow analogously." with "The solutions for the 
> other examples are exactly analogous."
> ---
>
> NOTE CONVENTIONS
>
> Much of this section could also go in an appendix. I don't have a 
> preference, works ok either way. Your call.  Ideally this will be 
> pulled out and used by more than one note.
>
> I suggest adding a formal TODO on this point. See also my note to the 
> list on this.
> ---
>
> I would put the vocabulary first, in the conventions section, it is 
> more important. In fact, it might be better to put the vocabulary in 
> the very beginning, because you use the terms right away.
>
> Also, put partition last, as it is less important (as a bonus, it 
> would also be in alpha order...)
> ---
>
> Diagramming:
> I still don't know what an open  or closed arrow means.  It is not 
> obvious to me by looking at the different arrows. Perhaps you mean the
shape of the arrowhead? The terms open and closed dont convey that to
me. Is this a standard terminology for arrows that I am not familiar
with?
> ---
>
> 'arrowsor' and 'arrowsindicate'need spaces to separate words.
> ---
>
> In: "*  Downwards facing braces are used to indicate pairwise 
> disjointness between subclasses or owl:allDifferent for individuals. 
> (All sibling classes are disjoint and all individuals of each type are

> different in these examples.)"
>
> What is the owl symbol if the pairwise disjointness is between 
> classes? Does it ever appear in a diagram? You might address this 
> something like as follows:
>
> Downwards facing braces are used to indicate pairwise disjointness 
> between subclasses or between individuals. These are represented in 
> OWL as owl:?? and allDifferent respectively. (All sibling classes are 
> disjoint and all individuals of each type are different in these 
> examples.)"
>
> This might be an incorrect wording for what you are trying to say.
> ---
>
> "SWBP" --> "SWBPD"  (tut tut)
> ---
>
> Pattern 1:
>
> To focus on the postive first, replace:
> "The second is more complex but is more flexible.  Some classifiers 
> also work more reliably with Pattern 2 than Pattern 1."
>
> with
>
> "The second pattern is more flexible, and some classifiers work more 
> reliably with it than with Pattern 1. However, Pattern 2 is more
complex."
> ---
>
> PATTERN 1:
>
> "In this approach, the class Health_Value is".
>
> Why a definite article? This is first mention of this class. Below I 
> suggest a rewording for this pattern which says what to do in more 
> detail.  I feel that the readers of this note will find it easier to 
> create their own examples if we give more details on exactly what 
> needs to be done, rather than mainlu just describing what is the case,

> once you have the pattern.  Both are needed.
>
> You may think this too wordy... I made similar changes to approach 4 
> in the classes as values note. I notice that you have very nice 
> wording in the comments to this effect when presenting the code, that 
> is excellent.
>
> The sentence: "Values are sets of individuals." is slightly ambiguous.

> 'values' here refers to the feature space, all possible values. But 
> each individual is also a value. I suggest using the term feature 
> space here.
>
> Overall, I suggest the following rewording.
> Replace:
> "In this approach, the class Health_Value is considered as the 
> enumeration of the individuals good_health, medium_health, and 
> poor_health. Values are sets of individuals. To say that "John is is 
> in good health", is to say that "John has the value good_health for 
> health_status" This assumes that a value is just a unique symbol, and 
> a value set is just a a set of such symbols."
>
> with
>
> "In this approach the feature space is represented as an enumerated 
> set of individual values.  The feature of interest is represented as 
> an OWL property (e.g. health_status).  We wish to restrict the range 
> of this property to be one of three values corresponding to good, 
> medium and poor health. To achieve this, we create a class that 
> represents the set of all possible values for the given feature, and 
> we enumerate each value.  This class (e.g. Health_Value)is defined to 
> consist of exactly three enumerated individuals: good_health, 
> medium_health, and poor_health. The name includes the string "_value" 
> to indicate that this class was specifically created for representing 
> values. Each enumerated individual is an instance of the value class.
>
> To say that "John is is in good health", is to say that "John has the 
> value good_health for health_status". For this pattern, a value is
just a unique symbol, and a value class is just a set of such symbols."
> ---
>
> Are the values 'sets' or 'lists' of individuals? Sometimes order DOES 
> matter, so from a common sense perspective, they are not sets
(although, if the order is not formalized, then from a model-theoretic
viewpoint, I guess they are sets). Anyway, be consistent.
> ---
>
> replace:
> {{The value set and make it equal to the enumeration of the three 
> individual values}}
>
> with
>
> {{Create the value class and make it equal to the enumeration of the 
> three individual values}}
> ---
>
> The comment: {{Define each of the individual values as an individual 
> of type Health_value}} should be boldface, like the others. Check for 
> other examples of font inconsistency.
> ---
>
> Replace: "Many people find this the more intuitive approach." with 
> "Many people find this approach very intuitive."  because you have not

> introduced the other pattern yet.
> ---
>
> Replace
> "There is no possibility of further subpartitioning of values." with 
> "There is no possibility of further subpartitioning of values (e.g. 
> good_health into very good and pristine health)."
>
> Replace:
> "It is not possible, as it is for classes, to say that one individual 
> is equivalent to the the union (disjunction) of two other 
> individuals."
>
> with
>
> "It is not possible to say that one individual is equivalent to the 
> the union (disjunction) of two other individuals.  An analogous 
> statement can be made with classes." This may just be style
preference; you may not like it. It is longer, but [possibly] slightly
more accurate.  The problem is, strictly speaking, you cannot, for
classes, "say that one individual is equal to the union of two other
individuals" You CAN say something very analogous.
> ---
>
> Replace
> "Because individuals cannot overlap, if Health_Value is defined as 
> equivalent to enumeration of one list "
>
> with
>
> "Because individuals cannot overlap, if Health_Value is defined as 
> being equivalent to the enumeration of one list "
> ---
>
> Replace
> "To do so would cause the reasoner to indicate a contradiction. (i.e 
> that Health_Value was "unsatisfiable".)"
>
> with
>
> "To do so would cause the reasoner to find a contradiction and flag an

> error."
>
> Unless you really want this theorem-prover speak (is it germane to the

> note?). Whatever you decide, use the same convention throughout, this
occurs in more than one place.
> ---
> The last disadvantage starts off sounding like an advantage.
> Replace:
>
> "The representation is in OWL-DL, and DL reasoners should eventually 
> be expected to make correct inferences with individuals used in this 
> way. However, neither FaCT nor Racer (the two most widespread open 
> source reasoners in use today) perform all the expected inferences 
> reliably. "
>
> with
>
> "Although the representation is in OWL-DL, currently, neither FaCT nor

> Racer (the two most widespread open source reasoners in use today) 
> reliably perform all the expected inferences.  In the future, 
> reasoners will likely be able to make correct inferences with 
> individuals used in this way. "
>
> Or shorten last sentence even more:
> "This limitation will likely go away with improved reasoners.
>
> ---
>
> PATTERN 2:
>
> In the title of this pattern, and in the first sentence, you say 
> 'feature' when I think you mean 'feature space'.
> ---
>
> I don't think the word 'continuous' is accurate because it might not 
> be continuous, it could still be discrete. Or if strictly speaking it
is accuarate, it might be misleading.
> ---
>
> You say: "the Good_health_values partition". The vocabulary definition

> does not define partition as a noun, just as a verb.  You need to
amend the definition if you want to use 'partition' as one of the
mutually disjoint collectively covering subclasses.
> ---
>
> The sentence: "Theoretically, there is an individual health value, 
> Johns_health, but all we know about it is that it lies someplace in
the Good_health_value partition. " will likely confuse people. I had to
puzzle for a while about it, and after reading the code, realized that
these two variants are just like the two variants of approach 4 in the
classes as values note [exactly analogous, I think].  I think it may be
clearer to present pattern 2 here as I [re-]presented approach 4 in the
other note.  That is:  Just describe the first variant as if it is THE
approach. And then say, by the way, there is a minor variant... This
would entail
> 1) removing the sentence: "There are two variants presented: one in
which the individual Johns_health is explicitly represented, the other
in which it is implied by an existential restriction." or moving it to
later, as a summary remark.
> 2) removing the header: "Representation variant 1: Using a fact about
the individual"
> 3) adding an introductory remark for the 2nd variant.
> 4) do something about the Venn diagram. It will need to be moved to
after the variant, or simplified to leave out the restriction. The
restriction is pretty confusing, in that diagram, so I suggest the
latter option. Have every arrow represent an simple instance of the
binary relation: has_health_status.  Maybe add more named individuals?
>
> btw: The 'J' in "Johns_health" is a different font.
> ---
>
> The Healthy_Person class seems an optional, rather than essential part

> of this pattern.  Perhaps this could be indicated?
> ---
>
> Here is a suggested rewrite taking into account the above comments; it

> is modeled after the rewrite for pattern 1.  I also emphasize what is
similar and different about this pattern and the first.
> Replace:
> "In this approach we consider the feature as a class representing a
continuous space that is partitioned by the values in the collection of
values. To say that "John is in good health" is to say that his health
is inside the Good_health_values partition of the Health_value feature.
Theoretically, there is an individual health value, Johns_health, but
all we know about it is that it lies someplace in the Good_health_value
partition. The cass Healthy_Person is the class of all those persons who
have a health in the Good_health_value partition."
> with
> ===
> "In this approach, the feature space is represented as a value class
partitioned by a group of subclasses (e.g. Good_health_value
Poor_health_value).  As for pattern 1, we represent the feature of
interest (has_health_status) as an OWL property, and we create a value
class (Health_Value) that is used to restrict the range of the property.
The key difference is in how we represent the values and the value
class. The allowed values (good, medium and poor health) are represented
as subclasses, not individuals. The value class is defined as the union
of these subclasses.
>
> Using this pattern, to say that "John is in good health" is to say
that the value representing his health_status (e.g. Johns_health)  is
contained in the Good_health_value partition of the Health_value feature
space.   Formally, Johns_health is an instance of the value class:
Good_health_value.
>
> We can also create a class called Healthy_Person, defined to be the 
> class of all persons whose health_status has a value in the 
> Good_health_value partition. In this case, the classifier can infer 
> that John is in that class." ===
>
> NB: Although I spent a lot of time on this, I am still not entirely 
> happy with this wording, it loses some of the simplicity of your text,
in the attempt to be more precise. Perhaps there is a best of both world
middle ground that you can find?
> BTW: you are using plural for the names of some of the classes. I
fixed them, they are correct in the figures (singular).
> ---
>
> Not all of the comments in the Code for this example are the same 
> font.
> ---
>
> You use the term 'parent value class'. It is a parent class, from a 
> graph-theoretic point of view, but from the user's point of view, it 
> is the class representing the main/whole feature space. The 'child'
value classes represent portions of the whole feature space. I suggest
not using the word parent. [minor style point]
> ---
>
> Replace: "you make the individual a type of the restriction." with 
> "you make the individual an instance of the restriction."
> ---
>
> Fig 3: you refer to "lists of values" change to sets?
> ---
>
> The wording: {{The disjoint axioms make the subclasses partitioning}}

> seems a bit akward. Maybe you were doing a dance with terminology... 
> Perhaps try: to {{The disjoint axioms make the subclasses partition 
> the value class: Health_Value}}
>
> Also, move this comment to immediately after the followign 
> comment,because it applies to all three subclass definitions: 
> "{{Define each of the subclasses that make up the partitioon and make 
> them pairwise disjoint}}"
>
> Better yet, skip that comment, it is probably unnecessary, given the 
> one above.
>
> And fix: 'partitioon'
> ---
>
> There is a missing full stop after the definition of  
> "medium_health_value".
> ---
>
> In the comment for defining healthy person, note that it is not 
> mandatory for the pattern (or if it IS, can you tell me why?).
> ---
>
> Suggested indenting tweak to make things more clear what the two 
> classes are that are being intersected. It took me a while to puzzle
it out. This might be too much work in general, if automatically
generated... :Healthy_person
>    a    owl:Class ;
>    owl:equivalentClass
>         [ a       owl:Class ;
>           owl:intersectionOf (:Person
>                               [ a       owl:Restriction ;
>                                 owl:onProperty :has_health_status ;
>                                 owl:someValuesFrom :Good_health_value
>                                ])
>               ] .
> ---
>
> Figure 4: minor tweak. Highlight exactly what is different with this
figure, compared to figure 2.  Make the new part blue, or in bold?
Maybe add text somewhere or caption the figure to say exactly what
changed with this variant:
>         1.      instance now implied, not explicit (noted by dotted
lines)
>         2.      new arrow from john to good_health_value
> [maybe overkill, it is pretty clear just  by looking at it...]
> ---
>
> reasoner and reasonable in same sentence (stylistic quibble). maybe 
> use inference engine or classifier isntead of reasoner?
> ---
>
> Give a simple example of alternate partitionings for the same feature 
> space. A real life example that turned up in Boeing was dividing up
the fuselage into [front, middle, rear] and [front, back]. Each was a
partition. The problem arose because we needed to do a semantic mapping,
which of course is inherently ambiguous.
> ---
>
> The following seems contradictory:
> "If variant 2 is to be used as part of a database schema or similar, 
> then a convention for creating anonymous instances in the database is 
> required. (Logicians call such anonymous instances "skolem 
> constants".) In practice, this can usually be ignored."
>
> If you can ignore it, then a convention is not required.
>
> This point is fairly lost on me, I can't follow what you are getting 
> at.
> ---
>
> WELL, I don't know what happened, someone must have slipped a much 
> finer toothed comb in my pocket - I didn't think there would this much

> more additional feedback...
>
> Despite all the verbiage, I really like the note, all this is just 
> fine tuning.
>
> Mike

--
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
email: rector@cs.man.ac.uk
web: www.cs.man.ac.uk/mig
        www.opengalen.org
        www.clinical-escience.org
        www.co-ode.org

Received on Monday, 7 March 2005 20:01:29 UTC