Protocol for Web Description Resources (POWDER): Description Resources

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-readable. 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 the Last Call Working Draft of this document, the Last Call period being synchronized with two other documents in the set: Grouping of Resources and Formal Semantics. These three document are expected to be advanced to Recommendation Status. The POWDER Working Group welcomes comments on these through to 14 September 2008. Comments are equally welcome on the other documents that are also available as working drafts, in particular, the Primer and Test Suite. Changes to this document since the previous version are recorded in the Change Log.

Please note that this document includes a feature at risk related to the status of the HTTP Link header. Furthermore it refers to a feature at risk in the Formal Semantics document. The Working Group is particularly keen to receive feedback on these issues and the definition of wdrs:issuedby as a sub property of both foaf:maker and dcterms:creator (an alternative might be to make both of those sub properties of wdrs:issuedby, the definition of a class that is the union of dcterms:Agent and foaf:Agent etc).

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.

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, 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 next section introduces the division between the operational semantics of POWDER (designed to be easy and practical to use in everyday situations) and the more formal semantics (designed to make POWDER available on the broader Semantic Web). This division means that there are several components to the Protocol for Web Description Resources which in turn leads to there being several documents in the set.

The method of defining the scope of a DR, that is, defining what is being described, is provided in Grouping of Resources [GROUP]. The layered semantics of POWDER is defined in a Formal Semantics document [FORMAL]. It is hoped that the provision of those documents allows the present one to give a clearer, more concise definition of the structure and use of Description Resources. The full set of POWDER documents also includes its Use Cases, Primer and Test Suite, together with the namespace documents [WDR, WDRS, WDRD] and GRDDL transform [PDR-GRDDL].

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 what 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 labelling 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 dereferenced from those IRIs.

Trust is a central theme of POWDER; however, we do not prescribe a single method through which trust must be conferred on Description Resources. By its very nature, trust is a human judgment that can only be made by weighing the likelihood that the data is true against the consequences of it being false. This judgment is highly dependant on the circumstances under which the need to extend trust arises. POWDER does, however, provide support for, and is amenable to, a variety of methods through which users and user agents can establish trust.

Reference is made throughout this document to POWDER documents. Unless otherwise stated, these are XML documents that have their root element in the POWDER namespace. A POWDER processor is software that can process POWDER documents, the minimum specification for which is set out in Section 3.

1.1 Operational and Formal Semantics

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 much of the gap between 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, it is appropriate to perform the GRDDL transform to render the data as syntactically valid RDF/OWL (see Section 2.2 below). The semantics of such documents, known as POWDER-S documents, are defined in a companion Formal Semantics document [FORMAL]. This includes a Semantic Extension to RDF that must be understood if the OWL data is to be processed effectively.

1.2 Namespaces and Terminology.

The POWDER vocabulary namespace is http://www.w3.org/2007/05/powder# for which we use the prefix wdr. The POWDER-S namespace is http://www.w3.org/2007/05/powder-s# for which we use the prefix wdrs. All 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#`
`wdrs`	`http://www.w3.org/2007/05/powder-s#`
`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/`
`dcterms`	`http://purl.org/dc/terms/`
`xsd`	`http://www.w3.org/TR/xmlschema-2/`
`ex`	An arbitrary prefix used to denote an 'example vocabulary'

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 in 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 that are encoded largely in XML. The terms POWDER-S and DR-S refer to RDF/OWL representations, the full semantics of which are expressed when account is taken of the extension defined in the Formal Semantics document [FORMAL].

2 POWDER Structure and Semantics

2.1 Operational Semantics

On 14th December 2007, the entity described at http://authority.example.org/company.rdf#me said that everything on example.com is red and square.

is encoded in POWDER as shown in the example below, which in turn 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      <issuedby src="http://authority.example.org/company.rdf#me" />
4      <issued>2007-12-14T00:00:00</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 src="http://authority.example.org/icon.png" />
15     </descriptorset>
16   </dr>

17  </powder>

Operationally, a user (or user agent) should begin the examination of a POWDER document by considering the attribution element which, if the document is valid in the XML-sense of the term, will be present and contain an issuedby 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 that is the value of the src attribute of the issuedby element points to a description of a trusted individual or entity (or includes such a description directly), the data provided in the remainder of the document will usually be trusted, subject to integrity-checking mechanisms such as those discussed in section 5.

Support for including the description of the entity that created the POWDER document directly within it as shown in the following example is dependent on the Feature at Risk detailed in the Formal Semantics document.

If the user (or user agent) confers his/her 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(s), each of which will be attributed to the same person or entity. Where those IRI sets overlap, the descriptions are additive. In Example 2-2 below, the opinion of the Exemplary Description Authority is that everything on example.com is red; IRIs on example.com where the path starts with /foo can be dereferenced to resources that are BOTH red AND shiny.

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#" 
2          xmlns:foaf="http://xmlns.com/foaf/0.1/"
3          xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
4          xmlns:ex="http://example.org/vocab#">

5    <attribution>
6      <issuedby>
7        <foaf:Organization>
8          <foaf:homepage rdf:resource="http://authority.example.org/" />
9          <foaf:name>The Exemplary Description Authority</foaf:name>
10         <foaf:nick>EDA</foaf:nick>
11       </foaf:Organization>
12     </issuedby>
13   </attribution>

14   <dr>
15     <iriset>
16       <includehosts>example.com</includehosts>
17     </iriset>
 
18     <descriptorset>
19       <ex:color>red</ex:color>
20     </descriptorset>
21   </dr>

22   <dr>
23    <iriset>
24       <includehosts>example.com</includehosts>
25       <includepathstartswith>/foo</includepathstartswith>
26     </iriset>

27     <descriptorset>
28       <ex:finish rdf:resource="http://example.org/vocab#shiny" />
29     </descriptorset>
30   </dr>

31 </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 preceding examples are discussed in later sections of this document.

2.2 Formal Semantics: POWDER-S

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 transformation 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.

The aim of POWDER-S is to make POWDER data available to more general Semantic Web tools, not to create an alternative encoding. All POWDER-S documents are syntactically valid RDF/OWL documents; however, logical inferences may only be drawn by applications that implement the semantic extension defined in the Formal Semantics document [FORMAL]. That document provides full details of the transformation, which is split into two steps. In brief: the first step reformulates the IRI set definition purely in terms of regular expressions that are matched against a candidate IRI. Other elements of the document are unaffected in this intermediate stage, which is known as POWDER-BASE. The second step transforms POWDER-BASE into POWDER-S. This document is not concerned with the intermediate step and presents only POWDER and POWDER-S examples.

Example 2-3: Generic example of a POWDER-S Document Containing a Single Description Resource [RDF/XML]

This is the result of the GRDDL transform performed on example 2-1

1  <?xml version="1.0"?>
2  <rdf:RDF
3     xmlns:wdrs="http://www.w3.org/2007/05/powder-s#"
4     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
5     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
6     xmlns:owl="http://www.w3.org/2002/07/owl#"
7     xmlns:dcterms="http://purl.org/dc/terms/"
8     xmlns:foaf="http://xmlns.com/foaf/0.1/"
9     xmlns:ex="http://example.org/vocab#">
 
10    <owl:Ontology rdf:about="">
11      <wdrs:issuedby rdf:resource="http://authority.example.org/company.rdf#me" />
12      <dcterms:issued>2007-12-14T00:00:00</dcterms:issued>
13    </owl:Ontology>
 
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-s#matchesregex" />
18          <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com)(:([0-9]+))?\/</owl:hasValue>
19        </owl:Restriction>
20      </owl:intersectionOf>
21    </owl:Class>

22    <owl:Class rdf:nodeID="descriptorset_1">
23      <owl:intersectionOf rdf:parseType="Collection">
24        <owl:Restriction>
25          <owl:onProperty rdf:resource="http://example.org/vocab#color" />
26          <owl:hasValue>red</owl:hasValue>
27        </owl:Restriction>
28        <owl:Restriction>
29          <owl:onProperty rdf:resource="http://example.org/vocab#shape" />
30          <owl:hasValue>square</owl:hasValue>
31        </owl:Restriction>
32      </owl:intersectionOf>
33      <dcterms:description>Everything on example.org is red and square</dcterms:description>
34      <foaf:depiction rdf:resource="http://example.org/icon.png" />
35    </owl:Class>
 
36    <owl:Class rdf:nodeID="iriset_1">
37      <rdfs:subClassOf rdf:nodeID="descriptorset_1"/>
38    </owl:Class>
 
39 </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 wdrs:issuedby property (line 11) is a sub-property of both foaf:maker and dcterms:creator, implying that its range is the intersection of those vocabularies' Agent classes. The consequence is that the object of wdrs:issuedby can be either an instance of the dcterms:Agent class or foaf:Agent class but only those classes (or sub-classes thereof). For the avoidance of doubt: it is the POWDER document that is issuedby the Agent not the resources that the POWDER document describes.

