Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a First Public Working Draft designed to put the group's core ideas in the public view and to seek feedback on them. There are two areas in which the working group is particularly calling for input: a detail of the structure of a Description Resource (section 2), and the linkage between resources and their descriptions (section 4). Once these issues have been resolved and text added where indicated, the POWDER Working Group intends to publish revised drafts and ultimately advance the document to Recommendation status. It is noteworthy that the Working Group charter lists the withdrawal of the PICS Recommendations in favor of POWDER among its success criteria and feedback on this would also be welcomed.
Please send comments about this document to public-powderwg@w3.org (with public archive).
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
link ElementsHTTP Response HeaderThe 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 attributable to a named individual, organization or entity that may or may not be the creator of the described resources. This contrasts with more usual metadata that typically applies to a single resource, such as a specific document's title, which is usually provided by its author.
This document sets out how Description Resources (DRs) can be created and published, whether individually or as a bulk data, how to link to DRs from other online resources, and, crucially, how DRs may be authenticated. The aim is to provide a platform through which opinions, claims and assertions about online resources can be expressed by people and exchanged by machines. POWDER has evolved from the data model developed for the final report [XGR] of the Web Content Label Incubator Group [WCL-XG] from which we define a Description Resource as: "a resource that contains a description, a definition of the scope of the description and assertions about both the circumstances of its own creation and the entity that created it."
The method of defining the scope of a DR, that is, defining what is being described, is provided in a separate document: Grouping
of Resources [GROUP]. Companion documents describe the RDF/OWL vocabulary [VOC]
and XML data types [WDRD] that are derived from the Grouping of Resources document and this document, with each term's
domain, range and constraints defined. As each term is introduced in this document, it is linked to its description in the vocabulary document. The
POWDER vocabulary namespace is http://www.w3.org/2007/05/powder# for which we use the QName wdr.
POWDER takes a very broad approach so that it is possible for both the resource creator and third parties to make assertions about all kinds of things, with no architectural limits on the kind of thing they are making claims about. For example, medically proficient organizations might be concerned with properties of the agencies and processes that produce Web content (e.g.. companies, people, and their credentials). Equally, a 'Mobile Web' application might need to determine the properties of various devices such as their screen dimensions, and those device types might be described with such properties by their manufacturer or by others. Although the broad approach is supported, we have focused on Web resources rather than trying to define a universal labeling system for objects.
For further indicative examples of POWDER usage, please refer to the [USECASES]
The following qnames and namespaces are used in this document
| Qname | Namespace |
|---|---|
wdr | http://www.w3.org/2007/05/powder# |
rdf | http://www.w3.org/1999/02/22-rdf-syntax-ns# |
rdfs | http://www.w3.org/2000/01/rdf-schema#" |
owl | http://www.w3.org/2002/07/owl# |
foaf | http://xmlns.com/foaf/0.1/ |
dc | http://purl.org/dc/elements/1.1/ |
dcterms | http://purl.org/dc/terms/ |
In this document, the words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are to be interpreted as described in RFC2119.
White space is any of U+0009, U+000A, U+000D and U+0020. A space-separated list is a string of which the items are separated by one or more space characters (in any order). The string may also be prefixed or suffixed with zero or more of those characters. To obtain the values from a space-separated list user agents MUST replace any sequence of space characters with a single U+0020 character, dropping any leading or trailing U+0020 character, and then chopping the resulting string at each occurrence of a U+0020 character, dropping that character in the process.
A generic example of a Description Resource is shown below, followed by explanatory notes.
Example 2-1: Generic Example of a Description Resource (Graphed)
1 <wdr:DR> 2 <foaf:maker rdf:resource="http://authority.example.org/foaf.rdf#me" /> 3 <dcterms:issued>2007-07-02</dcterms:issued> 4 <wdr:validFrom>2008-07-07</wdr:validFrom> 5 <wdr:validUntil>2008-07-07</wdr:validUntil> 6 <wdr:hasScope> 7 <wdr:ResourceSet> 8 <wdr:includeHosts>example.org</wdr:includeHosts> 9 </wdr:ResourceSet> 10 </wdr:hasScope> 11 <wdr:hasDescriptors> 12 <wdr:Descriptors> 13 <ex:property1>value 1</ex:property1> 14 <ex:property2>value 2</ex:property2> 15 </wdr:Descriptors> 16 </wdr:hasDescriptors> 17 <dc:description>Textual information to display to end users</dc:description> 18 </wdr:DR>
Line 1: A DR is an instance of an OWL class.
Line 2: The FOAF term maker MUST be present
and is used to provide details of who or what created the DR. It is anticipated that
an individual or organization is likely to produce many Description Resources and will publish details, such as name and address, in a centralized
location. The range of foaf:maker is foaf:Agent which has subclasses of foaf:Person and foaf:Organization.
Line 3: A DR SHOULD provide information about when it was created. The Dublin Core [DC] term
issued,
which is a subproperty of the DC term date, is recommended for this purpose.
Line 4: A DR MAY include the date from which it is valid using the validFrom property. If this is absent, the value of the
dcterms:issued property (if present) should be taken as the effective date from which the entity that created the DR will
stand by the claims and assertions made.
Line 5: A DR SHOULD provide information about when it will expire using the validUntil property. This is
the date after which the entity that created the DR will no longer stand by the claims and assertions made. The validUntil date SHOULD be the same as
the HTTP cache header (if set). It is not an error if the cache header has a later date since the data has its own expiry. However, if the
valid until date is after that given in a cache header, a processor MAY legitimately continue to use the DR beyond its cache period.
Lines 7 - 9: A DR MUST include a definition of its scope, that is, the set of resources that it describes. This is linked from the DR using the
hasScope property. The structure and semantics of
the ResourceSet Class is described separately [GROUP].
Lines 13 - 14:The descriptors are contained within an instance of an OWL Class (lines 12-15). The descriptors are
a necessary part of a DR (a Description Resource without a Descriptors class would be meaningless), however, they DO
NOT describe the DR, rather, they describe the resources in the Resource Set that is the scope of the DR. This is a break from the RDF model and means
that a generic RDF/OWL inference engine MUST NOT be used directly to make inferences based on DRs. Generic RDF and OWL tools MAY be used, however, to
validate, extract and process the relevant data, generating triples that can be so used.
Line 17: Where the creator intends the content of a DR to be seen and understood by end users, a textual summary of the
Description Resource may be included using the Dublin Core element description.
End user tools MAY display this directly. If the descriptors can be summarized meaningfully in an image, such as a trustmark or seal of approval, the FOAF term
depiction is appropriate.
N.B. The semantics of what is being described or depicted are important. Any logo belonging to the entity that created the Description
Resource can also be linked using foaf:depiction, however, it should be linked from (is a property of) the entity's description, i.e. the target of
the foaf:maker term, not from the DR directly. Likewise, if the dc:description is a summary just of the
Descriptors then it should be linked from there, not the DR as a whole.
There has been substantial discussion about what the structure of a DR should be. The structure shown here (and assumed throughout the document) flows from the data model developed in the Incubator Activity and is believed to be easy to understand by people creating DRs. The separation of attribution, scope and descriptors is clear.
However, an alternative approach would be to use the hasDescriptors property to link the Resource Set, not the DR, to the Descriptors.
The principal argument for this is that a generic RDF processor would recognize the Descriptors as applying to the Resource Set and therefore make correct inferences. In the model shown above, such a processor might infer, wrongly, that the Descriptors described the DR itself.
Changing to this model would not be without its own problems however. It separates the Resource Set and Descriptors from the rest of the DR and therefore from the (important for expected applications) attribution and validity information.
Both models require some specialized 'POWDER processing' and neither offers significant processing efficiencies.
The working group has been unable to decide which option to take and is therefore keen to receive feedback on this point.
As well as conforming to the POWDER vocabulary [VOC], Description Resources serialized in XML MUST also validate against the XML Schema [WDRD]. This provides POWDER processors with a quick validation route.
The data contained in valid DRs can readily be extracted using a few simple SPARQL queries such as that shown below.
Sample SPARQL query to extract basic data from a DR
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX wdr: <http://www.w3.org/2007/05/powder#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX dcterms: <http://purl.org/dc/terms/>
SELECT DISTINCT ?rs ?ds ?maker ?validFrom ?validUntil ?issued ?desc
WHERE {
?dr rdf:type wdr:DR .
?dr foaf:maker ?maker .
?dr wdr:hasScope ?rs .
?dr wdr:hasDescriptors ?ds .
OPTIONAL {?dr wdr:validFrom ?validFrom}
OPTIONAL {?dr wdr:validUntil ?validUntil}
OPTIONAL {?dr dcterms:issued ?issued}
OPTIONAL {?dr dc:description ?desc}
}
When run against Example 2-1 this query returns the following result:
| rs | Blank node |
|---|---|
| ds | Blank node |
| maker | http://authority.example.org/foaf.rdf#me |
| validFrom | 2008-07-07 |
| validUntil | 2008-07-07 |
| issued | 2007-07-02 |
| desc | Textual information to display to end users |
This provides important data relating to the context of the description (when it was created and when it will expire) and a textual summary of the description. The data also gives the URI of the data to query to find out who creted the DR and indicates that the Resource Set and Descriptors are nested within it as opposed to being in a separate named graph. Two further queries, one each on the Resource Set and Descriptors, returns all the necessary data.
Sample SPARQL queries to extract Resource Set Definition and Descriptors from blank nodes within a DR
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX wdr: <http://www.w3.org/2007/05/powder#>
SELECT DISTINCT ?p ?o
WHERE {
?dr rdf:type wdr:DR .
?dr wdr:hasScope ?rs .
?rs ?p ?o
}
And
SELECT DISTINCT ?p ?o
WHERE {
?dr rdf:type wdr:DR .
?dr wdr:hasDescriptors ?ds .
?ds ?p ?o
}
These return the following data from the Resource Set definition
| p | o |
|---|---|
| http://www.w3.org/1999/02/22-rdf-syntax-ns#type | http://www.w3.org/2007/05/powder#ResourceSet |
| http://www.w3.org/2007/05/powder#includeHosts | example.org |
And this from the Descriptors
| p | o |
|---|---|
| http://www.w3.org/1999/02/22-rdf-syntax-ns#type | http://www.w3.org/2007/05/powder#Descriptors |
| http://example.org/#property1 | value 1 |
| http://example.org/#property2 | value 2 |
Interpretation: if today's date is between 2007-07-07 and 2008-07-07, then the entity identified at http://authority.example.org/foaf.rdf#me asserts that all resources on example.org, and any of its subdomains, have properties 1 and 2 with the values 1 and 2 respectively.
Some examples of using N3 Rules and/or SWRL to be inserted here.
It may be necessary, or convenient, for an entity to create several DRs in order to describe all their Resource Sets.
This may be because the entity wishes to describe certain facets of a Website (for example, semantic keywords, or which resources
are mobile friendly) for intersecting, but not identical, Resource Sets. Since a DR can only scope one Resource Set, the entity would use a
Package incorporating a DR describing each.
Any number of DRs may be encapsulated in a Package. The Package may be retrieved from its own URI, and hence it provides a convenient publication and discovery mechanism for a group of associated DRs (for example, all the DRs which together describe an entire Web site). This allows a content provider to use a common link across all their resources to point to their DR Package.
When the Package is retrieved and processed, the particular Description Resource that applies to the resource that linked to the Package must be determined. The Resource Set (RS) definition within each successive DR must be inspected until a match is found: i.e. when the URL of the resource that linked to the package is contained in that DR's RS scope. Once an applicable DR is found, the DR itself may be retrieved to obtain the descriptors therein.
It is legal for the resource to be in scope of more than one DR, however only the first matching DR in the ordered list will be applied to the linking resource. A resource should only link to Packages wherein one of the DRs describes the resource (otherwise the link would be irrelevant).
The set of all resources described by the DRs in the Package can only be determined fully by taking the union of the Resource Sets of each of the DRs themselves. However, it is useful for the Package to include a processing hint about the range of resources described. As a minimum, a Package SHOULD provide a white space separated list of the hosts on which the described resources are to be found. In more complex situations, it may be appropriate to provide an additional processing hint about what resources are described in a Resource Set. However, processors MAY ignore this information.
Example 3-1: Generic Example of a DR Package
1 <wdr:Package rdf:ID="p1"> 2 <wdr:aboutHosts>example.org</wdr:aboutHosts> 3 <wdr:hasDRs rdf:parseType="Collection"> 4 <wdr:DR rdf:about="#DR1" /> 5 <wdr:DR rdf:about="#DR2" /> 6 … 7 <wdr:DR rdf:about="#DRn" /> 8 </wdr:hasDRs> 9 </wdr:Package>
Line 1 Like a Description Resource, a Package is an instance of an OWL Class.
Lines 2 The value of the aboutHosts property is a white space separated list of hosts. Although the range of this
predicate is the same as includeHosts, its domain and semantics are different. It is a processing hint that applies to the
whole package, not a Resource Set definition. A resource on any of the hosts listed in the value of the aboutHosts property is
not guaranteed to be described by the DRs within the Package although it is reasonable to expect that it will be so.
Lines 3 - 8 are an ordered, closed list of DRs, linked from the Package using the hasDRs property with an RDF parse type of Collection.
The package processor will attempt to find the described resource in the Resource Set of the first
DR. If this proves successful then that DR applies to the described resource, if not, if moves on to the next DR in the Collection. The scope of DRn
should ideally be the host(s) listed in the aboutHosts property of the Package and effectively
provide a default DR (i.e. if the described resource is not found in the other DRs, then it should be in the Resource Set of DRn).
dcterms:isPartOfEach DR within a Package is a DR in its own right. It is possible therefore, especially in highly optimized systems where DRs are cached, that the 'wrong' DR within a Package will be applied by mistake. Consider the case where the first DR in the Package applies to all resources on example.org with a path that contains 'foo'. The second and final DR in the Package just applies to example.org, that is, in effect, all resources on example.org that do not have 'foo' in their path. Given a candidate resource of http://www.example.org/foo.html it is important that the processor checks the first DR before the second to retrieve the DR for the 'foo' resources. This is explicit in the RDF Collection in the Package but if a processor retrieves the DRs from its cache, the relationship within the Package may be lost.
Two requirements flow from this:
isPartOf
with the Package URI as its object.Example 3-2 expands upon that given in 3-1 to show this.
Example 3-2: Expanded version of Example 3-1 (Graphed)
<wdr:Package rdf:ID="p1">
<wdr:aboutHosts>example.org</wdr:aboutHosts>
<wdr:hasDRs rdf:parseType="Collection">
<wdr:DR rdf:about="#DR1" />
<wdr:DR rdf:about="#DR2" />
</wdr:hasDRs>
</wdr:Package>
<wdr:DR rdf:ID="DR1">
<dcterms:isPartOf rdf:resource="#p1" />
<foaf:maker rdf:resource="http://authority.example.org/foaf.rdf#me" />
<dcterms:issued>2007-08-02</dcterms:issued>
<wdr:validUntil>2008-08-02</wdr:validUntil>
<wdr:hasScope>
<wdr:ResourceSet>
<wdr:includeHosts>example.org</wdr:includeHosts>
<wdr:includePathContains>foo</wdr:includePathContains>
</wdr:ResourceSet>
</wdr:hasScope>
<wdr:hasDescriptors>
<wdr:Descriptors>
<ex:colour>blue</ex:colour>
<ex:shape>triangle</ex:shape>
</wdr:Descriptors>
</wdr:hasDescriptors>
<dc:description>Everything on example.org with 'foo' in the URI is blue and triangular</dc:description>
</wdr:DR>
<wdr:DR rdf:ID="DR2">
<dcterms:isPartOf rdf:resource="#p1" />
<foaf:maker rdf:resource="http://authority.example.org/foaf.rdf#me" />
<dcterms:issued>2007-08-02</dcterms:issued>
<wdr:validUntil>2008-08-02</wdr:validUntil>
<wdr:hasScope>
<wdr:ResourceSet>
<wdr:includeHosts>example.org</wdr:includeHosts>
</wdr:ResourceSet>
</wdr:hasScope>
<wdr:hasDescriptors>
<wdr:Descriptors>
<ex:colour>red</ex:colour>
<ex:shape>square</ex:shape>
</wdr:Descriptors>
</wdr:hasDescriptors>
<dc:description>Everything on example.org without 'foo' in the URI is red and square</dc:description>
</wdr:DR>
Importantly, all resources on example.org, whether they have 'foo' in their URI or not, can link to the p1 Package. This is usually easy to arrange through server configuration or HTML templates.
linkFrom PropertyThe model of a Package containing a series of DRs with Resource Sets that can be parsed until a match is found is only applicable if there is a URI structure or some other system that supports it. This is not always the case. For example, some content management systems use numerical URIs that have no readily identifiable structure. This does not mean that there won't be intersecting Resource Sets with different facets that need to be described. However, it does mean that the described resource itself must identify the precise DR that describes it through linking directly to it.
Consider a TV show fan site that has several pages about each of its two main characters, Alice and Bob. The DR for the site includes semantic descriptions for both Alice and Bob, giving their character name, the name of the actor that plays them etc. This helps content aggregators and search engines to identify resources about these popular characters. Both DRs are in the same file at http://www.aliceandbob.example.com/powder.rdf. Pages about Alice contain the link
<link rel="powder" href="http://www.aliceandbob.example.com/powder.rdf#alice" type="application/rdf+xml" />
with pages about Bob having a similar link but with #bob as the fragment identifier (see section 4 for details). Both DRs
have excactly the same scope of aliceandbob.example.com, and both have a valid until date some months hence. Therefore, a POWDER-aware user
agent might legitimately cache the DR related to Alice and apply it equally to pages about Bob. There's nothing in the Resource Set definition to
prevent this since there is no structure to the URIs of the resources on the Web site. The linkFrom property overcomes
this problem.
DRs that have a linkFrom property (with a Boolean value of true) MUST NOT be applied to any resource that
does not explicitly link to it through either an HTTP Response Header or HTML link element. It should be noted that the
linkFrom and dcterms:isPartOf property described in the previous section are mutually exclusive. A DR that has both
properties is invalid.
It is also noteworthy that the linkFrom property provides a mechanism for instantly switching the DR applicable to a particular page.
If the example fan site's home page begins the day being solely about Alice but is updated at noon with breaking news about Bob, changing the
link tag will change the DR that applies to the home page without violating caching rules.
The Alice and Bob fan site example is continued in the next section.
As noted above, when describing content using vocabularies covering different facets, DRs may apply to intersecting but not identical Resource Sets. For example, a large portal may wish to describe its content as being mobile friendly, accessible and/or child-safe. This leads to many permutations since not all content that is mobile-friendly will be child-safe; not all accessible content will be mobile-friendly and so on. To avoid creating Descriptors classes for every permutation, an RDF Collection can be used to create a single Descriptors class with multiple elements.
Continuing the Alice and Bob fan site example, a Collection is used in the following two DRs.
Example 3-3: Example use of an RDF Collection (Graphed)
1 <wdr:DR rdf:ID="Alice"> 2 <foaf:maker rdf:resource="http://authority.example.org/foaf.rdf#me" /> 3 <dcterms:issued>2007-08-02</dcterms:issued> 4 <wdr:validUntil>2008-08-02</wdr:validUntil> 5 <wdr:linkFrom>1</wdr:linkFrom> 6 <wdr:hasScope rdf:resource="#scopeDef" /> 7 <wdr:hasDescriptors rdf:parseType="Collection"> 8 <wdr:Descriptors> 9 <foaf:primaryTopic> 10 <ex:Character> 11 <foaf:name>Alice Smith</foaf:name> 12 <ex:playedBy>Jane Doe</ex:playedBy> 13 </ex:Character> 14 </foaf:primaryTopic> 15 </wdr:Descriptors> 16 <wdr:Descriptors rdf:about="#showProfile" /> 17 </wdr:hasDescriptors> 18 <dc:description>Everything you want to know about Alice</dc:description> 19 </wdr:DR> 20 <wdr:DR rdf:ID="Bob"> 21 <foaf:maker rdf:resource="http://authority.example.org/foaf.rdf#me" /> 22 <dcterms:issued>2007-08-02</dcterms:issued> 23 <wdr:validUntil>2008-08-02</wdr:validUntil> 24 <wdr:linkFrom>1</wdr:linkFrom> 25 <wdr:hasScope rdf:resource="#scopeDef" /> 26 <wdr:hasDescriptors rdf:parseType="Collection"> 27 <wdr:Descriptors> 28 <foaf:primaryTopic> 29 <ex:Character> 30 <foaf:name>Bob Bobbington</foaf:name> 31 <ex:playedBy>John Doe</ex:playedBy> 32 </ex:Character> 33 </foaf:primaryTopic> 34 </wdr:Descriptors> 35 <wdr:Descriptors rdf:about="#showProfile" /> 36 </wdr:hasDescriptors> 37 <dc:description>Everything you want to know about Bob</dc:description> 38 </wdr:DR> 39 <wdr:ResourceSet rdf:ID="scopeDef"> 40 <wdr:includeHosts>aliceandbob.example.com</wdr:includeHosts> 41 </wdr:ResourceSet> 42 <wdr:Descriptors rdf:ID="showProfile"> 43 <ex:fanSiteFor>Alice and Bob's Adventures</ex:fanSiteFor> 44 <dc:copyright>The Exemplary Production Company</dc:copyright> 45 </wdr:Descriptors>
The first DR in Example 3-3, lines 1 - 19, is about Alice and the second, lines 20 - 38, is about Bob.
The scope of both DRs is the same and is defined in a single Resource Set, lines 39 - 40.
Each DR includes an RDF Collection of two Descriptor classes. The first Descriptor class in the Alice DR is specifically about Alice and the first Descriptor class in the second DR is specifically about Bob. The Descriptor class in lines 42 - 45 is common to both DRs.
Lines 5 and 24 show the linkFrom property in use (see previous section).
A significant amount of additional advice on re-using code is provided in the Primer.
This section makes two key assumptions that, at present, may be regarded as unsafe.
We believe that POWDER offers a use case for both and are keen to exchange ideas with others on these issues.
A given resource (hereafter known as the described resource) may relate itself to a DR (or DR package). This relationship must provide enough information for the DR to be retrieved. There are two methods to provide such a relationship, detailed below.
Note that if the related DR does not include the described resource in its Resource Set definition, then the DR cannot be considered valid for the described resource.
link ElementsThe HTML link element's rel attribute defines the relationship of the
link/@href to the HTML document. To relate the document (i.e. the described resource) to a DR, the string powder MUST
be present in the rel attribute. N.B. the value of the rel attribute is a white space separated list so other relationship types may
be included too.
Example 4-1-1: using the link element to relate to a DR
<html>
<head>
<link rel="powder" href="exampleDR.rdf" />
<title>Welcome to example.com </title>
</head>
<body>
<p>Today's content is ....</p>
</body>
</html>
Note that this approach requires the described resource to be requested and parsed in order to find the DR location, which may be a less efficient
method than using a HEAD request (see below). However 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.
Add more detail as required when issues resolved.
HTTP Response HeaderIt is also possible for the described resource, having been requested, to indicate a relationship to the DR in the HTTP response header. Section 19.6.2.4 of RFC 2068, Hypertext Transfer Protocol -- HTTP/1.1, states that the Link entity-header field provides a means for describing a relationship between two resources, generally between the requested resource and some other resource.. The relationship to a DR may be indicated by providing the URI of the DR and the type of relationship, e.g.:
Link: <http://www.example.com/exampleDR.rdf> rel="powder"
Add more detail as required when issues resolved.
describedBy and mapsTo PropertiesIn semantically-rich environments, it is appropriate to link a resource to a DR that describes it through the
describedBy predicate. For example, a document might be part of a collection about a particular topic described
in a DR. Such a document might be annotated using RDFa as shown below.
Example 4-1-3: RDFa snippet using wdr:describedBy
<html xmlns:wdr="http://www.w3.org/2007/05/powder#">
<head><title>The English Civil War</title></head>
<body>
...
<div>
<link rel="wdr:describedBy" href="http://education.example.org/powder.rdf#DR_1" />
<p>Charles I came to the throne believing in his Divine Right to rule...
</div>
</body>
</html>
The describedBy property can point to a DR or a DR Package which should include the resource that
pointed to it in its scope.
A related property, mapsTo, allows resources that already provide a description, such as a tag, to be linked directly to a
POWDER Descriptors class. A typical usage scenario for mapsTo is provided in section 2.3.3 of the POWDER Use Cases and
Requirements document [USECASES]. Here, a user-generated tag - i.e. free text which can be interpreted in multiple ways -
is mapped to a predefined Descriptors class. Thus it is possible to anchor natural language terms in more precise semantics.
N.B. Recall that the semantics of the wdr:Descriptors class is that it is a container for descriptors that are to
be interpreted as being 'one step removed' from whatever points to it, i.e. the relationship is of the form:
The entity that created the DR says that the Descriptors can be applied to any resource in the Resource Set.
The Descriptors do NOT describe the Description Resource. Hence, if something like a user-generated tag is mapped to a POWDER Descriptor class, it is the tagged item that is described, not the tag itself.
The important difference between describedBy and mapsTo is that the former links to a DR that provides the
full description (attribution, scope and description) whereas the latter merely amplifies another descriptive item.
As shown above, a described resource may link to a DR either through a Link HTTP Response Header or, if
the described resource is an HTML document, through an HTML link element. Of the two, the HTTP route is preferred since
a HEAD request (defined in section 9.4 of RFC2616) will return the link to the DR.
The DR may then be requested (or queried) via that URI. This method is particularly useful when the information in the DR
will determine whether the described resource should be requested in full and subsequently delivered.
If there is no HTTP Response Header linking to a DR, and the resource is an HTML document, then it needs to be parsed to discover any links to Description Resources.
Some or all of this next section may be moved to the Primer
This section is informative.
Individuals, organizations or other entities may with to publish any number of Description Resources or packages thereof. Such repositories may be available as a single download and/or may support real-time queries for particular DRs. If real time queries are to be supported, it is appropriate to do so through SPARQL queries. Some examples of useful SPARQL queries are given below, based on the following data.
Sample data for demonstration of template SPARQL queries
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:wdr="http://www.w3.org/2007/05/powder#"
xmlns:ex="http://example.org/#">
<wdr:DR rdf:ID="dr1">
<foaf:maker rdf:resource="http://www.example.org/foaf.rdf#me" />
<dcterms:issued>2007-08-02</dcterms:issued>
<wdr:validUntil>2008-08-02</wdr:validUntil>
<wdr:hasScope>
<wdr:ResourceSet>
<wdr:includeHosts>example.net</wdr:includeHosts>
</wdr:ResourceSet>
</wdr:hasScope>
<wdr:hasDescriptors>
<wdr:Descriptors>
<ex:colour>red</ex:colour>
<ex:shape>square</ex:shape>
</wdr:Descriptors>
</wdr:hasDescriptors>
<dc:description>Everything on example.net is red and square</dc:description>
</wdr:DR>
<wdr:DR rdf:ID="dr2">
<foaf:maker rdf:resource="http://authority.example.org/foaf.rdf#me" />
<dcterms:issued>2007-08-02</dcterms:issued>
<wdr:validUntil>2008-08-02</wdr:validUntil>
<wdr:hasScope>
<wdr:ResourceSet>
<wdr:includeHosts>example.com</wdr:includeHosts>
</wdr:ResourceSet>
</wdr:hasScope>
<wdr:hasDescriptors>
<wdr:Descriptors>
<ex:colour>blue</ex:colour>
<ex:shape>triangle</ex:shape>
</wdr:Descriptors>
</wdr:hasDescriptors>
<dc:description>Everything on example.com is blue and triangular</dc:description>
</wdr:DR>
</rdf:RDF>
For the purposes of this example, the data publisher has guaranteed that every Resource Set definition includes the includeHosts property.
Therefore the following query can be used with confidence to request a simple mapping of hosts against all the DRs available from the repository that describe them.
Sample SPARQL query to create a DR to host mapping
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX wdr: <http://www.w3.org/2007/05/powder#>
SELECT DISTINCT ?dr ?hosts
WHERE {
?dr rdf:type wdr:DR .
?dr wdr:hasScope ?rs .
?rs wdr:includeHosts ?hosts
}
Produces the result
| dr | hosts |
|---|---|
| <…#dr2> | example.com |
| <…#dr1> | example.net |
The more usual real-time request, though, would be for all DRs that describe a given resource. So if the resource for which a description is required is http://www.example.net/geometry.html the following SPARQL query would be appropriate.
Sample SPARQL query to identify a DR applicable to a given host
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX wdr: <http://www.w3.org/2007/05/powder#>
SELECT DISTINCT ?dr ?hosts
WHERE {
?dr rdf:type wdr:DR .
?dr wdr:hasScope ?rs .
?rs wdr:includeHosts ?hosts .
FILTER regex(?hosts, "example.net")
}
Produces the result
| dr | hosts |
|---|---|
| <…#dr1> | example.net |
Having discovered the URI of the DR(s) that describe the host in which we're interested, queries such as those outlined in section 2.1 can be executed.
A classification indicates that a resource has passed a series of tests, meets a set of criteria, or otherwise possesses a pre-defined set of
properties. The classification SHOULD be published as an instance of POWDER's Descriptors class (or subclass thereof) as part of an RDF instance
that indicates the entity or organization that created it. It MAY be possible to derive further details of the classification by further processing.
or the classification may refer solely to documentation. Conceptually, a classification is a Description Resource without a scope that can be referred
to by other Description Resources.
A classification MAY include further classes representing the individual tests, properties or criteria. For example, a classification may be defined as follows:
Example 5-1: Generic Example of a classification scheme
<rdf:Description rdf:about="">
<foaf:maker>
<foaf:Organization>
<foaf:name>The Example Classification Company</foaf:name>
<foaf:nick>EGCC</foaf:nick>
<foaf:homepage rdf:resource="http://classify.example.org/"/>
</foaf:Organization>
</foaf:maker>
<dcterms:issued:2007-07-30</dcterms:issued>
</rdf:Description>
<wdr:Descriptors rdf:ID="red">
<ex:colour>ff0000</ex:colour>
<rdfs:seeAlso rdf:resource="http://classify.example.org/colours.html#red" />
</wdr:Descriptors>
<wdr:Descriptors rdf:ID="green">
<ex:colour>00ff00</ex:colour>
<rdfs:seeAlso rdf:resource="http://classify.example.org/colours.html#green" />
</wdr:Descriptors>
<wdr:Descriptors rdf:ID="blue">
<ex:colour>0000ff</ex:colour>
<rdfs:seeAlso rdf:resource="http://classify.example.org/colours.html#blue" />
</wdr:Descriptors>
A DR can refer to the classifications thus:
<wdr:hasDescriptors rdf:resource="http://classify.example.org/colours#green" />
A notable feature of classifications is that they will often be scalar, that is, one classification will be a sub class of another, forming a cascade. In this scenario, if the author classifies the resource using one classification, other classifications may be inferred. For example, a film that has been passed by a film classification board as 'Suitable for all ages' is also suitable for 12 year olds and 18 year olds.
Example 5-3: Example of a scalar classification scheme
<wdr:Descriptors rdf:ID="eighteen"> <rdfs:label>Suitable for persons aged 18 and over</rdfs:label> <rdfs:isDefinedBy rdf:resource="http://example.org/classifications#eighteen" /> </wdr:Descriptors> <wdr:Descriptors rdf:ID="twelve"> <rdfs:label>Suitable for persons aged 12 and over</rdfs:label> <rdfs:isDefinedBy rdf:resource="http://example.org/classifications#twelve" /> <rdfs:subClassOf rdf:resource="#eighteen" /> </wdr:Descriptors> <wdr:Descriptors rdf:ID="allAges"> <rdfs:label>Suitable for all ages</rdfs:label> <rdfs:isDefinedBy rdf:resource="http://example.org/classifications#all" /> <rdfs:subClassOf rdf:resource="#twelve" /> </wdr:Descriptors>
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, licence-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.
drAuthenticate PropertyAny method provided by a DR author for adding trust to their descriptions needs to be discoverable. To this end,
we define the drAuthenticate property with a domain of foaf:Agent. That is, it's part of
the description of an entity that creates DRs, not of the DRs themselves, and is expected to be discoverable by following the
foaf:maker property (required in all DRs). The range of drAuthenticate 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.
certifiedBy PropertyWhen Description Resources are created by, and remain under the control of, the providers of the content they describe (i.e. they are self-applied), trust may 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 DR are correct. The level of trust that can be placed in the DR 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 6-2-1: Example of a certificate, expressed as a DR
<wdr:DR>
<foaf:maker rdf:resource="http://example.net/foaf.rdf#me" />
<dcterms:issued>2007-07-02</dcterms:issued>
<wdr:validUntil>2008-07-07</wdr:validUntil>
<wdr:hasScope>
<wdr:ResourceSet>
<wdr:includeHosts>example.com</wdr:includeHosts>
<wdr:includeUriPattern>http://www.example.com/powder.rdf#dr1</wdr:includeUriPattern>
</wdr:ResourceSet>
</wdr:hasScope>
<wdr:hasDescriptors http://example.net/vocabulary#certified" />
<dc:description>Example.net certifies that the claims made by example.com are true</dc:description>
<foaf:depiction rdf:resource="http://www.example.net/icons/seal.png" />
</wdr:DR>
The above example DR states that the entity described at http://example.net/foaf.rdf#me certifies that the DR at http://www.example.com/powder.rdf#dr1 is true. This may be displayed to end users as the text 'Example.net certifies that the claims made by example.com are true' and/or as the image available at http://www.example.net/icons/seal.png.
The certification authority in example 6-2-1 is likely to have been paid for its services by the content provider and the latter will be keen to benefit from
the added trust afforded by the certificate. The certificate should therefore be discoverable from examining the original DR and the
certifiedBy property facilitates this. The domain of certifiedBy is a Description Resource and its range is
rdfs:Resource so that, as with drAuthenticate, it may point to a machine-processable or human-readable document.
supportedBy PropertyThe certification mechanism outlined 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 drAuthenticate and certifiedBy, the supportedBy has a range of rdfs:Resource and this
may be either a machine-processable or human-readable document.
Description Resources exist independently of the content they describe and are resolved from a URI 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/rdf+xml" />
The DR 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 the valid until date given in the DR and the fact that a POWDER-aware user agent may cache DRs until that date occurs. The Primer has more to say about this.
It is fundamental aspect of RDF that descriptive terms are explicitly defined by URI. 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.
Text on use of digital signatures to follow.
Text on use of web of trust ideas to follow.
To be added here or in the Primer. Will largely be an updated version of the that created for the XGR.
The editors duly acknowledge the earlier work in thia area carried out by the Web Content Label Incubator Activity, especially the contribution made by Jo Rabin, and the contributions made by all members of the POWDER Working Group.