Folks,
I quickly created 3 ontologies that illustrate an integration ontology pattern:
Integration-a-b.owl imports both ontology-a.owl and ontology-b.owl. Then in integration-a-b.owl various equivalences are made.
Integration-a-b-ontology-imports.png shows the imports.
Ontology-a-classes.png shows the classes of ontology-a.owl.
Ontology-b-classes.png shows the classes of ontology-b.owl.
Classes-equivalences-integration-a-b-ontology.png shows the classes and equivalences of integration-a-b.owl.
The equivalences are shown as darker ovals in the last png file above.
I hope this is a helpful illustration of one very typical pattern.
Thanks,
Leo
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Andrea Westerinen
Sent: Tuesday, February 04, 2014 10:33 PM
To: Ontology Summit 2014 discussion
Subject: Re: [ontology-summit] OWl and Knowledge reuse via import and modularization
Gary, I emailed on this topic (importing everything versus modularity) a few weeks ago on
another Summit thread (and Leo expanded on it). Also, I just posted about it on my blog. Here is the text:
[My previous post talked ...] about creating small, focused "modules" of cohesive semantic content. And, since these modules have to be small, they can't
(and shouldn't) completely define everything that might be referenced. Some concepts will be under-specified.
So, how we tie the modules together in an application?
In a recent project, I used the equivalentClass OWL semantic to do this. For example, in a Person ontology, I defined the Person concept with its relevant properties.
When it came to the Person's Location - that was just an under-specified (i.e., empty) Location class. I then found a Location ontology, developed by another group, and opted to use that. Lastly, I defined an "integrating" ontology that imported the Person
and Location ontologies, and specified an equivalence between the relevant concepts. So, PersonNamespace:Location was defined as an equivalentClass to LocationNamespace:Location. Obviously, the application covered up all this for the users, and my triple
store (with reasoner) handled the rest.
This approach left me with a lot of flexibility for reuse and ontology evolution, and didn't force imports except in my "integrating" ontology. And, a different application could bring in its own definition of Location and create its own "integrating" ontology.
But, what happens if you can't find a Location ontology that does everything that you need? You can still integrate/reuse other work, perhaps defined in your integrating ontology as subclasses of the (under-specified) PersonNamespace:Location concept.
This approach also works well when developing and reusing ontologies across groups. Different groups may use different names for the same semantic,
may need to expand on some concept, or want to incorporate different semantics. If you have a monolithic ontology, these differences will be impossible to overcome. But, if you can say things like "my concept X is equivalent to your concept Y" or "my concept
X is a kind of your Y with some additional restrictions" - that is very valuable. Now you get reuse instead of redefinition.
|
ontology-b-classes.png
Description: ontology-b-classes.png
onotology-a-classes.png
Description: onotology-a-classes.png
classes-equivalences-integration-a-b-ontology.png
Description: classes-equivalences-integration-a-b-ontology.png
integration-a-b-ontology-imports.png
Description: integration-a-b-ontology-imports.png
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014
Community Portal: http://ontolog.cim3.net/wiki/ (01)
|
