[Amanda Vizedom <amanda.vizedom@xxxxxxxxx>]

Indeed, Andrea. I wanted to chime in when you mentiond this before, but had no time. Let me try a short note now.

The style of modularity you mention, with what another summit poster (forgive me for forgetting who at the moment) referred to as 'placeholder' concepts within modules, can be very effective. The most effective technique I've found to date, for some cases.

Two additional points are worth making about how two execute this for maximum effectiveness (they may match what you've done, in fact, but are sometimes missed & so worth calling out for others.

Point 1: lots of annotation on the placeholders. The location & connection of the well-defined concepts to link them to is often being saved for later and possibly for someone else. In order to make sure the right external concept is connected, whatever is known or desired of the underspecifies concept shoud be captured (in the location case, for example, may be that it needs to support enough granularit to be used for location at which a person can be contacted at current time, or must be the kind os location that has a shipping address, or is only intended to be the place of business of the enterprise to which Person is assigned & out of which they operate (e.g., embassy, business office, base, campus). That's often known or easily elicitable without leaving the focus of a specialized module, and can be captured in an annotation for use in finding existing, well defined ontology content and mappping.

Point 2: advantages of modules, as you described are best maintained when the import and mapping are done *not* in the specialized module, but in a "lower" mapping module that inherits the specialized module and the mapping-target ontologies.  Spindles of ontologies, which can be more or less intricate, allow for independent development and reuse of specialized modules, with lower mapping and integration modules, with a spindle-bottom that imports all in the spindle and effectivle acts as the integrated query, testing, and application module for all the modules contained in that spindle, providing a simplified and integrated interface to a more complex and highly modular system of ontologies. Meanwhile, specialized modules can be developed with SMEs who don't know, care, or have time to think about the stuff they aren't experts about, like distinguishing kinds location or temporal relations or the weather. Using placeholders and doing your mapping elsewhere may sound like extra work, but considering what it can enable, it can be an incredibly effective approach.

Best,
Amanda  

On Feb 4, 2014 10:33 PM, "Andrea Westerinen" <arwesterinen@xxxxxxxxx> wrote:

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.

Andrea

On Tue, Feb 4, 2014 at 2:34 PM, Gary Berg-Cross <gbergcross@xxxxxxxxx> wrote:

OWL provides an owl:imports construct that allows people to combine ontologies by including all the axioms contained in an external ontology in one’s local ontology. But then , everything in the transitive closure of the imported ontology becomes a part of the local ontology. Have people found this to be a problem for their work and if so what are best practices around it?

There seem to be a number of efforts to get around this,such as modular approaches  but I'm not sure what the experience has been with them.The 

Survey of modular ontology techniques and their applications in the biomedical domain
by

Jyotishman Pathak,* Thomas M. Johnson, and Christopher G. Chute has some discussion.

Survey of modular ontology techniques and their applications in the biomedical domain

Jie Bao, Giora Slutzki and Vasant Honavar proposed a modular ontology language to get around 

http://www.aaai.org/Papers/AAAI/2007/AAAI07-206.pdf

Perhaps others have some experience with what these discuss.

Gary Berg-Cross, Ph.D.  

gbergcross@xxxxxxxxx     

http://ontolog.cim3.net/cgi-bin/wiki.pl?GaryBergCross

NSF INTEROP Project  

http://www.nsf.gov/awardsearch/showAward.do?AwardNumber=0955816

SOCoP Executive Secretary

Knowledge Strategies    

Potomac, MD

240-426-0770

_________________________________________________________________
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/

--

Andrea Westerinen

T: 425.891.8407

arwesterinen@xxxxxxxxx or andreaw@xxxxxxxxxxx

http://ontolog.cim3.net/cgi-bin/wiki.pl?AndreaWesterinen

organizingknowledge.blogspot.com

_________________________________________________________________
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)