I think Pat has already covered the main issues but I couldn't let this claim
slip by ...
> Reason 3: Because we can use existential variables for querying RDF.
> (Pat suggests this in [1]. It was my reason a year ago.)
>
> Response: I've seen a lot of RDF query languages now, and this
> approach is not being used.
Not true. We have a group applying RDF to decentralized knowledge management and
we employ a "query by example" (QBE) mechanism using bNodes as variables for
retrieving subsets of (remote) RDF fact bases. We also use richer query
languages (RDQL) for more sophisticated work but QBE gives us a simple,
efficient lowest common denominator representation that we can broadcast across
our p2p network. It has the side effect that we can use RDF tools for
constructing and analyzing the queries which makes things like result caching
simpler to implement.
We also happen to use bNodes a lot in our fact bases for constructing structured
values, i.e. things like:
urn:epid:Dave eg:weight [rdf:value '68'; eg:units 'kg'].
We then use the heuristic that if we were to query for the values of
(urn:epid:Dave, eg:weight, ?) we pull back the whole tree of values connected
via bNodes. In this way the RDF sets that get returned across the network in
response to QBE queries are closed with respect to bNodes.
If we were to replace the bNode denoting Dave's weight in the above by a
urn:uuid construct then we could no longer auto-identify these structured
values. More seriously if we find another assertion about Dave's weight with the
same properties we have to keep that as well because it will have a different
uuid (and so could turn out to have more values associated with it) whereas in
the bNode case we know the bNodes are effectively lexically scoped and so that
we have a complete structured value.
These issues could be worked around but in practice we are finding bNodes
convenient and I, at least, was pleased when the RDF Core WG decided to retain
them.
Dave