Keith Alexander's SemWebDev Blog SemWebDev Posts RSS Feed

Abductive reasoning, template generation, and RDF-in-HTML

I’ve written before that I think the dual context of RDF-in-HTML is interesting; the information encoded as eRDF or RDFa exists in both a DOM tree and an RDF graph. I mentioned this to CaptSolo in #swig, and he said that if this context was important, it ought to be retained somehow when extracting the RDF. At the time I thought, yes, you could retain that context, maybe by reifying the triples and annotating the reification with XPath or something like that. But what possible use could that be?

Recently, I’ve been mulling over this problem: Suppose you are developing an RDF-based web application that has these requirements:

The application has to display certain known types of resources in a particular way.
The application has to accept and store types of resources that may be unknown to you, the developer.
The application has to be smart enough to display those unknown types in a reasonable way.

Ideally, what you want is to be able to mark up the things you know about, that are most important to your application. And for the unknown types, imagine if your application could magically know how to represent them sensibly, based on how you had marked up similar properties in the past.

Maybe this is where retaining the dual context even after the triples have been extracted, could come in handy?

If you mark-up your templates with eRDF or RDFa, then you are encoding how your application should represent specific combinations of triple predicates. Extract that knowledge, perhaps as fresnel , or maybe by annotating the triples with XPath or HTML snippets, find a best fit from the groups of data triples to the groups of template triples, and use that stored knowledge of dual context to generate new templates.

I’m not exactly sure how you’d do it – I imagine it’d be pretty complicated. Probably the simplest way would be to figure out how to parse eRDF into fresnel, and from there you could push that through an existing fresnel engine; there’s even one in PHP, called Horus (I think, by Chris Bizer, though the link seems to have broken).

Why not just start off doing the whole thing in fresnel then? Well you could (in fact it’s just this sort of thing that fresnel seems to be designed for), but to my mind it might be a bit abstract, and not leave you with as much control over the output as templating would – so maybe this could be a way to get the best of both worlds.

Maybe it’s a daft idea. I don’t have an immediate practical reason to try to develop it, but it seemed interesting as a thought exercise if nothing else.

POSH: Plain Old Semantic HTML

It seems that a while ago, I coined a new acronym: POSH.

Surprisingly (I think the acronym sounds quite unappealing[1]) it’s gained some currency, but already there seems to be some slippage in meaning.

The meaning that I intended was this: (x)HTML used as a data format; writing HTML so that the data in the document can be parsed or transformed into another specific format.

Some people seem to be using it in a similar way (Jeremy Keith talks about POSH patterns ), but the POSH page on the µf wiki seems to suggest that it’s just a new way of saying Semantic HTML.

Regardless of the precise meaning of POSH, it’s good to see a concerted effort to explain that microformats aren’t, can’t be, and shouldn’t be, an answer to every semantic html need.

Perhaps this is an answer to the problem I raised in an earlier post µf: How many is enough (Microformats can only encompass a small number of semantic html conventions; yet everyone and his dog wants a new microformat for their own knowledge domain; how can the Microformats community remain relevant if they can’t keep up with what people are doing with semantic html).

The two small objections I have with the way the microformateers are presenting POSH is that:

It seems to be just a new buzzword for Semantic HTML, rather than having a usefully distinct meaning.
Talk of a ‘Process’ and ‘Checklists’, and badges and things makes it seem a bit prescriptive – here’s what you have to do to be in our club. When in fact it’s really a descriptive term for what you may’ve been doing for ages anyway (but didn’t have a term for before).

(Not that I think it’s up to me to tell people how to use or promote POSH, I just thought that if I’m being credited with coming up with the acronym, I’d like to put on record what I mean/t by POSH).

It’ll be interesting to see if this gives a greater currency to the idea of semantic html patterns.

Notes

Although the French version, CHIC, is quite cute.

TheyWorkForYou.com - Low hanging fruit for the Semantic Web?

Update: Graham Higgins set up a kforge project for the further development of the parlparse rdf mapping.

Anybody interested in figuring out an RDF mapping for TheyWorkForYou?

I think this is a dataset that would really benefit from being availble as RDF - it\'s of wide public interest, it can usefully be related to lots of other data of lots of different types, from lots of different sources.

The XML is available here, and it wouldn\'t be hard to write XSLT to RDF/XML (I\'ve done some preliminary XSLT already).

We\'d just need to decide what ontologies to use, and what URIs to use for MPs, Parties, Constituencies, etc (it\'s mostly possible to use the fragment identifiers in the XML files, but perhaps wikipedia pages for the other entities?).

I\'ve put up a section for it on the brainstorming page of the GetSemantic Wiki - not sure if that\'s the best place to start the discussion or not. But if you\'d like to be involved somehow, or discuss it, or just leave some useful links, please do so.

Schema-cache: a store of RDF vocabularies

I needed a SPARQLable store for RDF vocabularies so that I could do things like retrieve labels for data displayed in my UI (vocabulary authors take note – this doesn’t work very well because most vocabulary terms don’t actually have human-readable labels).

iand thought a store full of schemas sounded like it might be a good idea, so he set up one on Bigfoot (the Talis platform – if you’d like to play with a bigfoot store yourself, danja can sort you out with one).

I filled it up with some more schemas, and wrote a web page interface to it to make it a bit easier to browse and search. If you're interested, you can take a look at the schema-cache; it's only a test version and there may be ugliness and broken bits (I’d appreciate an e-mail to keithalexander@keithalexander.co.uk if you find any).

So now I’m wondering what interesting things might be done with it – what kind of interface to the data could make it easier to shop for vocabulary?

To run with that metaphor, would a ‘shopping cart’ be handy? You could browse around, building up a collection of terms, and then have different options for exporting them, as an OWL/RDFS template, as a chunk of namespaces for using with RDF/XML or RDFa, or SPARQL/turtle prefixes, or eRDF s – would that be useful? What are the problems that vocabulary shoppers face, and how can those problems be addressed?

If you've got any ideas I'd love to hear them (either in the comments, or in an e-mail).

RDFa(dict) : An RDFa parser in Python

RDFadict is a python library that extracts triples from RDFa, and provides a pretty nice looking API for accessing them.

It looks like it would be fairly easy, if anyone were inclined, to implement a simple RDFa to SPARQL and back templating system (as I have done with eRDF) with it. Should anyone care to try, the basic steps of the system (as I implemented it at least) are:

Parse the template into triples
Process the triples\' nodes into SPARQL variables, IRIs or Literals. (eg: {$name} becomes $name, {$person.name} becomes $person_name).
Sort them into separate queries as appropriate. (I created separate queries for each new for loop, using a variable naming convention to indicate the nesting of the loops in the template - you may prefer a different approach).
Execute the queries, nesting the results in an associative array, as indicated by the aforementioned variable naming scheme.
Pass the results array back to the template for displaying.

eRDF-T with Tonic and Smarty

I’ve hammered together some classes that lets you use eRDF templating within the Tonic framework. The dependencies are:

The code I’ve written is:

lib/erdft_parser.php : a class that reads in an erdf template, generates and executes sparql queries, and returns a results associative array
lib/eRdfResource.php : for GET requests, this passes the template to the parser, and the results array to Smarty. For POST requests, it takes the POST associative array, processes it with the functions named in the @class attributes of the html form inputs, transforms it to RDF/XML and saves it to the ARC store
lib/FormProcessor.class.php : a simple class in which you can define the functions to pass the form values through.
lib/ArcAdapter.php : a wrapper class for the ARC api to tie it in with Tonic’s idioms and conventions
lib/deleteErdfResource.php : a class for deleting ARC RDF resources - POST the iri of a graph to a location that uses this class and the graph will be deleted.
namespaces.meta : a list of namespace = uri values. Define the namespaces you use in the eRDF templates here.

It’s still pretty rough and alpha state, but if anyone would like to play with it, I’d love to hear comments, suggestions, bugs and bug fixes.

So, here’s a simple Blog how-to:

(I’ve bundled tonic, smarty, arc and my code + the blog tutorial code up in a package so you don’t need to cut and paste, or spend ages trying to install things.)

1. Configuration

Configure Tonic

dispatch.php

    
        require_once \'tonic/tonic.php\';

        $tonic =& new Tonic();
        $tonic->config[\'users\'][\'root\'][\'password\'] = \'mypassword\';
        $tonic->config[\'virtual\'][\'/\'] = array(\'/templates/blog-post-list.html\', array(\'class\' => \'eRdfResource\'));
        $tonic->config[\'virtual\'][\'/Posts/[^/]+\'] = array(\'/templates/blog-post.html\', array(\'class\' => \'eRdfResource\'));
        $tonic->config[\'virtual\'][\'/admin/\'] = array(\'/admin/post-list.html\', array(\'class\' => \'eRdfResource\', \'owl:sameAs\' => \'/Posts\',\'permission\'=>\'6666\'));
        $tonic->config[\'virtual\'][\'/admin/delete\'] = array(\'/admin/delete.html\', array(\'class\' => \'deleteErdfResource\',\'permission\'=>\'6666\'));
        $tonic->config[\'virtual\'][\'/admin/[^/]+\'] = array(\'/admin/post-form.html\', array(\'class\' => \'eRdfResource\', \'owl:sameAs\' => \'/Posts\',\'permission\'=>\'6666\'));

        $tonic->init();

        $tonic->load();

        $tonic->exec();

$tonic->config[\'users\'][\'root\'][\'password\'] = \'mypassword\'; sets the root password for the app.

$tonic->config[\'virtual\'][\'/admin/[^/]+\'] = array(\'/admin/post-form.html\', array(\'class\' => \'eRdfResource\', \'owl:sameAs\' => \'/Posts\',\'permission\'=>\'6666\')); (and the other lines like this) define the urls you want your app to use, then the template the resource representation will use at that url, then an array of metadata. We tell it to use the eRDFResource class. The owl:sameAs property, when set, will let the eRdfResource use the data from the other url for an alternative representation of the resource. In this case, we are using it to say that /admin/foo should pull in data from the graph at /Posts/foo (instead of displaying it for reading, we will display it in a form for editing). In addition, you can set a metadata property called redirect_url - on a successful posting, the user will be redirected to this location. For info about permissions and other standard Tonic stuff, see the Tonic docs.

Configure ARC

edit the database connection details in lib/arc/arc_config.php

2. Write a template for all the pages to use

templates/erdft.xhtml

    
    
        
             baseUrl}/templates/tonic.css\"/>
                {foreach from=$css item=\"style\"}baseUrl}{/if}{$style}\"/>{/foreach}
           {foreach from=$resource->ns key="ns" item="href"}
        
            {/foreach}
            
            {if $resource->owlSameAs}{/if}
        {$resource->title|escape}
    
    
        {$resource->getBody()}

3. Write the admin Section

admin/post-list.html


    Admin Blog Posts
    
    {foreach from=\"$blogs\" item=\"blog\"}
        

            
                {$blog.title}
            
            
                {$blog.contents}
            
            
                
                
            
        Comments
        
            {foreach from=$blog.comments item=\"blog__comment\"}
            
                {$blog__comment.creator}
                {$blog__comment.contents}
                
                    
                    
                
            
            {/foreach}
        
        
    {/foreach}
    
    base_href()}Posts/-change-my-name-\">New

As you can see, the html uses eRDF to define the semantics of the smarty variables in the template. As I explained in my last post, the ‘blog_comment’ syntax tells the erdft parser how to nest the arrays, so that Smarty can display it when the data comes back. We can use the Smarty functions after the pipe character | to format the values that get passed into the variables. I’ve used base64_encode to avoid having full urls in the @ids of html elements (which is invalid html), and a replace function to change the blog post url into the url to edit the post.

/admin/post-form.html

    base_href()}\" method=\"post\" accept-charset=\"utf-8\">
    
        Blog Post: 
        Blog Uri owlSameAs}\" class=\"f_set_iri uri\"/> 
        (edit this to the uri you want the post to appear at)
        Title 
        Contents {$contents}

The points to notice here are: - the @names use square brackets to create an associative array structure that mimics RDF/XML - it is transformed to RDF/XML on the server. - the class names that begin with f_ are names of functions that will process the value on the server. f_set_iri sets the graph iri to this value.

4. Write the frontend

/templates/blog-post-list.html (the names and location of the template files are irrelevant, as long as you tell Tonic where to find them in dispatch.php)

    Blog Posts
    
    {foreach from=\"$blogs\" item=\"blog\"}
    {$blog.title}
    {/foreach}

/templates/blog-post.html

            {$title}
            
                {$blogtext}
            
            
                {foreach from=\"$comments\" item=\"comment\"}
                
                    {$comment.creator}
                    {$comment.contents}
                
                {/foreach}
        base_href()}\" method=\"post\" accept-charset=\"utf-8\">
        
            Comment?
            base_href()}\" />
            base_href()}#comment-{$smarty.now}\" class=\"f_set_iri f_set_redirect\"/>       Name 
            
        
        Comment

Again, much the same as before. I use a smarty {$smarty.now} to autogenerate an id number for the comment iri - which is a pretty bad idea on reflection, as a user would be able to edit that value in the input and overwrite a previous comment. If I were you, I would write a function to autogenerate the comment iri during processing. The $comment.iri_optional syntax means that the variable is optional: a post doesn’t _have_ to have comments.

5. Finished

That should be just about it. Add new namespaces to namespaces.meta - play around with the permissions and other meta data, either in the config array in dispatch, or in .meta files (eg: blog-post.html.meta is the metadata for the representation displayed by blog-post.html).

Things I\'d like to develop further

Caching. I think this might already be handled sufficiently by tonic - though I haven\'t really checked this out yet. It might be good to cache the generated SPARQL queries in such a way that they could be edited by the developer in special circumstances ( as suggested by shellac on #swig ).
Aggregate functions - count, max, min. Not entirely sure what the syntax should be here. It\'s important that the markup that generates the query also remains semantically correct in displaying the results.
Implement FILTER.

eRDF-T and Nested Arrays

In my previous post on an idea I had for eRDF-T - deriving SPARQL queries from an eRDF template, retrieving the data, and injecting them back into the template -, I mentioned that deriving multiple queries from a page would be necessary if you wanted to do thing like nested associative arrays and aggregate functions.

I spent a while puzzling over how to separate out the triples and variables from the template into sensible query-able groups - sifting through the triples depending on how they related to one another, adding in pseudo properties to the template to help. And then I had a simpler, and (I think) better idea: I could use the naming conventions of the template’s variables to denote how they should be grouped.

As I see it, basically what I’m trying to do is map from the graph structure of RDF to the tree structure of XML and nested arrays. SPARQL returns its results in a tabular structure, so you need to put together several SPARQL result-sets to get a tree-like structure. I can let the eRDF-t processor know how to separate the triples and nest the results by naming my variables like this: $org__member.name. The processor can then create an orgs group, which will contain a members group. The processor gets the results for the orgs array, and for each org, queries for the members relating to it (how they are related is defined through the eRDF properties), retrieving (at least), a value under the key/heading ‘name’. So the name of the first member of the first group can be found at $data[‘orgs’][0][‘members’][0][‘name’].

So the Smarty code, as you would write it, would look like:

    
        {foreach from="$orgs" item="org"}
            {foreach from="$org__members" item="org__member"}
            {$org__member.name}
            {/foreach}
        {/foreach}

The $row.key syntax tells the eRDF-t processor how to group together variables into a rows, and tells Smarty which values in the row to display. The double underscores in the array names tell the eRDF-t processor how the results should be nested - but are, of course, irrelevant to Smarty. I should say, Smarty isn’t integral to the technique. You could just pass different regular expressions to the eRDF parser’s constructor if you wanted to use another templating engine, or native PHP or whatever.

With eRDF, this might look like:

    
	<ul>
        {foreach from="$orgs" item="org"}
        <li class="-foo-Org" id="{$org.id}"> 
		<ul class="foo-members">  
	   {foreach from="$org__members" item="org__member"}
            	  <li id="{org__member.id}" class="foaf-name">{$org__member.name}</li>
            {/foreach}
	 	</ul> 
	  </li>
        {/foreach}
	</ul>

Which would convert to a query like:


	SELECT $id WHERE $id rdf:type <http://example.com/foo#Org> .

And for each of those result rows, generate a subsequent query like:

SELECT $id $name WHERE $id foaf:name $name .

Which would create a results array like:


orgs => (
  0 => (
    id => "org_1",
   members => (
      0 => (
        id => "member_1",
        name => "John Smith"
        )
      )
    ) 
  )

Semantic Blogging

Pretty much from the start of this blog, I’ve used eRDF to annotate the structure of the site (with SIOC and DC mainly). More recently, I started making more of an effort to mark-up the contents of the posts as well.

Why would I go to the trouble? Well, mainly as an experiment, to see what the process was like, and what the possibilities are. I’ve not noticed many other people doing it, which is understandable because it does involve extra hassle, and perhaps not any clear benefits as yet. It’s a bit of a shame from my point of view because a GRDDL/RDFa/eRDF enabled web, where you can create human-readable web pages that describe concepts, which semantically link to other concepts, seems like quite a neat idea; unfortunately GRDDL-able web pages to link to are not (yet) the norm, even in the RDF-enthusiast enclave of the web.

Magic

I wasn’t really expecting anything magical to happen, so I was pleasantly surprised recently when browsing through the DOAP Store to find a description of a software project that I had published on this blog

After I’d written it, I must have run it through triplr to check the RDF was right, and then clicked my PingTheSemanticWeb bookmarklet. And now some of the information was there on another web site … magic!

Now you might be thinking that I’m too easily impressed, that what happened there was not much different to what news feed syndication has been doing for years. And that’s sort of true; the same ends could have been achieved had I been publishing, say, a special XML format (or microformat) for describing software projects, and the DOAP store harvested that. Except I didn’t publish a special format, I just added some annotation to my XHTML, which describes not only software projects, but blog posts, people, magazine articles, and anything else I blog about. So the DOAP store can take the information about software, the SIOC browser could take the information about web-sites, blog posts, and online communities, a FOAF browser could take the information about people, and so on. But crucially, what I’m publishing isn’t just a bunch of disparate information that happens to be on the same page – it’s all linked together semantically, so, for example, a Technology Blogs aggregator could pick out all the blog posts that describe certain software projects. There’s semantic context to be harvested.

Writing inline semantic content

If you want to express the contents of your blog posts as RDF, you probably want a technique that lets you embed the semantics as you write the contents, rather than create, say, snippets of turtle about it at the end (though actually, it might be worth trying that just to see if it really is more effort or not).

I started off with eRDF, partly because:

I had bengee’s eRDF parser already to hand (though I have since also found an RDFa parser in php)
I didn’t like the idea of my pages not validating as XHTML – though now there is RDFa support in the W3C’s validators (which unfortunately I still couldn’t get to work)
I wanted to be able to style semantically cross-browser, and IE6 doesn’t do arbitrary attribute selectors (though IE6 support is not really an issue for the visitors to these web pages – - but classname selectors are still more friendly to write)
RDFa wasn’t (and isn’t) finalised yet.

For the last reason, I’m glad I didn’t start using RDFa yet, because there have been changes in the syntax, such as the change from @class to denote rdf:type, to the new attribute @instanceof, and it would have been really annoying to have to lose the semantics, or go back and make those changes.

One limitation of eRDF that I needed to work around for my blog posts is that it can’t express XHTML in literals. RDFa can, so I tried that, using a GRDDL profile for RDFa (hmm, can’t find it now – there were several), in addition to the eRDF profile, but triplr didn’t like it (with or without the eRDF profile as well). So I gave up and decided to provide the RDF/XML myself, using bengee’s eRDF parser, and specifically replacing the plain literal version of the sioc:contents with the full HTML version.

The down-side is that the eRDF parser doesn’t know about all the rules of eRDF, some of which are not documented any where, and which I only found out when testing out my javascript eRDF parser for Operator on Ian Davis’s home page (specifically, @href and @id work the same when it comes to determining the subject).

Another option I considered was some kind of semantic wiki-style markup that could parse into both HTML and RDF, but I couldn’t really think of a syntax that would be as powerful as HTML, and still be much simpler (not so much so as to make writing a parser worthwhile).

How to write about stuff semantically

A fairly common thing I wanted to mark up was the relationship between me and the thing I was linking to. Now, if I just did <a rel="foaf-knows" ... the subject would be the blog post, rather than me, so I do something like this:


<div id="surrogate-me">
    <a rel="owl-sameAs" href="http://keithalexander.co.uk/#me"></a>
    ...some stuff ...
    <a rel="foaf-knows" href="http://example.com/somebody/#me"><span class="foaf-name">Someone's name</span></a>
</div>

I can of course do the same thing when wanting to describe other people or things, and their relationships to other people, things, or documents. In such a case, I might want to relate those things to the blog post, to indicate that this blog post is about that person or thing:

 
<div class="sioc-about" id="joe-bloggs">
    <p>
        <a rel="foaf-homepage rdfs-seeAlso" href="http://example.com/joe-bloggs/home/">
            <span class="foaf-name">Joe Bloggs</span>
        </a> is a fictional example ... 
    </p>
</div>

In this case Joe Bloggs doesn’t already have a URI, but by using @id for the subject, my eRDF is minting one for him in the url space defined by my <base href=""/> element. If he already has a URI, I can do:


    <a rel="owl-sameAs" href="http://example.com/joe-bloggs/#me">
        <span class="foaf-name">Joe Bloggs</span>
    </a> is a fictional example ...

Unfortunately a lot of (non-information) resource URIs resolve to RDF/XML pages, rather than HTML, and I don’t want to send HTML browsers to RDF/XML pages purely for the sake of my generated triples. So I do something like:

<div class="sioc-about" id="joe-bloggs">
<a rel="owl-sameAs" href="http://example.com/joe-bloggs/#me"></a>
    <p>
        <a rel="foaf-homepage rdfs-seeAlso" href="http://example.com/joe-bloggs/home/">
            <span class="foaf-name">Joe Bloggs</span>
        </a> is a fictional example ... 
    </p>
</div>

In RDFa of course, I could use the @about to describe external resources without hyperlinking to the URI, which is more succinct, but there is arguably an advantage in taking the trouble to mint that extra local #joe-bloggs URI, in that it provides a sort of light-weight provenance chain back to the page that made the statement. I also like the idea of minting URIs that can resolve to both human and machine readable descriptions of the resource identified by the URI.

If all I wanted was to link semantically to a Joe Bloggs’ URI, but I wanted to make the hyperlink to his HTML homepage instead, I think I could do this in RDFa: <a rel="foaf:knows" href="http://example.com/joe-bloggs/home/" resource="http://example.com/joe-bloggs/#me">Joe Bloggs</a> which is quite concise, but I think (correct me if I’m wrong RDFa-ers) then I can’t state the relationships between Joe’s URI, his homepage URL, and the literal “Joe Bloggs”, so I’d probably opt for a more verbose but informative construction.

Future Plans

New Backend

At some point I’ll probably try to cadge another Bigfoot store, write a better blogging engine for it, and move my blog there. Since I already publish the blog as RDF/XML, importing it should be pretty simple (just POST all the RDF into the store).

At the moment, the blog is just stored in the file-system. A SPARQLable backend would make it possible to do more interesting dynamic things, like generating a FOAF document for me from my blogging activity. I don’t particularly like the idea of manually creating and maintaining a foaf file. But a document with statements about me and my social network (such as it is) aggregated from my posts, and possibly other online accounts (like Twitter via Tom Morris’s Twitter ->RDF service ), so that RDF-aware web sites like Revyu could be pointed at it, is a lot more appealing. (coincidentally, danbri just blogged a very similar sentiment.)

Another thing I’d like to do is, when parsing the eRDF from the posts, reify it to provide provenance about when the statements were made, by whom (ie: me ), in which post, and that kind of thing.

One thing I’m wondering about though, is how to deal with information that was true, but isn’t anymore. If I say that I’m based near somewhere, and then I move away, how can I give my dynamic FOAF page the smarts to know which statements replace older statements, and which augment the graph?

It’d also be nice to have a general data browser section, for searching through the data from the posts and elsewhere. After all, people often say that they use their blogs as a place to collect information about themselves, store links and ideas. With semantic annotation, that should become an even more interesting proposition.

It’s also pretty useful to have a human-readable rendition of the extracted semantic data, to help discover if you’ve made any mistakes in the semantic mark-up.

Semantic Link Previews

I’m quite jealous of Frédérick Giasson’s Semantic Hyperlink Plugin for Wordpress so it might be nice to have something like that built in. And because I’m annotating my HTML semantically, the link preview thing could also show how the linked-to resource relates to the resource linking to it.

hGRDDL

hGRDDL is a proposal/technique that Ben Adida came up with for transforming GRDDLable HTML pages into RDFa (rather than RDF/XML). I’d like to support that when the RDFa syntax is finalised.

Better Admin/Editor

One of the tricky/tedious things about writing semantically annotated blog posts is finding appropriate terms for what you want to describe, and then adding the namespaces to your document or template. With eRDF, you have to put all the schemas you’re using in the head of the document. With RDFa, you can add namespaces anywhere, which can be more conveniently ad hoc, though if you need to use that namespace again in another post, you’d have to cut and paste it in again.

What I want is to build an ajax interface to schema-cache into the editing pane, to somehow make the process easier and more streamlined – to be able to look up schema definitions, and insert new namespace declarations without changing tab. I’d also like for the namespace declarations to be dynamic – to only declare the namespaces actually used in that document.

Is Semantic Blogging Viable?

It’d be pretty good if more people embedded more data into their markup when blogging, but it does involve an extra investment of time, effort, and expertise, so what kind of return can bloggers expect on that?

For some, perhaps the thrill of seeing their data magically float off into the semantic web will be an incentive (at least until the novelty wears off, and/or spammers catch on and make things more complicated ).

Maybe if things like Frédérick Giasson’s Semantic Hyperlink Plugin for Wordpress become more popular, there will be more of an incentive to make your own pages semantically rich ones to link to.

Some might find it useful as an ad hoc way of recording statements about themselves and their activities, so that they can be dynamically retrieved later.

But as things stand, semantic blogging still needs a certain amount of expertise. I wonder if blogging tools will develop interfaces intuitive enough for people to blog semantically without needing to understand how to write RDF and HTML. Shift is an interesting step in that direction – in that it lets you drag and drop items from desktop address books and calendars into RDFa snippets you can drop into your text editor. At this stage though, you still need to be able not to baulk at all the angle brackets of an RDFa snippet, and you’d probably need at least some kind of understanding of RDFa syntax to use it. What these tools will need, I imagine, are ways of visually representing the underlying semantics of enriched documents, such that the general user can understand and care about getting them right.

More important than that though, are motivations strong enough to get people to embed semantics. Probably, if people do it at all, they won’t bother to mark up every bit of information, just the things that they particularly want to share, or index for their own reuse later (which, come to think of it, is the purpose behind a large chunk of web 2.0 sites).

Suggestions to Authors of RDF Vocabularies

Working on Schema-Cache, it was interesting to work with Ontologies and Schema as data, rather than my more usual mode of reading them as documents. It was also a little more difficult than I might have hoped, so I thought I’d lay out what some of the difficulties were here, in case any schema authors (or budding schema authors) care to take note and make their vocabularies more user (and developer!) friendly.

Use Absolute URIs

When I tried to save a lot of the vocabularies straight into Bigfoot, I got nasty error messages and problems because the vocabularies used relative URIs. The RDF Specification doesn’t permit this in RDF/XML – you can’t use \"\" or \"#foo\" without setting an xml:base.

To get round this, I set the base (as the URI the document was parsed from) manually, using bengee’s ARC RDF/XML parser, and then reserialising as RDF/XML, which I could POST to Bigfoot. This isn’t a good thing for you (as a publisher) to make me (as a consumer) do. Firstly it’s annoying and more hoops to jump through. Secondly, you probably publish your RDF at more than one URL – one will be the canonical one (perhaps with http://purl.org) and another might by the location that redirects to. Both of us want me to use the canonical URL, but you have to tell me what it is by setting the xml:base.

In the comments, Morten, explains that I\'m wrong about the spec not permitting relative URIs without an xml:base - he\'s right of course. However, I stand by the broader point that it is undesirable to do so because it makes it harder to consume the RDF, and might accidentally result in different URIs being used for the same terms.

rdfs:isDefinedBy

Remember to use this property to link a term back to the vocabulary that it belongs to. It’s really handy to have a formal link between a term, and the vocabulary that describes it, but quite a few terms do not link back to their vocabularies

This isn’t compulsory of course, but I’d consider it good practice – because once your vocabulary is out of it’s document form, and into an RDF store, it can be tricky to join it all back up again (you’d have to rely on string matching on the namespace, which makes things a bit more complicated).

vann

vann is a small vocabulary of properties for annotating vocabularies. These are the properties you can use to make your vocabulary descriptions a little richer.

changes – A reference to a resource that describes changes between this version of a vocabulary and the previous.
usageNote – A reference to a resource that provides information on how this resource is to be used.
example – A reference to a resource that provides an example of how this resource can be used.
preferredNamespaceUri – The preferred namespace URI to use when using terms from this vocabulary in an XML document.
preferredNamespacePrefix – The preferred namespace prefix to use when using terms from this vocabulary in an XML document.

I think it would be nice to see the preferred namespace properties in particular get wider usage amongst vocabulary authors; a possible use case is for RDF (re)serialisers to be able to use nice prefixes, rather than generated ns1, ns2, style prefixes.

Labels!

Most important, and most neglected of all I think, are labels. The definition (well, the rdfs:comment ;) ) for rdfs:label is A human-readable name for the subject. And yet there are no shortage of terms that use camel-casing in their labels rather than something that looks like it was intended to actually be read (rather than merely recognised) by humans. Perhaps I’m over interpreting the rubric here – in fact, even the RDFS Vocabulary is disappointing in this regard.

However if developers are to make use of the power, flexibility, and self-descriptiveness of RDF data, we need to be able to bring in labels for our data that we aren’t ashamed to display in our user-interfaces. If you have a look at some of the pages in Schema-Cache you’ll see what I mean. The page pulls in the rdfs:labels for the data it’s displaying, but the labels simply aren’t very good!

I’ve talked about this a few time on irc with fgiasson who seems to be doing similar sorts of things and experiencing the same kind of frustration. Thankfully, he’s an author of a number of large vocabularies himself, so has ample opportunity to put this into practice. But as the number of RDF developers and RDF applications grows, there will be more and more need for vocabularies to be aware of the uses they enable for their terms and the data they describe.

So you can greatly improve the usability of your vocabulary by thinking of your users’ users when writing your labels. And you don’t need to stop at one label – it will also become important to provide labels with translations into different languages. You can also help interface developers even more by using Morten Frederiksen\'s label vocabulary, which provides properties for singular and plural labels – and now inverse labels (singular and plural)! (Inverse labels reduce the need, and associated complexity, for inverse properties; they solve the problem of what text to show next to a link to a resource that, in the RDF, links in to the current resource).

A New Mailing List for RDF schema development!

Somewhat related to this, Ian Davis has today started a new mailing list for rdf schema development . As the description says, the list is:

A place for authors of RDF schemas to gather and talk shop. The focus is on smaller schemas that don’t already have an established community so discussion of improvements to FOAF, SIOC, DOAP and the like are off topic, although reference to those schemas and their designs is not.

I’m really looking forward to reading the threads on this list, and the advice and best practices for schema development that emerge.

HTML5 and the future of @profile

Tom Morris has written a post decrying the HTML5 working group's decision to drop the @profile attribute. I thoroughly agree.

The point that @profile has remained relatively obscure all these years is worth noting, but (as Tom says) does not mean that it should be thoughtlessly dropped from future specifications. It’s not that @profile is useless, it’s that its use hasn’t been clearly defined and explained.

The concept behind @profile has come of age now, and it’s the right time to define and push the idea. It needn’t necessarily be @profile in its current form; that could possibly be revised; perhaps HTML 5 could make it a new element, or allow it as an attribute on elements beyond head (to make it more suitable for use in constrained authoring environments like CMSs). But don’t leave HTML 5 without a mechanism to allow decentralised html data formats.

To ignore the principle of addressable html metadata profiles because one particular (and unabashedly limited) approach to data in html seems to get along ok without it, is either arrogant, or ignorant. (Besides which, it's distinctly at odds with the GRDDL CR specification).

Most of the people that get interested in microformats, they’re not, I don't think, especially interested in contact details or calendar events per se. But they love the idea of making data extractable from their html. Many of them even go to the trouble of creating their own formats, some complete with specification documents and examples and everything, hoping that their format will be endorsed by the Microformats community (which it almost inevitably won’t be).

@profile lets any html author develop and formalise their own formats, exposing their data clearly and reliably to user-agents. Microformats doesn’t, because without something in the HTML spec like @profile, microformats authors have to rely on the conventions they are using being common knowledge to user agents. And there are only so many conventions that common knowledge can accommodate.

So if the Working Group take the time to look at @profile properly, and work out a way to let authors specify the semantics and transformation/parsing scenarios that apply to their documents (converting, not just to RDF, but to other formats as well), they could turn the humble @profile into one of the most exciting and innovative features of HTML5.

(If they don't, we'll just have to invent a microformat for pointing to profile URIs).

MyPost2

Test 2 test34 test 34

RDF article @ Digital Web

My article about RDF was translated into french: RDF pour tous : du publicateur au développeur web

If you are a reader of this blog, I doubt you will learn much from it, but I wrote an article for Digital Web entitled RDF for the rest of us, which was published yesterday. I tried to explain the basics of why you would want to publish, and develop with RDF, and followed with a tutorial on using eRDF. One especially nice thing was that the article's editor, Matthew Pennell, went to the trouble of adding eRDF markup to the contributors' profiles.

Exhibit your RDF databases!

I've written a short script that reads in an Exhibit JSON template file, and turns it into SPARQL queries, queries a local ARC RDF store, and injects the results back into the items array of the JSON template, which it then outputs.

The script will generate a new query for every item it finds in the items array. The format of the template is the same as a normal Exhibit JSON file, except:

you need to specify your types and properties in the "types" and "properties" objects, and give them an "uri" property, containing the uri of the RDF Class or Property in the database. Actually, this is still normal to Exhibit, which can use these URIs in its RDF/XML exporter (though the exporter apparently needs a bit of work before it will do this for the rdf:types).
In each item, use empty strings for values that should be variables in the query
The value of the "label" property should be the name of another property from the properties object.

Here is an example:


					{

			    types: {
			        "Person": {
						uri: "http://xmlns.com/foaf/0.1/Person",
			            pluralLabel:  "People"
			        }
			    },
			    properties: {
			      
			        "name": {
						"uri": "http://xmlns.com/foaf/0.1/name",
			            label:        "Name",
			            valueType:    "item"
			        },
					"email": {
						"uri": "http://xmlns.com/foaf/0.1/mbox",
			            label:        "E-Mail",
						"pluralLabel": "e-mails",
			            valueType:    "uri",
			        },
					 "knows": {
							"uri": "http://xmlns.com/foaf/0.1/knows",
				            label:        "Knows",
				            valueType:    "item"
				        },
			    },
			    items: [
					{
						"type":	"Person",
						"label": "name",
						"name": "",
						"knows": "",
					},
					{
							"type":	"Person",
							"label": "name",
							"email": "",
							"name": "",
					}
			    ]
			}

You can see this in use at this basic Exhibit, and have a look at the json-to-sparql-and-back script itself.

What's the point? It's easy to write SPARQL queries.

It is pretty easy to do this manually anyway (in part, at least, because of the RDF-like nature of Exhibit's data structure), and I can't pretend the script does anything technically complicated or clever, but if you're putting up an Exhibit anyway, this script can let you remain in that mindset, or indeed make Exhibits from RDF datastores without knowing SPARQL at all - or even very much about RDF (beyond the concept of letting URI's identify concepts).

Where this idea could really become cool though, is if there was a web service to which you could send your json template and the location of a SPARQL endpoint, and get back a nice full Exhibit database object.

If you coupled this with some of SIMILE's other products (Piggybank and Solvent), then you've got a relatively easy way to present the data you've screenscraped, without doing any server-side coding at all. You could just scrape your data, save it to SIMILE's databank, and write your Exhibit with a call to the webservice, sending the query to your SIMILE databank. In fact, the webservice bit isn't even totally necessary - you could maybe use Lee Feigenbaum's sparql.js library to fetch the results, and the rest of the code would be trivial to rewrite in javascript too (though there are the cross-site XMLHttpRequest security restrictions you'd have to contend with).

Safer than SPARQL, easier and more open than an API

This also offers a minor solution to another problem: I might want to provide open access to my RDF data (or some of it), but I'm not going to put up a public SPARQL endpoint. If I gave you an endpoint to my ARC RDF store for instance, you could easily write (or miswrite!) a query that would give the database a lot to think about for a long time. I also probably wouldn't want you to see all my data, if I'm storing user account details and things in there (there are actually some ways around this with Arc, involving splitting sensitive properties into different tables).

It would be easy to provide an Exhibit JSON endpoint instead. You could predefine the properties and types objects of the classes and properties that you want to make available to the public, and publish what they are. And because there's no need for a DISTINCT in the generated query (Exhibit does a lovely job of smooshing together objects with the same id), and you can choose the LIMIT and set it relatively low, it shouldn't (I think, correct me if I'm mistaken!) be possible to send an Exhibit JSON query that would result in a hugely expensive query.

PHP RESTful Frameworks

Yesterday I spotted a new PHP RESTful framework (Konstrukt), which is interesting, because it sells itself in much the same way as Tonic, the framework I'm using at the moment (transparent use of HTTP, lightweight, flexible). I haven't dug around in the code yet, but it looks interesting.

The crucial points of difference between konstruct and tonic seem to be that Tonic:

Uses Smarty for templating (by default, though you can use something else fairly easily
Allows Regexes in URL patterns
Has a concept of ‘metadata’. Metadata includes properties like “last modified”, “created”, “template”, and “title”, which can be assigned manually or programmatically to resources.

Whereas konstruct:

Uses PHP as the templating language (by default)
Has a programmatic form builder class
implements built in support for 18n

There's also another PHP REST framework/toolkit called dbscript, which is a REST wrapper for database CRUD. I've included the descriptions of the 3 below, marked up with eRDF+doap mainly.

Konstrukt

A REST-ful framework of controllers for PHP5.

Key Aspects

Controllers are resources
URI-to-controller-mapping gives your application a logical structure
Routing based on logic rather than rules
Nested controllers supports composite view rendering
Formcontroller provides filtering and validation

Design Goals

Embrace HTTP rather than hide it
Enable the programmer, rather than automating
Favour aggregation over code-generation or config-files
Encourage encapsulation, and deter use of global scope
Limit focus to the controller layer

Konstruct SVN Repository

Tonic A RESTful Web App Development Framework

Tonic is an open source less is more, RESTful Web application development and Web site management PHP script designed to do things "the right way", where resources are king and the framework gets out of the way and leaves the developer to get on with it.

Tonic helps you develop Web applications that embrace the way the Web really works, enabling your applications to scale, extend and work with other systems easily.

Everything is a resource: Tonic works exclusively with resources, a resource is simply a piece of data with some metadata accessable by a URL using HTTP methods. Everything within a Tonic system is a resource and so can be handled via the standard HTTP interface.
Domain modelling through resources: When modelling your problem domain within a Tonic system, every domain object is a resource or a collection of resources.
Keep it simple, stupid!: Following the Unix philosophy of many small parts working together via a common interface, Tonic uses resources as it's "programs" and HTTP as it's "streams" to enable you to build complexity out of simplicity.

Main features

Tonic embraces a number of standard Web features and best practices, as well as features, principles and ideas taken from PHP, Unix, and other software design patterns:

Resource editing via HTTP PUT and DELETE methods (or via the Resource::save() and Resource::remove() PHP methods)
Easy to extend via new resource classes
HTTP basic and digest authentication
Resource method permissions to provide authorisation to individual resource methods
Output templating via Smarty
Output caching via HTTP 304 response codes and modified headers
Extendable resource storage types via adapters
Content negotiation
Match multiple URLs to a single resource
Follows Unix modular design principles

Tonic CVS Repository

dbscript

RESTful crud framework for php 4/5

dbscript is a web development framework, it helps php programmers take advantage of efficient design patterns and idioms from other dynamic languages and frameworks.

for example, the Mapper and Route classes work together to map actions and records to distinct urls. among the many advantages of routes are the automatic named routes: url_for( resource ).

restful urls, http-style controllers, atompub/html introspection documents and content-negotiation are among the sophisticated features of this programmer-centric development tool.

the framework is a database abstraction layer, with built-in adapters for PostgreSQL and MySQL.

Why RDF Ought to make Web Apps easier to build

Some too-hasty thoughts on why it ought to be fundamentally easier to build web apps based on RDF, instead of relational databases:

RDF is the Web

Unlike the relational database, RDF is designed to be part of the Web, to be the Web. Its standard method of unique identifier is the same as the Web’s.

A GET request of a URI to your web app is a request for a representation of a resource.

Typically, your web app has to deconstruct the URI being requested into distinct parts so it can go:

this bit means use this controller code
and then call this method
which will retrieve these bits of data (maybe using this part of the URI as a parameter)
and assign them to those variables
to populate that template

Fair enough. Frameworks will often use some naming conventions to shield the developer from the first two. But it still leaves a lot of grunt work.

With an RDF-based web app, the URI being requested is in itself an identifier for the resource being requested. So the framework can identify and retrieve the resource for you, leaving you to represent it.

RDF Represents All Data In the Same Way (Triples!)

This means that you can use the same code for saving user account data as for saving catalogue stock items, chemical formulae and blog posts. Which means less code to write and more tools to share.

RDF data is its own metadata

When you take data out of a relational database, it loses the semantics that the database schema gave it. So you have to write a lot of domain-specific code preserving your interpretation of the data’s semantics. RDF can keep its semantics right to the users’ screen if you want (for example, using RDFa or eRDF) (and even beyond: see Benjamin Nowack’s Web Clipboard ). So again, this means a potential for more generic tools and libraries, and less domain-specific code.

RDF is flexible

RDF can be a lot more flexible because it is self-describing, and doesn't rely on a larger structure, such as an XML tree, or a relational schema of tables, to give it its meaning. You don't have to know at the start of a project whether a relationship is one to many, or many to many, or know where everything fits into the DOM tree. This should mean less to set up for the developer, and a more rapid prototyping and development process.

(Although, this flexibility can be problematic later, as the data is less consistent and predictable.)

MyPost1

My Post 1

getSemantic.com

Thought I\'d put out a plug here to getSemantic, which is a community wiki and irc channel (freenode.net #getSemantic ) that seems to be all about semantic data formats (mainly html formats that can be serialised into RDF). There\'s a list of general aims on the wiki, the most general and mission-statementy of which is probably: [GetSemantic will] be a bridge not only between microformats, rdf and the semweb communities, but between users and all three.

My hope is that getSemantic will also become a good place to learn about how to build web sites with semweb tech, discuss best practices, and solve problems; a community that can answer questions like:

I know how to build web apps with PHP&MySQL/Rails/Turbogears/Coldfusion: How do I get started building a web application using RDF? (or:)
I know how to build web apps with PHP&MySQL/Rails/Turbogears/Coldfusion: why should I want to build a web application using RDF?
What\'s the best toolkit/pattern for doing what I want to do?

Or even (and especially) basic things like:

I want to publish some data as RDF, but I\'m not sure how, can someone show me?

eRDF at a glance: a beginners\' introduction

This is intended as an easy demonstration of the basics of eRDF.

eRDF

FOAF Classes:

FOAF properties:
property value:

To Use this Form:

Choose the type of thing you want to describe (eg: Person), and click the button
Move the cursor inside the new div element
Choose the property of the thing you are describing (eg: name), enter a value, and press the button.

This a limited example of eRDF - it is possible to do much more sophisticated things than this allows. Read the eRDF spec for more information.

Now to put the eRDF into an html page so that an eRDF parser can understand it, make sure the head has this attribute: profile=\"http://purl.org/NET/erdf/profile\", and contains links declaring the vocabularies you are using:

Full eRDF HTML Document

Basically what I\'m trying to show here is that to describe something with eRDF, you:

Pick a vocabulary (here we\'re using FOAF).
Give the containing element (which represents the Thing you are describing) an id, and a Class type (note that Class types in eRDF are indicated by prefixing the vocabulary term classname with a hyphen).
Within that element, give the child elements containing describe properties of your thing eRDF style classnames. (Here, choose the property from the list, enter a value, and press the button).

yrdy

yrdyyy

If the government published machine-readable data, we could ....

Tom Steinberg, of MySociety fame, started a google groups mailing list, for discussing action to get our governments to produce better, machine-readable, data, with which civic hackers could do interesting things. In his inaugral post, he pointed to a list of things that could be enabled if only the data was published in a machine-readable format. He went on to say:

In particular, I'd like to hear from the semantic web people what sorts of things can only be delivered to end users through a semantic approach.

(my emphasis)

Interesting question isn't it?

When I first read it, I was a bit stumped actually; I tend to think more about what semantic web technologies can do for me as a developer than what they can do for the end-user. As I mulled it over though, I realised that the main advantage of RDF (interoperability) is one that can be passed from the developer onto the end-user. The developer no-longer has to be the one to definitively provide all the data-sources of an application; s/he can devolve some of that responsibility to the user, give them the choice to bring other data into the mix - much like Tabulator does.

The example I gave on the mailing list was this:

I listen to a programme on the bbc featuring several politicians expressing their views on an issue, and I wonder what the voting history of those politicans has been with regards to that issue.

So I go to the bbc catalogue, copy the URL of the RDF description of that programme, and paste into the (RDF-enabled) TWFY site .

I then select a few options, press a button or two, and get back a report on how the politicans that featured in that programme had voted on legislation surrounding the issue discussed in the programme.

A feature like that (I think) can only be delivered to end users through a semantic web approach, by definition.

Microformats: How Many Is Enough?

You know the scene: XML guru scratches beard and says, Microformats, eh? No namespacing? Won’t scale.

Ah, says a Microformateer, but they aren’t designed to! and scoots off to write an hReview about the new hBIB proposal.

The point of course, is that the Microformats movement aims to develop only a limited number of standards for the most commonly published types of data on the web. They simply won\'t produce too many microformats.

But how many is too many? When will there be just enough that the most common needs are met, and microformat-metadata is still comprehensible, cohesive and maintainable enough for publishers and parsers to use?

People, after all, love microformats. Hyped on the potential for amazing cool things that can be done with a few commonly understood semantics for html, they want more. They have other data besides calendars and address books, and they want to do amazing cool things with that too. They want to mint their own Microformat, and see people do amazing cool things with it.

But how many of these will make it into the official Microformats canon? Precious few it seems. That perfect number of microformats, it seems, may already have been reached (or very nearly): though a few have made it to being specifications, there have been no new approved specifications in the wiki since about July 2005.

So, if it’s not un-microformatishly unpragmatic to think past today\'s problems, what does the future hold for Microformats? Can the canon react to the formats that people publish and the tools that they make, maintain its significance, and prevent the occurrence of too many microformats?

microformats

Processing HTML Form Values to RDF

Generic Form Processing

In an earlier post, I explained briefly how I imagined a generic form processor could work. And this is basically how it works in the code I have written. I did consider having the semantics of the form names derived from eRDF class names (instead of a structured @name on the input element), but decided that it was better to separate input and output at the expense of a bit of repetition (to put a previous value into a form for editing, you have to describe the structure twice: with the @class for appearing in the html, and @name for being saved again.)

I think it is better to separate input and output of forms because you may want to display a value in the form that will be saved with different semantics that it was retrieved with - or indeed, you might not want to save it at all - you may just need the value for processing some other part of the form.

Other Details of the Form Processor

The form processor class is where you write functions/methods for processing and validating your form values. If the function is passed a value that shouldn\'t validate, you can add an error message to the class\'s $errors array. An error will stop the form values from being saved to the datastore. The POST array is available to the form processor class for accessing and modifying, as is the iri to which the data should be saved, and the redirection_url - where the user can be redirected when the form has been saved.

One other important point is that, at the moment, everything under the \'rdf:RDF\' key of the POSTed array is converted to RDF/XML before it is saved (anything outwith that can be used for processing, but not saved), which means that if the input makes the XML invalid, it won\'t parse, and won\'t be saved. So I have had to convert XML special characters to entities on submission, and convert them back again if they are pulled into the template for display. This is a shame because it would be much preferable for the eRDF-T code, and the forms-to-rdf code to be independent of each other. The other solution would be to stick the contents in a cdata section, and only escape any cdata markers in the submitted values. All this because there isn\'t any way to save data through the ARC code without it going through an XML parser at some stage. And although it probably wouldn\'t be that hard to figure out the SQL needed to insert the values directly into the MySQL database in which the ARC store resides, and write some code to take the form array and save it directly, I don\'t have any real practical need to at the moment. Besides which, ARC2 is in the works - so maybe that will provide an easy way to do this.

Anyway, any constructive criticism of this approach to forms would be gratefully accepted.

HAML - a markup abstraction language - and triples notation?

I thought I didn’t like markup abstraction for templating; abstracting away from HTML leaves you with less control of your markup, and source code that looks quite different to what you get when you press View Source, so can be harder to debug – that was my thinking. But HAML has caught my interest (for now at least).

It gives you tersity for the common cases, but the power to make your markup how you like it when you don’t. It also looks quite readable by default because it uses a pythonic system of significant white space.

And it struck me that there are two possibilities in HAML of interest to the RDF-inclined web developer:

A triples notation, with embedded HTML


#me.-foaf-Person
  .foaf-firstName Keith
  .foaf-lastName Alexander

That’s eRDF in HAML, though that just comes out as nested divs, so you’d probably want to use some different tags, and write it as:

 #me.-foaf-Person
  %span.foaf-name
    %span.foaf-firstName Keith
    %span.foaf-lastName Alexander

You can of course use variables as well as literals - anything after an = will be interpreted as ruby.

Automatic RDF-in-HTML

Now, HAML doesn’t do this of course, but I reckon it wouldn’t take too much tweaking to make it do so. Take a look at this example from the HAML docs:


 # file: app/controllers/users_controller.rb
 def show
   @user = CrazyUser.find(15)
 end

 # file: app/views/users/show.haml
 %div[@user] 

 # is compiled to: 
 <div class="crazy_user" id="crazy_user_15"> 
 </div>

Basically, you populate the @user variable with an object, and the templating engine takes the class type and the id of the object to create the html attributes of the div.

What I’m thinking is, similar to the eRDF-T system I’ve blogged about previously, you can have a controller that, on being passed the URL being requested by the user, uses that URL as a resource URI to retrieve data about from the triple store. The controller could then (using ActiveRDF for instance, since we’re using ruby already) create an object with that data – or methods to retrieve it on the fly – and assign it to a @resource variable.

You could then (after tweaking HAML) write templates something like:

 %div[@resource]
  %h1 = @resource.dc::title

Which’d render as:

 
 <div id="article-1" class="-sioc-Post"> 
  <h1 class="dc-title">
		How to make friends and influence people
  </h1>
 </div>

To make dynamic web pages, you basically have to specify 3 things:

The data that you need.
The format of the output document.
Where the dynamic data goes in the output document.

In MVC style web apps, you typically split the first task over two stages: querying the database in the model, anid assigning the data to variables in the controller. The second and third steps are spread over the controller and view: putting data into variables, and embedding the variables in the output format..

By using the approach above, you can specify all three in the one template. This might sound like a bad thing because separation of concerns is, after all, a good thing. But we aren't talking here about a mess of ad hoc SQL queries, tag soup, global variables, and print statements. And I'm not sure that MVC is separating concerns in this case. It seems more like it's dragging out a process across extra stages that could be performed generically by a script exploiting sensible naming conventions (eg:the @resource object has dynamically added methods named after the rdf properties they access), rather than requiring rather predictable configuration by the programmer.

I think this could be an improvement over the eRDF-T approach because you still get semantic markup, you still only have to express those semantics once, but you get more flexibility when it comes to computed values (which are awkward to express as triples), the syntax is terser, and possibly more maintainable, and by decoupling the input semantics from the output semantics, it's easier to apply to non-html formats, and gives the template author more choice.

So does this make markup abstraction worthwhile?

Microformats aren\'t an answer to the Semantic Web.

I often see Microformats described as being the lower-case semantic web, which is a nice sound bite that seems to have given a lot of people the impression that HTML marked up with Microformats is somehow a light-weight, but sufficient (in an 80/20 kind of way) version of the Semantic Web – a semantic web, perhaps, that gets the basics right, but forgoes the formal stuff that no-one really needs anyway.

But it doesn’t get the basics right.

Basics of a Semantic Web

I think the basic requirements for the semantic web include:

Things have URIs

If data is to be any use, we need to know what the data is about; we need it to be uniquely identifiable. On the web, this is done with URIs. URIs also need to identify only one thing – which means you need different URIs for a web page, and for the things the web page is about.

It’s also crucial to the idea of Linked Data on the web that you can follow those URIs to get more information about the resource they identify.

eRDF has the ideal default behaviour with regard to this; every resource you describe with eRDF has a URI with a hash in it, identifying it as a non-information resource, and de-references to a description of the resource that is both human and machine-readable.

Microformats don’t encourage the use of URIs when describing things, and seem to provide, at best, a pretty fuzzy approach to identity which doesn’t distinguish a resource from a web-page, and doesn’t facilitate linked data on the web (rel-uids point away from the resource descriptions they identify).

Semantics are decentralised

The web is decentralised by nature; the semantics of a semantic web need to be decentralised too, not defined in one central place. Centralised doesn’t scale. Centralised semantics aren’t democratic, limit expression, and are (probably) inevitably debased as people abuse those semantics to fit their own purposes.

There is a consistent syntax for structuring all data

If we have a standard shape for data (eg: triples) then we can mix, merge, and manipulate all data using that shape, in the same way, irrespective of its semantics. This is crucial to data being interoperable in the web. Providing a tightly defined atomic structure for data is what allows the semantics to be decentralised and machine-readable, it’s an important part of what allows the semantic web to scale, and for developers to build an infrastructure of tools and software.

Microformats don’t have a consistent model, and in fact seem philosophically opposed to the idea. This makes them hard to parse, and much of the problems experienced by authors of microformatted data occur because of uncertainty as to how different microformats can be related to, and embedded in, each other – precisely because there is no underlying data model.

GRDDL, Microformats, and the Semantic Web

Another related claim that deserves some scrutiny is the idea that people can just write microformats and GRDDL will magically bring them into the Semantic Web.

There are some problems with this:

Microformats have been negligent in providing, and encouraging the use of, profile URIs – and Microformats need profiles for GRDDL to work.
Of the basic requirements outlined above, GRDDL only really helps transform microformats into a consistent syntax. There is still more to do.

Priming Microformats for a semantic web

Asides from declaring GRDDL profiles, I think to make your microformats part of a semantic web, you need to:

Give them URIs

In practice, I think this is best achieved by using @ids on the container elements of hCard, hCal, et cetera, and make sure that the GRDDL transformation uses those @ids to construct the URI.
Tie Down the Semantics

The Microformats specifications give very broad, vague semantics. An hCard might, for instance, be describing a person, organisation, place, or a vCard. So you need to be sure that your GRDDL transformation uses vocabulary terms that reflect either the specific meaning you intend, or the broader semantics of the microformat specification.

If you are using multiple inter-related microformats, make sure that that the GRDDLed rendition relates them in the way you expect them to be related.

The implication of this is that the machine-readable semantics are being defined by your GRDDL transformation rather than the microformat specification(s).

So in other words, Microformats are not, in themselves, building, or contributing to, the semantic web. They can be made to join the semantic web, but this requires extra effort on the part of individual authors – it does not come ‘for free’ with doing microformats.

Roundtripleting

Roundtripleting is the process of dynamically generating documents whereby the dynamic contents are retrieved with queries derived from the document template\'s own semantics.

Or that\'s what I\'m calling it for now anyway :) . The name is supposed to evoke the ideas of Roundtripping, Templating, and Semantics. It\'s a bit of a weird concept, so I\'m inclined to think that it needs a weird label; a purely descriptive term would either be too ambiguous, or too verbose.

Let me know if you can think of something better.

Mine999

Test 9999 test

Good Tagging, Bad Tagging, and the Semantic Web\'s Image problem

A major part of the negative press and misunderstanding surrounding the Semantic Web, the reason people think it won’t work, is that they assume that RDF is something that you publish for other people[1].

The reason that (according to Tim from LibraryThing) Amazon.com’s tagging doesn’t work, is that on Amazon.com, tagging is something you do for other people (to help Amazon’s customers). On LibraryThing, you tag for yourself first, and the network can benefit as a consequence.

RDF is directly useful to data authors because:

It’s a flexible data model. This makes it especially useful for modelling complex, heterogeneous, and changeable data structures. This flexibility is also useful when prototyping, or in the early stages of development, and the domain is not yet completely understood.
It uses shared vocabularies. This means that, where a domain has already been modelled, you don’t need to do as much work. Nor do you have to invest wholesale into an existing schema (as you would with relational databases, or XML). With RDF, you can cherry-pick the terms that suit you from various vocabularies, and fill in any gaps yourself.
It lets you link data. This is useful for merging your data with data from other sources.

So what I would like to see; what I think would cut down on the strawman-slaying; what would encourage greater adoption and development of semantic web technologies, is less of the ‘grand visions’, of the amazing hypothetical end-user experiences of the semantic web, and more tutorials and explanations of how semantic web technologies help developers solve real problems – big and small.

Grand visions are good too of course, but if we web developers are to help build a more semantic web, we need to have our bellies rubbed and our hands held. We need to be shown how RDF (and other semweb technologies) can be a solution to our current problems, not an extra problem to solve for the sake of possible future benefits.

¹ ... in order, apparently, to produce some massive, impossible, globally-consistent body of knowledge for an Artificially Intelligent brain to process, and deliver us better search results.

CDATA in XHTML

I\\\'ve just been looking at options for embedding arbitrary (RDF) literals within an XHTML document, and I wondered what would happen if I put the literal inside a CDATA section:

I tested in Firefox 2, Opera 9, and Safari 3, serving as text/html, and as text/xml. All these three browsers behaved properly (displaying cdata as content, not markup) with text/xml, but only Opera did this with text/html; Firefox displayed nothing, and Safari treated the content within the CDATA section as markup (nasty).

Why use eRDF?

Make your HTML a Data Source.

The idea of using semantic xhtml to let your web page be your API has been around for quite a while now, and there have been various blog posts and presentations on the subject by Tantek Çelik, Drew McLellan, Glen Jones, and MoreThanSeven. While that argument has largely been centred around Microformats supplemented by custom semantic html patterns, eRDF offers you a lot more if you want to make your web page your API.

If you markup your XHTML with eRDF, I immediately have a choice of three formats I can consume it in:

XHTML, which, of course, is XML, so I can use XML tools to get the data out. Even if I only want to consume the data in this format, I’m still glad you used eRDF because the class-names are really semantic; I can look up the meanings of your terms in the vocabularies you linked to in the head; your use of eRDF has also meant that every entity you describe has an @id, and I’ll often find this useful in processing your data.
RDF/XML. This is XML too, but with all the non-data stuff taken out, and the semantics are expressed (largely) in the element names rather than the attribute values. And as well as using it as XML with XML tools and libraries, I can use it as RDF, with RDF tools and libraries, and mash it up with other RDF data.
PHP I can use the ARC eRDF parser in PHP to parse eRDF into native PHP arrays, without any XSLTing. Of course, I could also use any language with XSLT and an RDF/XML parser.

Really Semantic class-names.

eRDF class-names are really semantic. Not only do they describe the contents of the element, but the term with which they describe can be looked up. If you really want to, you can look at the source code, look up the vocabularies cited, and see exactly what each term means.

This has a number of benefits for making your markup both more interoperable, and more maintainable.

Consistency for CSS

By re-using existing vocabularies, such as foaf, sioc, and dc, your class-names are more likely to be consistent within and between projects, making your CSS more maintainable and re-usable, than if you used ad hoc class-names of your own devising (a 2005 survey of semantic html attribute use found very little consistency in class and id values).

Platform for Javascript widgetry and wizardry

Javascript too can benefit from consistent class-names – not only does it make it easier to maintain, but it opens up possibilities for a common platform for javascript widgets and snippets that do things with specific kinds of information.

Some possibilities, like DHTML calendar and map widgets reading events and co-ordinates embedded in the same page, and turning them into an interactive presentation, are possible using microformats for the necessary semantic hooks, but the possibilities are more limited, not only in what things you can describe, but in how you relate them.

The idea here is that if you make your html really semantic, you can get widgets ‘for free’; they can simply plug in to your page and add functionality, without you needing to make special changes to your mark-up. To be honest, this is currently more potentiality than actuality, though as a sort of example, I have created a page that takes its data marked up in eRDF, and creates a SIMILE Exhibit from it.

Where the Web of Documents and the Web of Data meet

I think the concept of RDF-in-HTML, stitching the web of data tightly together with the web of documents, offers a number of interesting possibilities for user-interface design, especially the idea of Web Clipboards – where you can copy and paste, not just text, but information with semantics still intact after pasting.

Another possibility – and one which could be nicely combined with Web Clipboards – is using javascript (AJAX) to follow links to eRDF pages, parse them (probably on the server-side for the sake of speed and cross-domain capability), and feed the data back into the current page. I’ve put together a small example in the style of those link previews you get now in wordpress, only for data.

LazyWeb Request :: GRDDL / Scraper Repository

PiggyBank (if you’ve not come across it) is a firefox extension that (coupled with Solvent) lets you write/reuse screenscrapers that match up to url regular expression patterns to transform HTML pages into RDF that you can then import into Piggybank (which is an RDF database that lives within the browser). You can share scrapers via the Simile Wiki.

This is pretty great, but is limited to the client-side. What I want is a web service with a rest API to a repository of screen scrapers, using the same url pattern matching system. There would need to be some way of letting you specify or work out which scraper(s) you want to use in cases where more than one scraper matches the url. Perhaps that part could be partly based on a FOAF trust system ?

test5

Test 5 -- test 5

test

Musings on my ideal syntax for RDF-in-HTML

Looking again at the bnode comparison of µf, eRDF and RDFa I’ve been thinking about the relative advantages and disadvantages of eRDF and RDFa a bit. The great thing about GRDDL of course, is that if I come up with a syntax of my own that I prefer, I can just write a stylesheet and get on with it. I don’t need to evangelise it, or even document it.

Whether or not it’s worth the extra effort (over using an established syntax like eRDF or RDFa) is another matter of course ;).

I think my dream syntax would mainly be quite similar to eRDF, but enabling a few of the things that RDFa does.

What I like about eRDF

The main thing I like about eRDF is that all visible text and images are described with class-names. The class names, moreover, don’t contain any characters that need to be escaped in CSS. This is actually an extremely clever feature of eRDF. It encourages good separation of style and content; you can start with your content, mark it up with html and eRDF, and then when you come to style it, you have a lot of hooks to style something according to what it is.

I just read a post to public-rdf-in-xhtml-tf by someone concerned about @class being used for semantics instead of presentation. I've seen this argument play out in a few places, and I'd just like to add, not only is @class for semantics in the html spec, not only is it good practice for maintainability and so on, it's good practise for design.

A principle of good design is creating visual similarities between similar types of information; so it's a good idea to style, say, e-mail addresses the same way, and if you can use .foaf-mbox as your style hook, then so much easier for you. When I write CSS, semantic class-names make it easy for me to style elements by the type of information they contain, which helps the user visually identify them, and helps make the design consistent and clean. eRDF class names are even better because they come from shared vocabularies, which are easier to remember, understand, and re-use across projects than the ad hoc conventions I'd use otherwise.

What I like about RDFa

The main things I like about RDFa are:

You can declare namespaces at any stage in the document (if you’re blogging or something, you don’t need to edit the template whenever you want to use a new vocabulary).
You can describe resources external to the document (eRDF’s support for this is limited).
You can choose to have HTML and XML content in your object literals (eRDF only takes the text content).

A mix of eRDF and RDFa ?

So what I want is a syntax that:

uses class-names to describe all visible text and images
is element agnostic – (perhaps making the technique useful beyond pure (x)HTML). I feel that the semantics of html elements, and the semantics of RDF triples are qualitatively different, and I'd rather keep them separate. (In a little more detail, if an eRDF-style classname exists on an element, the object is, in order of preference: the @src, or @value, or child element(s) with @selected or @checked, or @id, or @title, or inner contents of the element).
gives me control over exactly which triples are generated (I don’t really like eRDF’s generation of rdfs:label triples from anchors)
lets me declare vocabularies anywhere in the document – not sure how to do this: XML namespacing feels a little wrong if you’re not using the colon separator. Also, as Ian Davis said about creating eRDF:
I wanted to be mindful that I wasn’t inserting URIs into class attributes but that I was mapping values from class attributes to URIs. Sort of a subtle point. The point is that I’m not trying to change or extend HTML, but add hints about how it can be interpreted as RDF.
Ian Davis, Re: RDFa reliance on namespace declaration, Fri, 16 Jun 2006 04:23:08 -0700
An alternative is to allow schema declarations in anchor tags as well as link elements. This is semantically right, but structurally feels a bit messy.
lets me choose to have HTML/XML content, or strip the tags. Not sure about the best syntax for that – maybe an extension to the class-name syntax, eg: sioc-contents-XML when you want all the tags in the output preserved.
lets me describe external resources, at least a bit. I don’t want to have to use non-HTML attributes like @about if I don’t want to. I think if descendant elements of an hrefed element have an eRDF-style class-name, the subject would be the @href, rather than the nearest IDed ancestor of the anchor. This is limited (unless you want to make massive portions of your document links), but would allow more semantic annotation of hyper links. Perhaps you could use @about, or owl-sameAs for larger portions of description.
ideally the html would validate. It’s not the worst thing in the world if it doesn’t in every situation (I would maybe sacrifice validation for the occasional @about), but it would be nice.

What would your ideal RDF-in-HTML syntax be like?

Some thoughts on Ontologies

Lately, partly because of what Graham Higgins and I have been doing on the RDF mapping of the TWFY data, I’ve been thinking about some considerations when writing ontologies, so I thought I’d write them down here so I can be corrected where I’m wrong.

Labels

Readable Labels

It’s quite important to make sure that the rdfs:labels are nice and human-readable. If you are writing an RDF-based application, since RDF is self-describing, you shouldn’t need to hard-code labels for values, you should be able to use the rdfs:label of the term that describes your data. Think how well the rdfs:label would read in a table header, or the label of a form widget.

Plural Labels

Morten Frederkisen has a charmingly compact vocabulary to help with labels, which can be used to define the singular and/or plural version of your term’s label.

Inverse Labels

One problem I’ve found with labels is when you want to display a link back to the ‘parent’ of the current resource, how do you explain to the user what the relationship of the current resource is back to its parent?

Easy, you create an inverse property, and do something like this:


DESCRIBE  ?inverse ?parent
WHERE {
?parent ?property <#current> .
?inverse owl:inverseOf ?property .
?inverse rdfs:label ?inverseLabel
}

But then you are authoring some more data, and are tempted to use your inverse term, and all of a sudden, it’s a little more complicated to query your data because you have to look for both the backwards and the forwards version of any particular property you are interested in. Worse, you might stand accused of creating an Anti-Pattern, and find that Tim Berners-Lee has already said it was unnecessary to define both backwards and forwards links.

The only loss in not having both, he says, is that there is no label for the reverse link.

Which is precisely what we want the inverse property for. timbl mentions that he has got round this by declaring an unnamed inverse predicate, and giving it a label.

A simpler version is suggested a couple of times in the comments (by shibl and Alexander Pohoyda) – just give the predicate a ‘reverseLabel’ property

Obvious Labels and the Marketing of Knowledge Description

A consideration that ontologies with ambitions for wider adoption need to take into account is how to market their terms at data authors shopping for definitions. I write an ontology that perfectly suits your needs, but you don’t realise that because I haven’t described the terms in such a way that you easily recognise their connection with your domain.

This might be especially likely if my ontology is a very general one, and you are looking to describe a particular subset of that domain. Someone might go looking for an ontology to describe the components of their blog. Now, arguably the best ontology for this (insofar as interoperability goes) would be SIOC (I’m currently using it for this blog). They have a nice shiny website, documentation, tools, a mailing list and an irc channel. But if our definition-shopper searches for blog in Swoogle or schemaweb, or even ‘blog ontology’ in Google, SIOC doesn’t feature at all.

Even if they browse through the ontology itself, they still might not grasp its utility for their purposes, since they are skimming for words like “Blog” and “Blog Roll”, and may fail to immediately see the relevance of more abstract terms like “Forum” and “Container” (SIOC has more specific terms as well; they are kept in a separate types module ).

Human Readable Semantics vs. Machine Readable Semantics

Another potential hazard of Ontologies, both for those writing them, and those using them, is that there can be disparity between the human-readable semantics (in the labels and comments), and the machine-readable semantics (how the terms relate to other terms). foaf:name for instance, is most commonly understood and used to describe the name of a person or organisation, actually has much broader machine-readable semantics – and can belong to any resource that has the rdf:type owl:Thing.

With foaf:Person, the human-readable semantics say that it doesn’t matter whether they’re alive, dead, real, or imaginary, yet the machine readable semantics say that a person is a spatial thing. So is Gandalf from Lord of the Rings a SpatialThing with a ‘spatial extent’ ? Arguably he does, but his spatial extent is imaginary too. (Maybe it’s just the nature of the semweb/kr game for things to be curiously metaphysical).

It’s quite possible that this doesn’t appear so contradictory to the authors of the spec (since this is human interpretation of natural language, there is bound to be some variation in understanding), but the larger point I’d draw from this, is that while shared vocabularies and open linked data are marvellous and everything, there is a cost.

If you’d like to use a particular term, you have to make sure it means what you want to say first, and chase down the machine readable and human readable semantics of both that term, and the terms it relates to. Otherwise you diminish the value of your data, and any dataset that uses it. And if you are writing an ontology, you can help the term shoppers by trying to ensure that your human-readable semantics reflect the machine-readable semantics transparently and unambiguously.

eRDF as Query and Report language

I was doing some Smarty templating, marking up the html with eRDF so that I could easily pull the data into the database as triples later. And then I thought about having to write SPARQL queries afterwards, and populate and assign variables, and embed those variables in the template.

It struck me that there would be a great duplication of effort here - I would specify some variables and triples in the SPARQL query to define the data I would get back, and then I’d be specifying triples with variables - the same triples - again in the eRDF HTML.

How can you cut out the repetition? Is it possible that the eRDF template can already contain all the information you need to query the datastore, and fill the template with the results? I hacked up a quick proof of concept to find out:


<p id="me"> My name is <span class="foaf-name">?name</span> </p>

can generate:


<#me> foaf:name ?name

from which you can derive the SPARQL:


SELECT ?name
WHERE
{
    <#me> foaf:name ?name
}

from which you can get the result:


 __________________
|   name          |
-------------------
| Keith Alexander |

Push the value into the right place in the template (where the name of the variable is the name of the result column), and you get: <p id="me"> My name is <span class="foaf-name">Keith Alexander</span> </p>

So far so good.

But what about multiple results? It seemed to me that if I wanted (as you generally do), to have a page with both one-to-one relations (eg: for a CD description - price, artist, record company, release date), and one-to-many relations (eg: the tracks on the album), you ought to do more than one query: one for the top-level single relations, and one for each list. I figured that I could use a pseudo ‘list item’ property (as well as rdf:li), on which an algorithm could determine that all things relating to that list item would feature in a multi-row result set, and should be moved to a different query. And I spent a while this afternoon scratching my head trying to hit upon a decent way to do that, until danja and shellac in the #swig irc channel pointed out that the single relations could ignore the extra rows. So that made it easier, at least for now. I put together a template using a Smarty foreach loop, with some code that fills the appropriate variables with either an array or a single value depending on a variable naming convention, makes a few changes to the template ready to be passed to Smarty, which does the rest. I even put in support for OPTIONAL clauses

How far can you go with this though?

Even so far, this system could actually be pretty powerful - coupled with a regular templating engine, you can process and format the variables in the template before the page is served.

I think it will be necessary to break it up into multiple queries, in order to allow things like nested loops, and a COUNT or AVG feature syntax (that's one of the nice things about using Arc's mysql based store - if SPARQL isn't powerful enough yet, you can get the SQL underlying it instead - and since we are writing eRDF rather than SPARQL, it doesn't really matter how we get the results). On the SPARQL side, it wouldn't be too hard to implement a FILTER - perhaps a variable naming convention like $foo_filter_regex_BAR where BAR is a constant defined in a file for such things. Or perhaps a pseudo-property, like sparql-filter:

	<p id="{$person_id}">
		<span class="foaf-name">{$name}</span>
		<br class="sparql-filter" title="FILTER regex(str($name), 'John')"/>
	</p>

(the eRDF template processor would know how to translate that into a query).

What about Forms?

A similar approach could be used for dealing with forms. By using input names that return associative arrays, you can easily generate arbitrary RDF/XML from the post data, eg:


	<form action="erdft_submit" method="post" accept-charset="utf-8">
		<label for="name">Name: <input type="text" name="rdf:RDF[foaf:Person][foaf:name]"/></label>
		<label for="name">Email: <input type="text" name="rdf:RDF[foaf:Person][foaf:mbox]"/></label>
		<input type="submit" value="Submit">
	</form>

Can generate:

	
	<rdf:RDF xmlns:foaf="http://xmlns.com/foaf/0.1/#">
		<foaf:Person>
			<foaf:name>John Smith</foaf:name>
			<foaf:mbox>john@example.com</foaf:mbox>
		</foaf:Person>
	</rdf:RDF>

- and that can then be saved to your data store.

For validation and processing, the form page would be parsed by the controller, so it knew what inputs to expect, and it would also pull class names from the form input/select/textarea/button elements that would tell the controller what function to run the value of that widget through. The naming could follow a convention like f_valid_email, and the controller would choose the valid_email() function stored in a separate file. Personally, I think this might be preferable to defining models with validation criteria for each property (as CakePHP does, for example), as this can get ugly if you want different validation criteria for different circumstances.

Is it worth it?

Ultimately I suppose, you can invent workarounds and fixes and things for just about anything if you want.
But should you?
Would this be a good method of web development?

Advantages

Follows the DRY principle.
By simply putting eRDF into your template, you get the query and variable setting for free, and your output is then also easily reinterpreted as RDF.
Less Mental Overhead: instead of thinking, how do I get my data from the store? where do I put it on the page? and possibly how do I mark it up semantically? , you just put the variables in the page where you want them to go, and describe them semantically with eRDF.
You get to do all or most of the work in your HTML files, instead of spread across Models, Views and Controllers. I personally think this seems preferable to an alternative approach, whereby HTML would be generated programmatically - I want control over my HTML.
Where the eRDF template approach is insufficient, it is still possible to tweak the query by hand in the 'controller' code.

Disadvantages

It violates the 'Separation of Concerns' principle of programming. This isn't necessarily a disadvantage because separation of concerns is mainly to avoid repetition and ease maintenance.
It is more processor-intensive, so you would probably want to cache pages and queries for better performance.
It shares the limitations of eRDF: of course you could take the same approach with RDFa, or some other form (Benjamin Nowack's M4SH wiki-syntax?), which might prove more expressive (I chose eRDF because the Arc classes already provided an eRDF parser; I like being able to use the properties and classes as css hooks).
In the ordinary run of things, you likely weren't fussy about expressing the precise semantics of your content in html - in which case, learning to do it in eRDF will incur a bit of mental overhead.

Try it out

If you want, you can have a go with the code I've written so far. It's still pretty basic alpha stuff, but if you want to look it over, I'd be delighted to hear comments, suggestions and improvements. For that code, you'll need Smarty and the ARC PHP RDF classes. If you don't want to use Smarty, you can rewrite the regular expressions that define the syntax for the sparql variables (these can be passed as arguments to the class) to use native php syntax instead - just make the first match be a valid sparql variable.

You'll also need an Arc mysql triplestore set up, with data in it, if the code is to do anything. Again, you pass the path to your datastore config file as a parameter to the eRDFT class (see erdft-smarty.phps).

Limitations

Currently, it only generates one big query, which gets you one big data table as a result. Also, properties can't be variables - only subjects and objects. I couldn't think of a way that you could express properties in eRDF so that they would be visible to the user anyway. Still, it would be nice to have variable/unknown properties. Perhaps a syntax like 'erdft-?foo'.

Future Ideas for eRDF-to-SPARQL-and-back-again

I'll probably knock up a Resource class so it can be used with the Tonic PHP REST library/framework, and do the nice automagic form processing things I described above. Then I guess I'll see if I can actually use it for more than "hello world" stuff.

Patterns Designed for the Web

Bill de hÓra recently blogged about how frameworks designed to work with the web are more effective than those designed to work around it. While I agree with that general sentiment, what I noticed was that all the frameworks mentioned called themselves MVC.

As Phil Jones observes, MVC was designed for developing desktop software in the Smalltalk environment It wasn’t designed for the web.

MVC was designed for dynamically manipulating interfaces in a state-ful local environment, not serving (and retrieving) documents in a stateless distributed environment.

That doesn’t mean that it’s necessarily terrible – those who develop MVC web frameworks do manage to hack around the inconsistencies and come up with software that is popularly acclaimed, and effective; but I suspect that that is rather in spite of, than because of, the MVC pattern.

MVC is popular, I think, because we like to have patterns to follow, so we can have a system for structuring code. It makes it easier to plan, separate responsibilities, maintain code, and add features if we know where everything is supposed to go. Unfortunately, on the web, the meaning of MVC becomes stretched, and it’s by no means clear any more where everything should go.

Personally, I’ve found MVC frameworks particularly unhelpful for much more than the relational database CRUD operations they are optimised for – it’s often not clear where the other stuff ought to fit in the stack. RDF, for instance, does not fit comfortably into the MVC stack because, being self-describing, and of consistent structure, it does not need application-specific model classes to carry its semantics from the database into the code. In fact, those model classes would only get in the way of the benefits of RDF’s flexibility

Worse than uncertainty, is the risk that using the wrong pattern leads you to spread out over several components what is more logically contained in one, or adding unnecessary layers of abstraction, making the code harder to write, understand and maintain.

So my guess is that using Semantic Web technologies for the M in MVC is not the most productive route forward. But what is? Jones suggests three alternative emerging patterns:

Data and Template
REST
Pipes and Filters

However, much as I like those concepts, they don’t, I think, really offer a sufficient alternative to MVC as a pattern for structuring code. What is needed from a pattern (if patterns are needed at all), is a broad structure for separating out code into components, that follows what developers actually need to do to create a (designed for the) web application, with a minimum of redundancy, complexity, and abstraction.

What would an application development pattern ‘designed for the web’ look like ?

Keith Alexander's SemWebDev Blog SemWebDev Posts RSS Feed

Abductive reasoning, template generation, and RDF-in-HTML

POSH: Plain Old Semantic HTML

Notes

TheyWorkForYou.com - Low hanging fruit for the Semantic Web?

Schema-cache: a store of RDF vocabularies

RDFa(dict) : An RDFa parser in Python

eRDF-T with Tonic and Smarty

1. Configuration

Configure Tonic

Configure ARC

2. Write a template for all the pages to use

3. Write the admin Section

Admin Blog Posts

{$blog.title}

Comments

4. Write the frontend

Blog Posts

{$title}

5. Finished

Things I\'d like to develop further

eRDF-T and Nested Arrays

Semantic Blogging

Magic

Writing inline semantic content

How to write about stuff semantically

Future Plans

New Backend

Semantic Link Previews

hGRDDL

Better Admin/Editor

Is Semantic Blogging Viable?

Suggestions to Authors of RDF Vocabularies

Use Absolute URIs

rdfs:isDefinedBy

vann

Labels!

A New Mailing List for RDF schema development!

HTML5 and the future of @profile

MyPost2

RDF article @ Digital Web

Exhibit your RDF databases!

What's the point? It's easy to write SPARQL queries.

Safer than SPARQL, easier and more open than an API

PHP RESTful Frameworks

PHP RESTful Frameworks

Konstrukt

Key Aspects

Design Goals

Tonic A RESTful Web App Development Framework

Main features

dbscript

Why RDF Ought to make Web Apps easier to build

RDF is the Web

RDF Represents All Data In the Same Way (Triples!)

RDF data is its own metadata

RDF is flexible

MyPost1

getSemantic.com

eRDF at a glance: a beginners\' introduction

eRDF

Full eRDF HTML Document

yrdy

If the government published machine-readable data, we could ....

Microformats: How Many Is Enough?

Processing HTML Form Values to RDF

Generic Form Processing

Other Details of the Form Processor

HAML - a markup abstraction language - and triples notation?

A triples notation, with embedded HTML

Automatic RDF-in-HTML

Microformats aren\'t an answer to the Semantic Web.

Basics of a Semantic Web

Things have URIs

Semantics are decentralised

There is a consistent syntax for structuring all data

GRDDL, Microformats, and the Semantic Web

Priming Microformats for a semantic web

Give them URIs

Tie Down the Semantics