Re: Semantic network DBMS [was: Re: Contexts (was Classes vs. Instances)]
Here at my development shop, we have several implementations like you
are suggesting - it's really not all that difficult to do.
The terms "node" and "arc or "edge" are more commonly used in formal
graph theory, where a whole realm of data-shaping possibilities opens
up. Our implementations are built with two open source projects:
Plexus, which provides graph interfaces to data and Meta-JB, which
allows us deeper abstraction of data in Java (kind of like Active Data
Objects and dcom). Both of the lead developers of these projects are
coworkers of mine, and there's a more in-house code that is not
open-source that facilitates the graph-to-database modelling and multi
database support. All of this is not trivial, it definitely isn't the
rocket sciences that it once was considered to be.
When implementing graph abstractions over databases - choosing your
meta-models is a whole other tier. (pun failure ;) ). Then there's
meta-models as graphs, and then graphs of meta-model graphs. This is
all before even implementing anything based on an ontology.
A commercial product would have to be considered a development product
as much as an infrastructure product, in the same way that engineers
think of DBMSs. A DBMS is nothing with without a schema to hold data,
and despite all the attempts for OODBMS's to gain a footing in the
market, nothing seems to stick. It seems to me that anything more
complicated that a SQL based database only attracts the attention of the
more elite tier of software engineers - which I think that this the main
reason we don't have commercial development products offered - complex
software products all together have been on the decline for 20 years.
Only the simplest and sleekest seem to become most generally accepted
have survived.
The trends have also disfavored the most technical of products, as even
the "elite" engineers are usually more expensive to ramp up to speed
than the specialized tools that they use. I.e., Esri's GIS tools may
have cost hundreds of thousands in the past, but it took developers many
months and sometimes years to master them. Now as they have simplified
them and reduced their pricing, they've gained greater market share
and stability.
Pitching a commercial product like this would demand a lot of it's
users, even if it didn't specifically address any kind of semantic
modeling. Vendors are very shy of that kind of responsibility.
Anyway, back to technology - there are lots of problems that are more
aptly solved be a graph abstraction of data - and nowadays people will
ONLY use a SQL database for persistence (with the expception of BDB and
Adabas). The impedance mismatch of graphs with SQL has performance
limitations of sizing and speed, but they don't really matter if you're
solving the problem.
Dave Sheremata
Sr. Software Engineer,
SAIC
Rich Cooper wrote:
> Hi Douglas,
>
> Why wasn't the IBM software released as a product? It would be
> interesting
> to know the rationale behind it.
>
> One surprising thing about DBMSs is the way performance varies with size.
> The winner on very large databases is nearly always Oracle, which has a
> tremendous amount of optimization. The loser on very small databases is
> also nearly always Oracle because that tremendous amount of optimization
> is expended on every query. Something like that might be behind the IBM
> product's nonrelease.
>
> -Rich
>
> Douglas McDavid wrote:
>
>> 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
>>>
>>
>>
>>