Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
POWDER — the Protocol for Web Description Resources — provides a mechanism to describe and discover Web resources and helps the users to make a decision whether a given 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 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 working draft of this document. It was developed by the POWDER Working Group, which expects to maintain this Primer in draft status while the related POWDER documents are undergoing review and eventually publish the final version 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 an abbreviation for "Protocol for Web Description Resources." The goal of the working group has been to develop a mechanism that allows not only the provision of descriptions but also a way to apply them to groups of online resources and for the authentication of those descriptions.
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 encodes formal semantics that underpin the operational semantics.
There is a third, transitory version of POWDER, called POWDER-BASE, which is intended for processors and is not of concern for this document. A "Gleaning Resource Descriptions from Dialects of Languages" (GRDDL) transform, may automatically generate POWDER-S as RDF/OWL from a POWDER document. The details of this transformation are defined in the [FORMAL] document. XSLTs are available to support this. 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 should 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 can be answered using a Description Resource, without having to retrieve the resource itself.
The following are examples of questions that could be asked using POWDER:
The POWDER Suite consists of the following documents, in order of recommended reading
There are a variety of tools available to aid in the implementation of POWDER
Coming soon
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.
From an End User's Perspective, POWDER:
From a Publisher's Perspective, POWDER:
From a Service Provider's Perspective, POWDER:
Use Cases That Have Driven the Development of POWDER Include:
POWDER offers 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.
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 IRIs, through the specification of things like domain names and paths, to the matching of IRIs 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.
N.B. POWDER uses the term IRI (Internationalized Resource Identifier [IRI]). The more common term URI is a subset of IRIs, so that all URIs are also IRIs.
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 Description Resource. This makes information retrieval more efficient and precise by reducing network traffic 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.'
Furthermore a POWDER document can be used as a set of instructions that allow a crawler to follow up on all links, pointing to DR in POWDER documents, to automatically create a triple store about those resources. This could be used in conjunction with XML-based site maps to create triples by processing those site maps.
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 as compliant using a DR supported by a test result expressed in [EARL]. 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.
[Example: mobileOK]
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.
Additionally in that fashion a user may be informed that he will not be able to access said content because he is not a paying customer.
Sites can use Description Resources to communicate the subject matter of 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:
As an alternative, someone may want to draw inferences based on the data
contained in POWDER documents.
Drawing an inference means deriving implicit information from known facts.
For example:
Therefore that particular resource conforms to accessibility level AA.
In order to do so, the following steps should be followed.
Following the example above we could now determine which resources on example.com are AA conformant, as well as the conformance level of a given resource.
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>
Any descriptive vocabularies may be used which are identified by a namespace. The POWDER namespace is required.
The "ex" namespace used above is a fictitious example to denote that any namespace may be used.
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 points to details of the person or organization that
has published the POWDER 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, describing that individual or organization, 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 publisher's profile would look similar to 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. 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 all the IRIs in all the IRI sets.
In this case, the scope is 'everything on example.com'. 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 must 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 two ways of providing this.
A DR must contain at least one of either a descriptor set or tag set, none of
which may be empty. Subject to that condition, any number of tag sets and descriptor
sets may be included. The example DR states that in the opinion of the entity referenced
by 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 (including XML literals) 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 highlighted.
Generic Example of a POWDER Document Containing a Single Description Resource.
This is a repeat of Example 2-1 in the Description Resources document [DR]
<?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 than this simple example.
The following example uses an ordered list of DRs. In such a list 0 or 1, DRs will apply to a given resource. A processor will work through the list until the first match is found. This feature is designed to make it easy to add POWDER descriptions to existing content within established workflows. Effectively it enables a list of exception to be created, ending with the general case.
NOTE: The example below contains an abouthosts element which may be used by
a processor to decide if a list, perhaps a long list, need be processed at all.
Here we know that only resources on example.com are described in the ordered
list, however it is important to recognize that this does not guarantee that
all resources on example.com are described.
Example of a POWDER document which contains an ordered list
This is a repeat of from Example 2-6 in the Description Resources document [DR]
<?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>
The example above encodes the following assertion made by the entity described at http://authority.example.org/company.rdf#me: all web resources with paths on example.com that start with /foo are blue, all other resources on example.com are red.
POWDER offers other methods of defining the scope of DRs that are designed to increase flexibility. For example, it is possible for the scope of a DR to be the union of two or more IRI sets, meaning that an IRI that is a member of any IRI set is described. The following example describes resources that are available from example.com where the path starts with /foo AND those at example.org where the path starts with /bar.
Example of a POWDER document with two IRI sets
This is a repeat of Example 2-8 in the Description Resources document [DR]
<?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.
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="describedby" href="powder.xml" type="text/powder+xml"/>
The relationship type (rel) of "describedby" tells user agents that the file contains a description of the resource and the mime type tells it that it is a POWDER document. 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 is 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, if using an HTML version that supports it.
<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="describedby" href="powder.xml" type="text/powder+xml"/>
<title>Welcome to example.com </title>
</head>
<body>
<p>Today's content is ....</p>
</body>
</html>
Adding this makes the relationship type "describedby" 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="describedby"; type="text/powder+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 describedby relationship type is made available as an RDF property, where a more formal relationship between a POWDER document and a resource that it describes is required. This 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 includes hyperlinks to ring tones, images and videos.
An XHTML/RDFa Fragment with Hyperlinks described using POWDER
<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
<ol>
<dr>
<iriset>
<includehosts>example.com</includehosts>
<includepathcontains>/videos/</includepathcontains>
</iriset>
<tagset>
<tag>Large download</tag>
<label>Only suitable for download via high-bandwidth connections</label>
</tagset>
</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 large downloads. All other resources on example.com are conformant with mobileOK [MOK]. 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 point from the author's profile to information about how a user (or user agent) can verify
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. 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 or 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, can have little value 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 describe reflect Web resources in their 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. If a request is then made for this document, an HTTP 302 redirect can be used to point the requesting client to the actual, current POWDER document.
A further option would be querying a known repository of DRs. 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 standards compliance 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.
Personal collections of DRs may be traded or passed between users of social networks or other groupings of similar interests. Search engines' indexes may also contain references to publically available DRs.
In short, DRs are normal documents that may be discovered in all the usual ways that other documents are discovered on the Web.
A POWDER Processor accepts queries for descriptions of specific resources which it generates by reading POWDER documents and returning RDF triples. There is a minimal set of requirements for a conformant POWDER processor given in the Description Resources document [DR] where implementers are encouraged to go further than the minimum. A POWDER Processor may act as a gateway to a repository of DRs and use that as its only source of data, or it may be more generalized, accepting both the IRI to be described and one or more POWDER documents as the source from which to generate the description. The application environment will determine which factors are important but it is of course useful to think about usability, error trapping and potential extensions of its functionality.
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 matchesregex property. The extension is defined in
POWDER: Formal Semantics
Add more here once experiments with Pellet and/or Jena are completed
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.
POWDER-S is not be dealt with in great detail in this document since it is essentially an extension of RDF and OWL which are fully documented elsewhere. 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 Grouping specification [GROUP] 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 the Formal document [FORMAL] for details.
Generic example of a POWDER-S Document Containing a Single Description Resource
This is a repeat of Example 2-3 from the Description resources document [DR]
1 <?xml version="1.0"?> 2 <rdf:RDF 3 xmlns:wdrs="http://www.w3.org/2007/05/powder-s#" 4 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 5 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" 6 xmlns:owl="http://www.w3.org/2002/07/owl#" 7 xmlns:ex="http://example.org/vocab#"> 8 9 <owl:Ontology rdf:about=""> 10 <wdrs:issuedby rdf:resource="http://authority.example.org/company.rdf#me" /> 11 <wdrs:issued>2007-12-14T00:00:00</wdrs:issued> 12 </owl:Ontology> 13 14 <owl:Class rdf:nodeID="iriset_1"> 15 <owl:equivalentClass> 16 <owl:Class> 17 <owl:intersectionOf rdf:parseType="Collection"> 18 <owl:Restriction> 19 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" /> 20 <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com)(:([0-9]+))?\/</owl:hasValue> 21 </owl:Restriction> 22 </owl:intersectionOf> 23 </owl:Class> 24 </owl:equivalentClass> 25 </owl:Class> 26 27 <owl:Class rdf:nodeID="descriptorset_1"> 28 <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> 29 <rdfs:subClassOf> 30 <owl:Class> 31 <owl:intersectionOf rdf:parseType="Collection"> 32 <owl:Restriction> 33 <owl:onProperty rdf:resource="http://example.org/vocab#color" /> 34 <owl:hasValue>red</owl:hasValue> 35 </owl:Restriction> 36 <owl:Restriction> 37 <owl:onProperty rdf:resource="http://example.org/vocab#shape" /> 38 <owl:hasValue>square</owl:hasValue> 39 </owl:Restriction> 40 </owl:intersectionOf> 41 </owl:Class> 42 </rdfs:subClassOf> 43 <wdrs:text>Everything on example.com is red and square</wdrs:text> 44 <wdrs:logo rdf:resource="http://example.org/icon.png" /> 45 </owl:Class> 46 47 <rdf:Description rdf:nodeID="iriset_1"> 48 <rdfs:subClassOf rdf:nodeID="#descriptorset_1"/> 49 </rdf:Description> 50 51 </rdf:RDF>
Line-by-line explanation:
matchesregex property
which is only understood by software that implements the semantic extension which confers membership of the class on resources whose IRIs
match the given regular expression(s).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 [XML]
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="describedby" href="/powder.xml" type="text/powder+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="describedby";
type="text/powder+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/2005/11/MWI-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. In Semantic Web terms, the typeof element is a shorthand for rdf:type and asserts that all
resources on example.com are instances of the mobileOK Class. Descriptive text and an icon are also provided.
The editor gratefully acknowledges the substantial contributions made by: