The model-based approach being explored here supports eager materialization of triples via derived attributes in the data. I used it last night to respond to a suggestion to add wikipedia links to Constituencies.
Constituencies are in a one-to-many relationship with Postcodes( it is treated as such even if postcodes may straddle constituency boundaries I think). Given the raw data now publicly available, I could load all these triples into the triple store so that a user could navigate from Postcode to Constituency or vice-versa, but that would be a lot of triples and a full property listing of a constituency would list a very large number of postcodes.
However TheyWorkForYou provide an API to do this decoding, so an alternative is to define the relationship in the data model, mark it as derived and define its derivation with a XQuery fragment.
The attribute definition is in the model, although currently the API key is revealed here. I hope I'm not violating TWFY's usage terms here.
An XQuery script is passed the model,entity and attribute names and generates a search form using the parameters defined in the rule. When submitted, the script substitutes the parameters in the XQuery template and evals the completed query. Here the attribute type is an rdf:Resouce so a URI is constructed and the script redirects to that URI.
Search for 2010 Constituency by postcode
We could mix the lazy and the eager. The query would first query the triple store but if there was no match, fall back to using the derivation rule and post the derived triple to the database before returning the result. This use of the triple store for caching lazily materialized triples seems quite neat but the benefits would depend on the relative query costs and stability of the facts.