W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > August 2006

Re: Implications and Issues in Converting UML to RDF/OWL When Constructing HL7 RIM Ontology

From: Alan Rector <rector@cs.man.ac.uk>
Date: Thu, 31 Aug 2006 18:22:26 +0100
Message-Id: <DC154F01-5D36-47F4-AE59-3EAF6E450438@cs.man.ac.uk>
Cc: public-semweb-lifesci@w3.org
To: drew.mcdermott@yale.edu

Just as an added note

If you express the example in the Manchester simplifeid syntax it  
becomes more obvious.
See just below previous example

On 28 Aug 2006, at 19:28, Drew McDermott wrote:

>> [helen.chen@agfa.com]
>> [...]
>> 2. Mapping UML attributes RDF properties
>> In OO, all attributes of a class will be inherited by its  
>> subclasses.  In
>> RDF/OWL, there is not such "inheritance", such that
>> {?A ?P ?X. ?B rdfs:subClassOf ?A} => {?B ?P ?X}
>> (the above rule does not exist in OWL semantics)
> I think some clarification is needed here.  (Perhaps just to clear up
> my own ignorance about UML.)  In OO-land one often writes ?A ?P ?X as
> a shorthand for "Every element of class ?A has value ?X for property
> ?P."  I assume that's what's meant here.  If so, then OWL _does_ have
> inheritance, but it's expressed in somewhat indirect ways.
> For instance, one might write (using N3 notation):
>    P a owl:Property .
>    A a owl:Class;
>      rdfs:subClassOf [a owl:Restriction
>                         owl:onProperty P;
>                         owl:allValuesFrom [a owl:Class;
>                                              owl:oneOf (X)]] .
>    B a owl:Class;
>      rdfs:subClassOf A .

CLASS B --> A.
       p ONLY {X}.

NB: this assumes X is an individual.

then it follows that the restriction p SOME X also applies to B.

IF all Bs are As AND
IF all As only have property P with values of the class {X}
THEN all Bs only have property P with values of the class {X}.

There is a further ambiguity as to whether (A p X) is intended to  
mean  (A --> p VALUE X) or (A--> p ONLY {X}) or both.
In the former case, all As are related to the individual X, but might  
be related to individuals, in the the latter it means that all As are  
related by p only to the individual X if they are related by p to  
anything, but might not be related to anything.  The two statements  
are independent: neither implies the other.

If the link is between two classes then we have a potential choice of:

	A --> p ONLY C.   (ONLY == allValuesFrom) "All As relatede by P only  
to Cs"
	A--> p SOME C     (SOME == someValuesFrom) "All As related by P to  
some C"

and in OWL full

	A --> p VALUE C                   "All As related by p to the class C"
	A FACT p VALUE C		"The class A is related by P to the class C"

Whether VALUE (value) SOME (someValuesFrom) or ONLY (allValuesFrom)  
the restriction is "inherited" by all subclasses.
The phrase "inheritance" in this case is just a specific case of  
logical implication.

The fact of a link between the two classes, qua classes is not  
inherited because it is about the classes themselves. It is a meta -  
statement rather than a statement.

The problem is really in the transformation from RDF to OWL, which is  
either ambiguous - if you take the simple forms such as (A P X) or  
roundabout and verbose if you take the official representation.  It  
is inevitable that simple transformation from RDF to OWL will be  
ambiguous because OWL is richer than RDF.   Therefore there is not  
enough information in a simple RDF representation for a  
transformations  to OWL without making some added assumptions.

What we are missing is a clean convention of the assumptions for  
"projecting" OWL onto RDF, and onto RDF(S).  To do that we need  
conventions for specifying the intended semantics of (A P X) in RDF.   
If A and X are both classes, then the literal RDF interpretation is  
almost never the literal interpretation of the RDF without  
supplemental assumptions.  To take a concrete example The class  
Finger is not a part of the class Hand, rather Fingers are parts of  
Hands, or rather more precisely all Fingers are part of some Hand (or  
were at some time except in truly pathological cases we don't usually  
worry about.)

Returning to the UML issue, a line with a cardinality attached in UML  
A -- p_association -- [n..m] C can be read in OWL 1.1 which includes  
qualified cardinality constraints as

	CLASS A --> p_association MIN n MAX m C;
			-->  p_association ONLY C.

which will necessarily be true of any subclass of A.  (This doesn't  
take account of the possibility of n-ary relations in UML-2, but  
covers almost all common cases.)

  or in N3 notation

   P a owl:Property .
   B a owl:Class.
    A a owl:Class;
      rdfs:subClassOf [a owl:Restriction
                         owl:onProperty P;
                         owl: [a owl:Class;
                                              owl:Min(n) C] ;
              subClassOf [a owl:Restriction
                        owl:onProperty P
                        owl:[a owl:Class
                                              owl:Max(m) C].

> Any inference one can make about an element of class A having value X
> for property P one can also make about an element of class B.
> However, if by ?A ?P ?X is literally meant that the class A itself has
> a certain property, then the inference rule is simply wrong.  For
> instance, if P = 'size' and X = 1000, then obviously one wouldn't
> conclude that every subclass of a class with 1000 elements had 1000
> elements.
> One caveat: I assume that UML, like most OO systems, imposes few
> formal limits on inheritance, and in particular allows it to be
> "overridden," perhaps constrained by the dictates of some formal
> nonmonotonic framework (although I doubt it).  In contrast, OWL is
> 100% logically pure, so that no exceptions to the inheritance rule are
> allowed.
>                                              -- Drew McDermott

Alan Rector
Professor of Medical InformaticsallValuesFrom
School of Computer Science
University of Manchester
Manchester M13 9PL, UK
TEL +44 (0) 161 275 6149/6188
FAX +44 (0) 161 275 6204
Received on Thursday, 31 August 2006 21:46:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:20:18 UTC