The matchesregex property restriction in the IRI set class (lines 14 - 21) draws on a semantic extension defined in the Formal Semantics document [FORMAL]. This supports the critical matching of an IRI against a regular expression to confer class membership on the resource denoted by that IRI. For emphasis we repeat that if the POWDER semantic extension is not understood, a generic RDF/OWL tool will not be able to ascribe any meaning to the properties of the IRI set class.

Notice that an rdf:nodeID is 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 22 - 35 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. Note 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/company.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      <issuedby src="http://authority.example.org/company.rdf#me" />
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      <issuedby src="http://authority.example.org/company.rdf#me" />
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]

   <?xml version="1.0"?>
1  <powder xmlns="http://www.w3.org/2007/05/powder#" 
           xmlns:ex="http://example.org/vocab#">

2    <attribution>
3      <issuedby src="http://authority.example.org/company.rdf#me" />
4      <issued>2007-12-14T00:00:00</issued>
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 4. Moreover, the disposition of content with different characteristics across a given Web site or set of Web sites can be discovered by processing the one document. If processed alongside a site map, for example, 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 5. 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. In this context, abouthosts provides a processing hint, quickly identifying whether a candidate resource might be described by the DRs in the document. The element also has a bigger role to play, which is discussed in section 2.5; for now we note that 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).

N.B. IRI sets within a POWDER document do not inherit the value of abouthosts as part of their definition and SHOULD include elements such as includehosts to ensure that they are self-contained. Semantically, it is an error if an IRI set defines a set of resources that is inconsistent with an abouthosts element. In POWDER-S, this is captured by making descriptorset-derived classes of resources a subset of the abouthosts-derived class of resources. A logical inconsistency arises if a descriptor is applied to a resource that is not within the scope specified by abouthosts.

POWDER-S does not directly support ordered lists, but their semantics is captured by asserting sub-class relationships in such a way as to create the necessary exclusions as shown in example 2-7 below.

Example 2-7: The POWDER-S Document Derived From Example 2-6 [RDF/XML]

1  <?xml version="1.0"?>
2  <rdf:RDF
3     xmlns:wdrs="http://www.w3.org/2007/05/powder-s#"
4     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
5     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
6     xmlns:owl="http://www.w3.org/2002/07/owl#"
7     xmlns:dcterms="http://purl.org/dc/terms/"
8     xmlns:ex="http://example.org/vocab#">
 
9     <owl:Ontology rdf:about="">
10      <wdrs:issuedby rdf:resource="http://authority.example.org/company.rdf#me" />
11      <dcterms:issued>2007-12-14T00:00:00</dcterms:issued>
12    </owl:Ontology>

13    <owl:Class rdf:nodeID="aboutset">  <!-- from the abouthosts element -->
14      <owl:intersectionOf rdf:parseType="Collection">
15        <owl:Restriction>
16          <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
17          <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com)(\:([0-9]+))?\/</owl:hasValue>
18        </owl:Restriction>
19      </owl:intersectionOf>
20    </owl:Class>
 
21    <owl:Class rdf:nodeID="iriset_1">
22      <owl:intersectionOf rdf:parseType="Collection">
23        <owl:Restriction>
24          <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
25          <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com)(:([0-9]+))?\/</owl:hasValue>
26        </owl:Restriction>
27        <owl:Restriction>
28          <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
29          <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]*)(\:([0-9]+))?(\/foo)</owl:hasValue>
30        </owl:Restriction>
31      </owl:intersectionOf>
32    </owl:Class>

33   <owl:Class rdf:nodeID="descriptorset_1">
34     <owl:intersectionOf rdf:parseType="Collection">
35       <owl:Class rdf:nodeID="aboutset" />
36       <owl:Restriction>
37         <owl:onProperty rdf:resource="http://example.org/vocab#color" />
38         <owl:hasValue>blue</owl:hasValue>
39       </owl:Restriction>
40     </owl:intersectionOf>
41   </owl:Class>

42   <owl:Class rdf:nodeID="iriset_1">
43     <rdfs:subClassOf rdf:nodeID="descriptorset_1"/>
44   </owl:Class>

45    <owl:Class rdf:nodeID="iriset_2">
46      <owl:intersectionOf rdf:parseType="Collection">
47        <owl:Restriction>
48          <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
49          <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com)(:([0-9]+))?\/</owl:hasValue>
50        </owl:Restriction>
51      </owl:intersectionOf>
52    </owl:Class>
 
53   <owl:Class rdf:nodeID="descriptorset_2">
54     <owl:intersectionOf rdf:parseType="Collection">
55       <owl:Class rdf:nodeID="aboutset" />
56       <owl:Restriction>
57         <owl:onProperty rdf:resource="http://example.org/vocab#color" />
58         <owl:hasValue>red</owl:hasValue>
69       </owl:Restriction>
60     </owl:intersectionOf>
61   </owl:Class>

62   <owl:Class>
63     <owl:intersectionOf rdf:parseType="Collection">
64       <owl:Class rdf:nodeID="iriset_2"/>
65       <owl:Class>
66         <owl:complementOf rdf:parseType="Collection">
67           <owl:Class rdf:nodeID="iriset_1"/>
68         </owl:complementOf>
69       </owl:Class>
70     </owl:intersectionOf>
71     <rdfs:subClassOf rdf:nodeID="descriptorset_2"/>
72   </owl:Class>

73 </rdf:RDF>

The key feature of example 2-7 is in lines 62 - 72 where the sub-class relationship between iriset_2 and descriptorset_2 is asserted. This uses owl:complementOf to exclude iriset_1 (i.e. everything on example.com with a path starting with /foo). If a third DR were added to the ordered list in example 2-6, then both iriset_1 and iriset_2 would be excluded from its sub-class relationship in its POWDER-S version thus:

Example 2-7 also shows that the abouthosts element from the original POWDER document (line 5 in Example 2-6) is transformed into a class very similar to those for the IRI sets, this time with a node ID of 'aboutset' (line 13 - 20). Both descriptorset_1 and descriptorset_2 are defined as the intersection of this set, and the various descriptive properties which ensures that the intended operational semantics of abouthosts are preserved. A logical inconsistency is detected if an IRI is asserted to be a sub class of a descriptor set that intersects with an about set of which it is not a member. The Formal Semantics document [FORMAL] has further detail on the processing of abouthosts.

2.4 DRs with Multiple IRI Sets

As noted in Section 2.1, the scope of a DR may be the union of multiple IRI sets. Example 2-8 below shows a DR for which the scope is all resources on example.com that have a path starting with /foo AND those on example.org that have a path starting with /bar. In POWDER-S, the sub-class relationship between each of the IRI sets and the descriptor set is asserted independently.

Example 2-8: A DR for which the scope is the union of two IRI sets

POWDER [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      <issuedby src="http://authority.example.org/company.rdf#me" />
6      <issued>2007-12-14T00:00:00</issued>
7    </attribution>

8    <dr>
9      <iriset>
10       <includehosts>example.com</includehosts>
11       <includepathstartswith>/foo</includepathstartswith>
12     </iriset>

13     <iriset>
14       <includehosts>example.org</includehosts>
15       <includepathstartswith>/bar</includepathstartswith>
16     </iriset>

17     <descriptorset>
18       <ex:color>red</ex:color>
19       <ex:shape>square</ex:shape>
20       <displaytext>Everything on example.com/foo, and everything on example.org/bar, is red and square</displaytext>
21       <displayicon src="http://example.org/icon.png" />
22     </descriptorset>
23   </dr>

24 </powder>

POWDER-S [RDF/XML]

1  <?xml version="1.0"?>
2  <rdf:RDF
3    xmlns:wdrs="http://www.w3.org/2007/05/powder-s#"
4    xmlns:foaf="http://xmlns.com/foaf/0.1/"
5    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
6    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
7    xmlns:owl="http://www.w3.org/2002/07/owl#"
8    xmlns:dcterms="http://purl.org/dc/terms/"
9    xmlns:ex="http://example.org/vocab#">
 
10   <owl:Ontology rdf:about="">
11     <wdrs:issuedby rdf:resource="http://authority.example.org/company.rdf#me" />
12     <dcterms:issued>2007-12-14T00:00:00</dcterms:issued>
13   </owl:Ontology>
 
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-s#matchesregex" />
18         <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com)(:([0-9]+))?\/</owl:hasValue>
19       </owl:Restriction>
20       <owl:Restriction>
21         <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
22         <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]*)(\:([0-9]+))?(\/foo)</owl:hasValue>
23       </owl:Restriction>
24     </owl:intersectionOf>
25   </owl:Class>

26   <owl:Class rdf:nodeID="iriset_2">
27     <owl:intersectionOf rdf:parseType="Collection">
28       <owl:Restriction>
29         <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
30         <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com)(:([0-9]+))?\/</owl:hasValue>
31       </owl:Restriction>
32       <owl:Restriction>
33         <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
34         <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]*)(\:([0-9]+))?(\/bar)</owl:hasValue>
35       </owl:Restriction>
36     </owl:intersectionOf>
37   </owl:Class>
 
38   <owl:Class rdf:nodeID="descriptorset_1">
39     <owl:intersectionOf rdf:parseType="Collection">
40       <owl:Restriction>
41         <owl:onProperty rdf:resource="http://example.org/vocab#color" />
42         <owl:hasValue>red</owl:hasValue>
43       </owl:Restriction>
44       <owl:Restriction>
45         <owl:onProperty rdf:resource="http://example.org/vocab#shape" />
46         <owl:hasValue>square</owl:hasValue>
47       </owl:Restriction>
48     </owl:intersectionOf>
49     <dcterms:description>Everything on example.com/foo, and everything on example.org/bar, is red and square</dcterms:description>
50     <foaf:depiction rdf:resource="http://example.org/icon.png" />
51   </owl:Class>

52   <owl:Class rdf:nodeID="iriset_1">
53     <rdfs:subClassOf rdf:nodeID="descriptorset_1"/>
54   </owl:Class>

55   <owl:Class rdf:nodeID="iriset_2">
56     <rdfs:subClassOf rdf:nodeID="descriptorset_1"/>
57   </owl:Class>

58 </rdf:RDF>

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 may be 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-9 below contains two descriptions that can be applied to example.org and example.com (defined in the abouthosts element), but those descriptions are not tied to particular IRI sets within a Description Resource.

Example 2-9: A POWDER Document With Descriptors That Can Be Referenced Externally, But With No DRs

