ontolog-forum
[Top] [All Lists]

[ontolog-forum] Paper on how to build your first ontology

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Rich Cooper" <rich@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 14 Dec 2011 15:18:23 -0800
Message-id: <8C9DFAFAB1164627A15D9394DB1B669A@Gateway>
Dear Ontologizers,    (01)

On this forum, we have occasionally tried to
construct small example ontologies for
illustrative purposes, and occasionally for
practical purposes.  Here is a paper that may be
of interest to others on the forum:    (02)

http://protege.stanford.edu/publications/ontology_
development/ontology101-noy-mcguinness.html
"Ontology Development 101: A Guide to Creating
Your First Ontology"
By Natalya F. Noy  and Deborah L. McGuinness
Stanford University, Stanford, CA, 94305
noy@xxxxxxxxxxxxxxxx   and    dlm@xxxxxxxxxxxxxxxx    (03)


But the paper is truly naïve in its claims.  One
particular quote stood out to me glaringly:    (04)

                Separating the domain knowledge
from the operational knowledge is another common
use of ontologies. We can describe a task of
configuring a product from its components
according to a required specification and
implement a program that does this configuration
independent of the products and components
themselves (McGuinness and Wright 1998). We can
then develop an ontology of PC-components and
characteristics and apply the algorithm to
configure made-to-order PCs. We can also use the
same algorithm to configure elevators if we "feed"
an elevator component ontology to it (Rothenfluh
et al. 1996).    (05)

I find this assertion amazingly naïve, though
commonly held among ontologists it seems.  More
acknowledgements of the historic data about such
reuse should be made any time this kind of claim
is made.     (06)

The historic data shows that such reuse is not
generally effective in practice.  The better
approach is to design a more generic algorithm
(i.e., the object oriented version)  in the first
place, and then to forecast the cost, schedule and
difficulties of applying that algorithm to new
areas.      (07)

It is unfounded to claim that the PC configuration
algorithm would necessarily have similar
requirements to the elevator configuration
algorithm.  History shows that it won't; stating
the problem in a single sentence doesn't make the
problem simple.      (08)

Historically, that claim has not held up, and
there is nothing in ontological progress to
believe that it will in any near future.      (09)

-Rich    (010)

Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On
Behalf Of Michael Gruninger
Sent: Wednesday, December 14, 2011 7:32 AM
To: [ontolog-forum] 
Subject: Re: [ontolog-forum] Ontology, Analogies
and Mapping Disparate Fields    (011)


Hi Ali,
here is the submitted version of the modularity
paper.
You can put it up on your own url somewhere until
it is
accepted by Applied Ontology.    (012)

- michael    (013)

Quoting Ali SH <asaegyn+out@xxxxxxxxx>:    (014)

> Hi all,
>
> Just wanted to pass along a link to an ontology
related story (though it's
> barely framed as such) in a relatively
mainstream technology news outlet:
>
http://www.physorg.com/news/2011-12-link-patterns-
spider-silk-melodies.html
>
> While these are the originating papers (
>
http://arxiv.org/ftp/arxiv/papers/1111/1111.5297.p
df [1]) and (
>
http://math.mit.edu/~dspivak/informatics/ologs--ba
sic.pdf [2])
>
> It seems to me that the author is reinventing
the wheel (though with a nice
> twist re formulating / expressing o-logs and
"sketches").
>
> Especially since their review of the ontology
field (in the *
> ologs--basic.pdf* paper) seems to extend only to
RDF/OWL and completely
> ignores (or misses) work on Common Logic,
conceptual graphs and the most
> glaring omission - the work on category theory
in Bremen. Incidentally,
> such an omission appears to be an unfortunate
corollary of the crowding out
> of any non-RDF/OWL work.
>
> In any event, it's interesting work, though the
correlation between the two
> seemingly disparate fields (spider silks and
melody) reminds me more of the
> seminal "Unreasonable Effectiveness of
Mathematics in the Natural Sciences"
> speech -
http://www.dartmouth.edu/~matc/MathDrama/reading/W
igner.html [3]
>
> A lot of semantic mapping to date has indeed
focused on DL level mappings
> (cf Euzenat & Shvaiko's Ontology Matching book
[4]), but there is a rich
> set of logical mappings which can capture a lot
of these structural
> similarities between disparate fields. I know
I've repeated this claim
> before, but the limited expressivity of DL's
mutes many of these mappings,
> because well, they generally aren't captured
(can't be expressed) in the
> formalism. There is something to be said for
picking the correct language
> to describe a domain, where difficult problems
become much simpler. I
> suspect this will be one of the first major
obstacles in orchestrating
> services based on LOD sets beyond the low
hanging fruit currently being
> explored.
>
> In a previous discussion with Bijan, we were
talking past each other re
> reasoning over expressive ontologies. I kept on
talking about reasoning
> "off-line", while he insisted such projects were
fatally intractable. I
> later realized the disconnect was that I was
talking about verifying an
> expressive ontology (which you only need to do
once, hence off-line), while
> he was thinking that you need to process the
entire ontology for every
> query. Verification need be done only once (and
indeed, off-line), while
> the deployment of queries over fragments of the
ontology can then deploy
> more optimized tools.
>
> I think there's an attractive case for
articulating in some way, in some
> place, an expressive version of an ontology,
even if for certain services /
> tasks you only deploy a decidable fragment of
said ontology. For one, it
> can greatly facilitate semantic mappings, while
secondly, it makes the
> entire project more upwards compatible,
especially as the major DL's are
> continually adding greater expressivity. The
expressive version of the
> reference ontology can function a sort of road
map for deployment, a sort
> of technology agnostic commitment, whereas DL or
otherwise deployed
> artifacts are technology dependent products /
services...
>
> Lastly, I'd point out that the group at the
University of Toronto does have
> a paper on this topic (modularizing and reducing
expressive ontologies into
> ontologies of other types that preserve the
logical structure of the
> models), which has the incidental benefit of
being able to identify logical
> similarity between theories according to an open
repository... I will see
> if I have permission to distribute a pre-print
to the list (Michael?).
>
> ===
> [1] Tristan Giesa, David I. Spivak and Markus J.
Buehler "Reoccurring
> Patterns in Hierarchical Protein Materials and
Music: The Power of
> Analogies" BioNanoScience Volume 1, Number 4,
153-161, DOI:
> 10.1007/s12668-011-0022-5
> [2] D.I. Spivak, R.E. Kent "Ologs: a categorical
framework for knowledge
> representation". PLoS ONE (in press): e24274.
(2011)
> doi:10.1371/journal.pone.0024274
> [3] Wigner, E. P. (1960). "The unreasonable
effectiveness of mathematics in
> the natural sciences. Richard courant lecture in
mathematical sciences
> delivered at New York University, May 11, 1959".
Communications on Pure and
> Applied Mathematics 13: 1-14.
doi:10.1002/cpa.3160130102.
> [4] Jérôme Euzenat, Pavel Shvaiko. *Ontology
Matching*. Springer-Verlag,
> Berlin Heidelberg (DE), 2007
>
> Best,
> Ali
>    (015)

<<attachment: winmail.dat>>


_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: 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 join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (01)

<Prev in Thread] Current Thread [Next in Thread>