Semantic network DBMS [was: Re: Contexts (was Classes vs. Instances)]
- To: "Rich Cooper" <rcooper15@comcast.net>
- Subject: Semantic network DBMS [was: Re: Contexts (was Classes vs. Instances)]
- From: Douglas McDavid <mcdavid@us.ibm.com>
- Date: Thu, 4 May 2006 06:17:11 -0700
- Cc: "'Alan Ruttenberg'" <alanruttenberg@gmail.com>, "Avril Styrman" <Avril.Styrman@helsinki.fi>, bniemann@COX.NET, "Cory Casanave" <cbc@enterprisecomponent.com>, cg@CS.UAH.EDU, "Nigam Shah" <nigam@psu.edu>, "'Paul Prueitt'" <psp@virtualTaos.net>, "'Paul J. Werbos'" <pwerbos@nsf.gov>, "Rolf Schwitter" <rolfs@ics.mq.edu.au>, "John F. Sowa" <sowa@BESTWEB.NET>, standard-upper-ontology@ieee.org, standard-upper-ontology@listserv.ieee.org, "Susan Turnbull" <susan.turnbull@gsa.gov>
- In-Reply-To: <004001c66f25$de7b8d70$6400a8c0@RCOOPER>
- List-Help: <http://listserv.ieee.org/cgi-bin/wa?LIST=STANDARD-UPPER-ONTOLOGY>, <mailto:LISTSERV@LISTSERV.IEEE.ORG?body=INFO STANDARD-UPPER-ONTOLOGY>
- List-Owner: <mailto:STANDARD-UPPER-ONTOLOGY-request@LISTSERV.IEEE.ORG>
- List-Subscribe: <mailto:STANDARD-UPPER-ONTOLOGY-subscribe-request@LISTSERV.IEEE.ORG>
- List-Unsubscribe: <mailto:STANDARD-UPPER-ONTOLOGY-unsubscribe-request@LISTSERV.IEEE.ORG>
- Sender: standard-upper-ontology@ieee.org
Rich --
In response to:
"However, I have seen good papers about the functional data model (FDM)
method of database representation where all the concepts are nodes and all
the relationships are arcs between pairs of nodes, and every relationship
has an inverse. It is very simple to construct an FDM with partial
knowledge of the application requirements, and change it quickly, as
compared to the usual SQL method. The only problem yet to be solved is
that FDMs are hugely inefficient when represented in that simple way."
Back in the late '80's I had access to an IBM dbms that was never
productized. This was before I joined IBM, and was approached as a
potential customer. This dbms was organized as the FDM you described.
This dbms had the advantages of extreme flexibility, and was lightning fast
on retrieval. A key design decision was to separate the data from the
pattern-processing language that manipulated the data. I put all this in
the past tense, unfortunately, as a Betamax-like footnote to the history of
technology.
By the way, one representation method like your FDM is NIAM (ORM). I think
I'm dating myself here!
Doug McDavid
Business Transformation Architect
IBM Academy of Technology - http://www-306.ibm.com/ibm/academy/index.html
mcdavid@us.ibm.com
408-927-1565 (IBM tie-line: 457)
"Rich Cooper"
<rcooper15@comcas
t.net> To
Sent by: "Avril Styrman"
standard-upper-on <Avril.Styrman@helsinki.fi>
tology@ieee.org cc
"John F. Sowa" <sowa@BESTWEB.NET>,
"Rolf Schwitter"
05/03/2006 07:53 <rolfs@ics.mq.edu.au>,
PM <standard-upper-ontology@listserv.i
eee.org>, <cg@CS.UAH.EDU>, "Nigam
Shah" <nigam@psu.edu>, "'Paul
Prueitt'" <psp@virtualTaos.net>,
"'Alan Ruttenberg'"
<alanruttenberg@gmail.com>, "'Paul
J. Werbos'" <pwerbos@nsf.gov>,
<bniemann@COX.NET>, "Susan
Turnbull" <susan.turnbull@gsa.gov>,
"Cory Casanave"
<cbc@enterprisecomponent.com>
Subject
Re: Contexts (was Classes vs.
Instances)
Avril Styrman wrote:
> Rich,
>
> even though views could be used to define types, the object-oriented
> way of doing this with an editor would be much quicker. It is just
> easier to press plus-button and give a name for the sub-table and
> add a couple of slots for it than to create views and to explicitly
> define relations of the views, and to join columns of tables. Perhaps
> I just haven't confronted an SQL editor with which this can be done
> as easily as with a basic ontology editor.
Nor have I; SQL databases are surprisingly short of good design tools
so far as I've seen. There are tools out there, but very few people seem
to use them, and they're not all that good.
>> So what exactly could be added to SQL to make types any more useful
>> there than the standard tables, views and procedures?
>
> If views were used to define types, there should be a detailed
> convention of how to use the views specifically for that task. If
> views were used in type definition, views could not be used in
> anything else. Maybe there are so many ways of using the views (?) that
> a convention could no be reached. In this case, another feature should
> be added to SQL: the reserved subTableOf property for all the tables.
> Only automatical functionality would be added to SQL editors: a
> subtable collects all the columns of its supertables. There would not
> be problems with stacks that you mentioned if SQL would remain
> othervise the same.
It would be relatively simple to develop a tool that helps you create
objects.
Whether the objects are implemented as views, tables or procedures seems to
me to be independent of the object level.
When C++ first came out, it was implemented as a precompiler which
translated
C++ into C. A similar approach could translate SQL++ into SQL. The only
loss with this scheme is reverse engineering; you might not be able to
translate
SQL into SQL++ without a huge amount of semantic discovery.
> Think how many hours the IT society would win if SQL databases
> were planned in an object-oriented fashion.
The main problem in the application of SQL to real world problems is not at
the design stage, when pretty simple structures are envisioned; its much
later
as the whole thing starts to look like a ramshackle database because the
requirements change so much faster than the database can be reorganized.
Practically every programmer who uses SQL databases today is very familiar
with the object-oriented approach to programming languages. I feel pretty
strongly that the way SQL provides persistent storage makes the
object-oriented
approch much less useful in that representation. But give me
object-oriented
programming languages over the old kind any day.
However, I have seen good papers about the functional data model (FDM)
method of database representation where all the concepts are nodes and all
the relationships are arcs between pairs of nodes, and every relationship
has
an inverse. It is very simple to construct an FDM with partial knowledge
of
the application requirements, and change it quickly, as compared to the
usual
SQL method. The only problem yet to be solved is that FDMs are hugely
inefficient when represented in that simple way. SQL brings a very large
degree of optimization because it only has tables, views, procedures and
domains. Adding more constructs to SQL would make optimization a bit
more difficult, but if a good case could be made that the new constructs
make
SQL databases easier to reorganize quickly, that would be a good selling
point.
JMHO,
Rich
> Avril
>
>
> Quoting Rich Cooper <rcooper15@comcast.net>:
>> Any frame can be implemented as a view, perhaps of multiple tables. To
>> use
>> multiple types (classes) in a frame, simply combine the tables with the
>> proper
>> join expressions and zot - you have a frame.
>>
>> When the industry found out that relational SQL databases were so
>> useful,
>> people naturally jumped to the conclusion that object-oriented databases
>>
>> could
>> go yet one better by adding types of a higher level of abstraction. As
>> you
>> may
>> have noticed, it didn't work. That's because object-oriented programs
>> use
>> stacks
>> to keep the objects straight, but persistent storage systems like SQL
>> don't
>> have
>> any use for stacks, except in stored procedures, where they are dynamic
>> data
>> structures, not persistent tables.
>>
>> So what exactly could be added to SQL to make types any more useful
>> there
>> than the standard tables, views and procedures?
>>
>> IMHO, SQL has reached its major advances already. More built in
>> functions,
>> a little improvement in domains (blobs should already have been
>> supplemented
>> with JPEGS, files, even databases as domains, but for some reason this
>> hasn't
>> happened yet).
>>
>> If anyone can suggest an improvement to SQL in detail, I would be very
>> receptive.
>>
>> Rich
>