Re: [OEP] Comments on Specified Values Note

Mike, All

Many thanks for the detailed comments.  There is a revised text at ????.
I hope I have followed most of the advice.
I respond to the comments in line where I have deliberately not done so. .

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

Revised version based on yours.

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

Done.

>
>
> Why not use the word "attribute"?

There is a potential confusion with "attribute" in Object-Attribute-Value triples, where an
"attribute" corresponds to a property rather than a class.  In mixed audiences we have found the
word
"attribute" troublesome because it triggers unwanted preconceptions in some of the audience.

>
>
> Give examples of each of the three ways to represent specified values,
> too abstract otherwise.

I've pointed to the examples below explicitly

>
>
> Diagramming conventions:
>
>
> 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.

I have put in a separate vocabulary section and, I hope, fixed this in each location. used.

>
>
> In the code you say 'the next line makes the partition exhaustive', but
> a mathematical partition is always exhaustive anyway.

Rephrased

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

I agree in principle but not in practice.  Pattern 2 is what people expect.  If we put it before
pattern 1 there is a serious danger that people will read no further. I'll take the group's advice
on this one, but I would leave them in this order by preference.

>
>
> Figure 1:
> * why does it not have an arrow from John to Person, as in figure 3.,
> They should be consistent, in any event.

Clearly it should.  Fixed.

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

Agreed but it gets cluttered to indicate both disjointness and exhaustiveness.
I've put in a version to try.
Alternatively one might write exhaustive, disjoint on the bar covering the subclass arrows.
On consideration, that's probably the best option, and avoid the mention of union in the diagram
altogether.  That way the diagram is the intention; the code is the means of achieving it.

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

I thought there were - somehow lost in versioning.  Fixed

>
> Add a sentence or two introducing the fact that you will be introducing
> two variants (minor).

Done.

>
>
> Say what notation you are using for the code. I'm not sure myself, but
> it probably is N3,

Done.  I don't like N3 either, nor am I particularly familiar with it, but it is what the group
decided to use.

>
>
> I am still puzzled by the following:
> :Person
> a owl:Class.:John
> a :Person ;
> :has_health_status :johns_health .

Well spotted. That's because it is missing a carriage return.  Must have happened in the post
editing.  There is a full stop, so that it parses, but no human could read it.
Fixed.

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

I'll put this in a note.  This is a major awkwardness with the OWL spec.  There is an allDifferent
but not an allDisjoint axiom.  The logicians aren't bothered because there is a work around - which
we will work into the tools in the near future.  Hopefully future versions of OWL will fix this.
(It isn't theoretical, we have had relatively modest ontologies blow up beyond the 1.5Gig Windows
limit because they numerous flat lists of 20-100 pairwise disjoint classes.  Since we would argue
that this is often good modelling style, the temptation to implement the OWL spec literally has to
be avoided by tool makers.  We need a note on this soon.

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