Re: Traversing trees with sparql?

I'm going to assume that "select a branch of a tree structure" means  
asking for every statement in that tree, or a description of the  
things in that branch.

It might be obvious, but it's probably worth pointing out that  
trimming this tree down through some kind of CBD operation would be  
rather important, for two reasons:

- the "alternative music" branch of the tree is going to shoot off  
into rdf: (type), rdfs:, and countless other ontologies, so it'll be  
much bigger than you expect;
- it's enormously likely that these things aren't trees at all (it  
only takes one pass into WordNet, and one pass back out further back  
up the tree, to make a cycle).

These pose difficulties to what you describe.

I can, however, imagine some operation based on:

- defining the set of relations that create a tree structure (e.g.,  
subPropertyOf in certain circumstances)
- walking down this tree under certain constraints, from a certain  
root, applying some descriptive function such as the CBD, and  
collecting the result.

If SPARQL supported transitive properties, it would be fairly  
straightforward to dump the tree structure with one query*, then cut  
it down on the client and issue one big DESCRIBE query with all of  
the desired nodes.

If I had time I'd throw together a proof-of-concept :D


* e.g. SELECT ?x ?y WHERE { ?x dmoz:narrow ?y . } WITH TRANSITIVE  
( dmoz:narrow )

> On 10/26/05, Jones, David H <> wrote:
>> I would like to be able to select a branch of a tree structure  
>> (similar
>> to the DMOZ directory tree, where the tree is formed by traversing  
>> the
>> dmoz:narrow property).  Can this be done in sparql? If so can someone
>> provide an example.
> I'd suggest this maybe prompts a side task for the WG. The choice was
> made to follow a statement-oriented approach to querying rather than a
> path-oriented approach (a la Versa etc.) . I've no idea what use cases
> were put forward in justification of the latter approach, but
> (assuming there are some in the archives)  it would be helpful to
> consider (and document) how they may be implemented when using SPARQL
> as it stands. (I don't know - is there any kind of algorithm that
> might improve on GET-results/translate-re-GET?)
> Cheers,
> Danny.
> --

Received on Wednesday, 26 October 2005 21:14:49 UTC