Following is a note I sent to the AE-SIG project for the OMG. (01)
I suspect that the tools that are being developed for the SIO
project could be very usefully applied to the requirements
for the AE-SIG. It would be an interesting and important test
case for the SIO tools and methodology. (02)
If successful, it would really demonstrate the value of ontology
for supporting software design and development. (03)
John Sowa
____________________________________________________________________ (04)
I'd like to comment on several issues that have come up in different
threads on this list and to suggest a project that could be done in
collaboration with Ontolog Forum. (05)
I'll relate this discussion to the following issues that were raised
in the thread about the recent AESIG telecon: (06)
SI> For example, we have had MOF, Semantic Web, Common Logic & REMMS
> proposed as foundations to build on.
>
> The consensus on the call was that we should not lock that down in
> the RFP but should express requirements and evaluation criteria by
> which to make such a choice. (07)
JRA> We also agreed that ability for existing modeling languages
> to participate in the ecosystem without change, and that existing
> approaches to describing modeling languages using MOF-like diagrams
> are mandatory requirements. (08)
EB> The question to which I don't have an answer is whether the AESIG
> has to make the choice of an approach before issuing the Foundation
> RFP, or should issue the Foundation RFP and see whether we can get
> consensus on a part of the solution as a means of making our decision. (09)
Instead of trying to get a consensus on a foundation, it should be
easier to get a consensus on requirements. Some observations: (010)
1. The systems mentioned above (and a few others) are important.
Therefore, any foundation should support all of them. (011)
2. Every declarative notation used by any or all of the above
systems is either called a version of logic or its semantics
can be formally specified by a mapping to some version of
logic. Therefore, we can agree that whatever foundation is
adopted either is or can be mapped to some version of logic. (012)
3. But the various systems use different versions of logic,
and any solution that can accommodate all of them must be
sufficiently general to represent the semantics of all. (013)
4. It might also be true that some of them don't require as much
logic or as powerful a version of logic as others. Therefore,
there must be some way of systematically accommodating and
relating various subsets. (014)
Given these observations, I suggest the following requirements,
which do not make any assumptions about the kind of logic: (015)
1. The foundation shall be a version of logic that is adequate
to specify all information required by all the systems and
components that are supported by the AESIG architecture.
Until some specific logic is chosen, the temporary acronym
for the foundational logic shall be FL. (016)
2. Formal mappings shall be specified to translate FL to and
from all the notations, diagrams, and languages used by the
various systems and components. (017)
3. Since different systems and components may require different
expressive power in their notations, mappings from all notations
to FL shall always be possible. But some information expressed
in FL might not be mappable to a logic that is more restricted. (018)
4. Appropriate tools and methodologies shall be defined to
perform the translations, check whether certain translations
are possible, and assist in any conversions that may be
required for cases in which full mappings are not possible. (019)
5. Languages, notations, and diagrams with good human factors
shall be defined for expressing information in FL and other
notations in a way that designers, developers, and users with
different backgrounds find readable and convenient. (020)
6. Interchange formats among FL and other notations shall be
defined that are efficient for computer processing, storage,
and transmission and that can be accommodated by both legacy
systems and any new technology that may be developed. (021)
I won't hide the fact that I have a strong preference that FL
should be either Common Logic or some subset of it. That isn't
much of a restriction, since CL is already recognized as a
superset of most of the languages we have been talking about. (022)
However, I will admit that FL might not be full CL. In fact,
it is quite possible that some smaller subset of CL might be
adequate. (023)
JRA> Cory and I... recognize that in any hub (including those defined
> by existing modeling languages such as BMM, BPMN, SoaML, UML,
> UPDM, EXPRESS, etc.) defines a vocabulary and set of pre-defined
> viewpoints. We need a mechanism for defining those vocabularies
> (i.e., models) and viewpoints. MOF is the current approach with
> diagram definition emerging as a potential way of addressing the
> viewpoints. (024)
The word 'hub' is not one I would apply to the modeling languages
in that list. What I would say, however, is that each of them is
based on a declarative language at its core, which is equivalent
to some version of logic. But that core is extended with a
a considerable amount of built-in vocabulary. (025)
To use the term 'ontology', which is the main focus of Ontolog Forum
in general and the SIO project in particular, each of the modeling
languages listed above has a significant amount of ontology. That
ontology is what defines its built-in vocabulary. (026)
The SIO project already has some useful tools for relating different
logics and ontologies. Its goal is to extend those tools and to
develop a methodology for relating different ontologies expressed
in different versions of logic. Following are some slides by
John Bateman, who described the tools and methodology that he
and his group have been developing at the University of Bremen: (027)
http://ontolog.cim3.net/file/work/SIO/2010-03-25_Getting-SIO-Started/Ontological-Modularity-for-Shared-and-Integrated-Ontologies--JohnBateman_20100325.ppt (028)
These tools and others that are being developed for the SIO project
could be used to relate the logics and ontologies that define the
various modeling languages in the above list. I believe that some
collaboration between the two groups could be very useful for both. (029)
EB> ... we need to distinguish between 'integrating language
> metamodels' and 'linking domain models', and we need to provide
> a technology that supports the latter, as well as the former. (030)
JRA> Conceptually linking language metamodel and linking domain models
> is the same. What is being linked is different, as is the meaning
> of the links, and how the stakeholders view the linked content. That
> implies at least different stakeholder viewpoints. However, I don't
> think it need imply different mechanisms for capturing, extending
> and integrating the content (a metamodel is after all a model too)
> or how the viewpoints are created and linked to the model. (031)
That comment is compatible with what the SIO project is doing.
The same tools can be used to relate models or metamodels. (032)
EB> I think we are largely in agreement in concept, but we disagreed
> on the words. (033)
Yes, the SIO gang also has other terminology, but I believe that the
the SIO tools would be very useful. (034)
John Sowa (035)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/sio-dev/
Join Community: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/sio-dev/
Unsubscribe: mailto:sio-dev-leave@xxxxxxxxxxxxxxxx
Community Shared Files: http://ontolog.cim3.net/file/work/SIO/
Community Wiki:
http://ontolog.cim3.net/cgi-bin/wiki.pl?SharingIntegratingOntologies (036)
|