POWDER [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      <issuedby src="http://authority.example.org/company.rdf#me" />
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 (which are preserved in POWDER-S). An HTML document at http://www.example.org/page.html might include a link element thus:

Although example 2-9 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. This has implications for the specification of a POWDER Processor. See Section 3 below.

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 an IRI set defined using the appropriate value of the includehosts element. This is because the semantics are different in a subtle but important way:

2.6 Pre-Defined Descriptors

As shown in the previous section, descriptorset elements can exist outside a DR. There are situations where defining descriptor sets independently of any DR but within the same POWDER document can be very convenient, and this is discussed in Section 2.8. This section is concerned with the definition of descriptor sets that can be referred to by DRs in other POWDER documents.

If a POWDER document does not include an abouthosts element in its attribution, then a descriptor set within it that has an identifier of its own may be used to describe any resource. However, this is the job that RDF vocabularies and OWL ontologies are designed for. Therefore, authors are strongly advised to create or use existing examples of either of those in preference to a POWDER document without any restriction on where the descriptions can be applied.

Bearing in mind that warning, some content providers and their suppliers may find it convenient to split Description Resources across several POWDER documents. In example 2-10 below, powder1.xml defines two types of book published by the organization described at http://education.example.org/company.rdf#me related to the UK National Curriculum. The publisher sells their books through two online outlets: books.example.com and archive.example.net and therefore restricts its descriptions to those hosts. powder2.xml describes one of those outlets (books.example.com), which brands its Key Stage 1 products as 'robin' and its Key Stage 2 products as 'starling.' By referring to powder1.xml, books.example.com is able to associate the publisher's relevant icon with the correct pages of its own e-commerce portal.

A POWDER processor MUST take full account of the abouthosts element in powder1.xml when processing the DRs in powder2.xml.

Example 2-10: Example of a Pre-Defined Descriptors Element and its Usage

powder1.xml [XML]

1  <?xml version="1.0"?>
2  <powder xmlns="http://www.w3.org/2007/05/powder#" 
3          xmlns:ex="http://education.example.org/vocab#">

4    <attribution>
5      <issuedby src="http://education.example.org/company.rdf#me" />
6      <abouthosts>books.example.com archive.example.net</abouthosts>
7    </attribution>

8    <descriptorset xml:id="ks1">
9      <displaytext>This material is suitable for UK National Curriculum Key Stage 1</displaytext>
10     <displayicon src="http://education.example.org/ks1.png" />
11   </descriptorset>

12   <descriptorset xml:id="ks2">
13     <displaytext>This material is suitable for UK National Curriculum Key Stage 2</displaytext>
14     <displayicon src="http://education.example.org/ks2.png" />
15   </descriptorset>

16 </powder>

powder2.xml [XML]

1  <?xml version="1.0"?>
2  <powder xmlns="http://www.w3.org/2007/05/powder#">

3    <attribution>
4      <issuedby src="http://books.example.com/company.rdf#me" />
5      <issued>2008-03-03T00:00:00</issued>
6    </attribution>

7    <dr>
8      <iriset>
9        <includehosts>books.example.com</includehosts>
10       <includepathstartswith>/robin/</includepathstartswith>
11     </iriset>
12     <descriptorset src="http://education.example.org/powder1.xml#ks1" />
13   </dr>

14   <dr>
15     <iriset>
16       <includehosts>books.example.com</includehosts>
17       <includepathstartswith>/starling/</includepathstartswith>
18     </iriset>
19     <descriptorset src="http://education.example.org/powder1.xml#ks2" />
20   </dr>

21 </powder>

Given powder2.xml, a POWDER Processor SHOULD use the descriptor sets defined in powder1.xml. Such a step is beyond the GRDDL transform, so that if powder2.xml is transformed, it will create a class that merely has a rdfs:seeAlso annotation thus:

However, given the two documents in Example 2-10, a POWDER Processor MAY go further and transform both and create the documents shown in Example 2-11 below.

Example 2-11: POWDER-S Version of Example 2-10

powder1.rdf [RDF]

1  <rdf:RDF
2    xmlns:wdrs="http://www.w3.org/2007/05/powder-s#"
3    xmlns:foaf="http://xmlns.com/foaf/0.1/"
4    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
5    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
6    xmlns:dcterms="http://purl.org/dc/terms/"
7    xmlns:owl="http://www.w3.org/2002/07/owl#">
 
8    <owl:Ontology rdf:about="">
9      <wdrs:issuedby rdf:resource="http://books.example.com/company.rdf#me" />
10     <dcterms:issued>2008-03-03T00:00:00</dcterms:issued>
11   </owl:Ontology>

12   <owl:Restriction rdf:nodeID="aboutset">
13     <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
14     <owl:hasValue>\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(books\.example\.com|archive\.example\.net)(\:([0-9]+))?\/</owl:hasValue>
15   </owl:Restriction>

16   <owl:Class rdf:ID="ks_1">
17     <owl:intersectionOf rdf:parseType="Collection">
18       <owl:Class rdf:nodeID="aboutset"/>
19     </owl:intersectionOf>
20     <dcterms:description>This material is suitable for UK National Curriculum Key Stage 1</dcterms:description>
21     <foaf:depiction rdf:resource="http://education.example.org/ks1.png" />
22  </owl:Class>

23  <owl:Class rdf:ID="ks_2">
24     <owl:intersectionOf rdf:parseType="Collection">
25       <owl:Class rdf:nodeID="aboutset"/>
26     </owl:intersectionOf>
27     <dcterms:description>This material is suitable for UK National Curriculum Key Stage 2</dcterms:description>
28     <foaf:depiction rdf:resource="http://education.example.org/ks2.png" />
29   </owl:Class>

30 </rdf:RDF>

powder2.rdf [RDF]

1  <rdf:RDF
2     xmlns:wdrs="http://www.w3.org/2007/05/powder-s#"
3     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
4     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
5     xmlns:owl="http://www.w3.org/2002/07/owl#"
6     xmlns:dcterms="http://purl.org/dc/terms/">

7    <owl:Ontology rdf:about="">
8      <wdrs:issuedby rdf:resource="http://education.example.org/company.rdf#me" />
9      <dcterms:issued>2008-03-03T00:00:00</dcterms:issued>
10   </owl:Ontology>

11   <owl:Class rdf:nodeID="iriset_1">
12     <owl:intersectionOf rdf:parseType="Collection">
13       <owl:Restriction>
14         <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
15         <owl:hasValue  rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(books\.example\.com)(\:([0-9]+))?\/</owl:hasValue>
16       </owl:Restriction>
17       <owl:Restriction>
18         <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
19         <owl:hasValue  rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/([^\:\/\?\#\@]+\.)*[^\:\/\?\#\@]+(\:([0-9]+))?(\/robin\/)</owl:hasValue>
20       </owl:Restriction>
21     </owl:intersectionOf>
22   </owl:Class>
  
23   <owl:Class rdf:nodeID="iriset_1">
24     <rdfs:subClassOf rdf:resource="http://education.example.org/powder1.rdf#ks_1"/>
25   </owl:Class>

26   <owl:Class rdf:nodeID="iriset_2">
27     <owl:intersectionOf rdf:parseType="Collection">
28       <owl:Restriction>
29         <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
30         <owl:hasValue  rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(books\.example\.com)(\:([0-9]+))?\/</owl:hasValue>
31       </owl:Restriction>
32       <owl:Restriction>
33         <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
34         <owl:hasValue  rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/([^\:\/\?\#\@]+\.)*[^\:\/\?\#\@]+(\:([0-9]+))?(\/starling\/)</owl:hasValue>
35       </owl:Restriction>
36     </owl:intersectionOf>
37   </owl:Class>
    
38   <owl:Class rdf:nodeID="iriset_2">
39     <rdfs:subClassOf rdf:resource="http://education.example.org/powder1.rdf#ks_2"/>
40   </owl:Class>

41 </rdf:RDF>

The pre-defined descriptions of powder1.xml are translated into resource classes with the appropriate descriptor restrictions, and a class with a nodeID of aboutset is also created to respect the abouthosts element. As noted in the discussion around Example 2.7, this is used as a restriction on the descriptors so that a logical inconsistency is raised if the descriptor sets are used to describe a resource on a different host.

Although abouthosts can provide a useful processing hint in a purely operational POWDER environment as shown in Example 2-6, taking account of it when checking that a particular descriptor set can be applied to a given resource can require significant processing, especially in POWDER-S. Furthermore, it can readily lead to mistakes. Use only when necessary.

2.7 Free Text Tags, Comments, Labels and "See Also"

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-12 below.

Example 2-12: 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      <issuedby src="http://authority.example.org/company.rdf#me" />
6      <issued>2007-12-14T00:00:00</issued>
7    </attribution>
  
8    <dr>
9      <iriset>
10       <includehosts>example.com</includehosts>
11     </iriset>

12     <tagset>
13       <tag>London</tag>
14       <tag>Swiss Re</tag>
15       <tag>gherkin</tag>
16     </tagset>
17   </dr>
18 </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).

The tag element can only be used within a tagset and specifically MUST NOT be used within a descriptorset. This is because the descriptor set element is used to contain values for properties taken from controlled vocabularies expressed in RDF.

Tag sets and descriptor sets can also be associated with other descriptive or informative resources (not necessarily POWDER documents) through the use of the seealso element. This has a src attribute that takes an IRI as shown in the example below. Associating tags with other resources in this way can help to disambiguate them. Each seealso in a descriptorset or tagset is transformed into an rdfs:seeAlso annotation on the relevant OWL class.

Two further rdfs annotation properties are accessible directly in POWDER: label and comment. The usage and transformation from POWDER to POWDER-S of all these properties are shown in the following example.

Example 2-13: Example of a DR Containing a Tagset that Links to Further Information that Puts the Tags in Context

POWDER [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      <issuedby src="http://authority.example.org/company.rdf#me" />
6      <issued>2007-12-14T00:00:00</issued>
7    </attribution>

8    <dr>
9      <iriset>
10       <includehosts>example.com</includehosts>
11     </iriset>

12     <tagset>
13       <label>Tags for the London landmark</label>
14       <tag>London</tag>
15       <tag>Swiss Re</tag>
16       <tag>gherkin</tag>
17       <seealso src="http://encyclopaedia.example.com/gherkin.html" />
18       <seealso src="http://photo.example.com/gherkin.jpg" />
19       <comment>Tags are linked to specific resources that contextualize them</comment>
20     </tagset>
21   </dr>
22 </powder>

POWDER-S [RDF/XML]

1  <?xml version="1.0"?>
2  <rdf:RDF
3    xmlns:wdrs="http://www.w3.org/2007/05/powder-s#"
4    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
5    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
6    xmlns:owl="http://www.w3.org/2002/07/owl#"
7    xmlns:dcterms="http://purl.org/dc/terms/"
8    xmlns:ex="http://example.org/vocab#">
 
9    <owl:Ontology rdf:about="">
10     <wdrs:issuedby rdf:resource="http://authority.example.org/company.rdf#me" />
11     <dcterms:issued>2007-12-14T00:00:00</dcterms:issued>
12   </owl:Ontology>
 
13   <owl:Class rdf:nodeID="iriset_1">
14     <owl:intersectionOf rdf:parseType="Collection">
15       <owl:Restriction>
16         <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregexp" />
17         <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com)(:([0-9]+))?\/</owl:hasValue>
18       </owl:Restriction>
19     </owl:intersectionOf>
20  </owl:Class>
 
21   <owl:Class rdf:nodeID="tagset_1">
22     <rdfs:label>Tags for the London landmark</rdfs:label>
23     <owl:intersectionOf rdf:parseType="Collection">
24       <owl:Restriction>
25         <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#tag" />
26         <owl:hasValue>London</owl:hasValue>
27       </owl:Restriction>
28       <owl:Restriction>
29         <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#tag" />
30         <owl:hasValue>Swiss Re</owl:hasValue>
31       </owl:Restriction>
32       <owl:Restriction>
33         <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#tag" />
34         <owl:hasValue>gherkin</owl:hasValue>
35       </owl:Restriction>
36     </owl:intersectionOf>
37     <rdfs:seeAlso rdf:resource="http://encyclopaedia.example.com/gherkin.html" />
38     <rdfs:seeAlso rdf:resource="http://photo.example.com/gherkin.jpg" />
39     <rdfs:comment>Tags are linked to specific resources that contextualize them</rdfs:comment>
40   </owl:Class>

41   <owl:Class rdf:nodeID="iriset_1">
42     <rdfs:subClassOf rdf:nodeID="tagset_1"/>
43   </owl:Class>

44 </rdf:RDF>

The seealso, label and comment elements are provided simply as shortcuts to avoid having to declare the rdfs namespace in a POWDER document. The relevant rdfs properties MAY be used directly within a tag set or descriptor set and these receive exactly the same semantics in the GRDDL transformation. For clarity, the following two statements are semantically equivalent in a POWDER document:

2.8 Multiple Descriptor Sets and POWDER Flexibility

In much the same way that a Description Resource may contain multiple IRI sets, it may also contain multiple descriptor sets. This is particularly useful where two distinct and independent types of description are applied to different sections of a single Web site. For instance, an editorial policy or trustmark might apply to a whole Web site, whereas a description of the content's suitability for children might vary in different sections, as the following example shows. Here the whole of movie.example.com is covered by the same trustmark with resources that have IRIs with a path beginning with /after9pm identified as only being suitable for adults. By defining descriptor sets separately within the POWDER document, these can be referenced as needed within the DRs without duplicating data. Separately, from the ordered list, the entity described at http://authority.example.org/company.rdf#me has tagged the /latest section with the phrases New Releases and What's Hot.

This example introduces some new elements and attributes, which are detailed below.

Example 2-14: An Ordered List of DRs, each with Multiple Descriptor Sets

POWDER [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      <issuedby src="http://authority.example.org/company.rdf#me" />
6      <issued>2007-12-14T00:00:00</issued>
7    </attribution>

8    <ol>
9      <dr>
10       <iriset>
11         <includehosts>movie.example.com</includehosts>
12         <includepathstartswith>/after9pm</includepathstartswith>
13       </iriset>

14       <descriptorset include="adult" />
15       <descriptorset include="trustmark" />
16     </dr>

17     <dr>
18       <iriset>
19         <includehosts>movie.example.com</includehosts>
20       </iriset>

21       <descriptorset include="allages" />
22       <descriptorset include="trustmark" />
23     </dr>
24   </ol>

25   <descriptorset node="adult">
26     <ex:agemin>18</ex:agemin>
27   </descriptorset>

28   <descriptorset node="allages">
29     <ex:agemin>0</ex:agemin>
30   </descriptorset>

31   <descriptorset node="trustmark">
32     <typeof src="http://trust.example.org/vocab#trustedsite" />
33   </descriptorset>

34   <dr>
35     <iriset>
36       <includehosts>movie.example.com</includehosts>
37       <includepathstartswith>/latest</includepathstartswith>
38     </iriset>

39     <tagset>
40       <tag>New Releases</tag>
41       <tag>What's Hot</tag>
42     </tagset>
43   </dr>
44 </powder>

POWDER [RDF/XML]

1  <?xml version="1.0"?>
2  <rdf:RDF
3     xmlns:wdrs="http://www.w3.org/2007/05/powder-s#"
4     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
5     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
6     xmlns:owl="http://www.w3.org/2002/07/owl#"
7     xmlns:dcterms="http://purl.org/dc/terms/"
8     xmlns:ex="http://example.org/vocab#">
 
9     <owl:Ontology rdf:about="">
10      <wdrs:issuedby rdf:resource="http://authority.example.org/company.rdf#me" />
11      <dcterms:issued>2007-12-14T00:00:00</dcterms:issued>
12    </owl:Ontology>

13    <owl:Class rdf:nodeID="iriset_1">
14      <owl:intersectionOf rdf:parseType="Collection">
15        <owl:Restriction>
16          <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
17          <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.org)(:([0-9]+))?\/</owl:hasValue>
18        </owl:Restriction>
19        <owl:Restriction>
20          <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
21          <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]*)(\:([0-9]+))?(\/after9pm)</owl:hasValue>
22        </owl:Restriction>
23      </owl:intersectionOf>
24    </owl:Class>

25   <owl:Class rdf:nodeID="iriset_1">
26     <rdfs:subClassOf rdf:nodeID="adult"/>
27     <rdfs:subClassOf rdf:nodeID="trustmark"/>
28   </owl:Class>

29   <owl:Class rdf:nodeID="iriset_2">
30     <owl:intersectionOf rdf:parseType="Collection">
31       <owl:Restriction>
32         <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
33         <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.org)(:([0-9]+))?\/</owl:hasValue>
34       </owl:Restriction>
35     </owl:intersectionOf>
36   </owl:Class>

37   <owl:Class>
38     <owl:intersectionOf rdf:parseType="Collection">
39       <owl:Class rdf:nodeID="iriset_2"/>
40       <owl:Class>
41         <owl:complementOf rdf:parseType="Collection">
42           <owl:Class rdf:nodeID="iriset_1"/>
43         </owl:complementOf>
44       </owl:Class>
45     </owl:intersectionOf>
46     <rdfs:subClassOf rdf:nodeID="allages"/>
47     <rdfs:subClassOf rdf:nodeID="trustmark"/>
48   </owl:Class>

49   <owl:Class rdf:nodeID="adult">
50     <owl:intersectionOf rdf:parseType="Collection">
51       <owl:Restriction>
52         <owl:onProperty rdf:resource="http://example.org/vocab#agemin" />
53         <owl:hasValue>18</owl:hasValue>
54       </owl:Restriction>
55     </owl:intersectionOf>
56   </owl:Class>

57   <owl:Class rdf:nodeID="allages">
58     <owl:intersectionOf rdf:parseType="Collection">
59       <owl:Restriction>
60         <owl:onProperty rdf:resource="http://example.org/vocab#agemin" />
61         <owl:hasValue>0</owl:hasValue>
62       </owl:Restriction>
63     </owl:intersectionOf>
64   </owl:Class>

65   <owl:Class rdf:nodeID="trustmark">
66     <owl:intersectionOf rdf:parseType="Collection">
67       <owl:Restriction>
68       </owl:Restriction>
69     </owl:intersectionOf>
70     <rdfs:subClassOf rdf:resource="http://trust.example.org/vocab#trustedsite" />
71   </owl:Class>

72   <owl:Class rdf:nodeID="iriset_3">
73     <owl:intersectionOf rdf:parseType="Collection">
74       <owl:Restriction>
75         <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregexp" />
76         <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(movie\.example\.com)(:([0-9]+))?\/</owl:hasValue>
77       </owl:Restriction>
78        <owl:Restriction>
79          <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
80          <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]*)(\:([0-9]+))?(\/latest)</owl:hasValue>
81        </owl:Restriction>
82     </owl:intersectionOf>
83  </owl:Class>
 
84  <owl:Class rdf:nodeID="tagset_1">
85    <owl:intersectionOf rdf:parseType="Collection">
86      <owl:Restriction>
87        <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#tag" />
88        <owl:hasValue>New Releases</owl:hasValue>
89      </owl:Restriction>
90      <owl:Restriction>
91        <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#tag" />
92        <owl:hasValue>What's Hot</owl:hasValue>
93      </owl:Restriction>
94    </owl:intersectionOf>
95  </owl:Class>

96   <owl:Class rdf:nodeID="iriset_3">
97     <rdfs:subClassOf rdf:nodeID="tagset_1"/>
98   </owl:Class>

99 </rdf:RDF>

As was shown in Example 2-10 above, if the src attribute is set on a descriptorset element in a POWDER document, then the IRI given becomes the object of an rdfs:seeAlso property and, depending on the application environment, it may become the subject of the sub-class assertion. Example 2-14 presents a different situation where the POWDER author has created some descriptor sets and then included them in the DRs. Hence the include attribute is set in lines 14, 15, 21 and 22 of the POWDER document.

Notice also that, rather than using xml:id to identify the descriptor sets, the node attribute is used (lines 25, 28 and 31). The transformation uses these attributes to create rdf:NodeID identifiers for the respective descriptor classes, as is the usual case with POWDER-S documents, so that they can only be referenced (and influenced) within the POWDER document and not from outside.

Line 32 of the POWDER document introduces the typeof element. This is POWDER's method for asserting that all the resources identified in the IRI set are instances of a particular class - i.e. asserting the rdf:type property. In POWDER-S this is effected by asserting a sub-class relationship between the descriptor class and the referred-to class (line 70). In common with the seealso, label and comment elements, typeof is provided as a shortcut. Writing rdf:type directly in a descriptor set has exactly the same semantics.

3 The POWDER Processor

The Protocol for Web Description Resources is designed first and foremost as a simple and efficient method of publishing metadata. A POWDER document contains sufficient information to yield a description of any resource that is within the scope of the DR(s) to which it has access. A key function of a POWDER Processor is therefore to return RDF triples that describe candidate resources.

If u is the URI or IRI of a resource, then as a minimum, a POWDER Processor MUST support the function describe(u) by returning RDF triples that describe u.

A minimal set of formal constraints are placed on how a POWDER Processor must be realized. It may be a component in a user agent or some other application that is able to process the descriptions it returns or a standalone online service. It may use HTTP to collect POWDER documents from the Web or it may act as a gateway to a repository of Description Resources. It will be able to process XML and RDF, and it is highly likely that a real application will support a variety of different functions and options, in particular, one or more of those related to trust as discussed in Section 5; however, a conformant POWDER Processor will support the key describe(u) function.

As an example, imagine a POWDER Processor that has access to the document shown in Example 2-1. The function call describe('http://www.example.com/') would return:

Notice that the description includes a link to the POWDER document from which the data was derived (this is optional). The wdrs:describedby property is discussed further in Section 4.1.3 below.

Where a POWDER Processor has a Web interface, describe(u) SHOULD be the default function available by sending an HTTP GET request to its IRI and including the candidate resource as the value for the parameter u in the query string. The query string should be URL-encoded as defined by XForms 1.0 [XF] such that, if ipp is the IRI of the POWDER Processor, then the above request for a description of http://www.example.com/ would be made by dereferencing the following IRI:

Example 3-1: Example Result from a POWDER Processor [RDF/XML]

<?xml version="1.0"?>
<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:ex="http://example.org/vocab#">
 
  <rdf:Description rdf:about="http://www.example.com/">
    <ex:color>red</ex:color>
    <ex:shape>square</ex:shape>
    <wdrs:describedby rdf:resource="http://...example2-1.xml" />
  </rdf:Description>
 
</rdf:RDF>

If the processor can find no information about the candidate resource within the data available at the time of the request, then it uses the wdrs:notknownto property to return the 'not known' message shown below.

Example 3-2: Example 'Not Known Result' from a POWDER Processor [RDF/XML]

<?xml version="1.0"?>
<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:wdrs="http://www.w3.org/2007/05/powder-s#">
 
  <rdf:Description rdf:about="http://www.example.com/">
    <wdrs:notknownto rdf:resource="ipp" />
  </owl:Ontology>
 
</rdf:RDF>

The range of wdrs:notknownto is the class wdrd:Processor, defined as the class of POWDER Processors.

The value for u may be replaced by the word 'referer', in which case the POWDER Processor SHOULD return a description of the IRI given in the HTTP REFERER field (or the not known response). This allows a POWDER Processor to return descriptions of resources that point to it. For example, an XHTML document published at http://www.example.com/ might include the following link element:

User agents following that link would receive the response shown in Example 3-1. (N.B. Only the behavior of the POWDER processor is specified here; the relationship type of meta is non-normative in this context).

The describe(u) function SHOULD also support an additional optional parameter, d. This is the IRI of a POWDER document and may include a fragment identifier as discussed in Section 2.5. Referring to Example 2-9 we can envisage a document at http://www.example.com/page.html that includes a link element pointing to /powder.xml#red and construct the function call:

describe(http://www.example.com/page.html, http://www.example.com/powder.xml#red)

ipp?u=http%3A%2F%2Fwww.example.com%2F&d=http%3A%2F%2Fwww.example.com%2Fpowder.xml%23red

Alternatively, the document at http://www.example.com/page.html might simply point directly to the POWDER processor with the following link:

<link rel="meta" href="ipp?u=referer&d=http%3A%2F%2Fwww.example.com%2Fpowder.xml%23red" type="application/rdf+xml" />

3.1 Error Handling

In addition to the descriptive or 'not known' responses, a POWDER Processor SHOULD also report errors of which there are two distinct types: data errors and processing errors. We reserve the generic error codes 100 and 200 respectively for these two types of error, with implementors free to define appropriate codes in the range 1xx and 2xx. A client will therefore always be able to determine which type of error has been reported even if it cannot understand the precise nature of that error.

Only one specific error is defined for all conformant POWDER processors: error 101 is raised when a candidate resource is within the scope of a DR that refers to a descriptor set that, through an abouthosts restriction, cannot apply. This can happen where the descriptor set and DR are defined separately as shown in Section 2.6.

Errors are reported using the wdrs:data_error, wdrs:proc_error and wdrs:err_code properties. If data is the IRI of the POWDER document containing the erroneous data, then the processor should return:

In similar fashion, if ipp is the identifier for the processor itself, then an internal error might be reported thus:

3.2 POWDER Processor Conformance Statement

A conformant POWDER Processor will support the describe(u) function in accordance with the specifications set out in this document and those to which it refers as follows. The POWDER processor:

MUST include the ability to process POWDER-BASE documents;
SHOULD include the ability to process POWDER documents;
SHOULD return an informative message if passed a POWDER or POWDER-S document if these are not supported;

For the purposes of the remaining conformance statements, the term POWDER document should be taken to mean both POWDER and POWDER-BASE documents. Similarly, the references to abouthosts apply equally to aboutregex in POWDER-BASE.

SHOULD be able to retrieve POWDER documents from the Web using HTTP;
MAY include the ability to process POWDER-S documents;
MUST check all POWDER documents used in returning a description of u for the presence of the abouthosts element;
MUST ignore all POWDER documents where abouthosts is present and the host component of u is not the same as, or is not a subdomain of, at least one of the hosts listed in abouthosts;
SHOULD return an error if, after this filtering, a DR in an available document refers to a descriptor set defined in one that is not available;
If available through a Web interface, the parameter names u and d MUST be used for the IRI of the resource to be described, and the data source from which the description is to be extracted, respectively;
MAY use one or more instances of the wdrs:describedby property to point to the POWDER document(s) from which the description was obtained;
SHOULD return other error messages, such as detecting that a POWDER document is invalid, unavailable over the network, etc.;
SHOULD NOT, where IRI₁ is in scope of a given DR and dereferencing it redirects to IRI₂, automatically treat IRI₂ as also being in scope of that DR.

The distinctions between how the different encodings of Description Resources arise because all POWDER documents can be transformed into POWDER-BASE. As the name suggests, this is the fundamental format. However, IRI sets are much more easily defined by humans using POWDER, and it is anticipated that it will be the predominant format. Where the processor is associated with a data source that does not make use of POWDER, perhaps using a different transform to create POWDER-BASE from a proprietary format and, due to its application environment, it is known with a high degree of certainty that it will never have to process POWDER documents from other sources, then it clearly will not have to support it (or POWDER-S).

POWDER-S is defined to allow Description Resources to be processed as part of the more general Semantic Web. The application context must therefore determine whether a POWDER processor should support it.

There is no requirement for a processor to use the XSLT transforms associated with the POWDER namespaces so long as the output is consistent with processors that do.

As noted, there are no other formal conformance criteria for a POWDER Processor; however, good implementations will go significantly further. For example, they may:

The inverse of the describe(u) function — 'find resources with these properties' — would be very useful in several of the scenarios set out in the POWDER use cases. Where the processor is acting as a gateway to a specific repository it is likely to be possible to specify a simple syntax for queries that would return DRs or IRI sets that include descriptor sets matching given properties. Since a descriptor set may contain RDF/XML with few constraints, a fully flexible function of this type could only be provided by supporting SPARQL queries against POWDER-S documents, noting that this requires an implementation of the POWDER semantic extension by the requesting agent.

4 Associating Resources and DRs

4.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 several methods to define such a relationship, detailed below.

4.1.1 (X)HTML link Elements

In HTML and XHTML documents, the link element can be used to point to a POWDER document with the relationship type of 'powder' as shown in Example.4-1. The relationship type is defined in the POWDER profile document, which should therefore be referenced in the head tag.

The WG is considering registering the powder relationship type with IANA and the relevant W3C working groups.

Documents MAY also include any of the attribution data from the POWDER document in meta tags. In particular, the issuedby field is likely to be useful to user agents deciding whether or not to fetch the full POWDER document. Any attribution data encoded in meta tags within an HTML document should be the same as that in the POWDER document. In case of discrepancy, the POWDER document should be taken as more authoritative.

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 4-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">
      <meta name="wdr.issuedby" content="http://authority.example.org/company.rdf#me"/>
      <link rel="powder" href="powder.xml" type="application/xml"/>
      <title>Welcome to example.com </title>
   </head>
   <body>
      <p>Today's content is …</p>
   </body>
</html>

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 a more efficient method of associating resources with a POWDER document is to use the HTTP Link Header.

POWDER WG would like to see the HTTP Link Header re-instated as described in Mark Nottingham's (updated) draft (or for the equivalent functionality to be made available in some other fashion). This document and its use for POWDER has been endorsed by the TAG. See Proposal4a and Proposal5 in http://www.w3.org/2001/tag/2008/05/20-minutes#item06. Until such time as the draft is moved to RFC status, the following section is formally flagged as a feature at risk.

4.1.2 HTTP Link Headers

The HTTP Link Header [REF] is an alternative to the HTML link element and has very similar semantics such that the following two links are equivalent:

User agents may discover the location of the POWDER document by inspecting the HTTP Response headers and pass it to a POWDER processor without having to parse the resource itself. This has several distinct advantages:

4.1.3 Semantic Linkage Using the describedby Property

We define the RDF property wdrs:describedby with a domain of rdf:resource and a range of wdrs:Document. This is the class of POWDER documents and is a sub class of foaf:Document.

In formats that support RDF properties directly it is appropriate to link a resource to a POWDER document that describes it through the wdrs:describedby predicate rather than the powder relationship type. 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 4-2 below.

Example 4-2: RDFa snippet using wdrs:describedby [HTML]

1  <html
2    xmlns="http://www.w3.org/1999/xhtml" version="XHTML+RDFa 1.0"
3    xmlns:wdrs="http://www.w3.org/2007/05/powder-s#">
4    <head>
5      <title>The English Civil War</title>
6      <link rel="wdrs:describedby" href="http://ecw.example.org/powder1.xml" />
7    </head>
8    <body>
9      …
10     <p>Charles I came to the throne believing in his 
11     <a href="http://monarchy.example.org/divine_right.html">Divine Right</a> to rule…
12     …
13   </body>
14 </html>

The html element (line 2) includes the version attribute defined in RDFa in XHTML: Syntax and Processing, currently a Candidate Recommendation.

Here the active document is linked to a description through the link element in the head with the relationship type defined using the wdrs:describedby property (line 6). 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 4-2 includes a link to another document on another host in line 11 (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 11-13 in example 4-3 below.

Example 4-3: RDFa snippet using two wdrs:describedby properties [HTML]

1  <html
2    xmlns="http://www.w3.org/1999/xhtml" version="XHTML+RDFa 1.0"
3    xmlns:wdrs="http://www.w3.org/2007/05/powder-s#">
4    <head>
5      <title>The English Civil War</title>
6      <link rel="wdrs:describedby" href="http://ecw.example.org/powder1.xml" />
7    </head>
8    <body>
9      …
10     <p>Charles I came to the throne believing in his 
11        <a about="http://monarchy.example.org/powder2.xml"
12        rev="wdrs:describedby"
13        href="http://monarchy.example.org/divine_right.html">Divine Right</a> to rule...
14     …
15   </body>
16 </html>

Note the use of the rev relationship type in line 12 which effectively switches round the subject and object of the triple. An RDFa processor will extract the following two triples from this snippet:

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 4-4 shows an ATOM feed of the documents discussed in example 4-3 that links to the same two different POWDER documents.

Example 4-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:wdrs="http://www.w3.org/2007/05/powder-s#"
  >
    <wdrs:describedby>http://ecw.example.org/powder1.xml</wdrs: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>
      <wdrs:describedby>http://monarchy.example.org/powder2.xml</wdrs: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 fulfill the role of 'default' description that is then overridden by powder2.xml.

4.2 Linking a Resource to a POWDER Processor to Acquire RDF

As described in Section 3, a POWDER processor may be set up as an online service through which RDF triples about a particular resource may be obtained. The simplest way to achieve this is to append the IRI of the POWDER processor with ?u=referer, adding the IRI of a POWDER data source if necessary, and include it in either an HTML or HTTP Link.

RDF-aware user agents, including those without any POWDER implementation, will be able to process the data received.

4.3 Linking POWDER documents

POWDER documents may refer to each other to facilitate easier discovery by user agents. The more element is a child element of the root element, may appear any number of times, and uses the src attribute to point to external POWDER documents. The data is retained in POWDER-S where it becomes an rdfs:seeAlso property with the POWDER-S document as its subject, as shown in Example 4-5 below.

Example 4-5: A POWDER Document Linking to Another

POWDER [XML]

1  <?xml version="1.0"?>
2  <powder xmlns="http://www.w3.org/2007/05/powder#" 
3        xmlns:ex="http://example.org/vocab#">

4    <more src="http://another.example.com/powder2.xml" />

5    <attribution>
6      <creator ref="http://authority.example.org/company.rdf#me" />
7      <issued>2007-12-14</issued>
8    </attribution>

9    <dr>
10     <iriset>
11       <includehosts>example.com</includehosts>
12     </iriset>

13     <descriptorset>
14       <ex:color>red</ex:color>
15       <ex:shape>square</ex:shape>
16       <displaytext>Everything on example.org is red and square</displaytext>
17       <displayicon ref="http://example.org/icon.png" />
18     </descriptorset>
19   </dr>

20 </powder>

POWDER-S [RDF/XML]

1  <?xml version="1.0"?>
2  <rdf:RDF
3     xmlns:wdrs="http://www.w3.org/2007/05/powder-s#"
4     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
5     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
6     xmlns:owl="http://www.w3.org/2002/07/owl#"
7     xmlns:dcterms="http://purl.org/dc/terms/"
8     xmlns:foaf="http://xmlns.com/foaf/0.1/"
9     xmlns:ex="http://example.org/vocab#">
 
10    <owl:Ontology rdf:about="">
11      <wdrs:issuedby rdf:resource="http://authority.example.org/company.rdf#me" />
12      <dcterms:issued>2007-12-14T00:00:00</dcterms:issued>
13      <rdfs:seeAlso rdf:resource="http://another.example.com/powder2.xml" />
14    </owl:Ontology>
 
15    <owl:Class rdf:nodeID="iriset_1">
16      <owl:intersectionOf rdf:parseType="Collection">
17        <owl:Restriction>
18          <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregexp" />
19          <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com)(:([0-9]+))?\/</owl:hasValue>
20        </owl:Restriction>
21      </owl:intersectionOf>
22    </owl:Class>

23    <owl:Class rdf:nodeID="descriptorset_1">
24      <owl:intersectionOf rdf:parseType="Collection">
25        <owl:Restriction>
26          <owl:onProperty rdf:resource="http://example.org/vocab#color" />
27          <owl:hasValue>red</owl:hasValue>
28        </owl:Restriction>
29        <owl:Restriction>
30          <owl:onProperty rdf:resource="http://example.org/vocab#shape" />
31          <owl:hasValue>square</owl:hasValue>
32        </owl:Restriction>
33      </owl:intersectionOf>
34      <dcterms:description>Everything on example.org is red and square</dcterms:description>
35      <foaf:depiction rdf:resource="http://example.org/icon.png" />
36    </owl:Class>
 
37    <owl:Class rdf:nodeID="iriset_1">
38      <rdfs:subClassOf rdf:nodeID="descriptorset_1"/>
39    </owl:Class>
 
40 </rdf:RDF>

4.4 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 POWDER and POWDER-S documents. The latter would best be exposed through a SPARQL endpoint. It is noteworthy that if a POWDER document is edited, it SHOULD be made available at a new IRI. As a practical step, that IRI is generally best discovered through an HTTP 302 redirect from an IRI published as the 'latest location.'

The publisher is, of course, free to set up whatever system they feel appropriate, but as there are no normative rules it is essential to provide adequate documentation, perhaps including sample queries that yield results that can be processed efficiently.

5 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.

5.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 dcterms:Agent and foaf:Agent. That is, it's part of the description of an entity that creates POWDER documents, not of the POWDER documents themselves. 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. The following snippet repeats the attribution element of Example 2-2 and includes a pointer to a document that describes how to authenticate the Exemplary Description Authority's POWDER documents.

5.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 5-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      <issuedby src="http://authority.example.org/company.rdf#me" />>
5      <issued>2007-12-14T00:00:00</issued>
6      <validfrom>2008-01-01T00:00:00</validfrom>
7      <validuntil>2008-12-31T23:59:59</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 src="http://authority.example.org/icon.png" />
18     </descriptorset>
19   </dr>
10 </powder>

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:

Temporal validity is independent of trust; that is, a POWDER document that is temporally invalid may be trusted by a user (or user agent). Similarly, a temporally valid document may not be trusted. 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 an HTTP cache header is set, the valid until dates are only applicable within the expiry period. Thus a processor MAY NOT continue to use the DR beyond its cache period until a fresh copy of the DR has been retrieved.

There are two further features shown in Example 5-1 that have not been discussed in this document previously.

In line 14, the descriptor set includes the sha1sum element which contains 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 5-1 is providing a very precise description of the document at http://www.example.com/powder.xml. User agents 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 5-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 src attribute of the certifiedby element. Only complete POWDER documents may be certified, not individual DRs.

Example 5-2: Example of the certificate in Example 5-1, expressed in POWDER-S [RDF/XML]

1  <?xml version="1.0"?>
2  <rdf:RDF
3     xmlns:wdrs="http://www.w3.org/2007/05/powder-s#"
4     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
5     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
6     xmlns:owl="http://www.w3.org/2002/07/owl#"
7     xmlns:dcterms="http://purl.org/dc/terms/"
8     xmlns:foaf="http://xmlns.com/foaf/0.1/"
9     xmlns:ex="http://example.org/vocab#">
 
10    <owl:Ontology rdf:about="">
11      <wdrs:issuedby rdf:resource="http://authority.example.org/company.rdf#me" />
12      <dcterms:issued>2007-12-14T00:00:00</dcterms:issued>
13      <wdrs:validfrom>2008-01-01T00:00:00</wdrs:validfrom>
14      <wdrs:validuntil>2008-12-31T23:59:59</wdrs:validuntil>
15    </owl:Ontology>
 
16    <owl:Class rdf:nodeID="iriset_1">
17      <owl:intersectionOf rdf:parseType="Collection">
18        <owl:Restriction>
19          <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
20          <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">^(http\:\/\/www\.example\.com\/powder\.xml)$</owl:hasValue>
21        </owl:Restriction>
22      </owl:intersectionOf>
23    </owl:Class>
  
24    <owl:Class rdf:nodeID="descriptorset_1">
25      <owl:intersectionOf rdf:parseType="Collection">
26        <owl:Restriction>
27          <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#certified" />
28          <owl:hasValue>true</owl:hasValue>
29        </owl:Restriction>
30        <owl:Restriction>
31          <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#sha1sum" />
32          <owl:hasValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</owl:hasValue>
33        </owl:Restriction>
34      </owl:intersectionOf>
35      <dcterms:description>authority.example.org certifies that claims made by example.com are true. Valid throughout 2008.</dcterms:description>
36      <foaf:depiction rdf:resource="http://authority.example.org/icon.png" />
37    </owl:Class>
 
38    <owl:Class rdf:nodeID="iriset_1">
39      <rdfs:subClassOf rdf:nodeID="descriptorset_1"/>
40    </owl:Class>
 
41 </rdf:RDF>

5.2.1 Full Interpretation of Example 5-1

Example 5-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 5-1 can certify that http://www.example.com/powder.xml is true.

First of all, like all POWDER documents, Example 5-1 is attributed to an identified entity. That entity's description is likely to include the authenticate property described in section 5.1, giving information on how its DRs may be authenticated.

Secondly, POWDER supports time-limited assertions (albeit through informal semantics). Operationally, Example 5-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.

5.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.

As an example, the mobileOK scheme allows content providers to claim conformance to a set of Best Practices designed to ensure at least a functional experience on mobile devices. Such a claim may be supported by reference to the mobileOK checker. In the example below, the owners of example.com are making a claim that all the resources on their Web site conform to mobileOK Basic. As supporting evidence, users are welcome to put any resource through the W3C mobileOK checker.

Example 5-3: A DR Claiming Conformance to mobileOK, Supported by the mobileOK Basic Checker [XML]

1  <?xml version="1.0"?>
2  <powder xmlns="http://www.w3.org/2007/05/powder#">

3    <attribution>
4      <issuedby src="http://www.example.com/company.rdf#me" />
5      <issued>2008-06-25T00:00:00</issued>
6      <supportedby src="http://validator.w3.org/mobile/" />
7    </attribution>

8    <dr>
9      <iriset>
10       <includehosts>example.com</includehosts>
11     </iriset>

12     <descriptorset>
13       <typeof src="http://www.w3.org/2008/06/mobileOK#conformant" />
14       <displaytext>The example.com webiste conforms to mobileOK</displaytext>
15       <displayicon src="http://www.w3.org/ICONS/mobileOK.png" />
16     </descriptorset>
17   </dr>

18 </powder>

POWDER-S [RDF/XML]

1  <?xml version="1.0"?>
2  <rdf:RDF
3    xmlns:wdrs="http://www.w3.org/2007/05/powder-s#"
4    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
5    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
6    xmlns:owl="http://www.w3.org/2002/07/owl#"
7    xmlns:dcterms="http://purl.org/dc/terms/"
8    xmlns:foaf="http://xmlns.com/foaf/0.1/"
9    xmlns:ex="http://example.org/vocab#">
 
10   <owl:Ontology rdf:about="">
11     <wdrs:issuedby rdf:resource="http://www.example.com/company.rdf#me" />
12     <dcterms:issued>2008-06-25T00:00:00</dcterms:issued>
13   </owl:Ontology>

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-s#matchesregex" />
18         <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com)(:([0-9]+))?\/</owl:hasValue>
19       </owl:Restriction>
20    </owl:intersectionOf>
21   </owl:Class>

