- From: Alan Rector <rector@cs.man.ac.uk>
- Date: Fri, 10 Dec 2004 07:14:34 +0000
- To: Christopher Welty <welty@us.ibm.com>
- CC: public-swbp-wg@w3.org
- Message-ID: <41B94CDA.773B292F@cs.man.ac.uk>
Chris, Pat, Natasha, All
I've been thinking about the conversation on N-ary relations. I have one
comment for Chris on the note below. The other for Pat - in a separate note to
follow.
I am not convinced that Chris' arguments apply to OWL provided that the correct
properties are functional, although they probably hold for RDF where it is not
possible to declare properties as being functional. In OWL, if the properties
are appropriately defined, I think it representation as classes (reification)
just changes the location of the potential branching. To eliminate the problem
of potential multiple tumours completely in either case, requires - you guessed
it - qualified cardinality restrictions.
Christopher Welty wrote:
>
> Natasha, Alan,
>
> I was not a WG member when the n-ary relations draft was developed and I have
> several comments:
>
> 1) The note misses a section on "problems" or "shortcomings" of the approach.
> There are two main problems with reification:
>
> a] unitended models: Reification introduces a new notion of identity for
> relation tuples, making it possible for the same relation (i.e. tuple) to
> exist multiple times. For example, it is possible for this model to exist:
>
> Christine has_tumor DR1
> DR1 diag_value Breast_Tumor
> DR1 diag_prob HIGH
> Christine has_tumor DR2
> DR2 diag_value Breast_Tumor
> DR2 diag_value HIGH
>
> In a logic with relations, clearly it would be impossible for there to be two
> of these, creating a difference between the reification approach and the
> relational approach. Since OWL does not have equality, there is no way to
> express that they are the same. This is especially critical in a logic that
> allows counting (like OWL), because a cardinality constraint (other than 0 or
> 1) would count these two individuals as different, even though they are the
> same.
>
Oddly, the note doesn't give the original pattern for the specific example but
presumably the statements in OWL would have been
ORIGINAL AS IMPLIED
Christine has_diagnoses someValuesFrom Breast_Tumour
or
Christine has_diagnoses hasValue(a_Breast_Tumour)
where a_Breast_Tumour is an individual of type Breast_Tumour
In either case the the property has_diagnoses is not functional (many valued),
as emphasised by giving it a plural form here. Therefore, the above is
compatible with any model (in the model theoretic sense) in which Christine has
at least one Breast_tumour. Whether she has more than one is open unless we
have a qualified cardinality constraint:
Christine has_diagnoses exactly(1) Breast_tumour
Exactly the same applies if we re-represent (reify) has_diagnoses. To make
things clearer, I shall change the name of the relation.
If diagnosis_value and diagnosis_probability are functional - as stated but not
emphasised in the section on the "corresponding class definitions", then the OWL
- which would be better rewritten so as to emphasise the similarity, comes out
as
Christine has_diagnosis_relation someValuesFrom
(Diagnosis_Relation AND
has_diagnosis_value someValuesFrom Breast_cancer
AND
has_diagnosis_probability someValuesfrom
High_values)
where High_values is the value partition including the individual 'High' in the
RDF example above.
This expression can be satisfied by any model in which there ios at least one
individual of class Diagnosis_relation that has a diagnosis_value of
Breast_cancer (and a probability from High_values). There an be multiple
Diagnosis_relations but each can have exactly one diagnosis_value. So again,
the expression is satisfied by any model in which an individual has at least
one, but possibly more, breast tumours. The only differences is where the
branching occurs.
Likewise, this can only be properly ruled out by a qualified cardinality
restriction:
Christine has_diagnosis_relation exactly(1)
(Diagnosis_Relation AND
has_diagnosis_value someValuesFrom Breast_cancer)
Note that:
a) The qualified cardinality restriction must not include the
has_diagnosis_probability clause, else Christine could have several different
Breast_Tumours with different probabilities.
b) This is an example where none of the work arounds for qualified cardinality
restriction work. It is impractical to have subproperties for each possible
diagnosis for every possible cardinality - more than impractical, literally
impossible since there are an indefinite number of such potential properties for
each diagnosis that can occur multiple times in the same individual.
A further note:
If we follow the implications of this example, then we can allow the
re-represented version to 'collapse' naturally into the original version by
making both has_diagnosis_value and has_diagnosis_relation subproperties of the
original property has_diagnoses.
has_diagnosis_value ==> has_diagnoses
has_diagnosis_relation ==> has_diagnoses
Then, with due attention to the range of has_diagnosis_relation:
has_diagnosis_relation (Diagnosis_Relation AND has_diagnosis_value
someValuesfrom X)
==>
has_diagnoses someValuesFrom X.
The one drawback of this is that if we ask for Christine's diagnoses, without
specifying a class Condition which is disjoint from the class Diagnosis
relation, we get back the Diagnosis-relations as well as the diagnoses. The
most general form equivalent to the original is
has_diagnoses someValuesFrom (not Diagnosis_relation).
on the assumption that the classes Diagnosis_relation and Disease are disjoint,
which is reasonable and that the range of has_diagnoses is
union(Diagnosis_relation Diagnosis).
I don't have Natasha's drawing tools available, but I could have a go when the
time comes at a minor fix and generate the required N3 and suggest a relabelling
or revision that she could easily convert.
Finally, it might, or might not, be worth noting that when RDF is queried using
a closed world query language such as RDQL, the difference is moot.
... more below
>
>
> b] Reificaiton creates a maintenance problem if you want to have local range
> or cardinality constraints on some role in the reified relation that depends
> on the class of some other role. You end up having to build a lattice of
> classes to represent all the possible combinations. For example, we might
> want to say that a person can buy no more than 1 book, whereas a company can
> buy up to 10. Expressing this constraint requires a special subclass of the
> reified relation class that represents the combination of range restrictions.
> The example becomes a bit lame because of the domain, but there are plenty of
> good cases for it.
Without qualified cardinality restrictions - sorry but they keep coming up -
this case applies equally whether we use re-represented (reified) relations or
not. If we don't use re-represented relations we have a horrible lattice of
properties which exist only to carry the cardinality constraintS specific to
each class. If we re-represent those properties as classes, we have a
corresponding horrible lattice of classes, plus an exactly parallel horrible
lattice of properties. The maintenance penalty is uglier in the second case, but
no more complex in principle.
... Or am I missing something.
>
>
> 2) I realize the issue of whether to refer to this as reification or not was
> discussed. I strongly disagree with the conclusion, however. The solution
> approaches in the note are both forms of reification. That there is an
> existing notion of reification in RDF doesn't change the fact that in the
> literature, which predates RDF by decades, this is known as reification. It
> will take one sentence to separate this reification from rdf-reification and
> properly orient people so they will know what it is called and can read more
> about it if they are interested.
Amen. I have to go back and retype every time - add notes to slides to link
them to other literature, etc. However, I'll leave others to fight the body in
high standards committees.
>
>
> 3) Reified relations {{may}} have an ontological status, that would be useful
> to mention briefly, again for the purposes of orienting the interested reader
> and giving them a good starting place to read more. It has been argued that
> reified relations actually represent the event that caused the relation to
> come into existence, and taking this perspective actually helps make the usage
> a little more clear.
If we get into this we should distinguish between the purely formal fact, that
we can take any relation and reify it, and the ontological notion of qualities
and quale, which provides good ontological reasons to do so. In practice in
GALEN, we make the decision about whether to reify or not, based on maintaining
a consistent pattern in a given area that knowledge engineers can follow
reliably. I think in almost all cases it corresponds to the distinction between
Qualities and ("Features" in GALEN) and mere properties ("Selectors") in GALEN.
(An example of a selector is the laterality of body parts. There is no
ontological status to the left-laterality of my left hand, it just is an
intrinsic property of the hand with no more to be said about it.) However, I
think we should be cautious about opening up ontological issues in SWBP. We
might put a brief note that they exist, but I wouldn't want to make this the
place where ontological battles get fought out.
>
>
> 4) The note misses a bibliography. Again, I think it is important in these
> notes to let people know that the semantic web did not invent or create these
> problems, and both the problems and solutions have a long history.
>
Greatly appreciated.
>
> I am willing to make these changes and generate a new draft.
>
> -Chris
Alan
>
>
> Dr. Christopher A. Welty, Knowledge Structures Group
> IBM Watson Research Center, 19 Skyline Dr., Hawthorne, NY 10532 USA
> Voice: +1 914.784.7055, IBM T/L: 863.7055, Fax: +1 914.784.7455
> Email: welty@watson.ibm.com, Web: http://www.research.ibm.com/people/w/welty/
--
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 Friday, 10 December 2004 07:13:48 UTC