Re: [OEP] review for n-ary relations draft

Chris

Sorry to be so slow to get back to you on this one.  I set it aside for my
editing of Natasha's draft (in progress).  If the notes below cover your
comments in principle, I'll try to draft something suitable for the formal note.

On point 1).

We had originally given the cardinality constraints a fairly light touch,
because they do get complicated.  And because they raise the dreaded QCR
problem.  Qualified Cardinality Constraints are required to express them if
partially satisfactorily - sorry but yet again they come up.

a)    Your case 1 may be an advantage.  For example, I may have two observations
or opinions on the probability of the same tumour.  This is reasonable if I
interpret all the entities as 'representations' or 'concepts' - which is the
only thing that makes sense in the context of medical records, for example.

b)    If I explicitly want to avoid this, and produce a representation of
Christine, rather than observations of Christine, then I need an axiom schema,
i.e. my pattern needs to be extended to.

    Christine
       restriction(has_diagnosis cardinalityExactly(1)
                               (Diagnosis AND restriction(diagnosis_value
someValueFrom Breast_Tumour))

c)    Even with QCRs (b) is still an axiom schema,  there is no way to say, in
general, that there can be at most one diagnosis_relation class for each
diagnosis class for each person.

On point 2) the maintenance overhead.  I don't see why, with or without QCRs
this is any greater for reified relations that unreified relations.  If QCRs are
available, this is not a problem. One can say


       (Purchase AND
        restriction(settler someValuesFrom Company) ==>
                                        restriction(object maxCardinality(20)
Book))


       (Purchase AND
        restriction(settler someValuesFrom Person) ==>
                                        restriction(object maxCardinality(1)
Book))

where I use X==>Y for subclassOf( X,Y) for readability.

If you don't have qualified cardinality restrictions, you have a nasty work
around with nasty maintenance problems someplace.  The more you elaborate the
schema, the nastier they get, but nothing changes in principle.

I agree on "reified relations" and will try to add something to cover both
issues.  I'd be grateful for your help on the bibliography.

Regards

Alan



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.
>
> 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.
>
> 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.
>
> 3) Reified relations 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.
>
> 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.
>
> I am willing to make these changes and generate a new draft.
>
> -Chris
>
> 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