Toby Inkster has created a new RDFa checker, available here: check.rdfa.info
It checks RDFa 1.0 and the work-in-progress RDFa 1.1, extracts the RDF from pages, and also checks for the Facebook, Google, and CCrel uses of RDFa.
Toby Inkster has created a new RDFa checker, available here: check.rdfa.info
It checks RDFa 1.0 and the work-in-progress RDFa 1.1, extracts the RDF from pages, and also checks for the Facebook, Google, and CCrel uses of RDFa.
It looks like the O’Reilly product catalog uses RDFa. Check out this Nikon D5000 Manual. Looks like the GoodRelations schema, and quite a bit of data. We’ve long suspected that, once big consumers of web content started looking for certain RDFa vocabularies (i.e. Google and GoodRelations), there would be an uptick in RDFa production. Looks like this is indeed happening.
Check out the PLoS Journals, like PLoS Medicine or PLoS Genetics, and you’ll find RDFa for all bibliographic information, including authors, categories, etc.
Yahoo’s SearchMonkey work continues with some serious updates. We note in particular that, if you have a product to sell, the only way to mark it up is with RDFa. When you need fine-grained, dense structured data, it looks like RDFa is the clear choice.
Google just announced support for RDFa, starting with product reviews. Here’s Google’s FAQ on adding RDFa to your pages. This is a significant new direction for Google, where they will start looking at explicit data structure and provide enhanced search results accordingly. It’s fantastic to see them using RDFa for this task. It’s also fantastic to see them encouraging the use of a non-Google-branded vocabulary: open-vocabulary.org. Generic, reusable vocabularies built by industry groups, that’s exactly what we were hoping for with RDFa.
The side story here is that this was basically a Google-driven project from the start: they didn’t need the RDFa task force to create their vocabularies, to figure out how to mark up their pages, etc. Folks on the RDFa task force are finding out about this just now, as it happens. And we like it that way. RDFa is meant for communities of all sizes to mark up their pages, without centralized process overhead. Both Yahoo and Google’s RDFa launches were achieved without consultation with the RDFa community, and I consider that a success.
UPDATE: Google provides more details on RDFa for its rich snippets feature.
UPDATE 2: W3C blogs about the great news for structured web data.
Stephane Corlosquet has posted a video shown at DrupalCon this month demonstrating things you can do with RDFa and Drupal. Dries Buytaert (creator of Drupal) writes about it here.
In this post, Martin McEvoy announes a new extension for Dreamweaver supporting RDFa:
I am proud to announce RDFa Documents extension For Dreamweaver versions 8 to CS4
RDFa Documents contans a HTML TagLibrary with RDFa attributes and a XHTML+RDFa 1.0 Document Type Declaration.
The Extension will be available via Adobe Exchange (soon), after its passed a review by Adobe’s QA
The Extension Makes RDFa available to any Layout or Template that supports HTML/XHTML, It is also possible to convert existing Documents to RDFa using the Dreamweaver conversion utility.
For Now you can download the RDFa Dreamweaver Extension at the following location:
There is also a tutorial.
In Case Study: A Linked Open Data Resource List Management Tool for Undergraduate Students, Chris Clarke and Fiona Greig report on a direct manipulation package for editing pages with RDFa in:
The interface to build or edit lists uses a WYSIWYG metaphor implemented in Javascript operating over RDFa markup, allowing the user to drag and drop resources and edit data quickly, without the need to round trip back to the server on completion of each operation. The user’s actions of moving, adding, grouping or editing resources directly manipulate the RDFa model within the page. When the user has finished editing, they hit a save button which serialises the RDFa model in the page into an RDF/XML model which is submitted back to the server. The server then performs a delta on the incoming model with that in the persistent store. Any changes identified are applied to the store, and the next view of the list will reflect the user’s updates.
Using the approach of direct manipulation of RDFa, which is then posted this back to the server has two advantages. Firstly, in elegance simplicity of implementation—rather than having to keep track of multiple operations or edits to data in the persistent store via complex form submission or multiple AJAX calls, we are simply allowing the user to directly edit an RDF model locally (albeit via an appropriately familiar and usable metaphor) and simply send one form field containing the new model back to the server to update the stored copy. Secondly, by embedding RDFa in the HTML view of the entity, we are providing systems integrators or even indexing agents (such as Yahoo’s SearchMonkey) another route to discovering the semantics of the data represented in the page.
The Open Archives Initiative, which “develops and promotes interoperability standards that aim to facilitate the efficient dissemination of content”, has just published support for RDFa.
I’ve written some thoughts on Yahoo’s SearchMonkey after having seen it live:
Yahoo recently announced SearchMonkey, and for the first time in 10 years, I have a reason to switch search engines, from Google to Yahoo (In fact, I just did that in Firefox.) Most web-savvy engineers know that online services succeed in big ways when they become platforms: when other developers can expand on the functionality in ways not foreseen by the original developers. Yahoo is the first to figure out how to do just that with a major search engine. With SearchMonkey, any developer gains the ability to provide custom ways of extracting and presenting page data within Yahoo search results.
[...]
And the best part is that Yahoo has separated data extraction from data presentation. Specifically, a data extractor for LinkedIn can produce RDFa, and different presentation applications can use different portions of that RDFa. If the extractor for Monster.com produces the same RDFa, then the same presentation application can be used to display both Monster.com and LinkedIn data. And if LinkedIn and Monster.com produce RDFa natively, within their web sites, then there’s no need to build data extraction… the presentation application can work natively on the raw web pages.
Check out SearchMonkey.