Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
POWDER - Protocol for Web Description Resources - provides a mechanism to describe and discover web resources and helps the users to make a decision whether the resource is of interest. There are a variety of use cases: from providing a better means to describing web resources and creating trustmarks to aiding in content discovery, child protection and semantic web searches.
There are two varieties of POWDER: a complex, semantically rich variety, called POWDER-S, and a much simpler version, just called POWDER, which is intended as the primary transport mechanism for Description Resources. POWDER-S can be generated automatically from POWDER.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a First Public Working Draft, designed to aid discussion and solicit feedback. It was developed by the POWDER Working Group, which expects to advance this Working Draft to become a Working Group Note. The Working Group expects to revise this Primer while the related POWDER documents are undergoing review and eventually publish the Primer as a Working Group Note.
The Working Group solicits review and feedback on this document and the associated documents. All comments are welcome and may be sent to public-powderwg@w3.org. All messages received at this address are viewable in a public archive.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
POWDER is the abbreviation for "Protocol for Web Description Resources", meaning a way to describe online resources. The goal of the working group has been to develop a mechanism that allows not only the provision of those descriptions, but also a way to apply them to groups of online resources and to authenticate the descriptions and the claims they make.
The primary 'unit of information' within POWDER is the Description Resource (DR), which comprises:
There are two varieties of POWDER:
The simple version has relatively loose, human-readable 'operational semantics,' and is written in XML.
The semantically-rich version, known as POWDER-S, allows POWDER to harness
the semantic web at large and includes formal semantics that underpin the
operational semantics.
A "Gleaning Resource Descriptions from Dialects of Languages" (GRDDL) transform may automatically
generate POWDER-S as RDF/OWL from a POWDER document.
Alternatively, POWDER-S may be written directly.
There is no restriction on which form to use, but it should be noted that the simple version is intended as the primary exchange mechanism between systems. All POWDER tools will process POWDER. Using the POWDER-S form is optional, so that a processor may not necessarily understand this form.
POWDER-S is designed to facilitate incorporation of POWDER information in larger RDF-based systems and it should be noted that such systems will need to implement a Semantic Extension to do this (see "How do I process POWDER-S").
Importantly, POWDER allows a variety of questions to be answered about a given Web resource or group of resources, without having to actually retrieve and inspect the resource(s).
At first a Description Resource is simply a claim: somebody is making some statement about a given resource, or group of resources. However, most users would have to trust the person that made the claim before deciding whether to trust the data. If a DR is made available directly by a well-known content provider that is trusted to uphold a certain level of quality, then the data might readily be trusted. However, this will not always be sufficient. Since a DR may be published by anyone, anywhere, to describe anything, an end user may reasonably want to query the cited author of the DR to ask questions such as: Did you really make that claim? And, if so, when? Would you make the same claim today?
For some situations this might still not be sufficient for the end user. To facilitate the further extension of trust a means has been provided to allow certification of DRs. A Description Resource that has been certified immediately gains in trust, through the verification by a third and trusted party of the original claims made by the DR author.
Through the combination of these tools various questions, not limited to the following, can be answered using a Description Resource, without having to retrieve the resource itself:
The POWDER Suite consists of the following documents, in order of recommended reading
The amount of information on the web grows continually. Conversely, the amount of time people have to devote to this information seems to be decreasing. To cope with these constraints (too much information and too little time), users need a system where more customized content is delivered to them in the most personalized way. Basically the average user wants to get online, find what they want and move on.
Furthermore, it could be argued that many have even turned to personal social networks in order to create an environment that attempts to restrict the information flow to only that which the user wants. In effect, users have created an artificial means to "filter" information. Although social networks are growing in popularity and provide a valuable service, they are not the answer to the ultimate goal of personalized content delivery.
This is where POWDER offers the method for a much more dependable means by which to deliver the most relevant information without putting the onus on the user to verify and validate every aspect. Both information providers and information consumers are interested in getting the highest return for their individual investment of time and effort.
There is no system or organization that should not want to benefit from adopting a means by which they could enhance their customer's experience.
Authors and information providers wish to still reach both users that have embraced social networking as well as those who have not. Thus they need to highlight the information they provide and make identification, acquisition, retrieval and aggregation easier.
Let us examine how POWDER can simultaneously meet these needs.
This is one of the most powerful overarching features of POWDER and one that has been an unresolved challenge until now. It allows one to offer semantically rich information about entire groups of online resources with both flexibility and precision in the way the group is defined. A processor may use a single POWDER document to extract information about many - perhaps huge numbers of - other resources. In addition, the maintenance of such Description Resources is simplified by support for defining many descriptions in a single document.
The methods for grouping resources range from the individual listing of URIs, through the specification of things like domain names and paths, to the matching of URIs against regular expressions. Requests made to a POWDER Processor, however, are always handled at the level of an individual resource. The RDF returned will be triples about that resource, allowing an application to analyze the data and decide how to act case by case.
Traditionally, meta information is always linked to a single resource and is usually embedded within it, as is the case, for example, with the HTML META element where the attributes are chosen and the values are given by the author. When metadata is embedded in content in this way, the complete resource has to be retrieved in full to then determine if it is of interest or not.
POWDER describes online resources that may be of interest to a user or a system. The keyword is "may", because the requester can decide prior to resource retrieval whether the resource should be retrieved at all, based on information provided by a web Description Resource. This makes information retrieval more efficient and precise by reducing network traffic and and server load. From a user perspective it means greater personalization and less irrelevant content.
POWDER allows profile matching - that is, the retrieval of resources according to user preferences, device capabilities and current state at the time of content delivery. The use cases [USECASES] deal with adaptive search results based on context, suitability for mobile devices, functional user experiences based on capabilities, web accessibility, child protection and privileged content.
Resources and the DRs that describe them may be connected to each other in a web of trust. Partners in this web may be certification authorities that verify the truthfulness of claims made in Description Resources. Other partners may be repositories of thematically linked URIs, such as white lists for web sites that are recommended for children.
There are several possible models in which assertions and claims can be made, authenticated and reported to the end user. The Use Cases and Requirements document lists several use cases which have a number of elements in common but differ in details such as whether it is the content provider or the trustmark operator that makes the original claim, whether the data is stored on the trustmark operator's servers or alongside the content itself, and whether the trustmark operator provides the description or the authentication for a description.
POWDER makes it easy for annotations to be created and published independently of the relevant content. Such annotations may cover large amounts of content as it is created with only occasional changes needed to the annotations. This matches typical content production workflows where different individuals are often responsible for the two tasks. In situations where annotation can only be done by the content author, all too often content is published without any meaningful metadata.
Cost-effective, trusted annotations have a significant potential benefit to content aggregators, search engines and related services.
Semantic Searches could return results filtered for location-based cultural parameters. Information provided on the Web can affect users in different ways depending on the context in which it is retrieved. For example, nudity on a medical website dealing with breast cancer may be fully appropriate if it is known prior to retrieval what the context of the content is. Content promoting discrimination may be appropriate for analysis purposes but may be served with additional contextual information in other circumstances. Semantic annotation also allows the disambiguation of terms such as 'football.'
In summary, POWDER empowers users to find more of what they ask for and less of what they don't.
The previous section describes the benefits of POWDER and the reasons why it is a compelling method for defining relatively small amounts of data that can be applied to large amounts of content.
The following are brief examples of how POWDER applications work.
POWDER offers various possible methods by which trust claims and assertions can be made and used.
A user could install a browser plug-in designed to provide an indication (such as a visual logo or audible alarm) that a Web site is trustworthy or not. The plug-in would rely on various sources such as reputation and accreditation services to determine trustworthiness.
This can be particularly valuable in cases where certain sites are required by law or other regulations to provide a certain level of content or access. Once those sites have been approved and tagged as having met specific standards, an automated process can aid the discovery and regular review of the site's content and its DR for continued authenticity and validity. This could go as far as generating a report for the evaluating party.
A Web site operator submits their work to a trusted organization that can authenticate the work and provide a Description Resource that identifies the site as accurate or trustworthy.
POWDER enables search engines and portals, if they so choose, to provide customized links for users who prioritize compliance with particular accessibility checks. For example, an organization might review Web sites to determine their level of compliance with accessibility guidelines [WCAG]. The reviewed Web sites can be duly tagged with the results in the form of a DR. The search engine/portal can then present or perhaps highlight the best sites based on a user's preference settings and the tags on the reviewed Web sites. The system can be highly granular so that the links presented to a user with limited manual dexterity (to resources that support keyboard navigation) would differ from those presented to a user with a visual impairment.
In a similar fashion to the accessibility case, POWDER may be used to identify resources that conform to W3C mobileOK [MOK]. A user wanting to browse the Web using his mobile phone may request that the search provider favor links suitable for display on his device. When the search engine retrieves a set of links from its index, it determines which have an associated mobileOK descriptor, and presents those before the remainder.
Online child protection, as well as the continuation of offline child protection, is a priority for any responsible site or service provider, whether directed at children or not.
A service provider may include a feature that offers parents the ability to determine the type or level of content they would allow their child to view. In today's market, most, if not all, service providers do offer some degree of parental controls. A hypothetical Web site that sells an array of merchandise can use POWDER to accurately describe their content as either being child appropriate or intended just for adults. While most of their content and products are appropriate for all ages, there are also numerous pages showing "adult" toys. When a child whose setting allows him only to view content that is age appropriate accesses this online retailer through the family network he will only be able to view the content that is deemed age appropriate and not that in the adult category.
[Example: ICRA Labelling]
Web pages and whole Web sites containing any type of rich assets such as video/streaming video or audio can be tagged with that information using POWDER. A search engine, content aggregation or adaptation service can then determine whether a user is accessing content via a low or high bandwidth connection and return only those pages that contain assets and images that will be supported by that user's connection speed.
A user pays an extra fee to his ISP in order to have privileged access to third-party premium content. When he accesses a premium page on one of these third-party Web sites via his ISP, the server is able to recognize him as a paying customer and deliver the content that has been described as premium by an associated Description Resource.
Sites can use Description Resources to communicate their content more accurately and with greater relevance to user requests.
Because the same term can suggest two distinctly different meanings, the judicious use of Description Resources can go a long way in making a site more valuable to a greater number of people. An owner of a global sports site can provide descriptors that are accurate enough so that users searching on the term "football" can receive the portions of the available content relating to the specific game that the user's location suggests is what they are searching for information about.
By developing an appropriate and detailed vocabulary, Description Resources can be used to identify the value of a site as being either of value in its own right or as an excellent example of something that is intrinsically bad (in the opinion of the DR author).
Usage of POWDER is dependent on the intended results.
The process is a sequence and can be stepped through all the way or terminated at the appropriate place to obtain the desired result.
For someone who wishes to describe content:
For someone who wants to access RDF triples obtained from POWDER documents:
For someone who wants to make inferences based on the data contained in POWDER documents:
The first step is to create a skeleton POWDER document in XML and declare the namespaces:
<?xml version="1.0"?> <powder xmlns="http://www.w3.org/2007/05/powder#" xmlns:ex="http://example.org/vocab#"> </powder>
The "ex" namespace used above is a fictitious namespace with "ex" for "example" to denote that any namespace may be used here that contains the needed vocabulary.
Next we need to say who has created the document. All POWDER documents have exactly one "attribution" element, and within that an "issuedby" element. This contains details of the person or organization that has published the document. Exactly which details is for the publisher to decide, but a name and a homepage address should usually be included, perhaps along with contact details. POWDER authors may use either the Friend of a Friend [FOAF] vocabulary or the Dublin Core [DC] to do this.
<?xml version="1.0"?>
<powder
xmlns="http://www.w3.org/2007/05/powder#"
xmlns:ex="http://example.org/vocab#"
<attribution>
<issuedby src="http://authority.example.org/company.rdf#me" />
</attribution>
</powder>
An individual or organization may publish many Description Resources.
Therefore it is more convenient to define the profile information in a single
file and refer to it from each POWDER document as it is created.
The above example points to a profile as listed below. Notice the rdf:ID="me",
which is referred to by the #me in the above example.
The profile would look like this:
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:foaf="http://xmlns.com/foaf/0.1/">
<foaf:Organization rdf:ID="me">
<foaf:name>The POWDER Company</foaf:name>
<foaf:homepage>http://authority.example.org</foaf:homepage>
</foaf:Organization>
</rdf:RDF>
A POWDER document will typically also include information about when it was created (our example was created on 14 December 2007).
<?xml version="1.0"?>
<powder
xmlns="http://www.w3.org/2007/05/powder#">
<attribution>
<issuedby src="http://authority.example.org/company.rdf#me" />
<issued>2007-12-14T00:00:00</issued>
</attribution>
</powder>
Next an actual Description Resource (DR) is added. This example POWDER document will contain a single Description Resource, as the "dr" element.
<?xml version="1.0"?>
<powder
xmlns="http://www.w3.org/2007/05/powder#">
<attribution>
<issuedby src="http://authority.example.org/company.rdf#me" />
<issued>2007-12-14T00:00:00</issued>
</attribution>
<dr>
</dr>
</powder>
The Description Resource itself must contain at least one set of IRIs (International Resource Identifiers). This is the scope of the Description Resource - i.e. what it describes. IRIs are a superset of the well known Uniform Resource Identifier (URI) with the expansion of also allowing international characters. If multiple IRI sets are included within a DR, then the scope is the union of all the IRIs in all the IRI sets.
In this case, the scope is 'everything on example.com' or, more formally, the set of IRIs that have a host whose last two components are exactly example.org. This is done using the "includehosts" element. There are other elements available which are described in detail in the Grouping of Resources document [GROUP]. All Description Resources have to contain at least one iriset element, and this cannot be empty and cannot contain any elements from any other namespace.
<?xml version="1.0"?>
<powder
xmlns="http://www.w3.org/2007/05/powder#">
<attribution>
<issuedby src="http://authority.example.org/company.rdf#me" />
<issued>2007-12-14T00:00:00</issued>
</attribution>
<dr>
<iriset>
<includehosts>example.com</includehosts>
</iriset>
</dr>
</powder>
The final key element of a Description Resource is the actual description.
There are three two ways of providing this.
A DR must contain at least one of these three and may contain any greater number of them, none of which may be empty. The DR states that in the opinion of the entity references in the "issuedby" element, all resources within its scope are described by all descriptive elements.
We'll add one of these to our example: a descriptor set. It may contain RDF/XML properties with literal values or resources identified by an IRI. In addition, a textual and/or graphic summary that can be displayed to end users may be included in a descriptor set using the "displaytext" and "displayicon" elements as shown in the completed example below. Notice that the namespace used in the descriptor set is also declared.
Generic Example of a POWDER Document Containing a Single Description Resource. This is a repeat of Example 2-1 from the Description Resources document [DR] [XML]
<?xml version="1.0"?>
<powder xmlns="http://www.w3.org/2007/05/powder#"
xmlns:ex="http://example.org/vocab#">
<attribution>
<issuedby src="http://authority.example.org/company.rdf#me" />
<issued>2007-12-14T00:00:00</issued>
</attribution>
<dr>
<iriset>
<includehosts>example.com</includehosts>
</iriset>
<descriptorset>
<ex:color>red</ex:color>
<ex:shape>square</ex:shape>
<displaytext>Everything on example.com is red and square</displaytext>
<displayicon src="http://authority.example.org/icon.png" />
</descriptorset>
</dr>
</powder>
Of course, much more complicated structures are possible within POWDER
documents.
The following example uses an ordered list to confer a hierarchy of importance
to describe exclusions.
Example of a POWDER document which contains an ordered list (from Example 2-6: A POWDER Document Containing an Ordered List of Description Resources [DR] [XML])
<?xml version="1.0"?>
<powder xmlns="http://www.w3.org/2007/05/powder#"
xmlns:ex="http://example.org/vocab#">
<attribution>
<issuedby src="http://authority.example.org/company.rdf#me" />
<issued>2007-12-14T00:00:00</issued>
<abouthosts>example.com</abouthosts>
</attribution>
<ol>
<dr>
<iriset>
<includehosts>example.com</includehosts>
<includepathstartswith>/foo</includepathstartswith>
</iriset>
<descriptorset>
<ex:color>blue</ex:color>
</descriptorset>
</dr>
<dr>
<iriset>
<includehosts>example.com</includehosts>
</iriset>
<descriptorset>
<ex:color>red</ex:color>
</descriptorset>
</dr>
</ol>
</powder>
All web resources with paths on example.com that start with /foo are
blue.
Thus, all web resources on example.com are red, except those that have a path
starting with /foo and are blue.
Also, it is possible for the scope of a DR to be the union of two IRI sets.
The following example shows descriptors that apply to two different IRI sets simultaneously.
<?xml version="1.0"?>
<powder xmlns="http://www.w3.org/2007/05/powder#"
xmlns:ex="http://example.org/vocab#">
<attribution>
<issuedby src="http://authority.example.org/company.rdf#me" />
<issued>2007-12-14T00:00:00</issued>
</attribution>
<dr>
<iriset>
<includehosts>example.com</includehosts>
<includepathstartswith>/foo</includepathstartswith>
</iriset>
<iriset>
<includehosts>example.org</includehosts>
<includepathstartswith>/bar</includepathstartswith>
</iriset>
<descriptorset>
<ex:color>red</ex:color>
<ex:shape>square</ex:shape>
<displaytext>Everything on example.com/foo, and everything on example.org/bar, is red and square</displaytext>
<displayicon src="http://example.org/icon.png" />
</descriptorset>
</dr>
</powder>
Like any other resource on the Web, POWDER documents can only be found if you know where to look or you can follow a link from where you already are. Individuals or organizations whose activities include reviewing and describing online content will be able to set up and advertise the existence of a repository of Description Resources (see ICRA example). A content provider can aid the discovery of DRs that describe their content by linking to them (this applies whether the DRs were created by the content author or a third party).
There are several methods of linking from a resource to a POWDER document that describes it. First of all, HTML documents can include a link element in much the same way as is common for linking to CSS style sheets, RSS/ATOM feeds, etc.
<link rel="powder" href="powder.xml" type="application/xml"/>
The relationship type (rel) of "powder" tells user agents the kind of resource that is being linked to. The type attribute declares that it's an XML document and the value of the href is the IRI of the POWDER document. Just as with stylesheets, it's important to include this link on all described pages, so it's best included in the document template.
When using HTML link elements in this way, authors should also refer to POWDER's profile document as shown below.
<html xmlns="http://www.w3.org/1999/xhtml">
<head profile="http://www.w3.org/2007/11/powder-profile">
<meta name="wdr.issuedby" content="http://authority.example.org/company.rdf#me"/>
<link rel="powder" href="powder.xml" type="application/xml"/>
<title>Welcome to example.com </title>
</head>
<body>
<p>Today's content is ....</p>
</body>
</html>
Adding this makes the relationship type "powder" clear and allows content authors to include data about the POWDER document within the described resource. As shown in the example above, this can include information about who has issued the DRs (issuedby), so that a user agent that recognizes and trusts that Description Resource author will be more confident that the data available is trustworthy and therefore that the link is worth following.
Whilst HTML link elements do make POWDER documents discoverable, the preferred method is to configure the server to include an HTTP Response Header that does the same job.
Link: <powder.xml>; rel="powder" type="application/xml";
This has several distinct advantages:
Where POWDER documents are discoverable via HTTP Link: headers, a user agent or Web crawler can discover them by doing an HTTP HEAD request which may affect how, or indeed whether, a subsequent GET request is made. The HTTP Link: header was originally defined as part of HTTP but removed in RFC2616. It has since been revived, with changes [http://tools.ietf.org/html/draft-nottingham-http-link-header-02].
From a POWDER perspective, the semantics of the HTTP Link: header are identical to the HTML link element.
Where a more formal relationship is required between a POWDER document and a resource that it describes, POWDER's "describedby" property is available. This is an RDF property and therefore may be used, for example, in XHTML documents annotated with RDFa as described in section 4.1.3 of the Description Resources document [DR]. One important benefit of using RDFa to link to POWDER documents is that it allows you to point to a description of the destination of a hyperlink.
As an example of this, imagine an XHTML document about a rock band that included hyperlinks to ring tones, images and videos.
An XHTML/RDFa Fragment with Hyperlinks described using POWDER
XHTML fragment [XHTML]
<ul>
<li><a href="/clips/low_res_clip.mpg"
rev="wdrs:describedby"
about="/powder.xml">30" clip</a></li>
<li><a href="/videos/full_video.mpg"
rev="wdrs:describedby"
about="/powder.xml">Full 10 minute video</a></li>
<li><a href="/tones/ring_tone1.mp3"
rev="wdrs:describedby"
about="/powder.xml">Ring Tone</a></li>
…
</ul>
powder.xml [XML]
<ol>
<dr>
<iriset>
<includehosts>example.com</includehosts>
<includepathcontains>/videos/</includepathcontains>
</iriset>
<descriptorset>
<typeof src="http://www.w3.org/2007/07/mobileOK#nonconformant" />
</descriptorset>
</dr>
<dr>
<iriset>
<includehosts>example.com</includehosts>
</iriset>
<descriptorset>
<typeof src="http://www.w3.org/2007/07/mobileOK#conformant" />
</descriptorset>
</dr>
</ol>
This ordered list of DRs states that resources on the example.com host where the IRI path includes /videos/ are not conformant with mobileOK [MOK]. All other resources on example.com are conformant with mobileOK Basic (i.e. are likely to provide at least a functional user experience on mobile devices).
By taking note of the available descriptions, the user agent may display the links differently on different devices (or chose not to display them at all). Notice a couple of points here:
Trust is a critical aspect of Description Resources; however, trust is very much a matter of opinion. The level of trust demanded of a given DR will depend on what the description says and to what use it will be put. For example, an individual user finding a DR that declares a Web site to offer children's birthday party ideas can make his/her own assessment of its quality and usefulness. In contrast, a multi-million dollar business will need very strong assurance that a DR declaring a Web site to be medically accurate and freely available is trustworthy before including it in a portal of high quality, license-free health care materials. For this reason, we do not define a single trust mechanism that must be used. Rather, there are a variety of different methods of adding trust to DRs, some of which may be used in combination.
authenticate
property to provide information about how a user (or user agent) can verify
you as the author of a DR. This is not limited to persons, but can be used
for organizations and other entities.certifiedby
property.supportedby
property. This points to further DRs or other Web resources that contain
information supporting the claim made.Where applicable, we define vocabulary terms designed to aid the building of trust.
The methods cited here do not comprise an exhaustive list. Other techniques, such as XML Signature [XMLSIG] and Web of Trust [WOT], may be equally applicable. As noted in the introduction, trust is a human judgment that can only be made by weighing the likelihood that the data is true against the consequences of it being false. This judgment is highly dependent on the circumstances under which the need to extend trust arises. It is clear, however, that Description Resources are unlikely to be trusted in isolation and that both their publishers and consumers will only benefit from their existence if one more more techniques for enhancing trust are employed.
These methods would also serve to increase trust placed in the meta information provided for Web documents in general.
Today's meta data, such as the keywords provided in META elements, increasingly lose meaning, as this mechanism has been abused to such a degree that renders it practically useless from an informational point of view. Search engines do not place much stock on keywords to give any indication about the relevance of a given Web page to a given topic and use different means, such as incoming links, as a basis for page ranking.
False claims made in meta information, intended to lure the user into clicking on a link to a resource, also serve to lower the value of meta information.
Also, a less deliberate yet still disturbing fact about meta information is aging. As meta information is not kept up to date, it loses its relevance to the content it describes.
POWDER elevates meta information once again into the spotlight by allowing a third-party to certify the veracity of the meta information given, declare the date of the verification, and define a date after which the certificate will no longer be valid.
DRs should always reflect the Web resource in its most current state. This
requires that DRs are kept up-to-date and will thus change frequently.
Therefore it is important to provide a link to the "latest" version of DR
document, which has the added benefit of providing a DR history.
For example, a link element such as
<link rel="powder" href="powder.xml" type="application/xml"
/>
could be such a link where, if a request is then made for this document, HTTP 302 redirect should be used to point the requesting client to the actual, current document.
Alternatively, a HTTP link header could be used, as in
Link: <powder.xml>; rel="powder" type="application/xml";
Here too, a server side temporary redirect should point the client to the correct file.
There are several ways of discovering DRs.
This is the easiest way to find the appropriate DR. The HTTP header may contain a link element, a head request to that web resource that will reveal the link to the associated DR, which can then be retrieved prior to retrieving the resource and being acted upon.
With this option, upon retrieval of the resource, a link element may be present to point to the appropriate DR.
Since the creation of DRs is not limited to the author or provider of a
web resource, repositories of DRs may be created by companies or special
interest groups, for example those specializing in certification or child
protection. These may then be queried to obtain descriptions and scope
information.
For example, a large content provider, upon planning to switch from regular
meta data to POWDER, could, in a first step, create one or several DR
documents. The scope would be set such as to cover all areas of the content
provider's content. Meta elements and various other information may be
copied into the DR documents. Insertion of the appropriate link in the web
resource, pointing to the correct DR, would be the last step prior to
publication of the DR documents.
DRs may be traded or passed between users of social networks or other groupings of similar interests.
Since DRs are simple, publicly accessible documents, they may be found by similar means as any other documents of this nature.
This is by no means an exhaustive list, but rather a small collection of examples. DRs are normal documents that may be discovered in all the usual wys that other documents are discovered on the web.
POWDER is the most commonly used form. Since it is written in XML and simple in structure it is easy to use even for those users with only a basic knowledge of XML.
POWDER-S is the semantically rich form of POWDER and would be used when the data should be represented in RDF and OWL. One of the most common use cases is that of linked data in the semantic web.
This section is intended to give a quick overview of the concept and requirements of a POWDER processor.
A POWDER processor is intended to read various types of POWDER documents and return RDF triples. There is no precise concept for a POWDER processor given in these documents, as implementors are free to choose whichever methods they deem fit for the task.
Conformance criteria for the resulting processor are provided in detail in [DR] and will be discussed here briefly.
As a minimum a POWDER processor must be able to describe a resource, accessed via a URI or IRI, and return the RDF triples that describe said resource.
The functionality of a POWDER processor may go far beyond that, but this is up to the implementor.
It is of course useful to think about usability, error trapping and potential extensions of its functionality beyond that which has been conceived of so far.
One of the more important topics of POWDER is trust. At some point the user will have to trust a source of information and then base a decision upon this trust whether to act upon a web resource in some fashion or not.
The most likely way to make this decision is to look at the DR attribution, describing who the author of a DR is, when it was created, etc.
The operational semantics, meaning the XML file, are underpinned by formal semantics. A GRDDL transform is associated with the POWDER namespace that allows the XML data to be rendered and processed as RDF/OWL.
However, RDF/OWL cannot currently interpret string values of RDF properties as International Resource Identifiers (IRI). In other words the string "http://example.org" is not necessarily recognized as the web address (IRI) http://example.org.
To allow this to happen a semantic extension has to be created that makes this definition and relates to the hasIRI property. The extension is defined in POWDER: Grouping of Resources
POWDER is a strong tool in the creation of trustmarks, which usually have some sort of period of validity.
This time period would be reflected in the DR itself, in the attribution section through the values of
validfrom
and
validuntil
These temporal statements deal with the assertions made within the DR.
The data itself, meaning the DR document, also has a temporal validity, which is declared in the HTTP header.
The time periods in question may conflict, which requires a second extension to RDF/OWL, which is defined in the document POWDER: Description Resources
No special knowledge is needed to understand plain POWDER.
The examples provided in the documents should be sufficient to begin using POWDER with only rudimentary knowledge of markup languages.
You will need to be able to publish (upload) the POWDER web descriptions to some location (server) where people can reach (download) them.
This may be the same location as the web resources themselves.
The creation of a DR could be accomplished via online tools provided by
companies who offer repositories of DRs or created by hand with a desktop
editor in the simple form outlined in this document.
In that case all that is needed, if so desired, is to link from the web
resource to the DR via a link element or other mechanism as outlined here.
Therefore if you can do this:
<link rel="stylesheet" href="/styles.css" type="text/css" />
You can easily do this:
<link rel="powder" href="/powder.xml" type="application/xml" />
Note the MIME type is application/xml, not the RDF one of application/rdf+xml
Example: using the link element to relate to a DR
<html>
<head>
<link rel="powder" href="exampleDR.rdf" />
<title>Welcome to example.com </title>
</head>
<body>
<p>Today's content is ....</p>
</body>
</html>
Example: HTTP link header
The HTTP Link Header is an alternative to the HTML link element and has very similar semantics such that the following two links are equivalent:
XHTML
<link rel="powder" href="powder.xml" type="application/xml"
/>
HTTP
Link: <powder.xml>; rel="powder" type="application/xml";
There is another method for linking to a DR in semantically rich environments via the describedBy and mapsTo Properties.
In semantically-rich environments, it is appropriate to link a resource to a DR that describes it through the describedBy predicate. For example, a document might be part of a collection about a particular topic described in a DR. Such a document might be annotated using RDFa as shown below.
Example: RDFa example using wdr:describedBy
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
xmlns="http://www.w3.org/1999/xhtml" version="XHTML+RDFa 1.0"
xmlns:wdrs="http://www.w3.org/2007/05/powder-s#">
<head>
<title>The English Civil War</title>
<link rel="wdrs:describedBy" href="http://ecw.example.org/powder1.xml" type="text/powder+xml" />
</head>
<body>
<p>...</p>
<p>Charles I came to the throne believing in his
<a href="http://monarchy.example.org/divine_right.html">Divine Right</a> to rule…</p>
<p>...</p>
</body>
</html>
Finally, you will need an application that retrieves and processes the request to a Web Description Resource and processes the obtained triples. SPARQL queries and GRDDL transforms can be used to obtain and process such information. There currently is no dedicated application available.
POWDER-S will not be dealt with in great detail in this document. The interested reader is encouraged to consult the [FORMAL] specification, which outlines POWDER-S exhaustively.
The FORMAL specification provides the necessary underpinning for POWDER and POWDER-S such that processing done on these types of documents can be conformant and consistent with existing semantic Web technologies. Furthermore, the FORMAL specification also outlines the support for non-url environments, e.g. ISBN codes or similar resources.
It should be noted, however, that the creation of POWDER-S documents requires the implementation of an RDF extension in the reasoning engine.
See section "4.3 POWDER-S IRI Set Semantics" in [FORMAL] for details.
Example: Generic Example of a Description Resource of a
POWDER-S document containing a single Description Resource.
This example also happens to be the POWDER-S variety of the example used in the creation of a DR.
1 <?xml version="1.0"?> 2 <rdf:RDF 3 xmlns:wdrs="http://www.w3.org/2007/05/powder-s#" 4 xmlns:foaf="http://xmlns.com/foaf/0.1/" 5 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 6 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" 7 xmlns:owl="http://www.w3.org/2002/07/owl#" 8 xmlns:dc="http://purl.org/dc/elements/1.1/" 9 xmlns:dcterms="http://purl.org/dc/terms/0.1/" 10 xmlns:ex="http://example.org/vocab#"> 11 12 <owl:Ontology rdf:about=""> 13 <wdrs:issuedby rdf:resource="http://authority.example.org/company.rdf#me" /> 14 <dcterms:issued>2007-12-14T00:00.00</dcterms:issued> 15 </owl:Ontology> 16 17 <wdr:iriset rdf:nodeID="iriset_1"> 18 <owl:intersectionOf rdf:parseType="Collection"> 19 <owl:Restriction> 20 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" /> 21 <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com)(:([0-9]+))?\/</owl:hasValue> 22 </owl:Restriction> 23 </owl:intersectionOf> 24 </wdr:iriset> 25 26 <owl:Class rdf:nodeID="descriptorset_1"> 27 <owl:intersectionOf rdf:parseType="Collection"> 28 <owl:Restriction> 29 <owl:onProperty rdf:resource="http://example.org/vocab#color" /> 30 <owl:hasValue>red</owl:hasValue> 31 </owl:Restriction> 32 <owl:Restriction> 33 <owl:onProperty rdf:resource="http://example.org/vocab#shape" /> 34 <owl:hasValue>square</owl:hasValue> 35 </owl:Restriction> 36 </owl:intersectionOf> 37 <dc:description>Everything on example.org is red and square</dc:description> 38 <foaf:depiction rdf:resource="http://example.org/icon.png" /> 39 </owl:Class> 40 41 <owl:Class rdf:nodeID="iriset_1"> 42 <rdfs:subClassOf rdf:nodeID="descriptorset_1"/> 43 </owl:Class> 44 45 </rdf:RDF>
Line-by-line explanation:
We also need to include:
The ICRA vocabulary facilitates what is intended to be a culturally neutral description of online content in terms that may reflect parental concerns around the world. Such descriptions, especially where backed up by third-party checks, can be useful in delivering appropriate content to different target groups, particularly children.
In the following scenario, we imagine that example.com publishes content across its portal that does not include any sex, nudity, violence or other potentially offensive or harmful material, except in its night life section, where references to alcohol, tobacco and potentially offensive language are to be found, especially as it invites users to post reviews of bars, pubs and clubs they have visited. Since all pages relevant to the night life section have a URL of the form http://www.example.com/nightlife... it is able to describe its own content in the following POWDER document.
Example: ICRA labelling
1 <?xml version="1.0"?>
2 <powder xmlns="http://www.w3.org/2007/05/powder#"
3 xmlns:foaf="http://xmlns.com/foaf/0.1/"
4 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
5 xmlns:icra="http://www.icra.org/rdfs/vocabulary2008#">
6
7 <attribution>
8 <issuedby src="http://www.example.com/company.rdf#me" />
<issued>2008-06-02T00:00:00</issued>
15 <certifiedby src="http://independent.example.org?verify=http%3A%2F%2Fwww.example.com%2Fpowder.xml" />
16 </attribution>
17
18 <ol>
19 <dr>
20 <iriset>
21 <includehosts>example.com</includehosts>
22 <includepathstartswith>/nightlife</includepathstartswith>
23 </iriset>
24
25 <descriptorset>
26 <icra:nz>1</icra:nz>
27 <icra:sz>1</icra:sz>
28 <icra:vz>1</icra:vz>
29 <icra:lb>1</icra:lb>
30 <icra:lc>1</icra:lc>
31 <icra:ha>1</icra:ha>
32 <icra:hb>1</icra:hb>
33 <icra:dz>1</icra:dz>
34 <icra:ua>1</icra:ua>
35 <icra:pa>1</icra:pa>
36 <displaytext>
No nudity; No sexual material; No violence;
Profanity or swearing; Mild expletives;
Depiction of tobacco or its use; Depiction of alcohol or its use;
No potentially disturbing material;
User-generated content such as chat rooms and message boards (moderated);
Contains advertising
</displaytext>
37 </descriptorset>
38 </dr>
39
40 <dr>
41 <iriset>
42 <includehosts>example.com</includehosts>
43 <includepathstartswith>/nightlife</includepathstartswith>
44 </iriset>
45
46 <descriptorset>
47 <icra:nz>1</icra:nz>
48 <icra:sz>1</icra:sz>
49 <icra:vz>1</icra:vz>
50 <icra:lz>1</icra:lz>
51 <icra:hz>1</icra:hz>
52 <icra:dz>1</icra:dz>
53 <icra:uz>1</icra:uz>
54 <icra:pa>1</icra:pa>
55 <displaytext>
No nudity; No sexual material; No violence;
No potentially offensive language;
No potentially harmful activities;
No potentially disturbing material;
No user-generated content; Contains advertising
</displaytext>
56 </descriptorset>
57 </dr>
58 </ol>
59
60 </powder>
The document contains two Description Resources that reflect the two
different types of content on (the fictional) example.com.
This document makes use of POWDER's ordered list feature such that
every page on example.com, irrespective of its content, can be
linked to the same file. This can be done by including a link element in each
page's HTML thus:
<link rel="powder" href="/powder.xml" type="application./xml"
title="ICRA labels" />
but is more efficiently done by configuring the example.com server(s) to include the equivalent HTTP Link header thus:
Link: </powder.xml>; rel="powder";
type="application/xml";
A user agent, such as a content aggregation service, can now support different policies with respect to the resources available from example.com. It may, for example, choose not to include the night life section for all its customers, or conversely to promote that section as it is a better fit for its own target market.
Notice also that example.com has referred to an independent certification body in Line 15. A user agent might be satisfied that example.com's description of its own content is sufficiently trustworthy to be of use or it may choose to query the service operated by http://independent.example.org before conferring trust on the data. In the specific case of ICRA descriptions, it is often the case that a description of content as being potentially harmful or offensive is trusted more readily than descriptions of content as being suitable for children. Thus external verification mechanisms can have varying degrees of importance even within a single domain of interest.
mobileOK is a standard that deals with content that is rendered within a mobile context and adheres to a set of guidelines called the mobileOK Basic Tests. Claiming mobileOK has been one of the major use cases of POWDER and the example below outlines how this claim can be made using a POWDER document.
Example: mobileOK (from Example 5-3: A DR Claiming Conformance to mobileOK Basic, Supported By the mobileOK Basic Checker [XML]
1 <?xml version="1.0"?> 2 <powder xmlns="http://www.w3.org/2007/05/powder#"> 3 <attribution> 4 <issuedby src="http://www.example.com/company.rdf#me" /> 5 <issued>2008-06-25T00:00:00</issued> 6 <supportedby src="http://validator.w3.org/mobile/" /> 7 </attribution> 8 <dr> 9 <iriset> 10 <includehosts>example.com</includehosts> 11 </iriset> 12 <descriptorset> 13 <typeof src="http://www.w3.org/2008/06/mobileOK#conformant" /> 14 <displaytext>The example.com website conforms to mobileOK</displaytext> 15 <displayicon src="http://www.w3.org/ICONS/mobileOK.png" /> 16 </descriptorset> 17 </dr> 18 </powder>
The above example shows a POWDER document which contains information about who has made the claim, when the claim was made and, in this particular case, also lists a supporting link to the W3C mobileOK Checker. The Checker is used to test conformance.
Next the DR contains the resources to which this claim applies and the descriptors, both as typeof element, as well as offering text and an icon
The path to the W3C icon is not know at time of writing this document and has to be corrected
The editors gratefully acknowledge the substantial contributions made by: