The following link asks for proposals for storing RDF documents in SQL:
http://www-db.stanford.edu/~melnik/rdf/db.html
Their motivation is:
>Motivation
>
>We need to be able to persistently store and manipulate (large amounts of)
>RDF data. One of the alternatives to do that is to use the relational
>database technology.
>A major advantage of this approach is that is provides a scalable
>off-the-shelf solution [this solution has appeared in most of the
>discussion recently on this list].
I would like to turn the question around. Is there a place for storing
table definitions in RDF? Wouldn't that make more sense? In addition, if
one did that, wouldn't one have produced a "middle layer" that was
web-oriented and efficient, perhaps even obviating the need for CORBA?
The criticism of this idea that I can immediately see is that with CORBA,
one can call *objects* located who knows where. CORBA turns all the
computers on the network into one giant *application*. But, if I read the
postings correctly, that's *not* what OpenEMed is using CORBA for. Rather,
they are using CORBAmed as a middle layer to gain access to "foreign"
databases around the network, NOT (repeat NOT) foreign *code* around the
network. The technique may involve running some foreign code, but the goal
is the foreign database.
Comments?
John
P.S. This underlying premise of this posting is that if middleware is
intended to let everything talk to everything, then there is an immediate
division of labor: middleware experts can continue to create middleware and
people like myself with SQL tables can continue to create SQL tables safe
in the knowledge that the middleware will take care of interoperating with
my tables.
