Re: ANNOUNCEMENT: RDFStyles: alternative to XSLT for RDF

Another possible starting point candidate for RDFpath that I was just 
reminded of again is Versa:

   http://www-106.ibm.com/developerworks/xml/library/x-think10/index.html

It is presented as a query language, but it looks to me like a simple path 
language candidate.

#g
--

At 14:02 28/10/03 +0100, Emmanuel Pietriga wrote:
>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

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Thursday, 30 October 2003 12:59:57 UTC