|
Leo, Elisa, et al,
Modularity is certainly an interesting challenge. The basic
questions are not that different to the modularity considerations
in any design exercise: too small and you run the risk of an
explosion of complexity between the modules; too large and you
lose the flexibility to use and combine the modules in different
ways for different use cases. As with design, part of the art is
making the modules coherent and thinking of the interfaces between
them.
An ontology standard like FIBO differs from a design exercise in
two important ways:
1. As an ontology, it aims to document business concepts rather
than to design a solution;
2. As a standard, its scope is not driven by individual use cases,
but is defined by scope of the logical and physical data for which
concepts are to be captured semantically.
However, in developing an ontology standard which may be used both
as a conceptual model and as a means to derive semantic tech
applications, we do need to consider the "design" aspects of
modularity as though this were a design effort. The OMG
participants in this initiative have given us considerable
leadership in this regard, and there are a number of explorations
in how to derive operational ontologies. The lessons learned from
these are what needs to feed back into the thinking about how big
or small the modules should be and where the boundaries should be
drawn between them. That is, the disposition of the modular
representation of the business reality, needs to be helpful to
developers. As an example, we have identified a broad range of
concepts around parties in roles, and a number of different
operational patterns that would each use different sub-sets of
these concepts.
In the original draft FIBO material, we followed something very
like "Ontology Design Patterns", in the form of archetypical sets
of concepts and the meaningful relationships between them (stuff
like events, activities, parties in roles, actors in processes,
contracts, transactions and so on). Different coherent sets of
concepts are recognizable within each broad domain, but the
messiness of the real world presents real challenges in the
depencies. As an example, you can't have an incorporated company
without equity, but you can't define equity without talking about
a company. Similarly in the archetypical models, the relationships
among agreements, parties, entities, commitments, contracts,
transactions and so on, have a lot of mutuality.
So I think there is a lot to think about in this area, and we
should draw lessons from the sort of experience Leo describes
below. We are still early enough in this part of the journey, to
have a chance of getting this right. Most of the work in figuring
out the business concepts has been done, but we are just starting
the process of identifying how to deliver the meanings of these
concepts in a way which supports the full spectrum of possible
applications. We also need to balance those different ways of
putting the meanings to work, so that what works best for one kind
of application does not make it harder to use the same material in
other kinds of application, including both conventional technology
deployment and Semantic Web applications.
Mike
On 25/01/2014 23:33, Obrst, Leo J. 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
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/
|
_________________________________________________________________
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)
|