- From: Graham Klyne <gk@ninebynine.org>
- Date: Mon, 27 Oct 2003 16:39:11 +0000
- To: Emmanuel Pietriga <epietriga@yahoo.fr>
- Cc: www-rdf-interest@w3.org
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. 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. 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"? Then consider the ways in which an RDF graph may be not-tree-structured: - There is no single source node: 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. - 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. - 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.) 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 -- At 16:46 27/10/03 +0100, Emmanuel Pietriga wrote: >Beyond the RDFPath problem, there are other problems to solve, like what >is the semantics of xsl:apply-templates in the context of an RDF graph. We >don't have a tree here, so what does: > ><xsl:apply-templates select="*" /> > >mean when applied to the context node of an RDF graph? > >Emmanuel > > > >Graham Klyne wrote: > >>At 12:59 24/10/03 +0200, Emmanuel Pietriga wrote: >> >>>I agree that it is something useful. But isn't this what XSLT already >>>does? That's what it does for XML. So why couldn't it do it for RDF? I >>>mean, except for the XPath part that is not (as discussed yesterday) the >>>best-suited technology to address nodes and arcs of an RDF graph, XSLT >>>seems to be well-suited to this task (all that is needed is to replace >>>XPath selectors by *RDFPath* selectors). >> >>I think that's a really interesting idea... using the existing XSLT >>design to its strengths and directly addressing its weakness with respect >>to RDF data. >>#g >> >>------------ >>Graham Klyne >>For email: >>http://www.ninebynine.org/#Contact > > >-- >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 Monday, 27 October 2003 13:31:54 UTC