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