A number of discussions are taking place in the new W3C RDFa Working Group about how to enable authors to use tokens in place of URIs. How do we avoid conflicts if anyone can define their own tokens? This post looks at how this might be achieved.

Since URIs are often conveyed as strings it's tempting to manipulate them as such, but it's better--and safer--to delegate URI manipulation to special functions. These can then have their own unit-tests, which will take into account the edge-cases that can catch us out.

In the light of the Google announcement that they will be processing RDFa, we look at the implications for data publishing -- and in particular, the key question of who owns your data?

This particular thought piece is aimed at people who are familiar with aspects of the semantic web.

You don't need to be an expert to understand the article, and you might find it interesting, even if you know next to nothing about the semantic web.

But I'm putting this little disclaimer right at the top here, so that no-one can say, "there you go...I told you the semantic web was difficult to understand, and Birbeck's latest blog-post just proves it".

One of the features of our RDFa parser (Ubiquity RDFa) is the ability to import RDFa from external documents. This is particularly useful for bringing in definitions for templates and other processing rules that you would like to have applied to the document being parsed, or for importing one definition into another (owl:imports is implemented this way).

The technique used to garner these triples is simply to import the external document into a hidden iframe, and then run the parser on it. However, as the JavaScript programmers amongst you will know, that only gets you so far; if the document containing the RDFa you want to import comes from a different domain to the one that your source document originates from, most browsers won't give you access to the DOM in the iframe.

There are all sorts of ways to try to work around this, and a common one is to use a server to convert the RDFa to JSON, since script tags aren't victims of the cross-domain limitation. We therefore decided to create a JSON format that was as close as possible to RDFa. Of course, since RDFa itself is a serialisation of RDF, then really we were actually looking to create a JSON format for RDF.

When sending small comments via services such as Twitter, it's pretty straightforward to add links to other documents. The general pattern is to abbreviate the link using an online service, and then paste the shortened link into your post. Software that displays your posts can then replace any string that begins with http: with a real link.

However, there are many occasions where a link is just not good enough. Sometimes you'd like to embed an image, or even a video. But if we start trying to add HTML mark-up, we'll pretty soon hit the character limit imposed by micro-blogging platforms.

Enter compact HTML, or CHTML...for short.

Determining the behaviour of an application at run-time using parameters is a well-established practice. But whilst it's possible with command-line and server-side applications, the scope for passing information to client-side internet applications is limited. With the growth in internet-facing desktop applications, widgets and gadgets, there is a need to pass parameters directly to the application, rather than via a server, and this post looks at how that might be achieved.

The BBC caused a storm recently by announcing that they won't be using the hCalendar Microformat on their pages, due to accessibility problems. One of the proposed solutions is to take a look at RDFa.

(This article originally appeared in February 2008 on my blog XForms and Internet Applications. )

One of the main goals of RDFa (syntax and primer), and its precursors, is to provide richer semantic information for search engines. In one of my early drafts I gave the example of a news story that referred to the British Prime Minister:

Such an article would be easily understood on the day of its publication, and even years later, someone reading this would probably know who the Prime Minister in question was, and possibly even be able to decipher 'yesterday'.

But what about trying to find this article? If I search in Google for articles about Prime Ministers I'll retrieve articles about the Australian and Malaysian PMs, both of whom are in the news this week, as well as links to the 10 Downing Street web -- site, stories about Gordon Brown, and so on. And if I search for "Winston Churchill" the article we're using as an example won't appear, since his name does not occur in the text.

Whilst delving into the 'information resource' debate I found the opposite of what I was expecting--that the distinction between information resources and ordinary resources, is not only useful but necessary.