ontology-summit
[Top] [All Lists]

Re: [ontology-summit] [ReusableContent] Reuse of Linked Data vis-a-vis R

To: Ontology Summit 2014 discussion <ontology-summit@xxxxxxxxxxxxxxxx>
From: Andrea Westerinen <arwesterinen@xxxxxxxxx>
Date: Tue, 28 Jan 2014 20:37:45 -0500
Message-id: <CALThp9njSeweZnLDbzWVgCCY=bo8-334_PcC0Rhq_a+RN-rNKQ@xxxxxxxxxxxxxx>
Elisa, I echo Leo's sentiment and observation that you developed FIBO given your constraints.  I totally understand and respect that.

One interesting observation that happened in the DMTF with CIM (the Common Information Model) is that we eventually moved each class to its own file - so that it could be maintained, evolved and tracked independently.  This was important as we did releases that updated or added many classes simultaneously.  It was quite easy to track the individual changes when we had this "extreme modularity".  Also, we had "profiles" related to how to use the classes to address particular management issues.  

I am certainly not advocating adopting the same approach for FIBO as CIM, but it is a data point (from another standards organization) that has proven successful.

Andrea


On Sat, Jan 25, 2014 at 6:33 PM, Obrst, Leo J. <lobrst@xxxxxxxxx> wrote:

Sure, Elisa, this is not meant as a comment on FIBO, etc., but as a general paradigm for integrating OWL ontologies.

 

Plus, of course,  it is a methodology that can be applied only when you have a certain complexity of ontology interaction and also, a certain maturity of understanding of ontologies by the larger community (our community is typically disparate software developers using the ontologies for various purposes, much smaller than that of FIBO, I think, and they kind of understand ontologies now and kind of trust us to do what’s right – a rare circumstance, in my experience).

 

I think you all probably developed FIBO as you had to, given your constraints.

 

Thanks,

Leo

 

From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Elisa Kendall
Sent: Saturday, January 25, 2014 5:34 PM
To: ontology-summit@xxxxxxxxxxxxxxxx


Subject: Re: [ontology-summit] [ReusableContent] Reuse of Linked Data vis-a-vis Reuse of Ontologies

 

Hi Andrea, Leo, & all,

I thought about this when we first started down the path, but the amount of work required just to get from the original EDM Council model in Enterprise Architect to where we are now was daunting as you might have guessed.  The first pass was really to get a decent baseline, and as you might imagine, there were many stakeholders with conflicting requirements to support.  I think this initial pass was really very informative for Mike Bennett and some other folks who have been following the process, though, and that may make them more amenable to doing even more modularization along these lines.  The biggest challenge is that there are OMGers who really want us to have far fewer modules, and to have one single UML model that corresponds to all of the FIBO Foundations OWL modules, which I've vetoed so far, but I'm not sure how likely I am to win the war on that front.  I think it defeats the purpose of having done all of the modularization work, and it would mean that the individual modules cannot evolve independently, which is a key requirement in my view.

The next phase of the OMG process is called finalization, and as part of that I have been thinking of filing issues against the current Foundations ontology to do some of this where it won't be disruptive to the other work in progress and where it makes sense to split things further.  We will need several integrating/mapping ontologies that bring all of the bits and pieces together for various use cases, I agree.  We currently don't have that at all, though there are two modules in Foundations that bring most of the others in.

Best regards,

Elisa

On 1/25/2014 11:32 AM, Obrst, Leo J. wrote:

Yes, good idea, Andrea. We do that in our own OWL ontology work, so that either the integration ontology I, consisting of equivalence or sub/superclass relations between the two ontologies A and B (you can also establish local property restrictions on the mappings if they make sense), simply makes those mappings or imports A & B, then makes those mappings.

 

We’ve also used this approach to expedite changes more dynamically (we have multiple kinds of software that use those ontologies), given that the individual ontologies may have distinct ontologists (sometimes in different companies) developing them. We then publish these mappings to the individual integrated ontology developers (A & B), who may choose to incorporate some/all of the integration ontology changes into their own ontologies directly. Then, when the next versions of ontologies are pushed out, we look at the integration ontologies and the other non-integration ontologies (using ontology-diffing tools, admittedly still relatively primitive), to determine the changes we need to make to the integration ontologies. Occasionally, it means that the integration ontology can go away, since one of the integrated ontologies has incorporated the changes, rendering the mappings moot.

 

Thanks,

Leo

 

 

