[Top] [All Lists]

Re: [ontolog-forum] Future directions [was Semantic Web shortcomings]

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "John F. Sowa" <sowa@xxxxxxxxxxx>
Date: Wed, 13 Aug 2008 18:42:19 -0400
Message-id: <48A3634B.40803@xxxxxxxxxxx>
Folks,    (01)

I changed the title of this thread from "Semantic Web shortcomings" to
"Future directions".  The main direction for the future should be on
integrating various tools, including the Semantic Web, in a way that
takes advantage of and builds on the best from all of them.  I'll
start with one of the later comments, by Ron W:    (02)

RW> What I want are better tools for building applications that are
 > based on the concepts behind the semantic web....
 > "What will happen if we turn off valve 298 in unit B?"  What are
 > the procedural steps required to verify that valve 298 can be closed
 > safely?"
 > "What is the best insurance product that we have for a business owner
 > with a wife and 2 kids in college?" What is the risk assessment for
 > this farm? What would be the premium? What information is missing to
 > complete this risk assessment?"    (03)

The first line sounds like a modest request for tools that use RDF(S)
and OWL, but the two examples get into complex planning and reasoning
that goes far beyond what any of the current Semantic Web tools can do.    (04)

Rather than saying that is a "shortcoming" of the SemWeb, it would be
better to consider Ron's note as a plea for a better integration of
*all* available tools.  The AI community has been working on tools for
planning and reasoning, the virtual reality people have been working
on simulations, the database companies have industrial-strength tools
for terabytes and petabytes of data, the communities for UML and other
design notations have valuable tools and methodologies.    (05)

There is an abundance of good technology from various sources, and
we should look for better integration of *everything*.  The SemWeb is
a good start, but we should emphasize *semantics*, independent of
notation.  XML is great for many purposes, but it is inefficient
for storage, data transmission, and complex processing.  Let's
focus on the semantic issues independent of notation.    (06)

MM> Frameworks like Ruby on Rails, PHP/Zend, and Python/Django have
 > gained wide acceptance and popularity in recent months (past 36
 > months or so) primarily due to their uncanny ability to get you up
 > and running on the Web in a matter of hours, not days.  You simply
 > need an idea, a relational database, and a server, and a few hours
 > of programming....
 > Ajith Ranabahu (PhD student at Wright State University) and I have
 > a short paper that summarizes some of this thinking that we presented
 > last year at ICSC (http://icsc2007.eecs.uci.edu/).  You can find a
 > PDF here for your perusal:
http://maximilien.org/publications/papers/2007/Maximilien+Ranabahu07a.pdf    (07)

That's another very important direction that must be accommodated.
Although most people who write about agile programming don't mention it,
Prolog is another extremely powerful language that is agile, logic
based, and compatible with RDBs *and* the WWW.  It is also used in
very complex reasoning tasks as well as mission-critical production
code.  (Experian is just one example).    (08)

AW> I'd argue that adding some missing items could still make the effort
 > viable...
http://www.reengineeringllc.com/Internet_Business_Logic_e-Government_Presentation.pdf    (09)

I would agree, but rather than use the verb "adding", I would suggest
using logic as a basis for *integrating*.  I would like to quote the
last slide in your presentation:    (010)

 > We need Natural Language to remove the semantic disconnect between
 > people and ontology notations.    (011)

As I said in a previous note, the sentences that follow "rdfs:comment"
can, with minor modifications, be written in a form that is readable by
*both* humans and machines.    (012)

AS> but IMHO SemWeb is not about software engineering. It is about
 > knowledge engineering.    (013)

RW> Software Engineering is required if you actually want anything
 > functional.  Otherwise all you get is words which is what we mostly
 > have now.    (014)

I agree with both of those comments, and I believe that we need both.
Different applications may need them in different proportions, but we
should have a framework that can accommodate *both*.    (015)

AS> Today we have databases but may be 5 years later we'll have
 > knowledge bases (formal ontologies) instead.    (016)

I'd like to remind people that the work on conceptual schemas, which
were a hot topic in the 1970s and 1980s, started in the database
community.  In fact, there were many people who worked on the
borderline between DBs and KBs who said that the primary difference
between them was a matter of emphasis on data storage or data
semantics.  One such person was me, in a paper from 1976:    (017)

    http://www.research.ibm.com/journal/rd/204/ibmrd2004E.pdf    (018)

Another one was a guy I collaborated with, Ted Codd.  Another one
was Tom Steele from AT&T, who said "The only logical notation for
conceptual schemas is logic."    (019)

LY> Yes, you can build the application in two hours or less, but
 > such proliferation does not bring a long-term solution to basic
 > problem of information overload. In fact, - it contributes to it.    (020)

I agree that rapid programming can often lead to sloppy code, but
many long-term projects have also been based on very poor designs.
A solid foundation in semantics should be able to support both
agile programming and highly disciplined projects.    (021)

CS> So what needs to be added to ontologies so that they can be
 > relevant to software engineering, yet without bastardizing that
 > essence you so rightly insist on?    (022)

The short answer is "integration".  But integration does *not*
depend on adding something, but on removing barriers between
different components and different ways of thinking about them.    (023)

For example, there was no excuse for building RDF(S) on triples,
when there had been 30 years of implementing and using n-tuples
in the tables of RDBs.  There was no excuse for designing RuleML,
when there was 25 years of using Prolog.  There was no excuse
for using "<something>" and "</something>" as delimiters when
there was 50 years of experience in using "(" and ")".  Etc.    (024)

Focusing on semantics can help us see what is fundamental
through a smokescreen of distracting notation.    (025)

John Sowa    (026)

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    (027)

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