Deborah,
First, let me sneak in a response to your previous mail. The Multilateral Interoperability Programme has established a successful model-driven information exchange environment that does not rely on ontologies. The model in question is IDEF1-X. Information exchange is based on database replication, and more recently on XML message exchange guided by an XSD. Ontologies are planned for the future but the versions fielded to date (none of which are US-based, somewhat ironically) use those two mechanisms alone.
Now on to the meaning of “a little more effort”. UCore and BFO, having no properties, are really just taxonomies. The assertion of a superclass/subclass relationship in an ontology is easily mimicked by a foreign key in a relational database schema. So let’s say we create a table named Hierarchy, with two columns – one for a parent key and one for a child key. An application developer must expend a little more effort to:
1. Write a query that retrieves the subclasses of a given class
2. Write a query that inserts/modifies the subclasses of a given class
3. Present the information to a user using the language of taxonomy rather than database management.
The queries are trivial. The presentation isn’t hard. If this functionality is part of some larger application that involves some domain-specific analysis, the effort to implement it will hardly be noticed.
The situation gets a little more interesting when you start placing restrictions in your ontology. But many of them have obvious counterparts in a database schema. “property only Class” is just a type specification. “property some Class” usually means “property can’t be null” or “there is a 1-to-many, not 0-to-many, association between two classes”.
Now before you get the wrong idea, I want to state for all the world to know that I firmly believe in modeling as close to the domain of interest as possible, and I also believe an ontology gets you closer than a relational database. My objective is for the community to create ontologies that present an incontrovertible argument sufficient to convince programmers with DBMS experience that learning ontology technology is worth their time.
Steve Wartik
Institute for Defense Analyses
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of MacPherson, Deborah
Sent: Tuesday, December 14, 2010 1:50 PM
To: Ontology Summit 2011 discussion
Subject: Re: [ontology-summit] Invitation to a brainstorming call for the 2011 Ontology Summit
What is the " a little more effort" required for relational databases?
DEBORAH MACPHERSON, CSI CCS, AIA
Specifications and Research
Cannon Design
1100 Wilson Boulevard, Suite 2900
Arlington, Virginia 22209
Direct Line 703 907 2353
4 Digit Dial 2353
dmacpherson@xxxxxxxxxxxxxxxx
cannondesign.com
ü Please consider the environment before printing this email.
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Wartik, Steven P "Steve"
Sent: Tuesday, December 14, 2010 1:19 PM
To: ontology-summit@xxxxxxxxxxxxxxxx
Subject: Re: [ontology-summit] Invitation to a brainstorming call for the 2011 Ontology Summit
> So my recommended way of promoting ontology is to build on what
> programmers already know and use: UML diagrams.
>
> Most programmers ignore the OCL language, which is a version of FOL
> in a weird notation. My recommendation is to use controlled English
> as a replacement for OCL.
Would that I had a nickel for every time I've seen someone misinterpret a "controlled English" sentence. Unless you mean something like SBVR. Though in my experience, SBVR is somewhat limited compared to OCL, and requires more effort to write (if not to read). YMMV.
But back to the original point about the usefulness of ontologies. Ontologies compete against database technology, which: 1) is mature and stable; 2) executes very efficiently due to highly optimized code; 3) offers a powerful, standard query language that is implemented by every important vendor. Popular examples of ontologies (the wine ontology, UCore, the biomedical ontologies I've seen) do not contain anything that can't be represented in a relational database with only a little more effort. Furthermore, tools that support ontologies are largely Java-based, and hence slower. And if they’re not quite immature, they aren’t yet mature either.
My conclusion, then, is that end users are likely to understand the benefits of ontologies well before programmers.
What will be needed for programmers to see the light, in my opinion, is:
1. Relationships established among a set of distributed ontologies. Database replication is notoriously error prone in practice.
2. A widely used application whose capabilities rely on reasoning. There’s something you can’t do in a DBMS without a massive application development effort.
These are my priorities for convincing programmers. I’m sure you can add your own.
Steve Wartik
swartik@xxxxxxx