Re: OMG Ontology Metamodel Definition Review

Hi All,

First, thank you for taking the time to read through our submission, and 
thanks in particular to Jeremy for
the detailed comments.  I will take them back to the team personally and 
ensure that we address them all
appropriately.  This kind of feedback is incredibly valuable to us, as 
we truly want the specification to be
useful and widely adopted.

A few thoughts on the hub and spoke conversation -- we initially sought 
to do exactly that, at first using
the core UML constructs as a basis for that work.  We failed miserably 
for a number of reasons, in part
because of using UML 1 tools rather than UML 2, but also because there 
were serious impedance
mismatches between the implicit semantics of some UML constructs and our 
understanding of the
related OWL constructs (e.g., associations/association classes vs. OWL 
properties, individuals in OWL
and UML instances, etc.).  We were also concerned about unintended 
semantics, or overly complex
semantics, creeping into the picture, making it difficult for downstream 
reasoners to leverage the
results.  We then looked at creating a core ODM metamodel that could be 
used as the hub for the set
of metamodels developed, but did not find enough commonality (although 
there is significant overlap
in some cases).  Lewis Hart and Patrick Emery spent a great deal of time 
developing the DL metamodel
which is now informative, in fact, to be used for that purpose, but we 
abandoned it for a number of
reasons, including lack of any clear "standard" DL aside from OWL.  
Arguably, there are a number of
core DL constructs that are represented in the DL metamodel, but it was 
not our intent to develop a
new knowledge representation language, simply to model those that were 
already in use.  Thus, we
elected to use the OWL Full metamodel as a vehicle for mappings in and 
out of the ODM.  All of the
mappings will be more fully specified (hopefully using a specification 
that is called MOF Query/View/
Transformation, or QVT) during the finalization phase of the 
specification -- which I think may address
Jeremy's concern about whether or not the mapping is sufficient for 
implementers to use.

More recently, we've been asked to provide forward and reverse mappings 
from SCL to UML/MOF
as well as to OWL, and mappings from the ER and Topic Maps metamodels to 
SCL.  Pat Hayes, who
was a great help to us in developing the SCL metamodel and mappings, has 
offered to help us with
some of this work, so our intent is to do as much as we can given the 
resources and time, without
risking delay in adoption of the work we've already done.  Likely much 
of this will happen during the
finalization phase of the specification's cycle through the OMG, again 
using the MOF QVT to document
the mappings once that specification stabilizes.  Some would argue, 
then, that it makes more sense
for the SCL metamodel to be the hub, given that it is more expressive 
... but we wanted to ensure
that developers who did not need that level of expressivity could 
effectively use the ODM as a
basis for model interoperability.  So -- we have (or will have) 
essentially two "primary" metamodels
(three including the combined RDF/RDFS metamodel) that we leverage for 
forward and reverse
engineering, and others that can be used to leverage existing resources 
as a basis for ontology
development in UML.

I hope this helps clarify the intent.  Please feel free to point out 
anything that might preclude us
from achieving this, or any thoughts that would improve the 
specification in general.  We really
are delighted to see that it is getting serious attention, and welcome 
as much feedback as people
have time to provide.  Since my focus has been on the SCL material in 
particular, I would
also appreciate any feedback on that work for those of you who have time 
and inclination.

Best regards,

Elisa


Jeremy Carroll wrote:

>
>
> My own nervousness was less well-informed.
> I believe this document is an important one, and that we should be 
> encouraging it to completion as quickly as possible.
> Hence comments should, in my view:
> - help correct the document
> - point out important weaknesses
> - or be supportive
>
> As far as I could tell, and I am glad that someone better informed 
> about UML than me tended to agree, the hub-and-spoke comment did not 
> point out an important weakness, but articulated an alternative 
> design. To fully address this comment I think would take quite some 
> time, since it's a few steps backwards before going forwards, and I 
> don't see (any/enough) benefit for this cost. (All process - no 
> content :( )
>
>
> Jeremy
>
>
>

Received on Thursday, 27 January 2005 19:29:49 UTC