And finally, I find this announcement exciting because the guidelines document uses the term 'Linked Data' throughout. This reflects an extremely deep understanding of the implications of what COI are doing with RDFa; the COI do not simply explain to people how to publish vacancies and consultations to the web -- they are describing how to publish that data to the Linked Data cloud.
A key component of any XForms processor is the dependency-engine. The idea is pretty straightforward, and will be familiar to anyone who has used a spreadsheet; if some item has its value set by a calculated expression that contains references to other items, then when any of those items change, the first item must be recalculated.
Although my talk Beyond Web 2.0 -- How RDFa Can Help to Democratise Data on the Web, took place back in June, it's only just now been made available online, due to technical problems.
(I should say too, that those same technical problems also mean that the video is in 50's style black and white; maybe it gives it a bit more authority.)
I really enjoyed the session, and you'll hear at one point near the end I get to put some questions to Othar Hansson and Kavi Goel, and the rest of the Rich Snippets team, about how they'll be using RDFa going forwards.
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.
To summarise the argument; first, we know that we need to be able to tokenise URIs, because they tend to be long and unwieldy. However, whilst the current use of prefixes to abbreviate URIs is useful, it only allows us to tokenise URIs that are used to identify vocabularies, and not full URIs. It's also not ideal that these prefixes are being expressed using a document architecture mechanism --
By adding a new attribute --
@token-- to the CURIE processing rules, we can tokenise full URIs, which gives authors the same level of simplicity that Microformats has. The key difference though, is that this tokenisation is completely scaleable, and so overcomes one of the major drawbacks of Microformats.
With my semweb consultantancy hat on, I've been working for a few months now on a number of RDFa projects with the UK's Central Office of Information. These projects have generally followed the same pattern:
A couple of days ago the UK Civil Service web-site was updated with a new look, and some exciting new features, some of which stem from the projects I've been involved in. There is still some more testing to do, so there haven't been any firm announcements yet, but I'm allowed to talk about one particular feature that is very exciting, the presence of RDFa in each of the job vacancies.
- define a vocabulary for some specific area of interest, such as job vacancies or government consultations;
- use that vocabulary in HTML pages, via RDFa;
- get my colleagues at webBackplane to build a prototype application using Drupal and ARC2, that both publishes and consumes pages in the right format;
- add an application to Yahoo!'s SearchMonkey to process the RDFa pages.
"Essentially, what we've done with RDFj is to map JSON to RDF -- with a few extra tweaks thrown in -- rather than simply mapping RDF to JSON. (RDFa took the same approach, starting with HTML, and then working out what RDF various patterns might represent.)
2009-04-18T14:48:42.679+00:00Just 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.
2009-03-20T09:58:31.179+00:00One 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."
2009-02-03T12:44:36.828+00:00In 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.
2008-11-07T14:46:26.702+00:00This post also appears on Mark Birbeck's webBackplane blog.
http:with a real link.
(image)Which would give you this:
img=http://snurl.com/252rjThat's a pretty efficient way to transmit an image in a post.
img(src=http://snurl.com/252rj)We could also write:
img(src=http://snurl.com/252rj,alt=A picture of Stooky Bill)
imgit would obviously be
img=http://snurl.com/252rjis equivalent to:
token=valuethen we needn't limit ourselves to HTML in our compact mark-up.
The BBC have caused a bit of a storm recently by announcing that they won't be using the hCalendar Microformat on their pages. The reason is the well-known problems with accessibility. One of the proposed solutions is to look at RDFa.
2008-06-21T14:25:55.369+00:00Yesterday I had a lot of fun at the Media Futures 2008 conference at Alexandra Palace. The panel I was on was called Openness and Innovation, and included Robert Cailliau, Ian Forrester, Matt Webb and myself. The chair was Bill Thompson.
2008-05-17T19:16:53.141+00:00Something which was part of the early design concepts from the XHTML Role Attribute Module, which has got a little lost, is that elements from any language can provide a handy source of role values too.
@rolewill need to be invented. This might be because they simply don't exist, or because we want the values to be 'cross-cutting', and apply to many different mark-up languages.
hintelement, that can apply to its form controls:The semantics of 'XForms hint' and pretty well defined, so it should be straightforward to apply them to other situations. For example, an Ajax library could pick up a hint and do something with it in an (X)HTML document, even without XForms:
Please enter your name
h2, etc., values then we don't need to invent new roles:
As you can see, a role-aware voice system would be able to provide feedback to a user in any mark-up language, simply by knowing XHTML role values.
Metadata is data about data...which is also data...kind of
turtles all the way down...
2008-05-01T13:50:59.067+00:00May is going to be pretty busy with talks about XForms, RDF and RDFa coming up.
2008-03-21T16:20:08.847+00:00Yes, I know...everyone seems to think that RDFa and Microformats are at war. And maybe some would prefer it to be that way. But whatever way you look at it, the work of the Microformats community has been key in getting people fired up about what they might do with metadata that is placed in HTML and XHTML pages. And RDFa is benefiting from the vibrant atmosphere which they have created.That doesn't mean I'm saying we can ignore the problems and limitations that Microformats have, such as the difficulty in mixing different formats in one document, the work involved in creating new formats (often wastefully duplicating work that has already been done, since specialist formats invariably already exist), or perhaps most significantly, the inability to refer to things that are not 'the current document'.So I have a suggestion.Why don't we emphasise the 'micro' in Microformats?Emphasise the 'micro'One of the original motivations for Microformats was that they were small, self-contained sets of rules that authors could apply to their documents, which would give the author some kind of benefit. Nothing in that broad definition says 'so therefore steer clear of all other formats or you'll catch the plague'.So why not use RDFa features within microformats, as appropriate? But Microformats could still retain the compactness of a particular format.I'll use rel-license as an example.rel-licenseThe rel-license microformat is simply the use of the value "license" in the @rel attribute, in some mark-up. For example, if we want to say that the current document is licensed under one of the Creative Commons licenses, we might use the following mark-up in our document:cc by 2.0However, what if we have a search page that returns lots of images or videos? What if each image or video is available under a different license to other images or videos on the page, or to the license for the page itself? Trying to solve this problem within the framework set by Microformats is proving quite difficult (see the open issues on the rel-license issues page), so at some point we need something more than rel-license.Reusing @src attributeThe mark-up we gave earlier to indicate that 'this document' is available under a certain license, amounts to two attributes, @rel and href:cc by 2.0RDFa lets us take that little 'package' (or 'microformat') and use it anywhere that we can set a 'subject'. Of course normally the subject is the current document, which is why the rel-license microformat looks just the same to an RDFa parser as it does to a Microformats parser. But RDFa allows this 'package' to be used with the @src attribute, giving us the following possibilities:(image) (object) As you can see, this straightforwardly solves the problem that rel-license is presenting to those who want to put many items in a page, so all that would be required to take this solution into the Microformats world would be to slightly extend the rel-license microformat to allow the src attribute as a subject.RDFa or Microformats?This example illustrates that if we see RDFa and Microformats as playing slightly different roles, then there is no need to take an 'either/or' approach to the two techniques.Since RDFa is a general-purpose syntax that is capable of supporting any vocabulary that anyone comes up with, now or in t[...]
2009-05-14T10:20:17.809+00:00Please note that this article has been updated to Getting started with RDFa: Creating a basic FOAF profile.Now that the RDFa syntax document is in last call, and people like Yahoo! are starting to index the data, it's worth putting more of your own data into your web-pages, using RDFa. A simple place to start is to modify your home-page or blog profile so that it includes FOAF information.FOAFIf you're not familiar with FOAF, or Friend-of-a-friend, it's a set of terms that can be used to describe people, organisations, and their relationships to each other. For example, we can mark up our names, point to our home-pages, indicate the companies and projects we work on (and point to their home-pages), and so on.Since this vocabulary is gaining in popularity, and since RDFa allows us to use any vocabulary we like without having to re-write it (or ask anyone), we'll use FOAF via RDFa to mark up our pages. We won't use every part the vocabulary, so if you want to find further properties, or more detail on the properties used below, look at the full FOAF specification.Creating a personThe first thing we need to do is to create a person object that will hold our information. This is done using the RDFa typeof attribute, which is much like @class in HTML. The type of the object we want to add is a Person and since 'person' comes from the FOAF vocabulary, we write it like this:
2008-03-03T14:05:14.283+00:00The following is a sample profile, created using the techniques described in the post First steps in RDFa: Creating a FOAF profile:
2008-02-21T22:47:58.875+00:00After a great deal of effort by some very dedicated people, the RDFa in XHTML: Syntax and Processing document has entered last call. The full story is on the front-page of the W3C site, or at this permalink. The status of 'last call' means that as far as the people who have been involved in creating the spec are concerned, any technical problems that might have existed have been resolved. Now it's the turn of the wider community to make comments about the document, and even try to implement RDFa processors.
2008-02-13T16:11:47.446+00:00One 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:Yesterday in Parliament the Prime Minister said that we will fight them on the beaches.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.So the original proposals for RDF in XHTML--now called RDFa--suggested that one way to solve this problem would be to allow metadata about anything to be added to HTML and XHTML documents. The example given above was extended as follows:Yesterday in Parliament the Prime Minister said that we will fight them on the beaches.The identifier p:WinstonChurchill was a made up placeholder, indicating simply that we need a unique identifier that tells us that this particular person is Winston Churchill, but since writing that early draft, DBPedia has come along, which means that assigning a unique identifier for the person Winston Churchill is easy.So if we have the identifier, and we have a way of adding the mark-up, all we need now is to get the data into the search engines, so that we can use them to find the article.And Google's Social Graph API shows that this is already possible.Google have released an API that allows us to search for people and their relationships to each other. The data is gathered during the normal indexing process, as long as it is provided to the indexer using the XFN microformat or via an external link to a FOAF document. This shows some interesting developments; first, that the Google indexing process is flexible enough to pick up different sorts of information and tie it back to a URL, and second that the search process is flexible enough to allow users to search for these different types of information in different contexts.So the logical next step is to add an RDFa processor to the Google indexing pipeline. Since RDFa is a generic language, able to express not just FOAF, but any RDF vocabulary, then Google will only ever need to add one RDFa processor to their system, and that processor will allow them to index all current and future RDFa, even if documents use vocabularies that hadn't even been invented at the time the processor was installed.This is a very different approach to the Microformats technique, since with Microformats, each format is unique and has its own parsing rules, which would mean that Google would have to add a different processor for each format. Not only that, it's very difficult to make multiple Microformats in the same document play together, and since each Microformat has to be centrally approved, there is no great momentum being built towards formats for disciplines such as engineering or chemistry.None of which is to belittle the fact that getting XFN indexed by Google is a great start. But whilst I've given examples here that use people, since [...]
2008-02-03T14:34:52.930+00:00I've seen a lot of impressive Silverlight and Popfly applications, but one of the limitations I see is that they always have to be run through the web browser. So I've posted a set of video tutorials to YouTube that show how to use a Popfly mashup as a desktop application, using the Sidewinder Web Applications Viewer. The complete collection is available as a tutorial on the Sidewinder Viewer site.
2008-01-20T11:43:10.165+00:00I quite like the 'planet' format of community web-site. It essentially consists of an automated site that reads RSS feeds from blogs and news servers on a particular topic -- MySQL, Gnome, Linux, microformats, etc. It's quite an important service within any community, since not only does it provide a useful place to keep up with what's happening, it's also a way for anyone new to get a 'view from 50,000 feet'. (Or metres.)
2008-01-11T09:17:40.775+00:00Yahoo! recently announced their entry into the mobile web applications space, with a service that allows applications to be built and hosted using Blueprint, a purpose-built mark-up language based on XForms.
2007-12-14T17:57:50.769+00:00I've not yet had a chance to write up my experiences at XML 2007 in Boston last week, but an announcement today by Amazon prompts me to at least summarise one of the talks I did, called XForms, REST, XQuery...skimming. (Slides)It's a theme I've touched on a little in this blog, and have spoken on before (at an XML UK meeting, last year, and at XTECH 2007, this year), and the idea goes something like this; building web applications by dynamically generating user interfaces that contain data, is awkward, and difficult to maintain. Web services (which includes REST and APP) removes some of the dependency on databases by hiding the data behind a simple abstraction layer--a kind of 'ODBC for the web'--and XQuery takes this further by giving us a standard language to get at the data.But XForms is the icing on the cake, since it gives us a rich-client language that can be deployed like traditional web applications, yet is one that ensures a clean separation of the data and the user interface.During the course of the presentation I showed how incredibly easy it is to create an application with XForms, since forms can be first created on the desktop--loading and saving their data from local XML files--before being deployed to any type of web server. By creating static forms that load their own data, rather than the more common model of dynamically generating static files that contain data, we end up with files that are completely agnostic about where they are delivered from. My demonstrations took them from the desktop, to a simple web server, to eXist (an XML database).But these applications could even run in 'the cloud', with no web-server. That may sound odd, but I could store any of these XForms applications in SVN or Amazon's S3 and they would work as well as if they were in IIS or Apache. This is the ultimate in simple maintenance and future-proofing, since you are no longer reliant on any particular operating system or server-side language...the forms just 'are'.GDataThe final step of my presentation was to take this a little further and show an XForm that interacts with Google's GData; the form is simple, and accepts a longitude, latitude and comment which is then inserted as a row into a Google Spreadsheet, using Atom Publishing Protocol (APP). Another form is then used to retrieve the entire spreadsheet, and each row is used to create a pin on a map.The great thing about this demonstration is that it shows that not only are our forms now agnostic about where they run--desktop, server-side, S3, etc.--but now the data becomes agnostic; we don't care how the data is stored, all we are concerned about is the protocol used to interact with it.And crucailly, XForms' ability to get at this data shows that it really is the missing link when it comes to building a new kind of web application.SimpleDBBut this generalisation about data just took another leap with the announcement today by Amazon of a closed beta called SimpleDB. This will allow programmers to store and query for data in a manner similar to the way that GData works.By putting data into the cloud, and then using an easily deployed, declarative rich-client language like XForms, it is possible for the architecture of web applications to be altered in a quite fundamental way, in a direction that is completely different to what we're used to.[...]
2007-12-10T14:24:15.479+00:00a monument to Gogol's "Nose" Originally uploaded by Incandenzafied One of the issues that people continually return to in relation to metadata in HTML (and with RDFa in particular), is how to know when it is safe to interpret some mark-up as 'additional' metadata. This often gets termed 'following your nose', since the idea is that you should be able to obtain from the document you are processing the information you need to add an extra layer of interpretation to the mark-up.(This shouldn't be confused with the other form of 'following your nose', practised by Gogol's Major Kovalyov, which is an altogether more fraught experience.)For example, if we were processing an HTML document that contained the hCard microformat, we might have:Mark BirbeckThe nose-related question being posed is, how do we know that it is legitimate to interpret the value called out by "fn" as a full-name? Is it not possible that on some occasions an author has simply created a @class value of "fn" to help their CSS?@profileOne way this question is answered in the world of microformats is to use the profile attribute to 'scope' these values; if the author has added the following, to the top of their document:then it is pretty clear that they want "fn" values to be interpreted as a 'full name', and it would be quite legitimate for a parser to extract this value and do something with it. The complete mark-up might look like this: . . . Mark Birbeck This is a good solution for microformats, since there are quite a few of them. Each microformat has different rules for parsing, so indicating the presence of one or more microformats in the profile attribute works well, and is very much in the spirit of the original meaning of @profile in HTML.But what of a generic solution like RDFa? Does the same situation arise?RDFa is unambiguousRDFa uses new attributes, as well as full identifiers for properties and values, so the problem of ambiguity does not arise. To make use of the FOAF value name an author would declare a namespace prefix, and then use any values that are enabled by that prefix, as follows: . . . Mark Birbeck This is about as good as it gets, since it makes use of existing, well understood XML techniques to define properties unambiguously. And since it is using the new property attribute, it is nigh on impossible that we would happen upon this mark-up in a situation where the author intended some non-RDFa meaning. In other words, RDFa provides a far better solution than the usual 'follow your nose' approach, which would have us load some kind of profile (as practised by microformats and GRDDL), since it requires no other indications in the document to help discern meaning, other than a few simple, generic, rules.Indicating the presence of metadataHowever, there is a separate problem that is often raised in conjunction with RDFa, which is how to know whether to actually parse the document or not; if an author has not included any RDFa, why spend time processing it?This is not a problem unique to RDFa, b[...]