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
reaching 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 simplified version called POWDER which is intended for
day-to-day usage.
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 document is a W3C First Public Working Draft published by the POWDER Working Group.
It is a companion document to
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.
The group does not expect this document to become a W3C Recommendation. The Working Group intends to advance the associated documents to W3C Recommendation after further review and comment. The Working Group expects to revise this Primer while the other documents are undergoing review and eventually publish the Primer as a Working Group Note.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. 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 was to develop a mechanism that allows not only the provision How does POWDER work in the real world?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.
POWDER therefore is a new generation of meta information that actually combines some of the best features of existing meta information mechanisms, like meta elements, Dublin Core and FOAF enriched by RDF/OWL properties.
There are two varieties of POWDER, a complex, semantically rich variety,
called POWDER-S and a simplified version.
The simplified version, also called the operational semantics, is written in
XML for easy day to day use.
The formal semantics, POWDER-S, are intended to provide mechanism to harness
the semantic web and underpin the operational semantics. A GRRDL transform
will create the needed RDF/XML for this use.
There is no restriction on which form to use, but it should be noted that the
simplified version is intended for the exchange of information between
systems.
The POWDER-S version is designed to facilitate incorporation of POWDER
information in larger RDF based systems.
Thus POWDER allows a variety of questions to be answered about a given web resource or group thereof, without having to actually retrieve the resource.
In the first step a web description resource is nothing but a claim. Somebody is making some statement about a given resource. However, the average user would have to trust that claim before making the decision to retrieve the resource itself. This might be perfectly acceptable in the case of a respectable content provider who is expected to uphold a certain quality. For unknown sources of web resources this might not be readily accepted by the end user. Thus a means has been provided to allow certification of web description resources.
A certified web description resource immediately, through the involvement of a third and trusted party, gains in trust, in so far that the third party verifies the claim made by the web description author.
Through the combination of these tools various questions, not limited to the following, can be answered through a web description resource, without having to retrieve the resource itself:
The following documents should be read to understand the nature of POWDER
Additional information may be found in
The amount of information on the Internet has increased exponentially since the Web’s inception approximately 20 years ago. Conversely, the amount of time people have to seems to be decreasing. Based on these factors, too much information + too little time, would lead people to gravitate to 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 theoretically limits the information provided to only what 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 onerous 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.
One of the most powerful overarching features of POWDER and has been unresolved challenge, up until now. POWDER allows you to offer semantically rich information about online resources in entire groups. This feature allows for both flexibility and precision. The ability to have information assessed within one document many pages at a time. In addition, maintenance of such web description resources becomes simplified by the nature of the centralized approach of maintaining many descriptions in potentially a single document.
The methods for grouping documents range from the individual listing of URI, over properties to the full use of regular expression, allowing for the creation of precise resource groups. Requesters such as user or even automated retrieval systems can analyze the data and act upon it.
Previously meta information was always linked to a single resource and usually embedded within, as is the case, for example, with the META element and the attributes used by the author.
This meant a resource would have to be retrieved in full to then determine if it is of interest or not.
Web description resources describe 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 would make information retrieval more efficient and precise.
You may want to engage in profile matching and enable users to retrieve resources according to user preferences, device capabilities and current state at the time of content delivery.
The use cases found in Use Cases and Requirements 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.
Description Resources facilitate this decision by making available rules about groups of Web resources to a Web Server. At request time the Web Server can determine if there are any rules in the description resource which apply to the requested URI, and respond to the user accordingly.
Online resources and description resources 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 web description resources. Other partners may be repositories of thematically linked URIs, such as white lists for web sites suitable for children.
There are several possible models in which assertions and claims can be made, authenticated and reported to the end user. We have listed several use cases which have several elements in common but differ in details such as whether it is the content provider or the trust mark operator that makes the original claim, whether the data is stored on the trust mark operator's servers or alongside the content itself, and whether the trust mark operator provides the description or the authentication for a description.
There is a potential benefit of web description resources 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 change its effect on users based on the context in which such information is retrieved. For example, nudity on a medical website dealing breast cancer may be fully appropriate if it is known prior to retrieval what the context of the content is. Discriminating content, offered for analysis purposes can be defused by provided further contextual information. Information can also be placed in context to each other such that a search for Madonna, with a musical context would not retrieve information on religious paintings.
Some information may, in general, fit a certain set of parameters, but may in single instances diverge. Such divergences can be described in detail in web description resources to facilitate a retrieval decision.
In summary POWDER provides a means to enable requesters to make more educated decisions about whether to retrieve a given resource or not.
You have just reviewed 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 an application would work.
POWDER offers various possible methods by which trust claims and assertions can be made.
User A could install a browser plug-in designed to provide a visual indication of whether a web site is trustworthy or not. The plug-in would rely on various source such as reputation and accreditation services to make the determination of trustworthiness.
This can be particularly valuable in cases where certain sites are required by law or other regulation to provide a certain level of content or access. Once those site have been approved and tagged as having met specific standards, an automated mechanism can be created to crawl those sites and review the sites label as well as the data for continued authenticity and validity. This could go as far as generating a report for the evaluating party.
This is a simple example of a web site operator submitting their work in to a pertinent trust organization that can authenticate the work and provide a description tag that identifies the site as accurate or trustworthy.
Search engines can be enabled to provide customized results for users who prioritize compliance with particular checks. In this example, an organization that reviews web sites and determines their level of compliance with Accessibility guidelines. The web sites are duly tagged with the results. The search engine can then surface the best sites based on a user’s preference settings and the tags on the reviewed web sites. Search engine would surface the sites that best facilitate keyboard navigation (based on the guidelines) to someone who has limited dexterity. The sites may surface differently for someone who is visually impaired.
User A wants to search content using his mobile phone. He wants MobileOK results only so he checks that box on the search page. The search engine retrieves a set of sets from its index and after determining which of those have an associated descriptor, discards all the others. Based on those descriptors, the search engine only surfaces those described as being MobileOK.
Online child protection, as well as the perpetuation of child protection, is a priority for any responsible site or service provider, whether directed at children or not.
A service provider would have 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, would have their content accurately described as either being child appropriate or intended just for adults. In the case of large online retailer, while most of their content and products are appropriate for all ages, there are also numerous pages of “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 those in the adult category.
Pages and ultimately sites containing any type of rich assets such as video/streaming video or audio can be tagged with that information. A search engine would be able to determine if a user is doing a search via a lower bandwidth connection and return only those pages that contain assets and images that will be supported by that user’s connection speed.
User A pays a premium at any given ISP in order to have privileged access to various other premium web sites, as a premium member of those sites. When user A access one of these premium web sites via his ISP, the server of that site determines that user A is a premium member of their site based on his ISPs identity management system, which has this user tagged as premium member.
Sites can use Description Resources to more accurately and relevantly communicate their content.
Because the same term can actually 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 accurate enough
for his content so that someone from the US searching on the term
“football” receives the portions of the content relating to American
football and if someone from the UK searches on the same term they
actually get content relating to soccer.
By developing an appropriate and detailed vocabulary, Description Resources can be used to identify the value of a sites as being either historically accurate and acceptable as fact or whether it is just a common ideology but no defensible historically.
The easiest way to create a DR is to write an XML document which contains something like the following example, of course adapted to the resources in question.
Generic Example of a POWDER Document Containing a Single Description
Resource [XML]
0 <?xml version="1.0"?> 1 <powder xmlns="http://www.w3.org/2007/05/powder#" xmlns:ex="http://example.org/vocab#"> 2 <attribution> 3 <maker>http://authority.example.org/foaf.rdf#me</maker> 4 <issued>2007-12-14</issued> 5 </attribution> 6 <dr> 7 <iriset> 8 <includehosts>example.com</includehosts> 9 </iriset> 10 <descriptorset> 11 <ex:color>red</ex:color> 12 <ex:shape>square</ex:shape> 13 <displaytext>Everything on example.com is red and square</displaytext> 14 <displayicon>http://authority.example.org/icon.png</displayicon> 15 </descriptorset> 16 </dr> 17 </powder>
Explanation:
Line 1:
All POWDER documents have the root element of powder. The ex namespace is
used to exemplify a descriptive vocabulary and is fictitious.
Lines 2 - 8:
All POWDER documents MUST have exactly one attribution element. This contains
the information about who has provided the description, and typically will
also include information about when it was created and any validity period.
Line 3:
The maker element MUST be included. This is interpreted by the POWDER GRDDL
Transform as the following triple: <> foaf:maker
http://authority.example.org/foaf.rdf#me. Since the range of foaf:maker is
foaf:Agent, it follows that the IRI given in the maker element MUST resolve
to an RDF Class (or sub class) of that type (which describes a person or an
organization). The issued element within the attribution element (line 4) is
optional and maps to dcterms:issued. The validfrom and validuntil elements
discussed in Section 4.2 may be included in the attribution element, as can
arbitrary RDF properties that describe the POWDER document. However, these
MUST have values that are either literal or are resources identified by a
URIref (using the ref="URIref" construct). In POWDER-S documents these are
encoded as rdf:resource="URIRef".
Lines 6 - 16:
This particular POWDER document contains a single Description Resource.
Lines 7 - 9:
The scope of the DR — i.e. what is described — is defined as set out in
the Grouping of Resources document [GROUP]. In this case, the scope is
'everything on example.org' or, more formally, the set of IRIs that have a
host whose last two components are example.org. All Description Resources
MUST contain an iriset element and, as described in the Grouping document,
this MUST NOT be empty and MUST NOT contain any elements from any other
namespace.
Lines 10 - 15:
The description itself. Unless a tagset is included (see section 2.7), a DR
MUST contain exactly one descriptorset element that MUST NOT be empty and MAY
contain arbitrary RDF/XML that describes the IRIs in the IRI set with the
proviso that, like the attribution element, such RDF/XML MUST have values
that are either literal or are resources identified by a URIref. As shown in
lines 13 and 14, a textual and/or graphic summary that can be displayed to
end users may be included. The GRDDL transform maps these to dc:description
and foaf:depiction respectively.
Publishing a DR is a two step process.
1. the DR must be created
2. the resources must have some form of reference to the DR that describes the resource in question.
A described resource may relate itself to a POWDER document. There are two methods to define such a relationship, detailed below.
1. (X)HTML link Elements
Example: using the link element to relate an XHTML document to a DR [HTML]
<html xmlns="http://www.w3.org/1999/xhtml">
<head profile="http://www.w3.org/2007/11/powder-profile">
<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>
2. Semantic Linkage Using the describedby Property
<html
xmlns="http://www.w3.org/1999/xhtml"
xmlns:wdr="http://www.w3.org/2007/05/powder#">
<head>
<title>The English Civil War</title>
<link rel="wdr:describedby" href="http://ecw.example.org/powder1.xml" />
</head>
<body>
…
<p>Charles I came to the throne believing in his
<a href="http://monarchy.example.org/divine_right.html">Divine Right</a> to rule...
…
</body>
</html>
There is a third method currently under discussion, which is that of the HTTP Link Header.
The HTTP Link Header may be re-instated as decsribed in Mark Nottingham's draft (or for the equivalent functionality to be made available in some other fashion). This would allow an agent to discover a POWDER document associated with a given resource using an HTTP HEAD request, i.e. without actually having to fetch and parse the document.
The easiest way would be to follow the link in the document or HTTP header. There may also be trusted third parties that maintain repositories of such DRs, shared tags, personal collections of links or DRs themselves.
Since DRs are simple, publically accessible documents they may be found by similar means as any other documents of this nature.
POWDER is the most commonly used form. Since it is written in XML and simple in structure it is easy to use even through users who are not very XML savvy.
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.
POWDER-S is the semantically rich form of POWDER and would be used when web resources need to be placed into relation to each other. One of the most common use cases is that of semantic web searches, where the search results need to be adjusted to fit more closely to the user's need.
### explain the components of a DR here, explain use of
Xpath, GREP scripts, javascript, validation of the DR, XSLT
Note: I could use some text here by someone who can explain this well (I
can't :-)
Note: Somebody please check the following for correctness...
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 decisison 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 properites as International Resouce Identifiers (IRI). In other words the string "http://example.org" is not necessarly recognized as the web address (IRI) http://example.org.
To allow this to happen a semantic extension has to be created that makes this definiton 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
validfromand
validuntilThese termporal 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 be conflict, which requires a second extention to RDF/OWL, which is defined in the document POWDER: Description Resources
Progess to this point at last F2F in London
The requirements to use POWDER are rather small.
You need the possibility to point from your web resource to a web description resource.
The precise form of this pointer is currently under discussion and will be either a <link> element in the document header or a HTTP response header. Depending on the variety used you will need to edit the HTTP header or insert a <link> element into the source code of your online resource.
Another method, for semantically rich environments exists as well, but does not require any special knowledge beyond what is described here.
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: using a HTTP response header to relate to a DR
<http://www.example.com/exampleDR.rdf> rel="powder"
No special knowledge is needed to understand POWDER.
You will need a working knowledge of
in order to use POWDER-S fully, however the examples provided in the documents should be sufficient to begin using POWDER with only rudimentary knowledge of markup languages.
You will need access to a location accessible by the intended audience of web description in order to store web description resources there.
This may be the same location as the web resources themselves.
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 snippet using wdr:describedBy
<html xmlns:wdr="http://www.w3.org/2007/05/powder#">
<head>
<title>The English Civil War
</title>
</head>
<body>
...
<div>
<link rel="wdr:describedBy" href="http://education.example.org/powder.rdf#DR_1" />
<p>Charles I came to the throne believing in his Divine Right to
rule...
</div>
...
</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. What does
it look like?
Example: Generic Example of a Description Resource
1 <owl:Class rdf:ID="ResourceOnExampleDotOrg"> 2 <owl:equivalentClass> 3 <owl:Class> 4 <rdfs:subClassOf> 5 <owl:Restriction> 6 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#includeHost" /> 7 <owl:hasValue>example.org</owl:hasValue> 8 </owl:Restriction> 9 </rdfs:subClassOf> 10 </owl:Class> 11 </owl:equivalentClass> 12 </owl:Class> 13 <owl:Class rdf:ID="BlueResource"> 14 <rdfs:comment>The set of all things that are blue</rdfs:comment> 15 <rdfs:subClassOf> 16 <owl:Restriction> 17 <owl:onProperty rdf:resource="http://colour.example#hue"/> 18 <owl:hasValue>blue</owl:hasValue> 19 </owl:Restriction> 20 </rdfs:subClassOf> 21 </owl:Class> 22 <rdf:Description rdf:about="#ResourceOnExampleDotOrg"> 23 <rdfs:subClassOf rdf:resource="#BlueResource" rdf:ID="assertion1" /> 24 </rdf:Description> 25 <rdf:Description rdf:about="#assertion1"> 26 <foaf:maker rdf:resource="http://www.example.com/foaf.rdf#david" /> 27 <dcterms:issued>2007-11-27</dcterms:issued> 28 <wdr:validUntil>2008-11-26</wdr:validUntil> 29 <dc:description>David says everything on example.org is blue!</dc:description> 30 </rdf:Description>The concept of a web description resource includes a description, a definition of the scope of the description and assertions about its own creation. When encoded in RDF/OWL this translates into 4 components: *The Resource Class (lines 1-12). In this section the body of online resource for which the description applies is defined - the scope. *The Descriptive Class (lines 13 - 21) Here resource is described via properties *The assertion that the Resource Class is a sub class of the Descriptive Class (line 23). This section determines the dependencies of various groupings to each other, in this case making one the subset of the other. *Attribution - the sub class assertion is attributed to a named entity (lines 25 - 30) In this section an assertion is made about the data within the scope.
The editors gratefully acknowledge contributions from:
@@ TODO @@
Check Primer for technical correctness