Re: Existentially Quantified Variables (bNodes) in RDF-like-languages

> > 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 acro ss
> 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.

Interesting.  I hadn't heard you were using them for QBE.  That's a
very reasonable use, given the current semantics.

I have a different Response to Reason 3, which covers your use.  I
think the Semantic Web consists of (or should consist of) an
accumulation of assertions.  If you're using RDF for something other
than asserting facts, then you're using it for an application which is
out-of-scope to my interests.   (Perhaps I should have defined that
scope in my original message.)

It is nice to be able to re-use tools, and QBE is certainly nice for
users.   Hmm.


> We also happen to use bNodes a lot in our fact bases for constructing structu
> red
> 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 i
> n
> the bNode case we know the bNodes are effectively lexically scoped and so tha
> t
> we have a complete structured value.

I don't exactly understand this, but I suspect this heuristic will
give you incorrect results in the presense of many kinds of inference.
DAML+OIL unique or unambigous properties can be used to make
assertions about the un-named object of exactly the sort you say will
become possible if we get rid of bNodes.

    -- sandro

Received on Friday, 5 April 2002 13:07:56 UTC