Re: some more RDF thoughts

>[Peter Breton]
>The beauty of the triple store mechanism is that you can accomodate ALL
>the data in it.
>
>[wmj]
>Other store mechanisms (for example relational) also "accomodate ALL
>the data in it."
>
Umm, yes they do, as does a filesystem, once you solve the "trivial" 
problem of mapping your data into flat files. :)

What I meant is that you store all the data in the same way, without 
defining new schemata for them, thus finessing the problem that the 
Associative Model of Data paper describes:

"Under the relational model, every table is structured differently that 
is, it has different columns and column headings and the programs are 
designed around the tables. It is impossible to write an efficient 
program that is capable of accessing a table whose structure is not 
known when the program is written, just as it is impossible to make a 
key that will open any lock."

(However, I believe that in the physical world there are, in fact, keys 
that open any lock :)

>[Peter Breton]
>the roundtrips from client/middleware to RDBMS are likely to be some of the
>most expensive operations
>
>[wmj]
>If the 'client/middleware' is not RDF, than is it another notation? Is RDF
>notation a technology looking for the applications?
>
The client/middleware that I was envisioning in this case is some kind 
of RDF-to-RDBMS engine. Given that this fit is somewhat unnatural, it 
seems that moving it closer to the RDBMS can only help its efficiency.

(At the moment, I think RDF is in fact looking for applications.....)

>[Peter Breton]
>3) Another road: since queries on an unbounded triple store ....
>
>[wmj]
>It seems that the problem is solved by "Associative Model of Data^(TM) -
>http://www.lazysoftware.com
>
Thanks for the pointer. I will check them out.

>BTW I am not an opponent of RDF, I am an outsider looking for insights and
>knowledge.
>
Likewise! :-)

Peter

Received on Friday, 22 June 2001 13:13:04 UTC