Some thoughts on RDF rendering
As part of the Semantic Portals work we've had to create a browsing utility that presents a web based UI for viewing and navigating a set of RDF descriptions (of environmental organizations). This blog note captures a few thoughts on how to go about this based on our experiences with the current prototype.
Many applications have a need to render RDF in human-readable form.
In some cases the requirement is to present a complete and accurate visualization of the RDF for people familar with the RDF model. There are many tools which support this both graphical (e.g. IsaViz, visualizer) and textual (e.g. brownsauce).
In other cases the need is to present an application specific UI which contains some data extracted from the RDF. In that case some form of template-driven rendering approach seems appropriate. There are some tools for this (e.g. RDFStyles) as well as general XSLT-for-RDF proposals (e.g. treehugger, RDF Template, RDF Twig) which could be used for rendering directly to XHTML.
One concern is how robust a template-driven approach is. It seems that a direct application of XSLT style templating might tend to produce monolithic templates which just insert strings extracted from the RDF graph into holes in the template. This fill-in-the-blanks approach could be fragile. We want to be able to write templates that can handle missing data and would not need substantial rewrites if the data were extended with extra properties or substructures. More specifically we identified the following requirements to enable robust templates:
- Open ended slots - rather than just put a specific property value in a slot in a template we wanted to be able to enumerate all properties of a particular type For example we have several different relational links between organizations in the dataset, we want to be able to write a template which says "list all relational links" here in such a way we can add new specific link types in the future without having to modify the templates.
- "Object" nesting - some of our data includes nested substructures (e.g. contact information) typically represented using bNodes. The top level template should be able to say "render the contact information here using an appropriate template" and then, when we later change the schema for the contact data, the top level template should remain valid, it should just find a different subtemplate to use for the contact information, dynamically.
- Conditionals - RDF is semi-structured, there are often missing values to cope with. A scripting language which can say "if this value is present do this bit of rendering" compactly and clearly would seem useful.
- Template extension. We aggregate data from different sources. We want the community to be able to add additional RDF in new schemas specific to specialist subgroups. Thus we'd like them to be able to publish appropriate rendering templates that the portal can use for rendering objects it doesn't know about.
Our current solution to all this is reasonably simple but proving quite effective for us. We use a general template language with scripting capability
Jakarata velocity. We place wrapped up versions of the RDF data together with a rendering manager object into the velocity context so that the velocity scripts can access them through a simple API. The velocity templates can call out to the embedded rendering manager asking it to render a structured resource using some appropriate template. The rendering manager can then discover the template to use based on the type of the resource being rendered and a weighted mapping of RDF classes to templates. We identify the templates using URIs making it easy to add new templates published by other providers. The RDF model wrappers provide convenience functions for iterating over all properties of a given type (identified by namespace, marker properties or the subproperty hiearachy) to make it possible to write templates with open-ended slots.
This approach seems to be working well for us. It does have a somewhat imperative (as opposed to declarative) flavour, but it does seem reasonably simple and flexible. The key was the use of a rendering manager to enable a template to invoke other templates indirectly via a template registry. Just another example of the old adage - there's no problem in computer science that can't be solved with one more level of indirection :-)
Categories XML and RDF
Posted by dreynold2 at April 27, 2004 04:51 PM