W3C home > Mailing lists > Public > public-rdfa@w3.org > July 2010

POWDER and RDFa

From: Andrea Perego <andrea.perego@uninsubria.it>
Date: Sat, 3 Jul 2010 18:06:58 +0200
Message-ID: <AANLkTikWAgCG-_g7vTd37P8Y57LgMDMGfYp0hCP7tQ_A@mail.gmail.com>
To: public-rdfa@w3.org
Dear all,

This is to inform you about recent work concerning the generation of
RDFa snippets by using POWDER [1].

Let me first give a sketch of what POWDER is for those who are not
acquainted with it.

POWDER (Protocol for Web Description Resources) is a W3C
Recommendation defining a mechanism thanks to which you can associate
a description with a set of resources whose URIs/IRIs match a given
pattern. Such descriptions, referred to as Description Resources
(DRs), are stored into XML files, called POWDER documents, along with
information about the DRs' author, issue date, validity period, etc.
POWDER defines also the protocol to be used to discover and process
such descriptions, which can be associated with the resources they
apply to by using either the HTTP "Link" header [2] or (X)HTML "link"
elements. Basically, a POWDER processor takes as input the URI/IRI of
a resource and the one of a POWDER document, and returns an RDF/XML
description of the resource based on the information contained in the
POWDER document.

It is however possible to go further: I can convert the RDF/XML
document returned by the processor into an RDFa snippet which can then
be included into the "head" of the relevant (X)HTML documents - i.e.,
an RDFa snippet which makes use of "meta" and "link" tags only. In
other words, I can use POWDER as a tool to consistently manage and
control, with a minimum effort, the RDFa snippets which will be
embedded in the pages of a website.

One of the existing POWDER processors, namely, 3P [3], has been
recently extended in order to support such feature through its RESTful
API. The details are available in the section of the 3P's website
titled "POWDER and RDFa" [4], where you can find also working
examples. Note that this is just a starting point. The plan is to
revise and further extend RDFa support based on the feedback we
receive. For the moment, we are considering to implement the support
to the generation of RDFa snippets to be embedded in the "body" of
XHTML documents (as CC's ones) and to improve performance through the
enforcement of caching mechanisms.

A note on metadata provenance. As mentioned above, any POWDER document
comes with information thanks to which you can identify who is the
author of the claims made in the POWDER document itself. Now, if an
RDFa snippet is generated from a POWDER document, and such POWDER
document is referred from the page including the snippet, you are able
to verify who is the author of the embedded RDF statements.

Note that the author of a POWDER document can be anyone, and not just
the owner/administrator of the described resources. Actually, you
might also have third-party agencies which release POWDER documents
certifying that a given set of Web pages or a whole website satisfies
given quality/content constraints - e.g., child-safe content and
services, mobileOk-conformant pages. By using POWDER you can then
embed such "certificates" into the XHTML code, and then (if you like)
you can also check who released such certificates. Another example
concerns CC licenses. An author/owner can use a single POWDER document
to specify which license applies to which of his/her resources, and to
automatically generate the corresponding RDFa snippets, which can then
be included into the relevant XHTML documents (even though they are
hosted by third-parties). Moreover, such POWDER document will allow
anyone to verify who has associated a given license with a given
resource and whether the resource has been attributed to its actual
author/owner.

Comments are more than welcome!

Cheers

Andrea

----
[1]http://www.w3.org/2007/powder/
[2]http://tools.ietf.org/html/draft-nottingham-http-link-header-10
[3]http://dawsec.dicom.uninsubria.it/andrea/ppp/
[4]http://dawsec.dicom.uninsubria.it/andrea/ppp/#sec-powder_and_rdfa
Received on Saturday, 3 July 2010 16:07:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 3 July 2010 16:07:27 GMT