> I would like to be able to select a branch of a tree structure
> 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.
SPARQL doesn't address this directly, but one approach is to combine
SPARQL with inferred properties.
There are perhaps ways of expanding SPARQL to handle trees directly; the
design considerations are essentially the same as expanding SPARQL to handle
lists directly. The WG has postponed that issue; i.e. decided not
to address it in this verion of SPARQL, leaving to normal W3C process
the question of when and whether a future version of SPARQL will
Please let us know wehther you find this satisfactory.
Support for collections/containers? or trees? or path regular
* accepted in 2004-09-16 discussion of content selection based on
client profile in Bristol
* Note that accessing collections can be done by combining SPARQL
with inference rules, which, by charter, is orthogonal:
The protocol will allow access to a notional RDF graph.
This may in practice be the virtual graph which would
follow from some form of inference from a stored graph.
section 2.1 Specification of RDF Schema/OWL semantics of
* postponed 22 Feb:
RESOLVED: to postpone accessingCollections because
* our not standardizing it doesn't stop anybody
* none of the extant designs seems sufficiently
Clark/UMD, Fukushige/MEI, and 2 others abstaining
* see also comments Traversing trees with sparql?, Barstow/Nokia,
esp point 2 on transitive closure
* WG discussion on using inference rules to supplement SPARQL: Re:
summary of some cwm/euler implementation experience w.r.t.
accessing RDF collections 8 Nov 2005
* WG discussion considering extending SPARQL with graph regular
expressions: Transitive properties 08 Nov 2005
* note W3C Launches Rule Interchange Format Working Group
Danny Ayers wrote:
> 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) ...