From n² wiki

Contents 1 Templating Unknown RDF 1.1 XSLT 1.2 Script Logic (eg: conditionals) 1.3 Deriving RDF->HTML serialisations from existing templates with eRDF annotation

[edit] Templating Unknown RDF

The general problem is how to serialize RDF as HTML. You have to know/decide:

• document order of properties
• which properties to display or not to display
• which html markup (+ extra text etc) to display the properties within
• depth of graph navigation (this is primarily a problem for routing rather than templating, but the template may have to cope with different degrees of 'augmentation' depending on the request)

[edit] XSLT

Quite powerful, but fragile because it deals with trees, not graphs, and harder to maintain with a mix of other scripting language (eg: PHP) code

[edit] Script Logic (eg: conditionals)

Hard code some logic based on some known important properties (eg: dc:title should usually go in a header of some kind, falling back to rdfs:label), and choosing vaguely appropriate markup based on the property value's content (eg: is it a url? is it text, is it long text?). Care needs to be taken to keep the code maintainable as conditions increase.

I think this is probably the easiest, best solution for relatively simple rdf->html serialisations.

My current approach is something like this:

• a resource view page is requested
• the code gets a SPARQL DESCRIBE of that resource, and parses it into a php data structure
• the application is configured to know which properties are 'special' - the template(s) can access these individually
• properties that are not 'special' or known to the application can be treated generically by the template(s); eg: display the property label and property value in dt and dd of a definition list

[edit] Deriving RDF->HTML serialisations from existing templates with eRDF annotation

If you have some html templates with eRDF markup, you have some machine-readable knowledge about how your application serialises certain types of combinations of RDF properties into html. So if the application has to deal with a new type of resource, it could look at the existing templates and generate a new one based on the markup it finds describing similar triples. The developer then has the option of further customising that template, and can signal that the processor can also examine it next time it is given an unknown resource type to represent.

I'm not quite sure yet what the most sensible way of retrieving and reusing the 'knowledge' from the templates is, or how complicated the process of finding similar triples needs to be (should it look up schemata and follow owl inheritance paths to find similar properties, for example?).

There is also the issue of serialising for different purposes (forms, full record display, record summaries, search listings etc), and the processor needs to be aware of which purpose it is serialising for, and therefore which templates to look at.

All in all, I think this is an interesting idea, but it might just be too complex to be worthwhile.