[Top] [All Lists]

RE: [ontolog-forum] Ontology mapping & "theorems for free"

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Holmes, Scott L. (SSS)" <holmes-scott@xxxxxxxxxxx>
Date: Sat, 11 Dec 2004 16:49:57 -0500
Message-id: <583F821690F46143908F09388640FD8501A3954E@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Please excuse the layout of this. I'm using a tool called Compendium
http://www.compendiuminstitute.org/ and I'm still trying to get a handle
on it's export capabilities.    (01)

Collaborative Construction of Ontologies    (02)

After reading over Nicolas's thoughts on Mark Munsen's presentation, I
thought I'd explore some ideas on the process of collaboratively
Constructing Ontologies. My assumption (like Nicolas) is that process of
collaborative Ontology development is similar to the process of
collaborative Software development. Collaborative process is the key
term here. It seems to me to be very risky to map Object Oriented
Analysis and Design techniques on to the actual content of Ontologies -
I'm constantly having to correct myself while developing an ontology
because I'm personally very OOA/D oriented and ontology classes and
properties are definitely not software objects and classes - this much I
know so far.    (03)

Is it possible to replace NCI CMS with Open Source CMS?    (04)

In looking at what amounts to NCI's Content Management System (CMS) for
ontology development, it appears to me that this proprietary network
could be replaced by an Open Source CMS such as Source Forge/CVS or
Plone CMS. A beautiful drawing of the NCI/Apelon system is on page 48 of
Mark Munsen's power point presentation:    (05)

http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2004_12_09    (06)

In addition, there appears to be some additional workflow concerns as
pointed out in the recent posts to the forum by Nicolas F Rouquette. In
my experience with collaborative efforts such as software development,
I've noticed how natural it is to impose restrictions on my fellow
developers to control how much can be done by any one team member. The
idea of placing limits on Scope, Contract and Extension points is a good
one. I actually thought these through out already in my study of
Ontology development but I didn't have the terminology to put these
concerns in words. For that I thank Nicolas.    (07)

For truly collaborative work on an Ontology, I believe some sort of
Content Management System is required. Version control is quite
important as Adam has pointed out. Elevation to a published work
requires very much testing and peer review. A normative Ontology would
almost certainly have to be voted on. Creating a collaborative
environment to support all of this will be quite an effort.    (08)

Over the last several years, I've been on a quest to find that perfect
collaborative environment to support just a small IT staff and a handful
of Financial team members. This search has been fruitful but there have
been huge disappointments along the way. The information I present below
may be assistance to Peter and others who are contemplating just such an
environment (as evidence by the outstanding Ontolog Wiki).    (09)

Source Forge CVS    (010)

Source Forge is an extremely popular repository of Open Source projects.
The backbone of a well thought out Open Source project uses Source
Forge's CVS repository to manage version control.     (011)

Reference:http://sourceforge.net/index.php    (012)

Reasons to use Source Forge    (013)

Source Forge has an extremely large user base and is well supported.
Source Forge is well funded and is in a state of constant improvement.    (014)

The security system is based on PuTTY keys and seems to be adequate.    (015)

The CVS repository at Source Forge is very mature and highly robust.
Generally, the user interface is easy to use after some initial
training. CVS includes a very easy to use Check In only feature. This is
ideal for small teams. The idea is that a diff function runs upon Check
In and any conflicts are presented to the developer for resolution. CVS
also includes a more traditional Check In/Out function with support for
file locking, etc.    (016)

The version control paradigm used by Source Code CVS is completely
managed by the Source Forge servers. All interaction with the CVS
servers is performed using client applications. In other words, there is
no software to install at the server side.     (017)

Reasons to not use Source Forge    (018)

Source Forge is designed by software developers for software developers
and has a highly technical look and feel throughout the system. Source
Forge CVS technology relies on CVS compatible tools developed by
commercial enterprises and other third parties. Subsequently the CVS
tools are not transparently integrated as they could be and will present
steep learning curves for new users.    (019)

Source Forge CVS does not allow any direct scripting or other
customizations to the basic work flow.    (020)

Source Forge can be very slow in response. Servers are in the process of
being upgraded, but the entire user base shares the same resources
generally so bottlenecks will probably always be a minor irritant.     (021)

Plone CMS    (022)

Plone is a mature and robust Open Source CMS developed by the users of
ZOPE, a large scale Open Source work flow engine optimized for CMS
duties. The user community is extremely large and very active.     (023)

Reference:http://plone.org/    (024)

Reasons to use Plone    (025)

Plone has a very attractive user interface. The user interface is
entirely web based. Users create articles that are submitted to an
editor for editing and publishing (or rejection back to the author).
Version control is managed by ZOPE which has an extensive web based user
interface with many features and plug ins.    (026)

