Re: [OEP] Comments on Specified Values Note

Mike, All

As the F2F is coming close, I've done an edit following Mike's excellent suggestions.  The diagrams
are still in .ppt but we will have nice OmniGraffle versions shortly.

It is at  http://www.cs.man.ac.uk/~rector/swbp/specified_values/specified-values-8.html

Main changes

*    Abstract and problem edited as suggested
*    Diagramming, vocabulary and syntax conventions made explicit plus appendix added with detail
*    Disjointness added explicitly to diagrams.  This does make them a bit cluttered.
*    Figure 1 corrected as per Mike's note
*    Considerations split into advantages and disadvantages
*    N3 syntax more extensively commented (and corrected)
*    Diagrams adjusted to be consistent
*    "quality" changed to "feature" throughout.  Some may prefer it the other way.  Easily changed
to taste.
*    Reference to Welty and Guarino for quality added
*    Additional diagram for pattern 1 variant 2 added.
*    Numerous minor fixes

Regards

Hope to speak with you later in the week.

Regards

Alan


"Uschold, Michael F" wrote:

> OVERALL: excellent note describing a very common and important problem.
> I have numerous comments and suggestions.
>
> The abstract is too abstract (as it were). Better for it to use less
> generic terms, use a nice example right away?  Here is a possible
> alternative, which I don't think is great, but it might be better in
> some ways:
>
> ===
> Creating ontologies frequently entails modeling various "features",
> "qualities" or "attributes" of existing
> concepts. For example: size may describe persons or other physical
> objects; rank may describe military officers. In OWL, such descriptive
> features are
> modeled as properties, often with domain and range constraints.  A
> range constraint specifies the possible values that a property may have
> (e.g. size may be small, medium and large). This document describes two
> methods to represent such collections of values: 1) as partitions of
> classes and 2)  as enumerations of individuals. It does not disscuss the
> use of datatypes to represent lists of values.</p>
> ===
>
> "for of use" should be "for use" ?
>
> General Issue:
>
> Start with specific example, then generalize. Give reader something to
> sink teeth into before talking in general abstractions. Then relate the
> details to the general abstractions.
>
> "feature" -> "features"
>
> Why not use the word "attribute"?
>
> Give examples of each of the three ways to represent specified values,
> too abstract otherwise.
>
> Diagramming conventions:
> * have as a separate appendix, or note. Have have all notes use same
> convention? Maybe add to the glossary note that will be drafted at some
> point?
> * is the term 'decorated' as widely used as 'labelled'? Use the more
> widely used term.
> * there is no mention of an arrow with a circle on one end. What does
> that mean?
> * have examples of each. This description is too terse.
> * Now there is no example illustrating the "blob on the origin" case.
> Hmm, maybe the blob is the circle. IN this case, the term 'decorated' is
> used in a way I found confusing. I thoguht it meant labelling, but now
> it also refers to what is at the beginning/end of a line? Does one also
> say a line is decorated with an arrowhead?
> * what does open/closed arrow mean? Does it relate to the blob?
> * IMHO, it is an odd and possibley dangerous convention to assume that
> all classes and individuals are mutually disjoint. It will be easy to
> forget.
>
> The term 'partition' has a specific mathematical meaning that is
> different from how it being used here.
> Mathematically, a partition refers to the mutually exclusive sibdividing
> up of a whole, not to the individual parts. One says of a particular
> dividing up: is it a partition? IF the parts overlap or do not add up to
> the whole, it is not a partition.
> Here you refer to each piece as a partition, this could be misleading.
>
> In the code you say 'the next line makes the partition exhaustive', but
> a mathematical partition is always exhaustive anyway.
>
> Pattern 2 should come before pattern 1 because:
> 1. it is simpler
> 2. it has some disadvantages that are addressed by pattern 1, which is a
> nice way to motivate pattern 1.
> 3. it fixes the minor problem that the note [1]  refers to a pattern
> that has not been discussed yet, making it hard to understand.
>
> Figure 1:
> * why does it not have an arrow from John to Person, as in figure 3.,
> They should be consistent, in any event.
> * the arrow from John to Person might be dotted, if the domain
> constraint for has_health_status is Person (but that may be too
> complicated and beside the point here)
> * it would be better if there was a good explicit diagramatic convention
> to indicate disjoint.
>
> Figure 2: Terrrific idea to have this figure, really helps with an
> additional perspective.
> I recommend having some of the arrows go to the other values in the
> partition, not just the good_health_value one.
>
> Add a sentence or two introducing the fact that you will be introducing
> two variants (minor).
>
> Say what notation you are using for the code. I'm not sure myself, but
> it probably is N3, which I'm not very conversant in.
> Mostly it is easy to figure out from context,  but there are things that
> I find confusing and non-obvoius.
> I recommend having an English sentence accompany each bit of code. This
> makes it unnecessary for the reader to be familiar with N3 to understand
> the note, it will also help them learn N3 on the fly.
>
> I am still puzzled by the following:
> :Person
> a owl:Class.:John
> a :Person ;
> :has_health_status :johns_health .
>
> This seems to be saying:
> * Person is an owl:class, with an instance John
> * a person has health_status equal to Johns_health
>
> But I can't see what syntactic convention says that it is John that is
> that person.
>
> It may be worth mentioning that the pairwise disjoint axioms will be
> exponentially explosive if ther are more than a few values. What to do
> then? Is the reader to think that they have to creates dozens or
> hundreds of disjointness axioms?
>
> Variant 2:
> YOu use a differnet name Jim, so I'm not sure in what sense it is a
> variant.
> I expected you would model the same information about John in a
> different way.
> I'm confused about what exactly is the same or different about these two
> variants. You don't say. I presume that in variant 2, you don't need to
> create an explicit class for HealthyPerson, but you don't say that. The
> note suggests that the second variant would also have that, but it is
> apparentlhy unnecessary.
>
> In short, I don't see an A/B comparison for the whole example. This
> might be confusing. I'm offline now, perhaps this is clear in the code
> referred to at the end of the note in all the different syntaxes.
>
> It might help to have a figure for this variant, which shows the lack of
> the healthy_person class.
>
> PROBLEM: are there any good diagrammatic conventions for representing an
> anonymous restriction class? An early version of Network Inference's
> editor, Construct had a convention that I found terribly confusing.
> There may be no ideal solutions, each will have problems. You want the
> class it self to look like all other classes, so it should be an elipse,
> but you also want to indicate how it is defined too.
>
> IDEA; for the future.  Future ontology editing tools may provide exlicit
> support for these ontology patterns, making it unnecessary to remember
> the boring bits, only their 'parameters'. e.g.  One could have the
> exponentially many disjoint axioms created automatically by saying a set
> of things are all mutally disjoint.
>
> 'quality space' is a new term, is it needed? What abot the term 'value
> space' to refer to the space of possible values? Ive seen that term
> used.
>
> "of discrete value" --> "of discreate valueS"
>
> Considerations using Pattern 1:
> * I suggest reorder them to indicate pros first and cons last.. There
> wasa much heated debate about making judgments, but when taken by
> themselves, most of these poits are clearlyl desirable or not.  Who
> would prefer for inferences to NOT work properly?  Who would argue that
> being NON-intuitive is a good thing?
> * there is not an anonymous instance here, there is an anonymous class
> (well ok, it is an instance of the meta-class OWL:Class, but that misses
> the point)
>
> "an unique" --> "a unique"  (may be ok both ways)
>
> Remove parens form the remark about unique name (or is it nameS)
> assumption. Prefix the sentence with "Importantly, "

--
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 Tuesday, 1 March 2005 17:47:27 UTC