From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Andrea Westerinen
Sent: Saturday, January 25, 2014 2:07 PM
To: Ontology Summit 2014 discussion
Subject: Re: [ontology-summit] [ReusableContent] Reuse of Linked Data vis-a-vis Reuse of Ontologies

 

In an offline conversation with TSchneider, I was discussing a possible approach for addressing the modularization vs "inclusive" definition problem (that occurs because you have to import all the related ontologies).

 

In a recent project, I used the equivalentClass OWL semantic to address the issue.  So, for example, in a Person ontology, I defined the Person concept with its relevant properties, but when it came to the Person's Location - that was just an under-specified Location class (in the Person namespace).  I reused a Location ontology (with its own namespace) for a complete definition of that concept.  Lastly, I defined an "integrating" ontology that specified the mappings between the concepts.  So, Person:Location would be defined as an equivalentClass to Location:Location.  

 

Obviously, the application covered up all this for the users and my triple store (with reasoner) handled the rest.

 

That left me with a lot of flexibility for reuse and ontology evolution, and didn't force imports except in my "integrating" ontology.  And, each application could have its own "integrating" ontology.

 

Andrea

 

On Fri, Jan 24, 2014 at 2:28 PM, Andrea Westerinen <arwesterinen@xxxxxxxxx> wrote:

Elisa, 

 

I do recognize that a lot of work went into FIBO to create smaller, more reusable content.  In fact, that was one of the positives that I highlighted in my presentation yesterday [1].  It was straightforward to find concepts and the annotation was amazing!

 

But, I did find that for many of the more "advanced" topics, there were imports of most of the FIBO Foundational Ontology. For example, People.rdf imported Organizations (and FormalOrganizations), Locations (and Countries and Addresses), Goals, etc.  So, the more interesting topic ended up being rather "inclusive."

 

Might there be a way to modularize this even more?

 

Andrea

 

 

 

On Fri, Jan 24, 2014 at 1:43 PM, Elisa Kendall <ekendall@xxxxxxxxxxxx> wrote:

Hi Andrea and all,

I agree wholeheartedly with your suggestions, below.  For the work we do at OMG, we are trying very hard to create smaller, reusable ontology "modules" for FIBO, and to make them understandable, not adding any axioms that we can't support for a wide variety of applications, and not including any that the SMEs can't agree on.  We also use a couple of other tests for modularization - whether or not a concept is useful independently, and whether or not its definition might evolve independently, which seem to be holding up in the testing we've done so far on the early FIBO specifications.  Your thoughts on defining axioms based on context are similar to an approach I use for client work with segregating axioms by use case.  I wish more practitioners would think along these lines.

Thanks for weighing in,

Elisa



On 1/24/2014 1:06 PM, Andrea Westerinen wrote:

One of the questions proposed in Track A (Common, Reusable Semantic Content) asks whether the reuse problems (and perhaps their solutions) are different in the Linked Data and ontology spaces.  

 

Certainly, the uses of the two technologies are different ... as Linked Data is about the "links" and supplying relatively simple semantic annotations and new links ... but ontologies come down to T-boxes (more formal class, relationship and/or axiomatic definitions) and A-boxes (instance definitions).  It is much easier to reuse small, targeted schemas that define Linked Data and various annotations (such as schema.org) than it is to reuse (typically much larger) foundational or domain-specific ontologies.  

 

In terms of time spent "getting up to speed", small, targeted definitions always win.  However, it is also much more likely to be able to do reasoning over (and more complex analysis of) ontologies and A-boxes.  And, one can more easily combine multiple ontologies (for example, with constructs such as OWL's sameAs, differentFrom, disjointWith, ...) than to combine (or reuse) multiple Linked Data schemas. In my experience, I have seen developers typically pick one schema and just stick with that.

 

Taking a lesson from the Linked Data world, I would posit that the characteristics that make Linked Data schemas more friendly and reusable could be applied to ontologies.  That would argue for:

 

 * Smaller, more modular, targeted ontology fragments

 * Separation of semantic (class and relationship) definitions from the axioms that prescribe them 

 * (Perhaps) Definition of a context in which the axioms apply (and the assumption that there may be more than 1 context and therefore more than one set of axioms)

 

Another lesson that the ontology world must learn is that the fragments must be vetted, have real uses and sponsors, and not devolve to multitudes of overlapping and (sometimes) contradictory proposals.  (I think that the biomed BioPortal community has done a good job with this.)

 

What do you think?

 

 

Andrea Westerinen

 

 

 

 

 

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



 

--

 




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




--

_________________________________________________________________
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)
<Prev in Thread] Current Thread [Next in Thread>