ontology-summit
[Top] [All Lists]

Re: [ontology-summit] Invitation to a brainstorming call for the 2011 On

To: Ontology Summit 2011 discussion <ontology-summit@xxxxxxxxxxxxxxxx>
From: "MacPherson, Deborah" <dmacpherson@xxxxxxxxxxxxxxxx>
Date: Tue, 14 Dec 2010 13:50:04 -0500
Message-id: <43F2A07F08761449ABD2C0664C74D9FC1744E6B36B@xxxxxxxxxxxxxxxxxxxxxxx>

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


_________________________________________________________________
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/OntologySummit2011/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2011  
Community Portal: http://ontolog.cim3.net/wiki/     (01)
<Prev in Thread] Current Thread [Next in Thread>