Abstract
The purpose of the Protocol for Web Description Resources (POWDER) is to provide a means for individuals or organizations to describe a
group of resources through the publication of machine-readable metadata, as motivated by the POWDER Use Cases [USECASES].
This document details the creation and lifecycle of Description Resources (DRs), which encapsulate such metadata. These are typically
represented in a highly constrained XML dialect that is relatively human-readble. The meaning of such DRs are
underpinned by formal semantics, accessible by performing a GRDDL Transform.
Status of this document
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 Public Working Draft, designed to aid discussion and solicit feedback. Changes since earlier versions
of this document are recorded in the change log but it should be noted that this
version represents a substantial change since the
First Public Working Draft. Further changes are
likely to be much less significant. Please note that this draft includes a feature at risk
concerning the representation of the formal POWDER semantics. Minor revisions and corrections to this document
are to be expected in the near future.
This document was developed by the POWDER Working Group which expects to advance this Working
Draft to Recommendation Status.
Please send comments about this document to public-powderwg@w3.org (with public archive).
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.
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.
Table of Contents
1 Introduction
The Protocol for Web Description Resources (POWDER) facilitates the publication of descriptions of multiple resources such
as all those available from a Web site. These descriptions are always attributed to a named individual, organization or entity that
may or may not be the creator of the described resources. This contrasts with more usual metadata that typically applies to a
single resource, such as a specific document's title, which is usually provided by its author.
This document sets out how Description Resources (DRs) can be created and published, whether individually or as bulk data,
how to link to DRs from other online resources, and, crucially, how DRs may be authenticated and trusted. The aim is to provide a platform
through which opinions, claims and assertions about online resources can be expressed by people and exchanged by machines.
POWDER has evolved from the data model developed for the final report [XGR] of the Web Content Label Incubator
Group [WCL-XG] from which we define a Description Resource as: "a resource that contains a description,
a definition of the scope of the description and assertions about both the circumstances of its own creation and the entity
that created it."
The method of defining the scope of a DR, that is, defining what is being described, is provided in a separate document: Grouping
of Resources [GROUP]. Companion documents describe the RDF/OWL vocabulary [VOC]
and XML data types [WDRD] that are derived from the Grouping of Resources document and this document, with each term's
domain, range and constraints defined. As each term is introduced in this document, it is linked to its description in the vocabulary document.
A Primer and Test Suite complete the document set.
Clean up the usage of 'XML element' and 'RDF vocabulary terms' throughout this doc. We use the
same string for both but they're not the same species…
POWDER takes a very broad approach so that it is possible for both the resource creator and third parties to make assertions
about all kinds of things, with no architectural limits on the kind of thing they are making claims about. For example, medically
proficient organizations might be concerned with properties of the agencies and processes that produce Web content (e.g.
companies, people, and their credentials). Equally, a 'Mobile Web' application might need to determine the properties of various
devices such as their screen dimensions, and those device types might be described with such properties by their manufacturer or
by others. Although the broad approach is supported, we have focused on Web resources rather than trying to define a universal
labeling system for objects. In practice, POWDER associates a description with one or more IRIs [IRI] that must then be interpreted as being
descriptions of the resources resolved from those IRIs.
For indicative examples of POWDER usage, please refer to the use cases
The Protocol for Web Description Resources has been designed with a variety of content production workflows in mind.
It offers a practical contribution to such areas as content discovery, personalization and access control; one that
can be implemented readily by non-specialists. There is, however, a tension between this operational approach and the
broader goal of making the data available in a format that can be processed on the Semantic Web. By making data from
potentially disparate sources interoperable, and by enabling machines to process the meaning of that data, the Semantic
Web offers exciting possibilities in precisely the areas of interest to POWDER.
The tension between what can be processed by humans and what can be processed by machines is resolved by defining both operational and formal semantics of
Description Resources, and by bridging the two by way of a GRDDL transform that is associated with the root
POWDER namespace. POWDER documents are written in a highly constrained dialect of XML that may also include RDF/XML constructs within some elements. Such
documents may be processed directly in specialized systems, however, for more general environments, the semantics are underpinned
by the formal semantics of the output of the GRDDL transform. In addition to applying the transform (which uses XSLT), semantic
applications must also take note of two Semantic Extensions, one defined in the Grouping of Resources document [GROUP] and the other
in section 4.2 of this document.
1.2 Namespaces and Terminology.
The POWDER vocabulary namespace is http://www.w3.org/2007/05/powder# for which we use the prefix wdr. This and the other
prefixes used in this document, together with their associated namespaces, are shown in the table below.
| Prefix | Namespace |
|---|
wdr | http://www.w3.org/2007/05/powder# |
rdf | http://www.w3.org/1999/02/22-rdf-syntax-ns# |
rdfs | http://www.w3.org/2000/01/rdf-schema#" |
owl | http://www.w3.org/2002/07/owl# |
foaf | http://xmlns.com/foaf/0.1/ |
dc | http://purl.org/dc/elements/1.1/ |
dcterms | http://purl.org/dc/terms/ |
xsd | http://www.w3.org/TR/xmlschema-2/ |
In this document, the words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are to be interpreted as described in
RFC2119.
White space is any of U+0009, U+000A, U+000D and U+0020. A space-separated list is a string of
which the items are separated by one or more space characters (in any order). The string may also be
prefixed or suffixed with zero or more of those characters. To obtain the values from a space-separated list
user agents MUST replace any sequence of space characters with a single U+0020 character, dropping any
leading or trailing U+0020 character, and then chopping the resulting string at each occurrence of a U+0020 character,
dropping that character in the process.
The (unqualified) terms POWDER, POWDER Document and Description Resource (DR) refer to operational representations and semantics. The terms POWDER-S
and DR-S refer to documents and data that express the formal semantics of POWDER.
2 POWDER Structure and Semantics
2.1 Operational Semantics
The following example statement:
On 14th December 2007, authority.example.org said that everything on example.com is red and square.
is encoded in POWDER as shown in the example below which is followed by explanatory notes.
Example 2-1: Generic Example of a POWDER Document Containing a Single Description Resource [XML]
<?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.
Operationally, a processor should begin the examination of a POWDER document by considering the attribution element which, if
valid in the XML-sense of the term, will be present and contain a maker element.
This element is mandatory as, for most people, deciding whether to trust a given description is typically most dependent on answering the question
"who says?" If the IRI in the maker element points to a trusted individual or entity, the descriptions provided in the remainder of
the document will usually be trusted, subject to the integrity-checking mechanisms discussed in section 4.
If the processor decides to confer its trust in the document, then the remainder of the data can be processed, either in an entirely
operational manner or by performing the GRDDL transform associated with the POWDER namespace and merging the resulting RDF graph
(see section 2.2 below).
Either way, example 2-1 means that the processor can be confident that any resource identified by an IRI with a host having 'example.com' as
its last two components will be red and square. Conversely, an agent seeking resources that are red and square will trust example.com to
provide them.
User agents MAY display the text and/or icon to end users in any way deemed appropriate.
A POWDER document may contain any number of DRs, each describing its own IRI set, each of which will be attributed to the same person or entity.
Where those IRI sets overlap, the decriptions are additive. In Example 2-2 below, the opinion of the entity or person described by
http://authority.example.org/foaf.rdf#me is that everything on example.com is red; IRIs on example.com where the path starts with /foo resolve to
resources that are BOTH red AND square.
Example 2-2: Generic Example of a POWDER Document Containing Multiple Description Resources [XML]
<?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 </attribution>
5 <dr>
6 <iriset>
7 <includehosts>example.com</includehosts>
8 </iriset>
9 <descriptorset>
10 <ex:color>red</ex:color>
11 </descriptorset>
12 </dr>
13 <dr>
14 <iriset>
15 <includehosts>example.com</includehosts>
16 <includepathstartswith>/foo</includepathstartswith>
17 </iriset>
18 <descriptorset>
19 <ex:shape>square</ex:shape>
20 </descriptorset>
21 </dr>
21 </powder>
It is possible to create sets of Description Resources that are exclusive, i.e. where only one of a given list applies, as detailed in
Section 2.3. Other variations on the basic POWDER model set out in the preceeding examples are discussed in later sections of this document.
2.2 Formal Semantics
The operational semantics of POWDER, as defined above, are underpinned by more formal semantics. A GRDDL Transformation (which uses XSLT)
is associated with the POWDER namespace. When the trasformation is performed on a POWDER document, a Semantic POWDER document (POWDER-S) is
its output. The attribution information in the source document is encoded as a description of the POWDER-S document, and both the
IRI set and descriptor set are represented as OWL classes. A sub class relationship is then asserted between the two from which it can be
deduced that all instances of the IRI set are also instances of the descriptor set.
All POWDER-S documents are valid RDF/OWL documents, however, logical inferences may only be drawn by applications that implement the
semantic extensions defined in the Grouping of Resources document [GROUP] and in section 4.2 of this document.
Example 2-3: Generic example of a POWDER-S Document Dontaining a Single Description Resource [RDF/XML]
This is the result of the GRDDL trasform performed on example 2-1
1 <?xml version="1.0"?>
2 <rdf:RDF
3 xmlns:wdr="http://www.w3.org/2007/05/powder#"
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 <rdf:Description rdf:about="">
13 <foaf:maker rdf:resource="http://authority.example.org/foaf.rdf#me" />
14 <dcterms:issued>2007-12-14</dcterms:issued>
15 </rdf:Description>
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#includehosts" />
21 <owl:hasValue>example.com</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:Restriction>
42 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#hasIRI"/>
43 <owl:someValuesFrom rdf:nodeID="iriset_1"/>
44 <rdfs:subClassOf rdf:nodeID="descriptorset_1"/>
45 </owl:Restriction>
46
47 </rdf:RDF>
It is anticipated that POWDER-S documents will typically be generated by performing the GRDDL transform associated with
POWDER after validity and trust has been conferred on the input document. However, a POWDER-S document may be created independently in
which case the question of trust remains open.
If trust is conferred on a POWDER-S document directly, or is inherited from the POWDER document that was transformed to
generate it, then the graph can be merged with other graphs available to the processor.
The properties of the IRI set class (lines 17 - 24) draws on a @@@ semantic extension @@@, defined in the Grouping of
Resources document. This defines a property hasIRI that maps a string to an IRI. In similar fashion, string values
for properties like includehosts are mapped to particular components of an IRI. If these extensions are not
understood, a generic RDF/OWL tool will not be able to ascribe any meaning to the properties of the IRI set class.
The hasIRI property is used directly in line 42. Between lines 41 and 45, OWL constructs are used to
assert that all instances of the IRI set Class are also instances of the descriptor set Class.
The WG wishes to flag this as a Feature at Risk.
An alternative approach would be not to assert the sub class relationship and leave it to POWDER processors to infer it.
Given the text above concerning trust, it is believed that asserting the relationship is the right thing to do, however, we recognise
that this does mean publishing a relationship that will outlast any validuntil date that may be included.
Notice that nodeIDs are used to identify the IRI set and descriptor set classes meaning that they cannot be referenced by external documents.
This is deliberate and ensures that further properties cannot be added that might render the assertions made the POWDER document author incorrect.
The descriptor set class is pure RDF/OWL and is effectively a re-expression of the descriptorset element in a POWDER document with
full semantics. Lines 26 - 39 of example 2-3 are derived directly from example 2-1 lines 10 - 15.
2.3 Exclusive Description Resources
As noted in section 2.1, a POWDER document may contain any number of DRs. These may offer overlapping descriptions of the
same resources. It is often the case though that a description of one set of resources must not be applied to other
resources on the same Web site.
A modified version of example 2-2 is shown below as example 2-4. All that has changed is that the property in line 19,
part of the second DR, is now the same as that in line 10 which is part of the first DR — but with a different value.
Taken together, the two DRs state that in the opinion of the person or entity described at http://authority.example.org/foaf.rdf#me,
all resources on example.com are red, but that those on example.com where the path starts with /foo are BOTH red AND blue.
Example 2-4: A POWDER Document Containing Conflicting Description Resources [XML]
<?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 </attribution>
5 <dr>
6 <iriset>
7 <includehosts>example.com</includehosts>
8 </iriset>
9 <descriptorset>
10 <ex:color>red</ex:color>
11 </descriptorset>
12 </dr>
13 <dr>
14 <iriset>
15 <includehosts>example.com</includehosts>
16 <includepathstartswith>/foo</includepathstartswith>
17 </iriset>
18 <descriptorset>
19 <ex:color>blue</ex:color>
20 </descriptorset>
21 </dr>
21 </powder>
One way to avoid this paradox would be to add an extra definition to the first IRI set that excluded IRIs beginning with /foo as shown in example 2-5
thus creating two DRs with scopes that are disjoint.
Example 2-5: A POWDER Document Containing Disjoint Description Resources [XML]
<?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 </attribution>
5 <dr>
6 <iriset>
7 <includehosts>example.com</includehosts>
8 <excludepathstartswith>/foo</excludepathstartswith>
9 </iriset>
10 <descriptorset>
11 <ex:color>red</ex:color>
12 </descriptorset>
13 </dr>
14 <dr>
15 <iriset>
16 <includehosts>example.com</includehosts>
17 <includepathstartswith>/foo</includepathstartswith>
18 </iriset>
19 <descriptorset>
20 <ex:color>blue</ex:color>
21 </descriptorset>
22 </dr>
23 </powder>
POWDER supports this structure, however, in a commercial content production environment it can be impractical to keep track
of which exclusions should be written into which IRI sets, even with the aid of tools. This is particularly so where content
is being produced in multiple departments or bought in from multiple suppliers. In such situations, the more typical need, and the more natural way of
working, is to create a description that applies to all content on a given Web site except where indicated.
For this reason, POWDER uses the concept of an ordered list to create a set of DRs, only one of which applies to a given IRI.
Example 2-6: A POWDER Document Containing an Ordered List of Description Resources [XML]
1 <?xml version="1.0"?>
2 <powder xmlns="http://www.w3.org/2007/05/powder#"
xmlns:ex="http://example.org/vocab#">
3 <attribution>
4 <maker>http://authority.example.org/foaf.rdf#me</maker>
5 <abouthosts>example.com</abouthosts>
6 </attribution>
7 <ol>
8 <dr>
9 <iriset>
10 <includehosts>example.com</includehosts>
11 <includepathstartswith>/foo</includepathstartswith>
12 </iriset>
13 <descriptorset>
14 <ex:color>blue</ex:color>
15 </descriptorset>
16 </dr>
17 <dr>
18 <iriset>
19 <includehosts>example.com</includehosts>
20 </iriset>
21 <descriptorset>
22 <ex:color>red</ex:color>
23 </descriptorset>
24 </dr>
25 </ol>
26 </powder>
In the POWDER namespace, the ol tag indicates an ordered list of Description Resources. If a given IRI is within the scope of the
first DR in the list, then that DR applies, if not, move on to the second DR and see if the given IRI is within its scope and so on
until either a match is made or the end of the list is reached. As such, it is important to place any exclusions before other DRs that include that
resource in their scope, or else the exclusion will never be matched. An IRI can only be described by 0 or 1 DRs from an ordered list.
The first DR in the list in example 2-6 covers resources on example.com with a path starting with /foo and describes them as being blue.
Any resource available from example.com that does not have a path starting with /foo is described as being red. Further DRs may be added to
the list without the need to edit either of the existing DRs, although order may be important. This would be the case, if, for instance,
resources available from example.com with a path starting with /foo and a query string containing material=natural were green. Such a DR
would need to go above the first one in the example.
It is noteworthy that if the content provider at example.com wishes to link to this document, he/she can arrange for
all resources to include exactly the same pointer — the POWDER document contains all the necessary information to
discover how the red and blue resources are arranged. Linkage is discussed in more detail in section 3. Moreover, the
dispositon of content with different characteristic across a given Web site or set of Web sites can be discovered by processing the
one document. If processed alongside a site map, this becomes a powerful content discovery mechanism.
In order to minimize the processing of a sequence of DRs like this, we introduce the abouthosts element in line 3.
This takes a white space separated list of hosts and can be included in the attribution element of any POWDER document, whether it
contains an ordered list of DRs or not.
As defined in the vocabulary document [VOC], if the host component of a given IRI is included in the list
given as the value for the abouthosts element, then the POWDER document may, but is not guaranteed to, contain a
description of that IRI. If the host component of a given IRI is not included in the list given as the value for
the abouthosts element, then the processor MUST assume that the POWDER document does not contain a description of that IRI.
From a discovery point of view, it provides an efficient method of hinting at where to find the resources that match the given description(s).
The abouthosts element is discussed further in section 2.5.
POWDER-S does not support ordered lists and each DR is self contained. The GRDDL output of example 2-6 is shown in example 2-7.
Example 2-7: The POWDER-S Document Derived From Example 2-6 [RDF/XML]
1 <?xml version="1.0"?>
2 <rdf:RDF
3 xmlns:wdr="http://www.w3.org/2007/05/powder#"
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 <rdf:Description rdf:about="">
13 <foaf:maker rdf:resource="http://authority.example.org/foaf.rdf#me" />
14 <wdr:abouthosts>example.org</wdr:abouthosts>
15 </rdf:Description>
16
17 <owl:Class 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#includehosts" />
21 <owl:hasValue>example.com</owl:hasValue>
22 </owl:Restriction>
23 <owl:Class>
24 <owl:complementof rdf:resource="#iriset_2" />
25 </owl:Class>
26 </owl:intersectionOf>
27 </owl:Class>
28
29 <owl:Class rdf:nodeID="descriptorset_1">
30 <owl:intersectionOf rdf:parseType="Collection">
31 <owl:Restriction>
32 <owl:onProperty rdf:resource="http://example.org/vocab#color" />
33 <owl:hasValue>red</owl:hasValue>
34 </owl:Restriction>
35 </owl:intersectionOf>
36 </owl:Class>
37
38 <owl:Restriction>
39 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#hasIRI"/>
40 <owl:someValuesFrom rdf:nodeID="iriset_1"/>
41 <rdfs:subClassOf rdf:nodeID="descriptorset_1"/>
42 </owl:Restriction>
43
44 <owl:Class rdf:nodeID="iriset_2">
45 <owl:intersectionOf rdf:parseType="Collection">
46 <owl:Restriction>
47 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#includehosts" />
48 <owl:hasValue>example.com</owl:hasValue>
49 </owl:Restriction>
50 <owl:Restriction>
51 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#includepathStartswith" />
52 <owl:hasValue>/foo</owl:hasValue>
53 </owl:Restriction>
54 </owl:intersectionOf>
55 </owl:Class>
56
57 <owl:Class rdf:nodeID="descriptorset_2">
58 <owl:intersectionOf rdf:parseType="Collection">
59 <owl:Restriction>
60 <owl:onProperty rdf:resource="http://example.org/vocab#color" />
61 <owl:hasValue>blue</owl:hasValue>
62 </owl:Restriction>
63 </owl:intersectionOf>
64 </owl:Class>
65
66 <owl:Restriction>
67 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#hasIRI"/>
68 <owl:someValuesFrom rdf:nodeID="iriset_2"/>
69 <rdfs:subClassOf rdf:nodeID="descriptorset_2"/>
70 </owl:Restriction>
71
72 </rdf:RDF>
2.4 Multiple DRs With Different Attribution
As was made clear in section 2.1, the attribution element is mandatory in all POWDER documents. This is designed to allow users
and their tools to confer trust on the data. There may be situations where multiple DRs describe the same or overlapping IRI sets
but with different attribution data. For example, a Web site might be described by more than one third party, each with a different area
of expertise. In this situation, it is useful to cross-reference the Description Resources using the ref
attribute to facilitate easy discovery as shown in example 2-8 below. The value of ref is xsd:anyURI.
Example 2-8: Two POWDER Documents That Reference Each Other
powder1.xml [XML]
1 <?xml version="1.0"?>
2 <powder xmlns="http://www.w3.org/2007/05/powder#"
3 xmlns:palette="http://color.example.org/vocab#"
4 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
5 <attribution>
6 <maker>http://color.example.org/foaf.rdf#me</maker>
7 </attribution>
8 <dr xml:id="red">
9 <iriset>
10 <includehosts>example.com</includehosts>
11 </iriset>
12 <descriptorset>
13 <palette:color>red</palette:color>
14 </descriptorset>
15 </dr>
16 <dr ref="http://example.com/powder2.xml#square" />
17 </powder>
powder2.xml [XML]
1 <?xml version="1.0"?>
2 <powder xmlns="http://www.w3.org/2007/05/powder#"
3 xmlns:geometry="http://shape.example.org/vocab#"
4 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
5 <attribution>
6 <maker>http://shape.example.org/foaf.rdf#me</maker>
7 </attribution>
8 <dr xml:id="square">
9 <iriset>
10 <includehosts>example.com</includehosts>
11 </iriset>
12 <descriptorset>
13 <geometry:shape>square</geometry:shape>
14 </descriptorset>
15 </dr>
16 <dr ref="http://example.com/powder1.xml#red" />
17 </powder>
One might imagine that the person or entity described by http://color.example.org/foaf.rdf#me is
qualified to make pronouncements about the color of a given resource, whereas geometric analysis is better carried out by the person or entity
described by http://shape.example.org/foaf.rdf#me. Since attribution applies to all data within a POWDER document, assertions made by
shape.example.org must be encoded in a separate document. However, to aid discovery, the two documents can link to each other
as shown in lines 16 in each of the POWDER documents above. Both describe the same IRI set (everything on example.com and all its subdomains)
but the descriptions are attributed to different entities.
Notice that in example 2-8, each DR has an identifier so that it can be referred to directly.
The GRDDL Transform of powder1.xml in example 2-8 is shown in example 2-9 below where it can be seen that:
- the identifier assigned to the DR becomes the identifier for the sub class statement (line 33), and;
- the link to powder2.xml becomes the object of an
rdfs:seeAlso property of the descriptor set class (line 30).
Example 2-9: The POWDER-S Document Derived From powder1.xml in Example 2-8 [RDF/XML]
1 <?xml version="1.0"?>
2 <rdf:RDF
3 xmlns:wdr="http://www.w3.org/2007/05/powder#"
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:palette="http://color.example.org/vocab#">
9
10 <rdf:Description rdf:about="">
11 <foaf:maker rdf:resource="http://color.example.org/foaf.rdf#me" />
12 </rdf:Description>
13
14 <owl:Class rdf:nodeID="iriset_1">
15 <owl:intersectionOf rdf:parseType="Collection">
16 <owl:Restriction>
17 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#includehosts" />
18 <owl:hasValue>example.com</owl:hasValue>
19 </owl:Restriction>
20 </owl:intersectionOf>
21 </owl:Class>
22
23 <owl:Class rdf:nodeID="descriptorset_1">
24 <owl:intersectionOf rdf:parseType="Collection">
25 <owl:Restriction>
26 <owl:onProperty rdf:resource="http://color.example.org/vocab#color" />
27 <owl:hasValue>red</owl:hasValue>
28 </owl:Restriction>
29 </owl:intersectionOf>
30 <rdfs:seeAlso rdf:resource="http://example.com/powder2.xml#square" />
31 </owl:Class>
32
33 <owl:Restriction rdf:ID="red">
34 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#hasIRI"/>
35 <owl:someValuesFrom rdf:nodeID="iriset_1"/>
36 <rdfs:subClassOf rdf:nodeID="descriptorset_1"/>
37 </owl:Restriction>
38
39 </rdf:RDF>
If creating POWDER-S documents directly, the IRI given as the object of the rdfs:SeeAlso property in
line 30 would point to the sub class relationship class in the other POWDER-S document.
2.4.1 Maintaining Processing Order Across Mutliple POWDER Documents Using isPartOf
The same technique for referencing DRs in external POWDER documents as described in example 2-8 can be used when creating an
ordered list of exclusive DRs (see section 2.3). That is, a DR within an ordered list can refer to one
defined in a separate POWDER document. However, since those 'remote DRs' will be self-contained, there is a danger that they will be
cached by a POWDER processor and used outside the important context of the ordered list.
To avoid this the ispartof element can be used to indicate that a DR SHOULD be processed in the list context. This is
shown in example 2-10 below.
Example 2-10: Including an External DR Within An Ordered List
powder1.xml [XML]
1 <?xml version="1.0"?>
2 <powder xmlns="http://www.w3.org/2007/05/powder#"
3 xmlns:palette="http://color.example.org/vocab#"
4 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
5 <attribution>
6 <maker>color.http://example.com/foaf.rdf#me</maker>
7 </attribution>
8 <ol xml:id="list">
9 <dr ref="http://example.com/powder2.xml#blue" />
10
11 <dr xml:id="red">
12 <iriset>
13 <includehosts>example.com</includehosts>
14 </iriset>
15 <descriptorset>
16 <palette:color>red</palette:color>
17 </descriptorset>
18 </dr>
19 </ol>
20 </powder>
powder2.xml [XML]
1 <?xml version="1.0"?>
2 <powder xmlns="http://www.w3.org/2007/05/powder#"
3 xmlns:palette="http://color.example.org/vocab#"
4
5 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
6 <attribution>
7 <maker>http://color.example.org/foaf.rdf#me</maker>
8 </attribution>
9 <dr xml:id="blue">
10 <ispartof ref="powder1.xml#list" />
11 <iriset>
12 <includehosts>example.com</includehosts>
13 <includePathContains>sky sapphire</includePathContains>
14 </iriset>
15 <descriptorset>
16 <palette:color>blue</palette:color>
17 </descriptorset>
18 </dr>
19 <dr ref="http://example.com/powder2.xml#square" />
20 </powder>
The ref attribute is used in <ispartof> and
(optionally) within <ispartof> in preference to rdf:resource. The group believes
that using rdf:resource in this context (1) is inaccurate since it is simply an XML attribute, not
an RDF property, when parsed as XML, and (2) adds complexity through the need for decalration and use of the
RDF namespace and prefix. The group particularly welcomes any comments on this approach.
In example 2-10, the content provider, example.com, has created a POWDER document that contains an ordered list of two DRs. The
operational semantics of powder1.xml are:
For a given URI, U:
If U has a host that ends with the components example.com and a path that contains either 'sky' or 'sapphire', then color.example.org describes it as being blue.
If U is not described by the 'blue' DR, and U has a host that ends with the components example.com then example.com itself describes it as red.
The operational semantics of powder2.xml are:
For a given URI, U:
If U has a host that ends with the components example.com and a path that contains either 'sky' or 'sapphire', unless there is a DR higher up the ordered list at powder1.xml#list that also describes it, color.example.org describes it as being blue.
The isPartOf property and list identifier are not included in the GRDDL transform since all DR-S instances are self-contained.
2.5 Direct Resource Description
POWDER is predicated on the concept of IRI sets - applying descriptions to more than one IRI at a time. This relies on
there being some structure to the IRIs used. To a human reader, it would be fairly obvious that all resources with
an IRI on composers.example.org that have a path starting with /Mahler would be about a different composer to those with
a path starting with /Beethoven. IRI sets allow these relationships to become machine processable.
However, not all Web content is arranged in such clearly delineated fashion and as a result, it is impossible
to define a suitable IRI set. For example, a content management system may assign a simple numerical IRI to newly
added content irrespective of the type or the subject matter of content available from that IRI. In such a situation, the
usefulness of POWDER as a content discovery mechanism is reduced, but not eliminated.
The POWDER document in example 2-11 below contains two descriptions that can be applied to example.org and example.com, but those
descriptions are not tied to particular IRI sets within a Description Resource.
Example 2-11: A POWDER Document With Descriptors That Can Be Referenced Externally But No DRs [XML]
1 <?xml version="1.0"?>
2 <powder xmlns="http://www.w3.org/2007/05/powder#"
xmlns:ex="http://example.org/vocab#">
4 <attribution>
5 <maker>http://authority.example.org/foaf.rdf#me</maker>
6 <abouthosts>example.org example.com</abouthosts>
7 </attribution>
8 <descriptorset xml:id="red">
9 <ex:color>red</ex:color>
10 </descriptorset>
11 <descriptorset xml:id="blue">
12 <ex:color>blue</ex:color>
13 </descriptorset>
14 </powder>
From a discovery point of view, this tells us that there are red and blue resources available on example.org and example.com but can
go no further. Associating a description set with a specific IRI can only be done by linking from a resource
to a description, hence the inclusion of the identifiers on the descriptor set elements (lines 8 and 11).
An HTML document at http://www.example.org/page.html might include a link element thus:
<link rel="powder" href="/powder.xml#red" type="application/xml" />
Although example 2-11 does not contain any Description Resources, it does preserve two key elements of POWDER:
Firstly, the description is attributed and therefore an assessment of trust can be made in the same way as any other POWDER document.
Secondly, the attribution element includes an abouthosts element. This effectively limits the scope of the descriptions
to the declared hosts since if a resource is not available from a listed host, then, as noted in the discussion of Example 2.6 above,
the processor MUST NOT apply the data in the document to that resource.
This is an important point since it would be possible to claim that any resource on the Web is 'red' by including the link element
shown above. This may be what is required (see following section), however, the abouthosts element allows POWDER
document authors to set an outer limit on where the descriptions can be applied. It is for this reason that we specify that if the
abouthosts element is included in a POWDER document, then processors MUST NOT, rather than SHOULD NOT or MAY NOT, apply
descriptions within the document to any host other than those listed.
It is emphasized that providing descriptions in this way is inferior to the preferred method of explicitly associating them with
IRI sets within a DR. If a POWDER document is to describe all the resources on a given Web site in the same way, then authors should include
a Description Resource with a IRI set defined using the appropriate value of the includehosts element. This is because
the semantics are different in a subtle but important way:
Within a Description Resource, all IRIs that are instances of an IRI set are described.
The abouthosts element within the attribution element of a POWDER document states that all resources that are described within
that document are available from the given host(s), it does NOT guarantee that all resources on those hosts are described.
The first of these is clearly a better aid to content discovery.
2.6 Pre-Defined Descriptors
As shown in the previous section, Descriptors elements can exist outside a DR. If the POWDER document does not include an
abouthosts element in its attribution, then such a descriptor set may be used to describe any resource. This is useful,
for example, in claiming adherence to a code of conduct or standard that is published independently.
In example 2-12 below, powder1.xml includes descriptor sets that define two levels of educational value as defined by the
entity described by http://education.example.org/foaf.rdf#me. powder2.xml refers to one of those descriptor sets in describing
the content at example.com.
Example 2-12: Example of a Pre-Defined Descriptors Element and its Usage
powder1.xml [XML]
<?xml version="1.0"?>
<powder xmlns="http://www.w3.org/2007/05/powder#"
xmlns:ex="http://education.example.org/vocab#">
<attribution>
<maker>http://education.example.org/foaf.rdf#me</maker>
</attribution>
<descriptorset xml:id="Excellent">
<displaytext>This material is highly recommended for educational use</displaytext>
<displayicon>http://education.example.org/excellent.png</displayicon>
</descriptorset>
<descriptorset xml:id="Good">
<displaytext>This material is recommended as a source of extra information in educational use</displaytext>
<displayicon>http://education.example.org/good.png</displayicon>
</descriptorset>
</powder>
powder2.xml [XML]
<?xml version="1.0"?>
<powder xmlns="http://www.w3.org/2007/05/powder#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"">
<attribution>
<maker>http://authority.example.org/foaf.rdf#me</maker>
<issued>2008-03-03</issued>
</attribution>
<dr>
<iriset>
<includehosts>example.com</includehosts>
</iriset>
<descriptorset ref="http://education.authority.example.org/powder1.xml#Excellent" />
</dr>
</powder>
powder2.xml encodes a claim made by the entity described at http://authority.example.org/foaf.rdf#me that everything on
example.com is an excellent education resource, where excellence is defined by the entity described at http://education.example.org/foaf.rdf#me.
Several of the POWDER Use Cases[USECASES] make reference to scenarios where this kind of data structure is called for. Methods
for enabling trust in such data is discussed in section 4.
In the examples given so far, controlled vocabularies have been used to describe the resources. POWDER also supports free text 'tags'
too — that is, key words or short phrases that describe the content — as shown in example 2-13 below.
Example 2-13: Generic Example of a DR Containing a Tagset [XML]
1 <?xml version="1.0"?>
2 <powder xmlns="http://www.w3.org/2007/05/powder#"
3 xmlns:ex="http://example.org/vocab#">
4 <attribution>
5 <maker>http://authority.example.org/foaf.rdf#me</maker>
6 <issued>2007-12-14</issued>
7 </attribution>
8
9 <dr>
10 <iriset>
11 <includehosts>example.com</includehosts>
12 </iriset>
13
14 <tagset>
15 <tag>London</tag>
16 <tag>Swiss Re</tag>
17 <tag>gherkin</tag>
18 </tagset>
19 </dr>
20 </POWDER>
The DR in this example does not have a descriptor set, rather it has a tag set (it could have both). Any number of tags may be included
as elements within the tag set and these may contain any text (subject to usual XML data encoding rules).
A DR MUST contain either a tagset element, a descriptorset element, or both. It MUST NOT contain multiple elements of either kind.
The tag element can only be used within a tag set and specifically MUST NOT be used with a descriptor set. This is
because the descriptor set element is used to contain values for properties taken from controlled vocabularies expressed in RDF. A
tag set (and only a tag set) may optionally refer to one or more resources that help to define the meaning of the tags
by providing a white space separated list of IRIs as the value of the ref attribute.
For example, the tag set in example 2-13 might link to an online encyclopaedia page and an image of the London landmark suggested by the tags thus:
<tagset rdf="http://encyclopaedia.example.com/gherkin.html
http://photo.example.com/gherkin.jpg">
<tag>London</tag>
<tag>Swiss Re</tag>
<tag>gherkin</tag>
</tagset>
Show tags in the equivalent DR-S, example 2-13. Each IRI in the ref attribute becomes an rdfs:seeAlso property.
3 Associating Resources and DRs
3.1 Linking a Resource to a POWDER Document
A given resource (hereafter known as the described resource) may relate itself to a POWDER document. There are
two methods to define such a relationship, detailed below.
3.1.1 (X)HTML link Elements
In HTML documents, the link element can be used to point to a POWDER document with the
relationship type [REL] of 'powder' as shown in Example.3-1.
The relationship type is defined in the @@@POWDER profile@@@ document which should therefore be
referenced in the head tag.
N.B. the value of the rel attribute is a white space separated list so other relationship types
may be included too. For example, it may be desirable to give processors a clue as to which descriptive vocabulary or vocabularies
is/are used in the DR(s) in the POWDER document. Again, such relationship types may need to be defined in a profile document.
Example 3-1: 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>
Note that this approach requires the described resource to be requested and parsed in order to find the relevant POWDER document's location. This may be acceptable
for data warehousing, for example retrieving DRs asynchronously to a user request, so that the metadata about the described resource can be
inspected and usage trends compiled. However, other techniques may offer greater efficiency as discussed in the Primer.
POWDER WG would like to see the HTTP Link Header 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.
3.1.2 Semantic Linkage Using the describedby Property
In many other environments, particularly where there are well-defined semantics or a well-defined structure,
it is appropriate to link a resource to a POWDER document 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 in example 3-2 below.
Example 3-2: RDFa snippet using wdr:describedby [HTML]
1 <html
2 xmlns="http://www.w3.org/1999/xhtml"
3 xmlns:wdr="http://www.w3.org/2007/05/powder#"
4 >
5 <head>
6 <title>The English Civil War</title>
7 <link rel="wdr:describedby" href="http://ecw.example.org/powder1.xml" />
8 </head>
9 <body>
10 …
11 <p>Charles I came to the throne believing in his
12 <a href="http://monarchy.example.org/divine_right.html">Divine Right</a> to rule...
13 …
14 </body>
15 </html>
Here the active document is linked to a description through the link
element in the HEAD with the relationship type defined using the describedby
property (line 7). The POWDER document (powder1.xml) SHOULD describe the active document and may or
may not provide a description of other resources linked from it. For the purposes of this example we'll assume
that powder1.xml describes the whole of the Web site that includes this document as being a source of information
that is recommended for school study of the English Civil War.
Notice that the text in example 3-2 includes a link to another document on another host in line 12 (divine_right.html).
Suppose that document, and others on the monarchy.example.org Web site, are described by a different POWDER document. It
is possible to use RDFa to link to a POWDER document describing divine_right.html as shown in lines 12-13 in example 3-3 below.
Example 3-3: RDFa snippet using two wdr:describedby properties [HTML]
1 <html
2 xmlns="http://www.w3.org/1999/xhtml"
3 xmlns:wdr="http://www.w3.org/2007/05/powder#"
4 >
5 <head>
6 <title>The English Civil War</title>
7 <link rel="wdr:describedby" href="http://ecw.example.org/powder1.xml" />
8 </head>
9 <body>
10 …
11 <p>Charles I came to the throne believing in his
12 <a about="http://monarchy.example.org/powder2.xml"
13 rev="wdr:describedby"
14 href="http://monarchy.example.org/divine_right.html">Divine Right</a> to rule...
15 …
16 </body>
17 </html>
Note the use of the rev relationship type in line 13 which effectively switches round the subject and object
of the triple. An RDFa processor will extract the following two triples from this snippet:
<> wdr:describedby <http://ecw.example.org/powder1.xml>
<http://monarchy.example.org/divine_right.html> wdr:describedby <http://monarchy.example.org/powder2.xml>
A POWDER-aware Web browser may use the description provided in powder2.xml to decide to render the hyperlink in different ways. For example, if the document about
Divine Right is not suitable for display on mobile devices, the browser may not include the hyperlink at all when the primary document is viewed on a handheld device
but would do so on a desktop device.
POWDER may also provide useful annotations in syndication feeds, again with the
describedby property providing the link. Example 3-4 shows an ATOM feed
of the documents discussed in example 3-3 that links to the same two different POWDER documents.
Example 3-4: ATOM feed with links to POWDER documents [XML]
<?xml version="1.0" encoding="utf-8"?>
<feed
xmlns="http://www.w3.org/2005/Atom"
xmlns:wdr="http://www.w3.org/2007/05/powder#"
>
<wdr:describedby>http://ecw.example.org/powder1.xml</wdr:describedby>
<title>The English Civil War</title>
<link href="http://ecw.example.org/"/>
<updated>2007-10-30T15:00:00Z</updated>
<author>
<name>John Doe</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<entry>
<title>Charles I</title>
<link href="http://ecw.example.org/charles1.html"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2007-06-04T09:39:21Z</updated>
<summary>Charles I came to the throne believing in his Divine Right to rule...</summary>
</entry>
<entry>
<wdr:describedby>http://monarchy.example.org/powder2.xml</wdr:describedby>
<title>Divine Right</title>
<link href="http://monarchy.example.org/divine_right.html"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6b</id>
<updated>2007-06-06T13:43:54Z</updated>
<summary>Divine Right was claimed by several English monarchs, notably Charles I...</summary>
</entry>
</feed>
The feed element is linked to powder1.xml which is a hint, not a guarantee, that it describes many or all of the items in the feed.
The second item in the feed is described by a different POWDER document.
It is worth noting that the structure of the ATOM feed
plays no part in determining what is described by the POWDER documents — this is only defined in the IRI sets within the DRs they contain.
For the avoidance of doubt, powder1.xml does not fulfil the role of 'default' description that is then overridden by powder2.xml.
3.2 Requesting the DR for a Resource
3.2.1 Requesting the DR from the Described Resource
As shown above, there are two core methods for linking a resource to a DR that describes it — using the HTML link
element with a relationship type 'powder' or the describedby property in a variety of contexts. Clearly, the resource
must be parsed by a suitable user agent in order to detect the URI of the DR.
The following should be replaced if HTTP Link is moved to RFC status
It is anticipated that future work beyond the scope of POWDER will make it possible to use closely related methods to include
links to Description Resources through other means, notably within HTTP Response Headers. A good POWDER processor SHOULD therefore
inspect those headers and follow such links. This issue is discussed in more detail in the Primer.
3.2.2 Requesting a DR from a Repository
There are no normative rules on how to publish large numbers of Description Resources. However, individuals or organizations that create
DRs are encouraged to make them available both as bulk data and as POWDER-S documents in bulk and through a SPARQL endpoint.
The publisher is, of course, free to do this in any way they feel appropriate but it will be helpful to provide documentation that includes sample
queries that yield results than can be processed efficiently.
Examples are provided in the Primer.
More needed here? Previous version of the doc contains sample SPARQL queries - maybe we should have some XPath queries?
4 Trust
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, healthcare materials. For this reason, we do not define a single trust mechanism that
must be used. Rather, the following sections describe a variety of different methods of adding trust to DRs, some of which may
be used in combination. Where applicable, we define vocabulary terms designed to aid the building of trust.
4.1 Discovering the Trust Mechanism: the authenticate Property
Any method provided by a DR author for adding trust to their descriptions needs to be discoverable. To this end,
we define the authenticate property with a domain of foaf:Agent. That is, it's part of
the description of an entity that creates POWDER documents, not of the POWDER documents themselves, and is expected to be discoverable by following the
IRI given as the content of the maker element (required in all POWDER documents). The range of authenticate is simply rdfs:Resource
and so its value can be machine-processable, such as a WSDL document, or a human-readable document describing
any authentication services that the DR author offers or steps he/she recommends.
4.2 Certification using POWDER
Trust in Description Resources may readily be enhanced through third party certification. That is, an entity can publish data that
is identifiable through its origin and/or a digital signature that states that the named entity certifies that the claims and
assertions made in an identified POWDER document are correct. The level of trust that can be placed in the data then becomes
equivalent to the level of trust held in the certification body. Such certificates may themselves by expressed in a DR as
exemplified below.
Example 4-1: Example of a Certificate, expressed as a DR [XML]
1 <?xml version="1.0"?>
2 <powder xmlns="http://www.w3.org/2007/05/powder#">
3 <attribution>
4 <maker>http://authority.example.org/foaf.rdf#me</maker>
5 <issued>2007-12-14</issued>
6 <validfrom>2008-01-01</validfrom>
7 <validuntil>2008-12-31</validuntil>
8 </attribution>
9 <dr>
10 <iriset>
11 <includeresources>http://www.example.com/powder.xml</includeresources>
12 </iriset>
13 <descriptorset>
14 <sha1sum>j6lwx3rvEPO0vKtMup4NbeVu8nk=</sha1sum>
15 <certified>true</certified>
16 <displaytext>authority.example.org certifies that claims made by example.com are true. Valid throughout 2008.</displaytext>
17 <displayicon>http://authority.example.org/icon.png</displayicon>
18 </descriptorset>
19 </dr>
20 </powder>
This example introduces a number of features.
It is the nature of certificates that they have a period of validity. Trustmarks are typically awarded for a period of a year,
for example. To support this, POWDER defines two elements: validfrom and validuntil in lines 6 and 7.
These elements are of type xsd:date and have the following operational semantics:
A POWDER document is temporally valid unless:
- there is a
validfrom element present and today's date precedes it
- there is a
validuntil date and today's date is after the date given.
Temporal validity is independent of trust, that is, a processor may choose to trust a POWDER document that is temporally
invalid. Similarly, it may choose not to trust one that is temporally valid. However, from a policy perspective, the publisher of any
Description Resource should be prepared to stand by their claims for the entirety of any stated validity period.
If a valid until date is stated, it SHOULD be the same as the HTTP cache header (if set). It is not an error if the cache
header has a later date since the data has its own expiry. However, if the valid until date is after that given in a
cache header, a processor MAY legitimately continue to use the DR beyond its cache period.
Formally, we define the following semantic extension (see RDF-SEMANTICS for further explanation).
A POWDER document, ddd, a member of ICEXT(I(wdr:powder)) may be either date-valid, or date-invalid (but not both), depending on
the current date at the time of processing, as follows:
- If <ddd,f> is in IEXT(I(wdr:validfrom)) and f is after the current date, then ddd is date-invalid.
- If <ddd,u> is in IEXT(I(wdr:validuntil)) and u is before the current date, then ddd is date-invalid.
Otherwise ddd is date-valid.
Should we include the POWDER-S version of example 4-1 here too?
There are two further features shown in Example 4-1 that have not been discussed in this document previously.
In line 14, the descriptor set includes a SHA-1 Sum of the (one) described resource. Although not formalized in the semantics of POWDER,
this element provides processors with an integrity checking mechanism. The publisher of Example 4-1 is providing a very precise description of
the document at http://www.example.com/powder.xml. POWDER processors are therefore empowered to calculate a SHA-1 hash of the described
resource and use that to decide whether or not to trust the data. The sha1sum descriptor takes a single hash as its
value and may only appear once in a descriptor set. It is therefore only useful when describing a single resource, as is the case in
Example 4-1.
Since the expression of certificates in this way is at the heart of several POWDER use cases [USECASES] we also
define the certified element which has a data type of xsd:boolean.
The inverse relationship is also supported by the certifiedby element. That is, the attribution element in
http://www.example.com/powder.xml may include a pointer to this certificate by giving its IRI as the value of the certifiedby element.
Only complete POWDER documents may be certified, not individual DRs, since an IRI set cannot be defined in terms of fragment identifiers.
4.2.1 Full Interpretation of Example 4-1
Example 4-1 is a POWDER document that contains a single DR that describes a single resource - another POWDER document at
http://www.example.com/powder.xml. The same resource could be described using core Semantic Web technologies but POWDER offers a
number of additional features so that, in effect, Example 4-1 can certify that http://www.example.com/powder.xml is true.
First of all, like all POWDER documents, Example. 4-1 is attributed to an identified entity. That entity's
FOAF description is likely to include the authenticate property described in
section 4.1, giving information on how its DRs may be authenticated.
Secondly, POWDER supports time-limited assertions. Example 4-1 is only valid for the 2008 calendar year.
Thirdly, the DR includes text and graphics that can be displayed to the end user, providing a readily accessible human-readable representation
of the machine-processable data.
Fourthly, by providing a SHA1 hash of the described resource, the publisher of the certificate is making it clear exactly what it
is certifying and that if the described document is tampered with (and therefore leads to a different hash) the description will no
longer be accurate and should probably be disregarded.
4.3 Supporting Evidence: The supportedby Property
The certification mechanism detailed in the previous section entails a direct relationship between the content provider (or at least the
DR author) and a certification body. The supportedby property is similar in that it points to a third party from which data is available that will
confirm the claims and assertions made in the DR, however, there need not be a direct relationship between the parties concerned. The DR author may
discover independently that a third party shares their view and wishes to adduce further evidence to support their own description by pointing
to the external body. One scenario in which this might obtain is described in section 2.1.7 of the Use Cases document [USECASES].
There, a DR is used to declare a Web site to be suitable for children with external support for the claim coming from a company that offers a Web
site classification service.
In common with authenticate and certifiedby, supportedby has a range of rdfs:Resource and this
may be either a machine-processable or human-readable document. supportedby can be an element within the attribution element or
an individual DR.
Add in example of mobileOK Basic conformance with supporting evidence from the checker.
4.4 Trusted Source
Description Resources exist independently of the content they describe and are resolved from an IRI of their own. This is usually
discovered by following a link from the described content. If the Description Resource is hosted on a trusted server, typically one
operated by a trustmark scheme or certification body, then the trustworthiness of the DR is equal to the trustworthiness of the
server and its operator.
Imagine good.example.com has a commercial relationship with powder.example.org. The operators of good.example.com go
through a review process run by powder.example.org and are then entitled to include a tag like the one below in the code of their Web pages.
<link rel="powder" href="http://powder.example.org/dr46" type="application/xml" />
The document at powder.example.org remains entirely under the control of the reviewer who is free to change or remove it at any time.
N.B. Any such change must take account of any valid until date given in the document and the fact that a POWDER-aware
user agent may cache DRs until that date occurs. The Primer has more to say about this.
4.5 Machine Learning
It is fundamental aspect of RDF that descriptive terms are explicitly defined by IRI. Therefore if a particular descriptive
vocabulary becomes widely used, it will mean the same thing wherever it is found. This is important when deploying content analysis
software that uses machine-learning techniques. Once the software has been trained to recognize content matching descriptions made using
a particular vocabulary, where DRs are encountered using that same vocabulary, the newly discovered content can be analyzed and a
probability of its accuracy be calculated.
5 References
- [XGR]
- W3C Incubator Group Report P Archer, J Rabin, 20 February 2007. This document is at http://www.w3.org/2005/Incubator/wcl/XGR-wcl/
- [WCL-XG]
- W3C Content Label Incubator Group February 2006 - February 2007
- [GROUP]
- Protocol for Web Description Resources (POWDER): Grouping of Resources, A Perego, P Archer This document is at http://www.w3.org/TR/powder-grouping/
- [IRI]
- Internationalized Resource Identifiers (IRIs), M Dürst, M. Suignard. IETF, January 2005
- [VOC]
- Protocol for Web Description Resources (POWDER): Web Description Resources (WDR), A Perego, P Archer. This document is at http://www.w3.org/TR/powder-voc/
- [WDRD]
- Protocol for Web Description Resources (POWDER): Web Description Resources Datatypes (WDRD), A Perego, P Archer, K. Smith. This document is at http://www.w3.org/TR/powder-xsd/
- [USECASES]
- POWDER: Use Cases and Requirements W3C Working Group Note 31 October 2007, P Archer . This document is at http://www.w3.org/TR/powder-use-cases/
- [PRIMER]
- Protocol for Web Description Resources (POWDER): Primer 2008, K. Scheppe, D. Pentecost. (URI TBC)
- [TESTS]
- Protocol for Web Description Resources (POWDER): Test Suite 2008, P. Nasikas. (URI TBC)
- [GRDDL]
- Gleaning Resource Descriptions from Dialects of Languages (GRDDL) W3C Recommendation 11 September 2007. D. Connolly. This document is at http://www.w3.org/TR/grddl/
- RFC2119
- Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997. This document is at http://ietf.org/rfc/rfc2119.
- RDFa
- RDFa Primer 1.0 Embedding RDF in XHTML, B. Adida, M. Birbeck. This document is at http://www.w3.org/TR/xhtml-rdfa-primer/
- RFC2616
- Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding et al, June 1999. This document is at http://www.ietf.org/rfc/rfc2616.txt
- SPARQL
- SPARQL Query Language for RDF E. Prud'hommeaux, A. Seaborne. This document is at http://www.w3.org/TR/rdf-sparql-query/
- [BASIC]
- W3C mobileOK Basic Tests 1.0 S. Owen, J. Rabin. This document is at http://www.w3.org/TR/mobileOK-basic10-tests/
- [FOAF]
- FOAF Vocabulary Specification 0.9 Namespace Document 24 May 2007, D. Brickley, L. Miller. This document is at http://xmlns.com/foaf/spec/
- [DC]
- Dublin Core Metadata Initiative
- WSDL
- See, for example, Web Services Description Language (WSDL) Version 2.0 Part 0: Primer D. Booth, C. K. Liu, W3C Recommendation 26 June 2007. This document is at http://www.w3.org/TR/wsdl20-primer/
- RDF-SEMANTICS
- RDF Semantics, W3C Recommendation 10 February 2004, P Hayes. The key text is in Section 1.3. This document is at http://www.w3.org/TR/2004/REC-rdf-mt-20040210/
6 Acknowledgements
The editors duly acknowledge the earlier work in thia area carried out by the Web Content Label Incubator Activity, especially the contribution made by Jo Rabin.
David Booth and Jeremy Carroll of HP contributed substantaily to the operational/semantic model for POWDER with further contributions and support from all
members of the POWDER Working Group.
7 Change Log
As noted in the Status of the Document, this draft represents a very substantial change from the first public working draft. Wholesale changes have been made thoughout.
- Abstract extended
- Corrected erroneous use of the term 'QName' in the introduction
- Minor changes to the introduction, including the addition of the sentence "In practice, POWDER associates
a description with one or more URIs that must then be interpreted as being descriptions of the resources resolved
from those URIs."
- New section on Operational and Formal Semantics added; section on namespaces ad terminology renumbered accordingly.
- Renamed section 2 to POWDER Structure and Semantics and substantially re-written
- The contributions by David Booth and Jeremy Carroll are noted in the acknowledgements
- Section 3 on linkage between resources and DRs largely unchanged, but the growing call for the HTTP Link Header (or something like it) is of significance
- Section describing 'linkFrom' deleted. This is now covered in section 2.5
- Section on Classification removed and its essence replaced by section 2.6
- mapsTo property deleted and new section on tags introduced as section 2.7
- validfrom and validuntil properties moved to what is now section 4.2. The use of these properties in certifying other claims is now emphasized and their use in
generic POWDER documents reduced in prominence.
- Element/property names now all lower case to follow XML norms. ResourceSet renamed following advice from Jeremy Carroll.
- Use of 'IRI' cf. URI throughout.
- Section 3.1.1, link to POWDER profile removed for this iteration as the profile doc needs updating