Gary --
You wrote...
"Several issues arise even from such a simple example. To begin with,
the representation using existential restrictions (i.e.
owl:someValuesFrom) does not clearly communicate all of the semantics
we may want for car parts. For example, a strict reading of the
definition of the Crankcase class above is that a crankcase is part of
at least one engine. In point of fact, a crankcase cannot be part of
more than one engine. We may be tempted to add a cardinality
restriction (e.g. maxCardinality 1) on partOf to the definition of
crankcase, but this would be a mistake; since partOf is transitive, a
crankcase is also part of the car the engine is part of. Note also that
OWL-DL does not allow transitive properties to have any cardinality
restrictions. In general it is best to avoid placing restrictions
(including range restrictions) on transitive properties at all.
Indeed, once one starts to represent real world things, it seems that
they often do not fit into the OWL "either transitive or not
transitive" mold.
So, the question then is whether OWL (1.1?) can usefully represent
things that are mostly transitive, but with niggling non-transitivities?
Another example is "transitive over" as in [1,2]. Can that be represented in recent versions of OWL?
If the answer is No, then are we heading to a future in which OWL gradually gets displaced by some more flexible approach?
Cheers, -- Adrian
Internet Business Logic
A Wiki for Executable Open Vocabulary English
Online at www.reengineeringllc.com Shared use is free
Adrian Walker
Reengineering
[1] www.reengineeringllc.com/demo_agents/TransitiveOver1.agent
[2] www.reengineeringllc.com/demo_agents/OwlResearchOnt.agent
On 5/6/07, Gary Berg-Cross <gary.berg-cross@xxxxxxxx> wrote:
Pat,
In responding to Barry's comment on OBO:
Barry>>The OBO Foundry has no objection to mappings a la alternative (3)
>(see http://obofoundry.org/cgi-bin/table.cgi?show=mappings
<https://mail.em-i.com/exchweb/bin/redir.asp?URL=""
> ), though
>it has proved much more difficult in medicine than Pat here suggests.
>(3) may indeed be the right solution in the long run. But I believe
>that it can be successful only if different groups first follow
>alternative (2) in coherent fashion to create a solid basis for later
>>mappings. For alternative (3) surely gives ontology developers too
Barry >>little guidance as to what to do in the short run.
You said,
Pat>Perhaps. But what bothers me is this idea that ontology developers
need to be given 'guidance'. By who? By the ontology experts? But
there are no ontology-writing experts, really. We are all beginners
at this game. By philosophers? Excuse me while I laugh. By engineers?
Librarians? Software designers? Management experts? Nicola Guarino?
There are no end of people ready to give such advice, but none of
them have any real qualifications to do so; and all the advice given
Pat>is controversial.
I wonder if this is a tad strong. Would you agree that advice that shows up on representing
part-whole in OWL isn't helpful? For example,
Simple part-whole relations in OWL Ontologies W3C Editor's Draft 11 Aug 2005 at
http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/
provides the following advice/guidance that seems to me to be of value:
"In
many applications, what is needed is not a list of all parts but rather
a list of the next level breakdown of parts, the "direct parts" of a
given entity. It is therfore often useful to use the property hierarchy
to define a subproperty <http://www.w3.org/TR/rdf-schema/#ch_subpropertyof> of
hasPart that is not transitive and links each subpart just to the next
level. For these examples we shall call this subproperty
hasPart_directly. Note of course that the mere idea of a "direct" part
is subjective, one may invent intermediate direct parts depending on
numerous factors, or eliminate them. For example, we may choose not to
represent engine as a part of cars, but rather represent all the
components of engines as direct car parts. Grouping subparts into
larger parts may also be subjective, a common example is a flywheel in
a car, which can be viewed as an engine part or a transmission part in
an ontology that includes those classes.
Choosing whether to use partOf or hasPart
OWL supports inverse relations <http://www.w3.org/TR/owl-ref/#inverseOf-def
>
, so we can define an inverse of partOf, say hasPart. For any two
individuals I1 and I2, if "I1 partOf I2" then "I2 hasPart I1". However,
care must be taken when using inverses in restrictions on classes. To
say that "All As are parts of some B" does not imply that "All Bs have
some As as parts", i.e. the restriction
(Class A partial restriction(partOf someValuesFrom(B))
does not imply
(Class B partial restriction(partOf someValuesFrom(A))
Therefore,
if we want to say both that "all As are parts of some B" and "all Bs
have part some A", we have to assert each statement separately. Such
pairs of statements are sometimes called "reciprocals". "
Later another issue is addressed and guidance provided when considering parts of a car (engine, lights etc.):
"Several
issues arise even from such a simple example. To begin with, the
representation using existential restrictions (i.e. owl:someValuesFrom)
does not clearly communicate all of the semantics we may want for car
parts. For example, a strict reading of the definition of the Crankcase
class above is that a crankcase is part of at least one engine. In
point of fact, a crankcase cannot be part of more than one engine. We
may be tempted to add a cardinality restriction (e.g. maxCardinality 1)
on partOf to the definition of crankcase, but this would be a mistake;
since partOf is transitive, a crankcase is also part of the car the
engine is part of. Note also that OWL-DL does not allow transitive
properties to have any cardinality restrictions. In general it is best
to avoid placing restrictions (including range restrictions) on
transitive properties at all.
It would make more sense to add a
restriction on the partOf_directly property in the definition of these
classes, when it is appropriate. A single crankcase cannot be a direct
part of more than one engine, an engine cannot be a direct part of more
than one car, etc., so in these cases a maxCardinality restriction
would make the semantics more clear. "
So my question is, would
agree that such discussions are useful for clarifying issues in a
general sense and with a particular represenation in
particular? Aren't we all invested in a general effort to
"think clearly'?
Gary Berg-Cross
EM&I
Herndon VA
703-742-0595
________________________________
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
on behalf of Pat Hayes
Sent: Sat 5/5/2007 1:30 PM
To: Smith, Barry
Cc: [ontolog-forum]
Subject: Re: [ontolog-forum] Finnegans Web
> >PatHayes writes:
>>The real problem that
>>we face is this. One can take two people who agree completely about
>>the facts, and agree to use the very same logic to represent those
>>facts in, and yet they will produce different ontologies. (The
>>well-known example of how best to represent time and change is the
>>one I know in the most detail.) Moreover, those ontologies can be
>>formally inconsistent with one another. One cannot simply merge
>>together sentences from two such ontologies and expect to get a
>>sensible result. There are no *experiments* to resolve such
>>ontological differences, since the two authors agree about the
>>empirical facts; but one (for example) insists that there are two
>>distinct ways of existing in time, while the other treats these
>>simply as two (amongst many) ways to carve up a spatiotemporal
>>universe. The two authors here might be Barry Smith and me,
>>respectively. The differences are not empirical, but (sorry)
>>philosophical: in fact, they are *ontological*, in the original,
>>pre-AI, pre-Web, sense of that word. They reflect divergent,
>>incompatible, ways of thinking about some aspect of the world.
>>Differences like this cannot be resolved experimentally; and all the
>>evidence so far available suggests that to even attempt to 'resolve'
>>them, in the sense of deciding on a winner, is only going to alienate
>>a sizeable fraction of the user base.
>>
>>Now, what should we do about this? All the proposals I have ever
>>heard boil down to one of three alternatives: (1) ignore it and hope
>>it will go away (2) for each such conceptual debate, decide on one of
>>the alternatives and make it the single standard (somehow: perhaps by
>>compulsion, as some military funders seem to assume; perhaps by
>>commercial pressure, as PatC seems to suggest) or (3) find ways to
>>translate between them as they arise. I strongly believe that the
>>only long-term feasible method is (3), and we have made considerable
>>progress along these lines, enough to suggest that the translations
>>are always possible and often fairly easy, once one approaches the
>>problem in a pragmatic frame of mind. If all ontologies were written
>>in IKL, we could definitely do the translations for almost all of the
>>problems I aware of. In particular, option (2) simply isn't going to
>>work. People will simply not agree on what is the single right way to
>>write ontologies. Nor should they have to: there is absolutely no
>>reason why they should. Any attempt to enforce (or otherwise
>>persuade) the entire planet will only produce the kind of
>>interminable semi-philosophical debates that we are already having.
>
>Pat is doing very well
Thank you, Barry.
>until he inserts the phrase 'enforce ... the
>entire planet' into the discussion.
Perhaps the rhetoric did get a little flowery there.
>The OBO Foundry
>(http://obofoundry.org <http://obofoundry.org/> ) is realizing alternative (2), for biomedical
>ontologies, by involving only certain parts of the planet on an
>entirely voluntary basis.
Oh, let me say at once that I have no problem with this, and didn't
mean to argue against such initiatives. Of course alternative (3)
isn't meant to imply that every single separate ontology must be done
in isolation; quite the contrary, in fact. The SWeb idea envisions
communities forming, or being organized, which will cohere around the
use of an agreed ontological framework. I hope that many such flowers
bloom, and that many people get trained in their use, just as there
are such intellectual clusters in almost every technical domain of
application (the XML 'community', the UML, PSL, XMD 'communities',
etc..)
>One benefit we can claim is that we are
>giving non-experts in ontology much needed guidance as to how to
>represent, for example, size for tumors in such a way as to do
>justice to the fact that this varies with time. If all biologists
>working together on a given set of problems can be encouraged to
>represent this in the same way, then benefits of different sorts
>flow. We are visibly making progress as a result.
No doubt: and I don't mean to in any way disparage the advantages of
this arrangement when it works (and virtually any such framework is
better than no framework at all, no doubt). However, any such agreed
method has its dark side: things it cannot represent as well as a
different approach can. There is no universal ontological solvent. So
there will be rivals, developed perhaps for a different purpose but
which someone will discover can be used in this domain very usefully
for some purposes (just as people discovered that Petri nets can be
used to plug some expressive gaps in description logics). Then one
has a choice: to instruct them not to do that, or to find some way to
put the rival frameworks together. The problem now is that this way
will almost certainly involve moving outside the ground rules of both
of the frameworks, and doing something 'illegal'. And if those
notions of what is 'legal' have been incorporated into standards or
(worse) into software, then this translation process has been
artificially made much harder than it needs to be.
>The OBO Foundry has no objection to mappings a la alternative (3)
>(see http://obofoundry.org/cgi-bin/table.cgi?show=mappings), though
>it has proved much more difficult in medicine than Pat here suggests.
>(3) may indeed be the right solution in the long run. But I believe
>that it can be successful only if different groups first follow
>alternative (2) in coherent fashion to create a solid basis for later
>mappings. For alternative (3) surely gives ontology developers too
>little guidance as to what to do in the short run.
Perhaps. But what bothers me is this idea that ontology developers
need to be given 'guidance'. By who? By the ontology experts? But
there are no ontology-writing experts, really. We are all beginners
at this game. By philosophers? Excuse me while I laugh. By engineers?
Librarians? Software designers? Management experts? Nicola Guarino?
There are no end of people ready to give such advice, but none of
them have any real qualifications to do so; and all the advice given
is controversial.
On the other side of the coin, I have been constantly surprised by
the extent to which people in the wide world have come up with new
ontological ideas when left to their own devices. Would anyone in the
existing 'ontology community' have thought of the idea of
folksonomies? Would anyone have thought that a virtually empty
ontology (the Dublin Core) could acquire great ontological force
simply from being re-used in a large, and essentially socially
defined, set of transactions (FOAF)? I certainly didn't predict
either of these, and I didn't hear anyone in the ontology community
predicting them before they actually happened. What worries me is
that by setting up 'academies' to explain to the great unwashed how
to use these terribly sophisticated tools we have invented, we may be
stultifying creativity and invention.
No doubt this tension between exposition and limitation is universal,
and both are needed. I think that Barry and I can agree that some
form of (2) and of (3) is necessary in the long run. What I tend to
protest about is a version of (2) which implicitly or explicitly
claims universality for the whole of human thought; but I agree that
great benefits can flow from organized attempts to create ontological
versions of a 'controlled vocabulary', especially for a technical
community for whom accuracy of communication is vital; and that do
achieve this it may be essential to impose a single overarching
ontological 'top level' framework on the whole.
>It is a bit like
>wanting to populate a library by encouraging people to write books
>using bits of Hebrew, bits of French, bits of Gaelic,
In my vision of the Sweb, it is more like throwing a lot of kids
together who all speak different languages. And what happens then is
that at first a pidgin is spoken, with a simplified and crude grammar
and a mix of vocabularies; and then, in one generation, an entirely
new creole language appears. Never underestimate the ability of
people to find ways to express things :-) And whether they talk
proper, like, in some teecher's opinion, ain't really to the point.
>and to
>encourage people not to worry about the resultant difficulties in
>understanding, because we will have Pat to translate it all into IKL
>and sort out translations as the need arises.
Not Pat, but the products of the IKRIS project and then some. In
fact, we are already starting a project (which my friends, indeed,
call "pat-in-a-box") to automate these translation strategies as part
of a general-purpose ontology interface. If we ever get it done, it
will be openly and freely available.
Pat
PS. Great subject line, Barry.
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki:
http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (01)
|