Re: A quick intro to the RDF data model.


I suggest separating the description of how RDF works, and how it is like a
relational database, from the statements about what you cannot do with a
relational database that you can with RDF.  That's because you can do most
of the examples with no problem using SQL.  Or maybe you need different

E.g. -

"  _:654123 hasHomepage
   _:654123 isOwnedBy urn:usssn:123-56-1234
   _:123141 isOwnedBy urn:usEIN:13976-45-12
   urn:usEIN:13976-45-12 hasHomepage

Now, one can query for "Wings" by homepage:  you can ask "find me the
menu for the restaurant who's homepage is".  That's
not the same as asking "find me the menu for", since
these are URIs, not URLs -- they're just names, not links.  "

select item from menu join restaurants
where restaurants.homepage = '';

BTW, it is not usually considered good naming form to name tables with
plural names.

'..., since these are URIs, not URLs -- they're just names, not links.  A
obvious case is Jane's diner: "find me the menu of the restaurant called
"Eat at Jane's" that is located in Tallahassee, FL"'

select item from menu join restaurants
where name = 'Eat at Jane\'s'
and city = 'Tallahassee'
and state = 'FL';

'This isn't a problem: all one has to do is add another

"   _:654123 hasHomepage
   _:654123 isOwnedBy urn:usssn:123-56-1234
   _:123141 isOwnedBy urn:usEIN:13976-45-12
   urn:usEIN:13976-45-12 hasHomepage'

You have only changed the primary key from "Joe's" to "_:654123".  You still
have a local identifier acting as a primary key, only its value has changed.

The real point to be made here is that you can keep piling on additional
properties without adding or changing existing tables.  The tradeoff for
this flexibility is that you have to keep repeating the property type (its
uri) and the subject's type for each triple, whereas with a relational
database, you do not have to do that, or at least not as often.  Also a
fixed table design lends itself to more query optimization techniques.

"SELECT ?name, ?price
        FROM restaurants.nt
        (?x rdf::type wn::Restaurant)
        (?x fp::costsAbout ?price)
        (?x _::isCalled ?name)
        (?x fp::hasMenuItem ?c)
(?c rdf::type wn:EthnicCuisine)
        rdf for
        fp for
        wn for
        _ for <>"

select name, cost
from menu join restaurants
where cuisine in ['Chinese', 'Vietnamese', 'Thai']
and restaurants.approximate_price < 16
and restaurants.approximate_price > 9

What's that, you say?  This SQL query had to specifically list all the
ethnic cuisines?  Well, guess what?  You have to do that with RDF too, in
order to tag them "with rdf::type wn:EthnicCuisine".  You just list them in
a different place.  And the list in the SQL query could have been obtained
from a query over a "ethnic_cuisine" table.  Similar remarks hold for the
approximate price - somewhere you have to define what that "fp::costsAbout"
predicate means.  So even in this example there is virtually no difference
between the relational database and the RDF example.

You cannot show why RDF is desirable by showing how it does the same things
as a relational database only more clumsily and with less chance for
optimization.  You have to get at the differences.  I think that these
include -

1) More flexibility (not restricted to predefined tables and relationships)
2) A convention for cross-database identifiers (the URIs) and easy ways to
declare that two URIs represent the same subject (with the help of OWL)
3) Uniform semantics across databases (i.e., across collections of triples).
4) An ontology language -OWL- designed to support inferencing and structured
type (class) systems (and to be able to piece the latter together from
multiple sources)
5) A web-capable interchange syntax (RDF/XML) (although mainline databases
are mostly able to interchange XML formatted data too, these days)
6) The ability to make statements about the predicates themselves -
something you cannot do in a relational database even when you can access
the names and data types of the various fields.
7) The ability to type literal values with datatypes from a standard (XML
Schema), that are not tied to a specific programming language or RDBMS.
8) The ability to include things (resources) that have properties but no
explicit identifier.  You were trying to get at this when you brought in
blank nodes, only unfortunately you supplied them with handy identifiers so
the point is lost.

I'm sure others can add still more benefits of RDF (or RDF + OWL), but for a
comparison with relational databases, I think the above items are very
cogent.  See if you can come up with examples that hightlight them and truly
are hard with a relational database.  The examples you show so far are
practically isomorphic with typical sql examples.


Tom P

Received on Thursday, 11 September 2003 23:32:59 UTC