On 14/04/2010 5:52 PM, Cory Casanave wrote:
> John,
> I would suggest an additional requirement:
> * Semantic Encapsulation
> It should be possible to use and reference a concept defined in another
> ontology without trusting all assertions in that other ontology or
> including the other ontology. The view of the other ontology should be
> limited to the semantics required to be shared between the two domains.
>
>
In software engineering, there are 2 approaches used to resolve issues
similar to this.
1) Create smaller libraries with dependencies on other libraries. Do not
put too much in one ontology.
2) Provide for statements of exclusion to permit the user to say "I want
library X as part of my project but exclude the following dependencies
from X since I have my own functions that replace the functions that
library X needs to be functionally complete. (01)
This places the responsibility on the user to ensure that the resulting
package of artifacts is sufficiently complete to meet the needs and is
compatible to the extent required. (02)
> This is, perhaps, also an addition to the possible relationships between
> ontologies in your SIO paper.
>
> Example: Consider that I have a process model in organization-A that
> uses a process in organization-B. Both models are published on the web.
> I want to be able to use the organization-B process as a sub-process in
> organization-A and thus know how to evoke it and perhaps pass data and
> rights. I do not, however, want to commit to anything else in that
> other ontology which would require substantial integration. The net
> effect of requiring such deep integration in a lattice of architectures
> would be both impractical and fragile. What I do what to be able to say
> is that I am using this other process and agree it is a process - but
> with minimal commitment to anything else.
>
>
You have to replace any part of organization-B's process that you want
to exclude. In software, the compiler and build process will check this
for you and tell you if B might collapse because you have not provided a
piece that it needs to be functionally complete.
Depending on the guys who implemented the build, they may still let you
try to run the combined artifact and let you deal with the collapse if
it happens or thety might just refuse to continue until you have either
provided the missing pieces or explicitly promised to replace the piece
before you run it. (03)
> Support: This seems to be a general problem with FOL based integration.
> I would be interested in how an encapsulated reference may be supported
> in CL. Benjamin Grosof has made quite a few references to FOL
> fragility with respect to a rules based approach
> (http://www.mit.edu/~bgrosof/paps/talk-iswc2009-rules-tutorial.pdf).
>
> -Cory
>
>
I believe that for ontologies to become part of the application stack,
these problems need to be addressed. (04)
Ron
> -----Original Message-----
> From: sio-dev-bounces@xxxxxxxxxxxxxxxx
> [mailto:sio-dev-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F. Sowa
> Sent: Wednesday, April 14, 2010 12:12 AM
> To: sio-dev@xxxxxxxxxxxxxxxx
> Subject: Re: [sio-dev] Sharing and Integrating Ontologies
>
> Following is a note I sent to the AE-SIG project for the OMG.
>
> 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.
>
> If successful, it would really demonstrate the value of ontology
> for supporting software design and development.
>
> John Sowa
> ____________________________________________________________________
>
> 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.
>
> I'll relate this discussion to the following issues that were raised
> in the thread about the recent AESIG telecon:
>
> 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.
>
> 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.
>
> 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.
>
> Instead of trying to get a consensus on a foundation, it should be
> easier to get a consensus on requirements. Some observations:
>
> 1. The systems mentioned above (and a few others) are important.
> Therefore, any foundation should support all of them.
>
> 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.
>
> 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.
>
> 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.
>
> Given these observations, I suggest the following requirements,
> which do not make any assumptions about the kind of logic:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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:
>
> http://ontolog.cim3.net/file/work/SIO/2010-03-25_Getting-SIO-Started/Ont
> ological-Modularity-for-Shared-and-Integrated-Ontologies--JohnBateman_20
> 100325.ppt
>
> 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.
>
> 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.
>
> 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.
>
> That comment is compatible with what the SIO project is doing.
> The same tools can be used to relate models or metamodels.
>
> EB> I think we are largely in agreement in concept, but we disagreed
> > on the words.
>
> Yes, the SIO gang also has other terminology, but I believe that the
> the SIO tools would be very useful.
>
> John Sowa
>
>
> _________________________________________________________________
> 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
>
>
>
> _________________________________________________________________
> 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
>
>
> (05)
_________________________________________________________________
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 (06)
|