Re: [OEP] Comments on Specified Values Note

Mike

Many thanks for the detailed comments.  I am doing a careful rewrite to accommodate most of them and
fix the several serious bugs you picked up - some of the N3 had lost carriage returns in editing so
that it could only be read by computer.  I will get it to the group before the F2F, although the
diagrams may be back in their "ugly" mode if I don't get and master some new graphics tools.

I'll include a clearer statement of the graphics conventions that I think Natasha and I have both
used. I am happy to adapt on most things. I agree it would be much better if we could agree on a
single set of conventions insofar as  possible.

I am delivering a tutorial most of today and tomorrow, so it may be closer to the wire than I would
like before you receive it.

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 10:10:22 UTC