22   <owl:Class rdf:nodeID="descriptorset_1">
23     <owl:intersectionOf rdf:parseType="Collection">
24     </owl:intersectionOf>
25     <rdfs:subClassOf rdf:resource="http://www.w3.org/2008/06/mobileOK#conformant" />
26     <dcterms:description>The example.com webiste conforms to mobileOK</dcterms:description>
27     <foaf:depiction rdf:resource="http://www.w3.org/ICONS/mobileOK.png" />
28   </owl:Class>

29   <owl:Class rdf:nodeID="iriset_1">
30     <rdfs:subClassOf rdf:nodeID="descriptorset_1"/>
31   </owl:Class>

32 </rdf:RDF>

5.4 Trusted Source

Description Resources exist independently of the content they describe and are dereferenced 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.

5.5 Machine Learning

It is a 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.6 Trust Summary

The methods cited here do not comprise an exhaustive list. Other techniques, such as XML Signature [XMLSIG] and Web of Trust [WOT], may be equally applicable. As noted in the introduction, trust is a human judgment that can only be made by weighing the likelihood that the data is true against the consequences of it being false. This judgment is highly dependant on the circumstances under which the need to extend trust arises. It is clear, however, that Description Resources are unlikely to be trusted in isolation and that both their publishers and consumers will only benefit from their existence if one or more techniques for enhancing trust are employed.

