RE: some more RDF thoughts

[Peter Breton]
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
..............

[wmj]
Using the "trivial" schema of RDF to "store all the data in the same way" is
creating the "non-trivial" problem of harvesting meaning from the triple
store. Here are two interpretation of the following RDF statement
(http://www.w3.org/Home/Lassila, Creator, Ora Lassila) provided by Lars
Marius Garshol in a recent e-mail to the topicmapmail forum:

"(1) For every "Creator" predicate, the subject is an addressable
  resource, of which the object is an occurrence value of the type
  "Creator".
(2) For every "Creator" predicate, the subject is an addressable
  resource, while the object is the name of a topic of type
  "Person". The relationship between them is that there is an
  association of type "created-by" between them, with the subject
  playing the role "resource" and the object the role "creator"."

Enhancing (a,b,c) RDF schema by (Ra,Rb,Rc) role triple will eliminate
ambiguity and give

(http://www.w3.org/Home/Lassila, Creator, Ora Lassila)
(addressable resource, type, occurrence value)

[Peter Breton]
One possibility running through my head is a "double triple store".

[wmj]
Any comments for my version of a "double triple store"? :-)

Best

WMJ


-----Original Message-----
From: www-rdf-dspace-request@w3.org
[mailto:www-rdf-dspace-request@w3.org]On Behalf Of Peter Breton
Sent: Friday, June 22, 2001 1:13 PM
To: W.M. Jaworski
Cc: www-rdf-dspace; dspace-code@MIT.EDU
Subject: 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 Saturday, 23 June 2001 02:16:58 UTC