Facebook's adoption of RDFa as a way to provide extra features to its users has met with an ecstatic welcome by some, and suspicion and criticism by others. Here we discuss whether some in the semantic web community may be being too hard on their efforts.

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.

I did a couple of talks at SemTech 2009 this year, one of which was a panel discussion called A Shift in SEO. This is a summary of the main points.

Two exciting pieces of RDFa news arrived within ten minutes of each other in my Twitter client. Both concerned governments making data open -- one in the US, and the other in the UK.

I was recently lucky enough to take my first trip to Australia, where I was doing a couple of talks on RDFa.

Next week Mark Birbeck is in Australia, doing a number of talks on RDFa

Mark Birbeck's Tech Talk at Google, on RDFa, is now online

We're pleased to be launching two new initiatives to help people who are interested in XForms.

The first is the all new XForms Developer Zone web-site -- or xformsdz, as we're calling it.

Whilst the Developer Zone will be unashamedly biased towards XForms, within that, we'll have discussions, articles, code snippets, and tutorials about any XForms processor we can find, and any application framework in which it's used.

To accompany the web-site, we're also launching a regular newsletter, and a London XForms User Group.

Co-ordinating code reviews, commits and issues.

About a month ago Google added license filtering to Image Search, and provided a video tutorial on how to add licensing information using RDFa.

I was lucky enough to be interviewed about RDFa yesterday, by Paul Miller for his weekly podcast.

Welcome to the RDFa Handbook.

Over the coming weeks we'll be continuing on from the two introductory articles which first appeared on A List Apart in June and July, 2009.

The articles are Introduction to RDFa and Introduction to RDFa II, and it's worth reading them before continuing with the articles here.

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 last week has been great for the profile of RDFa, and this post is a mixture of my own experiences and some broader news during that time.

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.

Just over a year ago I wrote a blog post that showed how to create a FOAF profile on a web page, using RDFa. The idea was not only to show how easy it was to do in terms of the markup, but also to illustrate that once you are able to publish RDF via a web page, you need nothing more than a blog page to join the semantic web.

This blog post updates that old post, by first adding some guidance on how to check your document (using the Ubiquity RDFa parser), and then proceeding to add more features to your blog page.

One of our customers recently asked:

"I have a question on how we can open an XForms page from a non-XForms page. We are trying to have a summary page which is a non-XForm page and we would like to try to open an already existing XForms page by populating data on to it dynamically, by clicking on a component in the summary page. More like a summary-to-detail functionality....

We are trying to find the best way to do this."

It's an interesting question, and although we have worked out a couple of ways of looking at this on the client side, I thought the best answer for now was to user the server.

In a recent code review on the Ubiquity XForms project, the question of whether to test for an element by name or properties came up. In this post we look at the benefits that can be had from using duck-typing as a way to manage objects' functionality, rather than the more usual hierarchical solutions.

This presentation by Mark Birbeck was part of XML-in-Practice 2008, organised by the IDEAlliance, and showed developers how to use XForms in their Ajax applications.

In this post I look at how RDFa and other techniques to add extra information to documents evolved around the same time as Microformats, as part of the work at the W3C on the next generation of web languages. Whilst the traditional approach taken to language design at the W3C -- and now used in HTML5 -- seeks to anticipate authors' every needs, the RDFa approach resulted from a focus on clearly defined extension points that give authors control.

Like everyone involved in RDFa, I love seeing people use it to express information about themselves, using vCards, FOAF relationships, event information and so on. This type of information is often the first to get processed by new semantic technologies such as RDFa.

But to be honest, this is simple stuff. The real meat of RDFa is to be able to express much more complex collections of information, using nothing more than the tools of web-publishing.

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.