[OEP] Comments on Specified Values Note

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

Received on Saturday, 26 February 2005 12:32:46 UTC