Hans,
I agree. I have advocated pragmatic (yes, formal pragmatics) policies in the past, for the interpretation of ontologies. These are themselves ontologies/rules
which guide/prescribe/proscribe the interpretation of the ontologies on a given site or for a given use. There are some early ventures into this realm, using e.g., policy languages that evolved from other notions, i.e., agent-based systems, etc. But not a
whole lot yet.
There are some conferences, etc., addressing a “Pragmatic Web”, but folks need to understand more the real need for policies, i.e., how one should interpret
a given set of ontologies. Really the current state of practice is in informal representations of this, via annotations, documents, etc. But symbolic representation that could be interpreted would help. Not that that’s easy. It’s comparable to pragmas for
programming languages, i.e., instructions to the compiler on how to address this particular code. We are not far along yet.
Thanks,
Leo
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Hans Polzer
Sent: Friday, February 07, 2014 6:58 PM
To: 'Ontology Summit 2014 discussion'
Subject: Re: [ontology-summit] OWl and Knowledge reuse via import and modularization
Leo,
I would add something about the intended scope of applicability. For example, if the ontology is intended for supply chain management, does it include consideration
of international boundaries and the legal/regulatory/financial considerations associated with crossing such boundaries, and if so, does it handle all countries (on Earth) or just some specific set of countries. If its scope is strictly national, which nations
does it support? Some nations have internal boundaries which impact supply chain management. Other supply chain management scope dimensions might relate to the type of “supplies” that are to be managed. For example, does the ontology treat provisioning of
services (physical or electronic) as a supply to be managed? Does it handle fungible and bulk goods? Does it handle uniquely identified supply items (e.g., items with serial numbers). Does it support chain of custody or similar environmentally constrained
shipping considerations, such as in the case of certain medical supplies or perishable goods? I could go on, but I think this should help convey the idea of scope of applicability.
Hans
Gary,
Yes, indeed. Really the ontologies require more documentation:
1) Definitions of what the classes/properties mean in standard natural language (English, etc.)
2) If available, more strict axiomizations: in OWL ontologies, if the axioms exceed OWL expressivity, one can express these in textual annotations.
3) The use cases (pragmatics) for classes/properties/axioms, at least expressed in ontology-general or more specific textual annotations.
Other:
4) Are instances available, and can we compare them against their specific (1-3) documentation?
The given example is very simple, and for real application, would need 1-4 to help assure us that the equivalences are accurate.
Thanks,
Leo
Thank you for advancing the conversation. Concrete, illustrative examples can help focus the discussion. And you've shown how to do it if the concepts are equivalent or thought so.
In your examples things are a bit simple and would be a bit more difficult, I think, with ontologies that were generated without considering what had been done in a domain. So for example equating/equivalence
between A and B ontologies seems directly possible, but if one of them was a bit more precise and detailed and said that PLACE hasA LOCATION then we might not equate PLACE in A with LOCATION in B.
We'd know more about what is meant by the 2 concepts if we looked at the data instances they represent and found that in A we have place locations like Grand Canyon and in B they are lat-lon.
SOCoP Executive Secretary
On Fri, Feb 7, 2014 at 3:05 PM, Obrst, Leo J. <lobrst@xxxxxxxxx> wrote:
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
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.
_________________________________________________________________
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/
|
_________________________________________________________________
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)
|