<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">I forwarded Roger's message from a few weeks ago to Simon Cox, and am taking the liberty of copying Simon's reply to the group. It appears that the differences between UML and OWL may be surmountable in terms of our requirements.<DIV><BR class="khtml-block-placeholder"></DIV><DIV>It is my impression that we've substantially embraced the notion of an information model / architecture that can be expressed using (appropriate subsets / profiles of) a variety of technologies. However, we have not yet really addressed the question of which tools to choose for a given application, or the nature of profiles that will allow us to swap model definitions among different encodings.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Flip<DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR><DIV>Begin forwarded message:</DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><B>From: </B><<A href="mailto:Simon.Cox@csiro.au">Simon.Cox@csiro.au</A>></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><B>Date: </B>April 13, 2006 6:05:37 AM PDT</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><B>To: </B><<A href="mailto:pcd@ecosystem.com">pcd@ecosystem.com</A>></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><B>Subject: </B><B>RE: [Tdwg-tag] UML limitations for our uses?</B></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR style=""></DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"><FONT class="Apple-style-span" color="#0000FF" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">That's interesting stuff.</SPAN></FONT></SPAN></DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"><FONT class="Apple-style-span" color="#0000FF" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">The idea of determining class membership on the basis of property values is not very different from the classic UML classifier - its just that UML encourages "strong-typing" - the class membership determines the set of properties that must be populated - while the inferred-class approach is more "weak-typed", or (as Roger points out) "multi-typed" depending on the ontology you choose to apply to the (set of) observations. (Look - observations appear again! - thats because the Observation viewpoint makes the property-type a primary property, while the type of the feature-of-interest is more remote.)</SPAN></FONT></SPAN></DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"></SPAN> </DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"><FONT class="Apple-style-span" color="#0000FF" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">In the web article I take issue with many of the points in the section headed "Differences between OWL properties and UML associations/attributes". For example:</SPAN></FONT></SPAN></DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"><FONT class="Apple-style-span" color="#0000FF" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">1. UML associations always have direction. It can be "unpsecified", "source->target", "target->source" or "bi-directional"</SPAN></FONT></SPAN></DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"><FONT class="Apple-style-span" color="#0000FF" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">2. binary relations are a subset of general associations. In many (most?) UML models only this subset is used.</SPAN></FONT></SPAN></DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"><FONT class="Apple-style-span" color="#0000FF" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">i.e. in both of these cases UML is actually richer, but can always be "profiled" to look like OWL.</SPAN></FONT></SPAN></DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"><FONT class="Apple-style-span" color="#0000FF" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">3. I would phrase this more like "UML association and role names are contextual - the same word may be used in different places to mean different thing, but is scoped by its context so the complete designator is effectively the scoped-name" so they end up being unique anyway ...</SPAN></FONT></SPAN></DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"></SPAN> </DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"><FONT class="Apple-style-span" color="#0000FF" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">Roger's comment "</SPAN></FONT><FONT class="Apple-style-span" color="#0000FF" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">If we want to assure that we can swap between two or more modeling languages then we can't use all the feature of any of them but have to come up with a subset</SPAN></FONT><SPAN class="442334512-13042006"><FONT class="Apple-style-span" color="#0000FF" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">" is important. This is also why in the UML-GML world we use a subset/profile of UML (no operations, mandatory rolenames, single inheritance) to yield a subset of XML (no XML attributes, no mixed-content, very sparing use of <choice>, some cardinality restrictions).</SPAN></FONT></SPAN></SPAN></DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"><SPAN class="442334512-13042006"></SPAN></SPAN> </DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"><SPAN class="442334512-13042006"><FONT class="Apple-style-span" color="#0000FF" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">Rather than imagine that one-solution-suits-all, we should rather focus on criteria on how to select which tool to use when.</SPAN></FONT></SPAN></SPAN></DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"><SPAN class="442334512-13042006"></SPAN></SPAN> </DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"><SPAN class="442334512-13042006"><FONT class="Apple-style-span" color="#0000FF" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">Simon</SPAN></FONT></SPAN></SPAN></DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"></SPAN> </DIV><DIV dir="ltr" align="left"><SPAN class="442334512-13042006"></SPAN> </DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><BR><DIV><DIV>On Apr 3, 2006, at 5:03 AM, Roger Hyam wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"> <BR> There is an interesting article here:<BR> <BR> <A class="moz-txt-link-freetext" href="http://www.cs.vu.nl/~guus/public/owl-restrictions/">http://www.cs.vu.nl/~guus/public/owl-restrictions/</A><BR> <BR> That discusses the differences between OWL and UML. <BR> <BR> One of the features of OWL that I like is the notion of a necessary and sufficient properties but alas this is lacking in UML. Sufficient conditions allow you to determine if an instance is a member of a class when it in not explicitly stated. You can therefore receive and object and work out what it is according to an ontology of your choice - which seems pretty useful to me. It is a mechanism, I believed, could enable us to integrate a simple core ontology with more complex specialist ontologies that some network participants may choose to use. It is not available in UML but could be used to reason about a UML ontology expressed in OWL or RDFS.<BR> <BR> OWL doesn't do qualified cardinality restrictions as well as UML - but there are work rounds and proposals and I am not sure how important this is.<BR> <BR> There is also a good quote in the article on data modeling versus building ontologies:<BR> <BR> "A data model is a model of the information in some restricted well-delimited application domain, whereas an ontology is intended to provide a set of shared concepts for multiple users and applications. To put it simply: data models live in a relatively small closed world; ontologies are meant for an open, distributed world (hence their importance for the Web)."<BR> <BR> I think we are sometime confusing the two in our discussions.<BR> <BR> Bottom line is:<BR> <UL> <LI>You can't express everything in UML or OWL.<BR> </LI> <LI>If we want to assure that we can swap between two or more modeling languages then we can't use all the feature of any of them but have to come up with a subset.</LI> </UL> The answer never includes a single TLA. <- apart from this answer!<BR> <BR> My personal feeling is that anything that is defined centrally by TDWG should use the lowest common denominator of features anyhow.<BR> <BR> As usual I am grateful for you comments/thoughts.<BR> <BR> Roger<BR> <BR> <BR> <BR> <BR> <BR> <BR> <PRE class="moz-signature" cols="72">--
-------------------------------------
Roger Hyam
Technical Architect
Taxonomic Databases Working Group
-------------------------------------
<A class="moz-txt-link-freetext" href="http://www.tdwg.org">http://www.tdwg.org</A>
<A class="moz-txt-link-abbreviated" href="mailto:roger@tdwg.org">roger@tdwg.org</A>
+44 1578 722782
-------------------------------------
</PRE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">_______________________________________________</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Tdwg-tag mailing list</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="mailto:Tdwg-tag@lists.tdwg.org">Tdwg-tag@lists.tdwg.org</A></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org">http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org</A></DIV> </BLOCKQUOTE></DIV><BR></DIV></DIV></BODY></HTML>