On 15/04/2010 10:27 AM, Cory Casanave wrote:
> Ron,
> A couple of additions are marked ([cbc]).
>
+1
> -Cory
>
> -----Original Message-----
> From: sio-dev-bounces@xxxxxxxxxxxxxxxx
>[mailto:sio-dev-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ron Wheeler
> Sent: Wednesday, April 14, 2010 7:08 PM
> To: [sio-dev] discussion
> Subject: Re: [sio-dev] Sharing and Integrating Ontologies
>
> 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.
> [cbc] Recognizing that this may not be possible if you don't own the
>dependent specification, which is common.
> 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.
>
> [cbc] There are at least 2 more patterns:
> 3) Provide specification of "public/private" facets in the model. This
>places responsibility on the publisher to understand what must be exposed.
>
> 4) Provide a way for the dependent specification to present a façade that
>complies with your requirements. Such a façade will be the subset of
>semantics both parties can agree on (the shared concepts).
>
> 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.
>
>
>> 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.
>
> [cbc] I was not talking about "replacing a part of a process", just calling
>it in their execution context. Or for a "data" reference that would mean an
>ability to change your context to that of the referenced element to access
>additional capabilities. Of course we do this all the time in software.
>
>
>> 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.
>
> [cbc] +2
>
> 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
>>
>>
>>
>>
>
> _________________________________________________________________
> 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
>
>
> (01)
_________________________________________________________________
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 (02)
|