6 References

7 Acknowledgements

The editors duly acknowledge the earlier work in this 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 substantially to the operational/semantic model for POWDER, with further contributions from Dan Brickley and support from all members of the POWDER Working Group.

8 Change Log

8.1 Changes since First Public Working Draft

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.

Element Name	Content	Attributes	Cardinality	Introduced
`powder`	`attribution`, `dr`, `ol`, `descriptorset`, `tagset`, `more`		The Root Element	Section 2.1
`attribution`	`issuedby`, `issued`, `abouthosts`, `validfrom`, `validuntil`, RDF/XML (excluding blank nodes)		Required	Section 2.1
`issuedby`	MUST contain or refer to an RDF class (or subclass) of type `foaf:Agent` or `dcterms:Agent`	`src`	Exactly one of these elements is required	Section 2.1
`issued`	`xsd:date`		Optional	Section 2.1
`dr`	`iriset` (1 or more) plus either 1 `descriptorset`, 1 `tagset` or both `descriptorset` and `tagset`		Optional	Section 2.1
`iriset`	See Grouping of Resources document [GROUP]		At least 1 in each `dr`	Section 2.1
`descriptorset`	`displaytext`, `displayicon`, `seealso`, `label`, `comment`, `sha1sum`, `certified`, `supportedby`, RDF/XML (excluding blank nodes), or a reference to another `descriptorset` element. See Formal Semantics document [FORMAL] for full details.	`src`, `include`, `node`	Exactly 1 required as child element of `dr` unless `tagset` is present. Any number may be a child element of `powder`	Section 2.1
`displaytext`	`xsd:string`		Optional	Section 2.1
`displayicon`	None, but the `src` attribute is the IRI of an image and is of type `xsd:anyURI`	`src`	Optional	Section 2.1
`ol`	At least 1 `dr`		Optional	Section 2.3
`abouthosts`	`White space separated list of hosts. When this element is present, descriptions within the document MUST NOT be applied to resources available from other hosts.`		Optional	Section 2.3 and Section 2.6
`tagset`	At least 1 `tag` plus any number of `seelaso`, `label`, `comment`,		Optional	Section 2.7
`tag`	`xsd:string`		At least 1 within a `tagset`	Section 2.7
`seealso`	None, but the `src` attribute is of type `xsd:anyURI`	`src`	Optional	Section 2.7
`label`	None, but the `src` attribute is of type `xsd:anyURI`	`src`	Optional	Section 2.7
`comment`	None, but the `src` attribute is of type `xsd:anyURI`	`src`	Optional	Section 2.7
`typeof`	None, but the `src` attribute is of type `xsd:anyURI`	`src`	Optional	Section 2.8
`more`	None, but the `src` attribute is of type `xsd:anyURI`	`src`	Optional	Section 4.3
`validfrom`	`xsd:date`		Optional	Section 5.2
`validuntil`	`xsd:date`		Optional	Section 5.2
`sha1sum`	A SHA-1 sum of the described resource		Optional	Section 5.2
`certified`	An element of type `xsd:boolean` used when a DR certifies another resource.		Optional	Section 5.2
`certifiedby`	None, but the `src` attribute is of type `xsd:anyURI` which links a DR to another that certifies.	`src`	Optional	Section 5.2
`supportedby`	None, but the `src` attribute is of type `xsd:anyURI` which is a pointer to some other data source that supports the claims made in the DR.	`src`	Optional	Section 5.3

Term	Notes	Type	Introduced
`issuedby`	Sub property of `dcterms:creator` and `foaf:maker`.	RDF Data Property	Section 2.2
`matchesregex`	RDF/OWL tools must understand the POWDER Semantic Extension to process the semantics of this property.	RDF Data Property	Section 2.2
`notknownto`	Property used by a POWDER Processor that it does not have any information about a particular IRI	RDF Data Property	Section 3
`Processor`	The class of POWDER Processors	RDF Class	Section 3
`describedby`	An RDF property that links a described resource to a POWDER document. For use with RDFa and other rich formats.	RDF Data Property	Section 4.1.3
`Document`	The class of POWDER documents	RDF Class	Section 4.1.3
`authenticate`	An RDF property that links a `dcterms:Agent` or `foaf:Agent` class to a resource describing how to authenticate its DRs.	RDF Data Property	Section 5.1

Protocol for Web Description Resources (POWDER): Description Resources

W3C Working Draft — 15 August 2008

Abstract

Status of this document

Table of Contents

1 Introduction

1.1 Operational and Formal Semantics

1.2 Namespaces and Terminology.

2 POWDER Structure and Semantics

2.1 Operational Semantics

2.2 Formal Semantics: POWDER-S

2.3 Exclusive Description Resources

2.4 DRs with Multiple IRI Sets

2.5 Direct Resource Description

2.6 Pre-Defined Descriptors

2.7 Free Text Tags, Comments, Labels and "See Also"

2.8 Multiple Descriptor Sets and POWDER Flexibility

3 The POWDER Processor

3.1 Error Handling

3.2 POWDER Processor Conformance Statement

4 Associating Resources and DRs

4.1 Linking a Resource to a POWDER Document

4.1.1 (X)HTML link Elements

4.1.2 HTTP Link Headers

4.1.3 Semantic Linkage Using the describedby Property

4.2 Linking a Resource to a POWDER Processor to Acquire RDF

4.3 Linking POWDER documents

4.4 Requesting a DR from a Repository

5 Trust

5.1 Discovering the Trust Mechanism: the authenticate Property

5.2 Certification using POWDER

5.2.1 Full Interpretation of Example 5-1

5.3 Supporting Evidence: The supportedby Property

5.4 Trusted Source

5.5 Machine Learning

5.6 Trust Summary

6 References

7 Acknowledgements

8 Change Log

8.1 Changes since First Public Working Draft

8.2 Changes since 17 March 2008

8.3 Changes since 30 June 2008

Appendix A: Summary of POWDER Elements & Properties

A.1 XML Elements (in the wdr namespace)

A.2 RDF/OWL Classes and Properties (in the wdrs namespace)

4.1.1 (X)HTML `link` Elements

4.1.3 Semantic Linkage Using the `describedby` Property

5.1 Discovering the Trust Mechanism: the `authenticate` Property

5.3 Supporting Evidence: The `supportedby` Property

A.1 XML Elements (in the `wdr` namespace)

A.2 RDF/OWL Classes and Properties (in the `wdrs` namespace)