ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Is there something I missed?

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Ian Bailey" <ian@xxxxxxxxxxxxxxxx>
Date: Fri, 30 Jan 2009 21:13:56 -0000
Message-id: <004b01c9831f$bc8ecdb0$35ac6910$@com>
Hi All,    (01)

It's very tempting to compare RDBMS to ontology, but they're very different
beasts (apologies for grandmothers sucking eggs etc. to the likes of Dave
Hay and Matthew). In essence RDBMSs are collections of tables (columns and
rows). It's tempting to compare tables to classes, rows to instances, and
columns to attributes, and this (kinda) works in very simple cases. However,
there is the business of the foreign key to consider - when one value in a
column in one database matches a value in another, they constitute a
relationship ONLY when there is a foreign key constraint covering the column
in the first table and the matching column in the second. Without the FK
constraint, matching values can exist all over the place but they would not
be considered relationships.     (02)

The difference is subtle, but because of the FK constraint existing (or not
existing), the mapping to class, instance and attribute is not guaranteed.     (03)

Matthew West, myself and a bunch of other people (most notably Reiner
Reschke and Cliff Longman) did a lot of work on this in the 90s on the
PIPPIN project. Mapping classes to tables in a primitive fashion works 80%
of the time...but it's the 20% that kills you. There are lots of things you
can do to mitigate this - e.g. using system-only FKs rather than user-data
FKs...or going into the murky depths of one-table and three-table projection
- but at that point, the concepts of table, row and column have no semantic
whatsoever.    (04)

We spent the best part of a year trying to squeeze the last drop of
performance out of a multitude of different relational projections. They all
performed differently under different circumstances - e.g. read, write,
update. They also had some strange emergent performance properties as the
amount of data increased. Some were fast then slowed down to a crawl under
large amounts of data, others started out slow and stayed that way. Sadly
nothing got faster as the amount of data increased :(    (05)

There's another thing to consider when implementing ontologies in RDBMS -
SQL is a declarative language. You have very little control over how the
database kernel will execute a query or update. Once you start to monkey
around with exotic class-table projections, knowing how the SQL is executed
becomes quite important for performance reasons (Cliff Longman is very
knowledgeable in this area). It's worth noting that one RDBMS may well
execute the SQL differently to another - so, for example, you get the
performance problem cracked in Access, then migrate to Oracle and go back to
square one. Reiner and I grew old and stressed beyond our years trying to
get Matthew's EPISTLE models to perform in a production environment. If
there's one thing I learned (actually no, PIPPIN taught me an incredible
amount) it's that comparing ontology to RDBMS is a fool's errand.     (06)

Cheers
--
Ian    (07)

-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Mitch Harris
Sent: 30 January 2009 20:18
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Is there something I missed?    (08)

On Fri, Jan 30, 2009 at 2:46 PM, Schiffel, Jeffrey A
<jeffrey.a.schiffel@xxxxxxxxxx> wrote:
>> From: Patrick Cassidy
>
>> In the RDB's I have seen, each field (column in a table) often
> (typically?)
>> represents one relation on the type represented by the table, so the
> number
>> of columns does not have any relation to the arity of the relations
> used.
>> Two or more columns can be used together to represent higher-arity
>> relations, but they may be quite independent.
>
> I'm not certain I know what you mean. In an entity-relationship isn't
> the relation the entire row, not just one column? The entity is the name
> of the table. The names of the columns are the identifiers of an n-ary
> relation. Each row is an instance of the n-ary relation.    (09)

Yes to all of those.    (010)

> Or am I missing something?    (011)

I think PC's point is that it is -possible- to extract lower arity
relations from a large arity one.    (012)

My point, which is not contradictory to that, is that -most- db
tables/relations I see are spelled out as ternary or greater, whatever
the relations that it -could- be reduced to.    (013)

But reverse direction point of mine is that whatever the cogency of a
database is to a human reader, one can still artificially reduce the
max arity, and still preserve...let me see...correctness.    (014)

(I'm just trying to be explicit about technical meanings of words
-and- real world experience).    (015)

Mitch    (016)

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: 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 join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (017)



_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: 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 join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (018)

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