Re: ANNOUNCEMENT: RDFStyles: alternative to XSLT for RDF

Graham Klyne wrote:

> Indeed so.  But I still think your idea is a good one to investigate.
> 
> What follows are some disjointed ramblings, which you may well choose to 
> ignore.
> 
> I'm no expert on XSLT, but it seems that the behaviour of 
> <xsl:apply-templates /> is to use some context from the template that 
> invokes it, and use that in performing a further query.  

Aside from explicit (optional) parameters, a template called by an 
apply-templates instruction does not get any context from the calling 
template. Unless by context you mean the fact that it will be applied to 
a (limited) subset of nodes (essentially, but not necessarily, children 
of the context node in the calling template).


> In the case of 
> a tree query, the subsequent query may be quite clearly scoped.  In the 
> case of a graph query, I think the scope is not so constrained because 
> the graph may contain loops back to "higher" notes.

True. That's why I was mentioning the need to define the semantics of an 
apply-tempaltes select="*" equivalent as it cannot be transfered to the 
case of a graph straightforwardly.


> 
> One touchstone might be this:  given an RDF graph that follows a 
> strictly tree pattern (and RDF graphs used to represent frame-like 
> information do tend to follow such a pattern) then the [default?] 
> behaviour should be similar to normal XSLT behaviour.
> 
> So, if one imagines an RDF graph that has a single "source node", and 
> which contains a strict branching structure, how might this work?  The 
> initial query (I think of RDFpath as likely being RDF-query-like) must 
> somehow select (by name, or otherwise) the source node, and then 
> describe paths from that node, or related to that node.  For each 
> matching query, is it possible to identify a new node that serves a 
> similar role to the original "source node"?
> 
You mean what is called "context node" in standard XPath/XSLT ?
I believe Sean Palmer addresses this issue in his proposal [1] (I like 
this one btw ; it would be nice if it were extended to support selection 
predicates modeling constraints on literal datatypes).

[1] http://infomesh.net/2003/rdfpath/

> Then consider the ways in which an RDF graph may be not-tree-structured:
> 
> - There is no single source node:  

s/source/root ?

> maybe the root context must be 
> considered to be a set of nodes?  E.g.  I have found that graph queries 
> might start with something like "find all nodes of a given type", and 
> starting from these, paths through the graph can be traced by subsequent 
> queries.

In TreeHugger [2], the root is considered to be the RDF document. 
Children of the root are all nodes in the graph that are the subject of 
one (or more) statement. What you offer here seems to be a refinment of 
the same thing (by adding constraints on the members of this set).

[2] http://rdfweb.org/people/damian/treehugger/

> - branches may recombine, so that leaf nodes are shared between 
> branches.  This might still be processed as if it were a tree, if the 
> duplication thus engendered is not harmful.

It might be harmful. I think it is very dependant on what the 
transformation designer wants to do. I'm not sure about the best way to 
address this issue.



> - the graph may be cyclic.  One view might be to treat this as an 
> infinite tree.  (Something like this happens for the description of 
> recursive functions in functional programming language implementation.)

Could you give more information about this?

> Another view might be to use some kind of dictionary to avoid chasing 
> round loops -- such a dictionary might represent a new graph querying 
> context (is this similar to tabling of predicates in Prolog derivatives 
> like XSB?)
> 
> - are there any other patterns that break the XSLT tree-scanning model?
> 
> Set against these complications is the fact that the primitive relations 
> in an RDF graph are simpler than child relations in an XML tree:  there 
> are no attributes vs child elements to worry about, with different rules 
> for ordering and duplication.  There are no special properties that 
> demand treatment differently from other properties (other than possibly 
> for optimizations?).
> 
> #g
> -- 

I do not find this element/attr difference to be difficult to handle in 
XPath/XSLT. But it is indeed good not to have this additional complexity 
to add to an RDFPath language.

Emmanuel

-- 
Emmanuel Pietriga (epietriga@nuxeo.com)
tel (mobile): +33 6 88 51 94 98
http://claribole.net

Received on Tuesday, 28 October 2003 08:01:54 UTC