Additional commentary from Orri Erling. re.
ORDBMS, ADO.NET vNext, and RDF (in relation to Semantic Web
Objects):
More
Thoughts on ORDBMS Clients, .NET and RDF:
Continuing on from the previous post... If Microsoft
opens the right interfaces for independent developers, we see many
exciting possibilities for using ADO .NET 3 with Virtuoso.
Microsoft quite explicitly states that their thrust is to
decouple the client side representation of data as .NET objects
from the relational schema on the database. This is a worthy
goal.
But we can also see other possible applications of the
technology when we move away from strictly relational back ends.
This can go in two directions: Towards object oriented database and
towards making applications for the semantic web.
In the OODBMS direction, we could equate Virtuoso table
hierarchies with .NET classes and create a tighter coupling between
client and database, going as it were in the other direction from
Microsofts intended decoupling. For example, we could do typical
OODBMS tricks such as prefetch of objects based on storage
clustering. The simplest case of this is like virtual memory, where
the request for one byte brings in the whole page or group of
pages. The basic idea is that what is created together probably
gets used together and if all objects are modeled as subclasses of
(subtables) of a common superclass, then, regardless of instance
type, what is created together (has consecutive ids) will indeed
tend to cluster on the same page. These tricks can deliver good
results in very navigational applications like GIS or CAD. But
these are rather specialized things and we do not see OODBMS making
any great comeback.
But what is more interesting and more topical in the present
times is making clients for the RDF world. There, the OWL Ontology Language could be
used to make the .NET classes and the DBMS could, when returning
URIs serving as subjects of triple include specified predicates on
these subjects, enough to allow instantiating .NET instances as
'proxies' of these RDF objects. Of course, only predicates for
which the client has a representation are relevant, thus some
client-server handshake is needed at the start. What data could be
prefetched is like the intersection of a concise bounded
description and what the client has classes for. The rest of the
mapping would be very simple, with IRIs becoming pointers,
multi-valued predicates lists and so on. IRIs for which the RDF
type were not known or inferable could be left out or represented
as a special class with name-value pairs for its attributes, same
with blank nodes.
In this way,.NETs considerable UI capabilities could directly be
exploited for visualizing RDF data, only given that the data
complied reasonably well with a known ontology.
If an SPARQL query returned
a resultset, IRI type columns would be returned as .NET instances
and the server would prefetch enough data for filling them in. For
a SPARQL CONSTRUCT, a collection object could be returned with the
objects materialized inside. If the interfaces allow passing an
Entity SQL string, these could possibly be specialized to allow for
a SPARQL string instead. LINQ might have to be extended to allow
for SPARQL type queries, though.
Many of these questions will be better answerable as we get more
details on Microsofts forthcoming ADO .NET release. We hope that
sufficient latitude exists for exploring all these interesting
avenues of development.