Plone (and ZOPE) is written entirely in Python. There are tutorials and
examples available to assist with the creation of new content types (the
basic structure of a CMS entity). Subsequently Plone may be extended by
reusing existing content objects and by creating new ones.    (027)

Plone primarily generates XHTML 1.0 Transitional which is far better
than most of the other CMS systems out there.     (028)

Reasons to not use Plone    (029)

ZOPE is developed in Python which is primarily a server side scripting
language. There is much to set up on the server side. Mostly this
entails the uploading of files to the appropriate places. Interaction
with the host of the server may be required.    (030)

Not quite clear on the security of Plone. Needs research.     (031)

Ontology Development is much more than Check In Check Out.    (032)

Additional workflow would be preferred. Some way of enforcing Scope,
Contract and Extension Point would be a good first step.     (033)

jBpm/JBoss    (034)

JBoss jBpm is a flexible, extensible workflow management system.
Business processes, expressed in a simple and powerful language and
packaged in process archives, serve as input for the JBoss jBpm runtime
server.     (035)

Reference:http://jbpm.org/    (036)

This is probably a topic for another discussion, but I believe Ontolog
may benefit greatly by providing a user friendly collaborative
environment much like the Ontolog Wiki that facilitates the design,
implementation and publishing of normative Ontologies. This would be
very exciting and has the potential to get many more people
(particularly business people) involved in the some of the forum's
goals.    (037)

Scott L Holmes    (038)

-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Nicolas F
Sent: Friday, December 10, 2004 1:50 PM
To: ontolog-forum@xxxxxxxxxxxxxxxx
Subject: [ontolog-forum] Ontology mapping & "theorems for free"    (039)

Has anybody noticed a strong kindship between the issues we face in 
modular / formal ontology development
relative to issues of mapping and the ideas of Galois connections & 
"theorems for free" ?    (040)

While I was listening to Mark Musen's presentation,    (041)

9    (042)

I started to think about how good software engineering practices solve 
some of the
problems of ontology development such as those Mark mentioned in the
of NCI's change management process.    (043)

The issues there are about dealing with the distributed changes to 
various parts
of an ontology or to several ontologies that are used in diverse 
The problems stem from the fact that we can never anticipate all
ways in which somone is going to use an ontology or depend on several 
The changes made can affect such users and break the logical foundations    (044)

need for whatever reasoning tasks they do (classification, subsumption, 
query, optimization, compilation, ...)    (045)

 From a software point of view, it seems that ontology development lacks
a precise way to talk about software engineering notions like scope, 
dependencies, extension points, .... I know that there's a lot of work 
in ontology
with the notion of "topic map" and "concept map"; I don't know enough
that line of work to tell if the issues they have looked into adress all    (046)

of the
software engineering concerns of distributed change management.    (047)

There is an alternative approach to change management with the idea
of using category theory, Galois connections and theorems for free as
a heavy-duty machinery to "proove" that the consequences of changes
made in an ontology wouldn't break properties we need in uses of that 
ontology.    (048)

This alternative approach is based on a paper I read from Kevin and 
Roland Backhouse:    (049)

http://portal.acm.org/citation.cfm?id=1007979    (050)

Kevin and Roland show an application of theorems for free and Galois 
in order to "proove" statements (safe abstract interpretations)
about a set of things (implementation level) in terms of logical 
properties about
functions and the way they are used to build an implementation (this is 
where I understand
we need to have a parametric and higher-order capability to talk about 
functions and about their application)    (051)

I wish that I could fully understand Kevin and Roland's paper.
Alas, I was raised in France, not Britain; but the more I attempt
to understand their paper, the greener British grass looks to me.    (052)

Seriously though, we can take a step back and see:    (053)

- OWL made a number of tradeoffs biased towards practicality.
- the field of abstract interpretation, etc... offers a number of 
interesting ways
  to get help from formal specifications
- an ontology is a formal specification of some kind    (054)

The connection here seems to me that:    (055)

- the DL formulas we use in an ontology stand for the functions that 
Kevin and Roland use to talk about abstract specifications    (056)

(e.g the x operator introduced in their running example on p. 2)    (057)

- the "fold" function stands for a specific kind of logical inference 
like classification, subsumption, etc..    (058)

(e.g., the concept of "defined class" in Protege/OWL)    (059)

Is this just a French/British cultural joke or is there something worth 
pursuing here?    (060)

My hunch is that theorems-for-free says: "here's a way to put a theorem 
proover to a practical use for ontology
development to answer some practical questions in a different way than 
is currently done or not done at all,
e.g.: upper/lower ontology consistency; compatibility of multiple upper 
ontology mixins.    (061)

If these comments make sense to you, I'd be very interested to read your    (062)

opinions/feedback/suggestions about them.    (063)

-- Nicolas.    (064)

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (065)

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (066)
<Prev in Thread] Current Thread [Next in Thread>