From: Deborah Mcguinness (dlm@ksl.stanford.edu)
Date: 01/05/01
Thanks Frank for the work on the walkthru. I like it and think it improves things.
I do have a number of comments that I think might help readability.
I just run through the document in order and note comments. some are very minor (and i think completely non-controversial) but two are possibly controversial. I state them first:
1. Ora has written a new minimalist guide to RDF - i think we want to at least link to that if not replace the previous one we had with his.
2. recognizing that the walkthru may end up serving as a conceptual modeling guide for the naive new users, we might attempt to make some standard conventions. I find in teaching new people about modeling, it is useful to name properties with has- so that we end
up having the property
has-height
and the class height
then having the property has-height have a range restriction on it of height.
While we who are familiar with oo modeling dont really need these crutches any longer, the masses I find benefit from them.
thus i suggest putting this in at minimum in the height example, if not throughout the example.
running suggestions in order of appearance
- in a pass that i did to the walkthru, i tried to give a little more context. some suggestions are included below:.
I suggest changing:
Now, we begin our ontology definitions. First, we define a kind of thing
called an animal.
to
Now, we begin our ontology definitions. In order to describe objects, it is useful to define some basic types. If we are working in a domain of animals, we will want to define a kind of thing called animal.
suggest changing:
It doesn't say anything
else about what an animal is, etc.
to
It doesn't say anything
else about animal other than specifying an identifier.
suggest changing (in properties)
In this case, we're defining the parent relation
to
In this case, we're defining the parent relation which will be used to connect two animals.
in this example, since we state a domain, i would also suggest that we add a range -
thus adding
<rdfs:range rdf:resource="#Animal"/>
It is fine to leave the comment in place that suggests a better way of doing it. I just think it is useful to show parallel construction.
in the comment on animal, I suggest being overly clear...
suggest changing
<rdfs:comment>
If x is an animal, then it has exactly 2 parents (but NOT vice versa).
</rdfs:comment>
to
<rdfs:comment>
If x is an animal, then it has exactly 2 parents (but it is NOT the case that anything
that has 2 parents is an animal).
</rdfs:comment>
on min, max cardinality, i suggest stating that no statement of cardinaly == min card 0
by adding after
<rdfs:Class rdf:about="#Person">
<restrictedBy>
<Restriction daml:maxcardinality="1">
<onProperty rdf:resource="#spouse"/>
</Restriction>
</restrictedBy>
</rdfs:Class>
If no minimum cardinality is specified, a minimum cardinality of 0 is assumed.
Thus, <Restriction daml:mincardinality="0"> would not need to be asserted.
on the introduction of hasClassQ (and maxcardinalityQ), i suggest adding an example after the mention that one could have jobs other than those that are fullTimeOccupations.
suggest adding after:
(This still allows for the possibility that they may have
multiple jobs of other types than FullTimeOccupation).
No jobs that were not fullTimeOccupations would be allowed to be added if the example had been:
<rdfs:Class rdf:about="#Person">
<restrictedBy>
<Restriction daml:maxcardinality="1">
<onProperty rdf:resource="#occupation"/>
<hasClass rdf:resource="#FullTimeOccupation"/>
</Restriction>
</restrictedBy>
</rdfs:Class>
I would suggest using conventions in the walk thru for slots being prefixed with has.
we will probably be setting standards for conceptual modeling for naive people (as mentioned above.)
suggest changing:
A Person has a height, which is a Height. (height is a Property, or relation;
Height is a Class, or kind of thing.)
<rdf:Property rdf:ID="height">
<rdfs:range rdf:resource="#Height"/>
</rdf:Property>
to
A Person has a property called has-height, which is a Height. (has-height is a Property, or relation;
Height is a Class, or kind of thing.)
<rdf:Property rdf:ID="has-height">
<rdfs:range rdf:resource="#Height"/>
</rdf:Property>
changing:
Finally, TallThing is exactly the class of things whose height is tall:
<rdfs:Class rdf:ID="TallThing">
<sameClassAs>
<Restriction>
<onProperty rdf:resource="#height"/>
<hasValue rdf:resource="#tall"/>
</Restriction>
</sameClassAs>
</rdfs:Class>
>From the inside out, this says first that TallThings must have the value tall as
value for their height property, ie having the value tall as your height is a
necessary condition for being a TallThing. Secondly, we say that TallThing is
exactly the same class as the the class of all such objects (ie all objects
having tall as their value for height), in other words: besides being necessary,
this condition is also sufficient for being a TallThing.
to
Finally, TallThing is exactly the class of things whose has-height is tall:
<rdfs:Class rdf:ID="TallThing">
<sameClassAs>
<Restriction>
<onProperty rdf:resource="#has-height"/>
<hasValue rdf:resource="#tall"/>
</Restriction>
</sameClassAs>
</rdfs:Class>
>From the inside out, this says first that TallThings must have the value tall as
value for their has-height property, ie having the value tall as the filler for the has-height property is a
necessary condition for being a TallThing. Secondly, we say that TallThing is
exactly the same class as the the class of all such objects (ie all objects
having tall as their value for has-height), in other words: besides being necessary,
this condition is also sufficient for being a TallThing.
Frank van Harmelen wrote:
> Ian,
>
> Thanks for your comments.
>
> > 1. I notice that you didn't change the domain restriction on "height"
> > (currently "Person"). I think that this is a mistake because, as I
> > showed in Washington, skyscrapers end up being either inconsistent (if
> > Building and Person are disjoint) or a sub-class of Person. At the
> > very least the property should be renamed to something like
> > personHeight.
>
> To reassure everyone: the current example is not inconconsistent, but only becomes inconsistent when extended in a "natural" way (adding the class buildings, with subclass skyscrapers that has the restriction that their height must be tall).
>
> I've simply removed the domain restriction on height, which was not required for anything in particular.
>
> > 2. As I already mentioned to you, the "spouse" example is a bad one
> > because it implies that persons can have many spouses, provided that
> > only one of them is a Person. It is hard to come up with good examples
> > of cardinalityQ constraints - how about a structural example such as
> > "a person can have at most 2 limbs of type Leg"? Another possibility
> > would be to have a Class "FullTimeOccupation" and state that a person
> > can have at most one FullTimeOccupation (but maybe several part time
> > jobs).
>
> I like your FullTimeOccupation example. I've now used "spouse" as an example of a maxcardinality constraint (person has max 1 spouse) and illustrated the qualified cardinality constraint by following your suggestion that a person may have at most one job of type
> FullTimeOccupation.
>
> > 3. About UnambiguousProperty. We could of course infer that the
> > inverse of a UniqueProperty must be an UnambiguousProperty (in fact
> > having both kinds of property is redundant). Maybe we should mention
> > this. Maybe we should use an example where the UnambiguousProperty
> > statement isn't redundant (because we don't already know that the
> > inverse is Unique).
>
> I've added the remark that the inverse of any UniqueProperty is an UnambigousProperty, and have left out any illustration of the latter. The textual explanation will do the job.
>
> Thanks for your comments,
>
> Frank.
> ----
This archive was generated by hypermail 2.1.4 : 04/02/02 EST