Entries in this category

Why RDF Templates Uses Macros

Excerpt: I'm working on a .NET version of RDF Templates using Carp. James asked why you had to use macros to get nice NodePaths like *[rdf:type = foaf:Agent] instead of QNames based off of the namespaces in the source documents or stylesheet. It's been a while since I wrote the specification and to be honest I'd forgotten why, other than just disliking QNames in content. After a bit of thought I remembered some of the original reasoning. You couldn't base QName expansion off of the source documents because RDF Templates and their NodePaths operate over a graph, not an instance document. The graph could have been bult from hundreds of individual instance documents each with their own namespace prefix mappings (or none …

Nearly Round-Tripping

Excerpt: Well, it's nearly there. The PHP implementation now supports the generation of elements given only the URI (as opposed to supplying the namespace and local parts separately) which was the major blocker on getting this working. I've extended the spec to allow NodePaths to be specified in the rt:name attribute of rt:element. They're distinguished from string values by enclosing them in curly brackets {} just like in XSLT. I'll do the same for attributes too. There's still some work to do on the actual XML generation around the namespace prefixes but it's essentially all there. The stylesheet itself would be cleaner with some conditional logic in there - that will come soon too. Here's the stylesheet: <rt:stylesheet xmlns:rt="http://purl.org/vocab/2003/rdft/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" …

Namespace Handling

Excerpt: After a bit of a breather, I'm back working on RDF Templates. My current focus is getting namespace handling to work correctly. This is a very small spec change but quite a lot of work in the PHP implementation. I have rudimentary handling sorted out now, but I'm ignoring some of the finer points such as unprefixed namespaces. These will come along shortly. Along the way I've added an rt:output element which is the RDFT analog of xsl:output. It lets you specify options such as XML or text output. I'm gradually edging towards the RDF syntax round-tripping milestone. After namespace handling is polished off I need to look at using RDFT elements to generate the values of attributes. This should be …

Resource Condition Extension

Excerpt: Currently resource conditions in a nodepath restrict you to a single arc and node pattern, e.g. resource()[arc()/literal() = literal('hello')]. I've relaxed this constraint so that the selection part of the condition can be any arc-matching nodepath. This means that you can now write conditions that test the arcs on a node, e.g. resource()[arc() = resource('http://xmlns.com/foaf/0.1/weblog')] would match any resource with a foaf:weblog property, no matter what the value of that property is, or resource()[arc('http://xmlns.com/foaf/0.1/knows')/resource()/arc() = resource('http://xmlns.com/foaf/0.1/weblog')] that matches any resource that knows a resource with a foaf:weblog. The new BNF for the spec is: ResourceCondition ::= ArcMatchingNodePath [ " = " NodeSpecifier ]

Arc Selection Syntax Reprise

Excerpt: OK, I implemented the proposed ArcPattern syntax change and decided that I didn't like it! However, I came up with an alternative that is even more expressive: introduce a specifier called arc() that acts in all ways like resource() but is to be used as the specifer in ArcPatterns. Here's how it would look: <rt:root-template> <rt:for-each rt:select="~subject()"> <rt:for-each rt:select="resource()/arc()"> <rt:for-each rt:select="arc()/resource()"> <rt:value-of rt:select="label()"/> </rt:for-each> </rt:for-each> </rt:root-template> For comparison, here's the original (i.e. current spec version): <rt:root-template> <rt:for-each rt:select="~subject()"> <rt:for-each rt:select="resource()/resource()"> <rt:for-each rt:select="resource()/resource()"> <rt:value-of rt:select="label()"/> …

Revised Spec Including Arc Selection

Excerpt: I've just published the latest RDF Templates Specification which includes the new arc selecting NodePaths. I've reworked large parts of the text too in an effort to make it more logical. There's still a long way to go before I'm happy with the spec but it's coming along quite nicely all the same. Of course, there's a new version of phpRDFT to go along with the spec too.

NodePath Terminology

Excerpt: The following is from the up-coming specification revision: A NodePath is evaluated in a particular context which is determined by the structure of the stylesheet and may be either node-context or arc-context. A node-matching NodePath has a NodePattern as its first pattern and is evaluated in a node-context. It is an error for this type of NodePath to be evaluated when the context is an arc. An arc-matching NodePath has an ArcPattern as its first pattern and is evaluated in an arc-context. It is an error for this type of NodePath to be evaluated when the context is an arc. NodePaths can change the context in which they are evaluated by the use of scope specifiers. A scope specifier overrides the current context by selecting …

Arc Selection Syntax Proposal

Excerpt: Adding arc selection to NodePaths has created some usability problems. Its not obvious from looking at a NodePath in isolation whether it expects nodes or arcs as its context. It's easy enough for the stylesheet author to work out but it might be a stumbling block for newcomers to RDF Templates. It's similar to the criticisms RDF/XML faces with the striping syntax - there's no easy way to identify whether you're looking at a node or an arc. RDF/XML has a convention of using an upper case first letter for nodes and lower case first letters for arcs but many schemas don't use this convention. Here's an example of the kind of problem that I'm talking about: <rt:root-template> <rt:for-each rt:select="~subject()"> …

Triples

Excerpt: Node: http://1.example.com/Arc:http://purl.org/dc/elements/1.1/creatorValue: "Fred Flintstone"Node: http://2.example.com/Arc:http://purl.org/dc/elements/1.1/publisherValue: mailto:publisher@example.comArc:http://purl.org/dc/elements/1.1/creatorValue: mailto:webmaster@2.example.comNode: http://3.example.com/Arc:http://purl.org/dc/elements/1.1/publisherValue: mailto:publisher@example.comArc:http://purl.org/dc/elements/1.1/creatorValue: mailto:webmaster@3.example.comNode: mailto:webmaster@3.example.comArc:http://www.w3.org/1999/02/22-rdf-syntax-ns#valueValue: "webmaster" Here's the stylesheet I used: <rt:stylesheet xmlns:rt="http://purl.org/vocab/2003/rdft/"> <rt:root-template> <html> <head> <title>Triples</title> </head> <body> <ul> <rt:for-each rt:select="~subject()"> <li>Node: <rt:value-of rt:select="label()" /> <ul> <rt:for-each rt:select="node()/resource()"> …

First Arc Selecting Stylesheet

Excerpt: I've just shocked myself by running my first arc selecting stylesheet. I'm shocked because all I've changed is the parsing mechanism for nodepaths so that arc selecting nodepaths are allowed. I thought I'd have to change a lot more than just that…! Anyway, here's the first stylesheet: <rt:stylesheet xmlns:rt="http://purl.org/vocab/2003/rdft/"> <rt:root-template> <html> <body> <rt:apply-templates rt:select="~node()" /> </body> </html> </rt:root-template> <rt:template rt:pattern="node()"> <p><rt:value-of rt:select="label()" /> has arcs:</p> <ul> <rt:for-each rt:select="node()/resource()"> <li><rt:value-of rt:select="label()" /></li> </rt:for-each> …

NodePaths for Arcs

Excerpt: I'm working on implementing nodepaths that select arcs. This is essentially just allowing node()/resource() as well as node()/resource()/node(). I've completed that change and now face the bigger challenge of implementing processing support. The current spec describes a processing model whereby a context node is selected from the graph and all operations act on that context node. However, I want to be able to act on nodes and arcs so that definition has to change. One small dilemma I have is what to call it - 'context node or arc’ is a bit of a mouthful and 'context resource’ while technically correct implies that literals cannot be the context which, of course, they can. I'm probably just going to just use the …

Updated RDFT Specification

Excerpt: I've just uploaded the latest RDFT specification which incorporates the alterations I've been discussing over the past few days, including: Source Scope — a new scope that makes the NodePath apply only to the original source graph without the RDFS closure rules. Label Function — a new function that returns the current node's label. Data Model — some clarification of the data model. Subject Specifier — a node specifier that matches only resources that are the subject of a triple. Also uploaded is the latest version of the RDFT reference implementation: phpRDFT which implements all the features described in the latest specification.

Schema Stylesheet and Nodepath Examination

Excerpt: Here's a little stylesheet that demonstrates the use of source scope nodepaths. It produces an HTML representation of an RDF schema. The source scope nodepaths are used to ensure that only the classes and properties described in the schema document are selected for output. However, the subsequent matches and selects are scoped against the RDFS closure of the graph so it will recognise subclasses of rdfs:Class and rdf:Property if those are imported. For example you could import the Owl schema and it would recognise owl:TransitiveProperty as a though it were an rdf:Property. <rt:stylesheet xmlns:rt="http://purl.org/vocab/2003/rdft/"> <rt:macro-set rt:prefix="rdf"> <rt:macro rt:name="type" rt:value="resource('http://www.w3.org/1999/02/22-rdf-syntax-ns#type')"/> <rt:macro rt:name="Property" rt:value="resource('http://www.w3.org/1999/02/22-rdf-syntax-ns#Property')"/> </rt:macro-set> <rt:macro-set rt:prefix="rdfs"> <rt:macro rt:name="Class" rt:value="resource('http://www.w3.org/2000/01/rdf-schema#Class')"/> …

Source Scoped Nodepaths

Excerpt: I ended up choosing '~’ as the prefix for the source scoped nodepaths. A source scoped nodepath uses all the nodes in the graph before the RDFS closure rules are applied. For comparison here is the same nodepath with three different scopes: resource()[resource('http://ex.example.com/age')/literal() = literal('23')] A locally scoped NodePath that selects the context node only if it has a 'http://ex.example.com/age’ property with a literal value of '23’. /resource()[resource('http://ex.example.com/age')/literal() = literal('23')] A globally scoped NodePath that selects all nodes from the RDFS closed graph that have a 'http://ex.example.com/age’ property with a literal value of '23’. ~resource()[resource('http://ex.example.com/age')/literal() = literal('23')] A source scoped NodePath that selects all nodes from the original source graph that have a 'http://ex.example.com/age’ property with a literal value of '23’. …

RDFS Closures

Excerpt: I really have to get the RDFS closures issue sorted out. Currently the spec mandates that the input graph be closed using the RDFS closure rules from the RDF model theory spec. This allows cool things such as automatic subProperty and subClass behaviour so you can write templates for foaf:knows and have it work even if the input graph is using Eric's relationship schema. The problem comes when you're dealing directly with rdfs:Class or rdf:Property such as when you're writing a stylesheet to produce a nice HTML representation of an RDF schema document. When you try to select all the classes in the schema you also get the inferred ones from the closure rules which rather messes things up. There are a …

Outputting Subjects and Objects

Excerpt: Here's an RDF Template that lists all the subject nodes of the triples in a graph followed by a list of the objects of those triples. The stylesheet distinguishes between resource and literal objects. <rt:stylesheet xmlns:rt="http://purl.org/vocab/2003/rdft/"> <rt:root-template> <html> <head> <title>Subjects and Objects</title> </head> <body> <ul> <rt:for-each rt:select="/subject()"> <li> <rt:value-of rt:select="label()" /> <ul> …

Selecting Only Subjects

Excerpt: For the RDF/XML round-tripping to work effectively, I need to be able to select only nodes that are the subject of a triple. Taking a leaf out of Sean B. Palmer's excellent RDFPath proposal, I'm introducing a subject() node specifier: subject() A node specifier that matches only resources that are the subject of a triple. Here are some examples of how it would be used in nodepaths: /subject() A globally scoped NodePath that selects all nodes in the context graph that are the subject of any triple in that graph. resource('http://example.com/') A locally scoped NodePath that selects the context node only if it has the given uriref and is the subject of any triple in the graph.

Outputting All Node Labels

Excerpt: Here's an RDF Template that outputs the labels for all the nodes in the graph: <rt:stylesheet xmlns:rt="http://purl.org/vocab/2003/rdft/"> <rt:root-template> <html> <head> <title>Output All Node Labels</title> </head> <body> <rt:for-each rt:select="/node()"> <pre> <rt:value-of rt:select="label()" /> </pre> </rt:for-each> </body> </html> </rt:root-template> </rt:stylesheet> This works well in the bleeding edge …

Arcs Not Forgotten

Excerpt: Arcs aren't forgotten in the RDF Templates design, and some way of manipulating them needs to be thought out if the RDF/XML round-tripping is to work. There are a couple of approaches to this from allowing nodepaths to select and match arcs to providing functions that access specific arcs from a given node. The former would allow the creation of arc specific templates to provide common behaviour no matter what the type of resource, e.g. outputing the dc:title of a resource in a consistent format. It means a change to the processing model though which may be complicated…

RDF Templates Label Function

Excerpt: Now the data model is a little clearer, I can introduce a new function: label: label() This acts on the context node. The function will return the string representation of the node's label. For a resource this is its uriref, for an untyped literal it is its value. For a blank node the label function will return an empty string. rong>Updated 14:14pm, 12 September 2003

RDF Templates Data Model

Excerpt: To support access to the labels of nodes in an RDF graph, I need to clarify the RDF Templates data model which is a little fuzzy at the moment. I think the following data types are required for now (others will be required later): node — represents a node in the graph. node list — represents a list of nodes which currently is unordered but should be able to be ordered in the future. string — an ordered sequence of characters. At the moment only the node and node list types are explicit and the string type is inferred. My thinking is that the rt:value-of element should return a string, therefore it needs to be able to convert nodes and node lists to strings. …

Why RDF Templates?

Excerpt: A couple of people have asked me why the world needs RDF Templates? My current answer is that if we're asking people to use the RDF data model then we'd better have good, portable ways of specifying how to make use of the data in that model. RDF Templates will hopefully provide a vendor and language independent means of specifying data extraction from a triple store. The more immediate and personal driver is that several of my current projects are running up against the same problem: serialisation of RDF data in a variety of formats. I've already mentioned placetime.com and semantic planet, but I'm also facing it at myRSS. myRSS essentially has a large triple store backend which is fed by …

RDF Templates Plans

Excerpt: I think the next steps for RDF Templates is to enable the round-tripping of RDF/XML. Is there a practical reason for doing this you might ask? Well, the reason I came up with RDF Templates in the first place was to solve a problem I had with placetime.com and Semantic Planet's source directory. Both of these services output HTML and RDF representations of the same things and both tie themselves in knots getting the right information out. With placetime I want to automatically incorporate RDF from other entities, e.g. the start and end instants of an interval. I could do this very easily if I just build an in-memory RDF model, add the triples I need from a query and …

RDF Templates Update

Excerpt: I've just uploaded a new version of the RDF Templates 1.0 spec, with a couple of minor changes suggested by Daniel Biddle.

RDF Templates

Excerpt: I posted this announcement to the www-rdf-interest mailing list just now: RDF Templates (RDFT) are an XML format for creating representations of RDF graphs. In a similar way to XSLT, RDF Templates define template rules with patterns which are matched against nodes. Template rules specify output actions and further node selections which trigger further template operation. However, instead of acting on an XML tree, RDFT acts upon an RDF graph. Nodes are specified using a 'nodepath’ syntax which defines conditional node/arc/node graph traversals. A macro definition facility is provided to reduce long nodepaths to easier to read strings. RDFT has been designed to parallel XSLT where sensible and anyone familiar with that language and with the principles of the RDF model should find it very easy to learn. RDFT solves a key …