Ideas on RDF Web Applications

From n² wiki

[edit] Goals

• maintainable, expandable, readable, reusable, tested&testable code base
• utilise the flexibility of RDF
• without making users too aware of the RDF underpinnings to the application

[edit] Conventions

• camelcase or underscore?
• url patterns /editor/Collection/1234 vs. /Collection/1234?action=edit
• directory structure (a suggestion):

	/css
	/js
	/imgs
	/templates
		/views (view a resource)
		/forms (edit a resource)
		/listings (search resources)
		
	/lib
		/resources (controllers)
		/adaptors
			bigfoot.php
			changesets.php
		/vendors (could go in /usr/lib/php/ ?)
			/arc

	/scratch(Smarty)
	/tests
	/utils (cli scripts for testing, running queries, etc)
	/logs

[edit] Application Design

Basically what the application needs to do is map a requested URL to an RDF resource, to a representation of it that includes:

• ( possibly a subset of) its properties
• (possibly) some properties of related resources
• an html serialisation suitable to the content
• possibly without the developer having to hardcode any fore-knowledge of what that resource and its properties are (which leads me to wonder, what /can/ the developer be permitted to know? )

How can you produce HTML representations of RDF resources, that are agnostic (at least to a degree) of the data they represent, transparent to the developer, easily modifiable, and maintainable?

[edit] Routing

Routing (mapping urls to the application's components) is an important part to the answer (I think). Good routing should be a secondary aid to the user in understanding the structure of the application (so long urlencoded query strings should be avoided if possible, at least for aesthetic reasons), but it is of prime importance to a flexible application - it is the key for passing information about the resource to be represented to the application.

[edit] Templating methods

[edit] XSLT (+ scripting language)

[edit] pros

• great for simple things: the platform can do the transformations, you don't need to parse the xml in php
• guaranteed well-formed xhtml output
• can neatly deal with properties that may or may not exist in the source xml.

[edit] cons

• quickly gets more complicated for more difficult things
• requires hybrid approach, which can make development and maintenance more difficult - how to know whether to perform logic in PHP or XSLT, difference in programming styles between XSLT and PHP
• harder to maintain HTML markup because it is within lots of other markup, in template rules that don't necessarily follow the html document order

[edit] pure PHP templating

• do query for resource
• parse xml result, probably into an associative array
• pass variable(s) to template

[edit] pros

• flexible: write whatever queries you want, and you have the power of the scripting language for manipulating the results

[edit] cons

• it involves hard coding a certain amount of assumptions
• the relationship between the variables in the template and the results of the query are not always transparent.

[edit] 'eRDF-T'

Let the markup be the query

[edit] pros

• don't have to write queries or assign variables, just write templates
• you get semantic eRDF markup 'for free'
• transparent relationship between template and data

[edit] cons

• you can only get out data that can be described with RDF-in-HTML; so calculated properties, such as counts are not easily possible. You also can't specify variable properties or types. It would be possible to add these features, but the more features you add, the more you compromise on simplicity; complexity increases more than linearly with functionality once you pass the limits of what can be described with RDF-in-HTML.

• performance; each template is parsed twice, once by the eRDF processor, and again by the templating engine (Smarty). Smarty is bad enough.

• two layers of under-the-hood complexity to navigate when trouble-shooting - the eRDF triples generated, and the sparql queries generated from the triples.

[edit] Loading a Resource into an 'ActiveRDF'-style object wrapper

see activerdf site

eg:

 <h1>{$resource->dc_title()}</h1>

[edit] pros

• you don't have to write queries
• transparent relationship between template and data
• flexibility (data doesn't have to be described by semantic markup; can be used)

[edit] cons

• no eRDF/RDFa 'for free'

[edit] Markup Abstraction + Object RDF wrapper

By using a markup abstraction syntax such as HAML, you could write/modify the engine to generate eRDF or RDFa instead of plain html - taking the semantics from the object's methods/attributes accessed. (see this blog post for further description)]

[edit] pros

• You get semantic markup for free
• (arguably) cleaner syntax for html
• Guaranteed well-formed xml output.

[edit] cons

• performance - slower than embedding variable in plain html
• flexibility: you may hit limits as to what html can be expressed in the abstraction syntax (HAML seems quite open-ended though)
• the code for a markup abstraction -> RDF-in-HTML would need to be written (so the semantic markup isn't really 'for free')
• markup abstraction is arguablly less maintainable for front end development as it's less obvious how the server side source relates to the client side "View Source".

[edit] JSON based data structure

[edit] pros

• easy way of getting RDF/sparql results into native PHP
• in native PHP, the data can easily be formatted, counted, etc etc.
• facilitates client-side(javascript) and server-side development in a transparent maintainable way - javascript can access the data via the same paths as the php template code.
• the JSON that drives the template can also be linked to in the html, making it easier for others to consume the data serialised on the page, if they should so wish.

[edit] cons

• you can load the entire resource and all its properties in the controller generically, based on the URL requested, but how can the application know whether to 'augment' those properties with the properties of related resources, and calculated properties. You may wish to get a count of how many of a certain property the resource has, without the performance drawback of retrieving them all.

[edit] fresnel

[edit] pros

• very high level
• could let the application be really quite data agnostic.
• there is a PHP fresnel engine (called Horus, built on RAP)

[edit] cons

• perhaps overly complicated
• no direct relationship between source code and the html, so perhaps a nightmare to maintain.
• When I tried it out last, Horus (or RAP, not sure which) started hogging resources, the script wouldn't complete, and the whole thing hung and had to be killed.
• still seems quite experimental

[edit] thoughts

I wonder if it would be possible to parse RDF-in-HTML templates into rules/data as to how certain combinations of classes and properties are best serialised. write eRDF templates, parse them into triples, which are reified and annotated with xpath describing the relevant html context.