Please refer to the errata for this document, which may include some normative corrections.
See also translations.
Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document underpins the Protocol for Web Description Resources (POWDER). It describes how the relatively simple operational format of a POWDER document can be transformed through two stages: first into a more tightly constrained XML format (POWDER-BASE), and then into an RDF/OWL encoding (POWDER-S) that may be processed by Semantic Web tools. Such processing is only possible, however, if tools implement the semantic extension defined within this document. The formal semantics of POWDER are best understood after the reader is acquainted with the Description Resources [DR] and Grouping of Resources [GROUP] documents.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is a W3C Recommendation that was developed by the POWDER Working Group.
Please see the Working Group's implementation report and Disposition of Last Call Comments. The disposition of comments received during previous calls are also available. Changes since the previous version of this document are minor in nature and are fully documented in the Change log.
Publication of this Recommendation is synchronized with several other documents:
The W3C Membership and other interested parties are invited to review the document and send comments to public-powderwg@w3.org (with public archive).
This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
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.
The Protocol for Web Description Resources, POWDER, offers a simple method of associating RDF data with groups of resources. Its primary 'unit of information' is the Description Resource (DR). This comprises three elements:
To some extent, this approach is in tension with the core semantics of RDF and OWL. To resolve that tension, it is necessary to extend RDF semantics as described below. In order to minimize the required extension, while at the same time preserving the relatively simple encoding of POWDER in XML which is generally readable by humans, we define a multi-layered approach. The operational semantics, i.e. the encoding of POWDER in XML, is first transformed into a more restricted XML encoding that is less easily understood by humans and depends on matching IRIs against regular expressions to determine whether or not they are within the scope of the DR. This latter encoding is, in its own turn, transformed into the extended-RDF encoding.
This document formalizes the semantics of POWDER to ensure consistency between the different layers. It is of particular importance to RDF/OWL-based, as opposed to purely operational, implementations of POWDER.
The data model makes the attribution element mandatory for all POWDER documents. These may contain any number of Description Resources (DRs) that effectively inherit the attribution of the document as a whole. Descriptor sets may also be included independently of a specific DR, and these too inherit the attribution. This model persists throughout the layers of the POWDER model, which are as follows:
The operational encoding, a dialect of XML, that transports the RDF data. It is expected that POWDER will typically be published and processed in this form.
POWDER's resource grouping methods are mostly geared towards URLs and Information Resources as defined in the Architecture of the World Wide Web [WEBARCH].
This is a largely theoretical XML encoding of POWDER that reduces all means of grouping resources according to their IRI into a single grouping method, that of matching IRIs against arbitrary regular expressions.
POWDER-BASE is provided as a means of formally specifying the semantics of the various IRI grouping methods defined in POWDER. POWDER-BASE is generated automatically from POWDER by means of the GRDDL transform [GRDDL] that is associated with the POWDER namespace and defined in this document.
Elements not concerned with IRI set definition are identical in POWDER and POWDER-BASE.
The Semantic encoding uses a fragment of RDF/OWL that has been extended in a way that facilitates the matching of the string representation of a resource's identifier against a regular expression. The regular expression syntax used is defined by XML schema as modified by XQuery 1.0 and XPath 2.0 Functions and Operators [XQXP].
OWL classes are used to represent sets of resources, grouped according to their IRI and according to their properties (descriptors). Resources are described by asserting that a class that defines a set of IRIs is a sub class of a descriptor-defined class-set. Attribution is provided by way of OWL annotation properties.
A small RDF vocabulary is needed to support POWDER-S. Although it is valid RDF/OWL, generic tools will only be able to process the semantics of POWDER-S if they implement the necessary extension defined in this document.
POWDER-S is generated from POWDER-BASE by means of the GRDDL transform [GRDDL] that is associated with the POWDER namespace. POWDER-S MAY be created directly, but this is generally inadvisable since, whilst a POWDER Processor MUST understand and process POWDER-BASE and SHOULD understand POWDER, it MAY NOT understand and process POWDER-S. The aim of POWDER-S is to make the data available to the broader Semantic Web via GRDDL, not to create an alternative encoding.
The conformance criteria for a POWDER Processor are given in the Description Resources document [DR].
The GRDDL transform from POWDER to POWDER-BASE to POWDER-S is defined in this document. The transform from POWDER to POWDER-BASE only affects elements related to IRI set definition, taking tokens as input and yielding a set of regular expressions as output. Such a transformation will be achievable by several means in different application environments. One available method is to use the XSLT stylesheet associated with the POWDER XML Schema [WDR2B], which uses XSLT 2.
A separate XSLT stylesheet, which only uses XSLT 1 is associated with the POWDER-BASE schema and achieves the more complex task of transforming POWDER-BASE to POWDER-S [B2S]. Both stylesheets are consistent with the normative text in this document, but their syntactic specifics are not normative; in effect, a POWDER processor MAY use different transforms to produce syntactically different but semantically equivalent OWL/RDF for processing POWDER documents.
Description Resources are defined separately [DR] and a further document defines the creation of IRI sets [GROUP]. Readers should be familiar with those documents before proceeding with this one. The full set of POWDER documents also includes its Use Cases, Primer and Test Suite, together with two namespace documents: the POWDER XML schema [WDR] and POWDER-S vocabulary [WDRS].
The POWDER vocabulary namespace is http://www.w3.org/2007/05/powder#
for which we use the prefix wdr
The POWDER-S vocabulary 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# |
xsd | http://www.w3.org/2001/XMLSchema# |
xsl | http://www.w3.org/1999/XSL/Transform |
ex | An arbitrary prefix used to denote an 'example vocabulary' from the example.org domain. |
Unqualified elements in this document are from the wdr
namespace.
In this document, the words MUST, MUST NOT, SHOULD, SHOULD NOT, MAY and MAY NOT are to be interpreted as described in RFC2119 [RFC2119].
For convenience and transparency, we have used the RDF/XML serialization for POWDER-S as we have throughout the document set. Other serializations, such as N3 [N3], are equally valid for POWDER-S. The GRDDL transformations associated with the POWDER namespace, which use XSLT to effect the transform, produces RDF/XML as output.
Examples in this document show fragments of data and each is linked to two external files that mirror the data in the text, one serialized as RDF/XML and one as Turtle [TTL]. However, in order to be valid documents, the external files include generic data not shown in the text that has been taken largely from examples 2-1 and 2-3 in the Description Resources document [DR].
The regular expressions in this documents should be interpreted as per Section 7.6.1 of the XQuery/XPath Recommendation [XQXP].
Conformant implementations of this Recommendation will transform POWDER to POWDER-BASE and/or POWDER-BASE to POWDER-S documents as described in sections 2 - 4.5 below.
The conformance criteria for a POWDER processor are specified in the Description Resources document [DR]. This makes it clear that a conformant POWDER Processor MAY NOT process POWDER-S documents. In applications that do process POWDER-S, however, conformance with this document means that the software will implement the Semantic Extension defined in Section 4.3 such that the results of the queries set out in Section 5 are indistinguishable from those returned from a conformant POWDER Processor working purely with POWDER or POWDER-BASE.
The attribution
element, present in all POWDER documents, provides data about
the authorship, validity period, and other issues that a user or user agent can use
when deciding whether or not to confer their trust on a POWDER document.
Most attribution
elements are not involved in IRI grouping, and as such are untouched during the transformation from POWDER to
POWDER-BASE. The only exception is abouthosts
, which sets an outer limit on the resources described by the
DRs within the document. POWDER abouthosts
elements are translated into
POWDER-BASE aboutregex
elements, as discussed in Section 4.5 below.
Since the attribution
element provides meta-data about the
document itself, it is transformed from POWDER (through POWDER-BASE)
into POWDER-S as annotation properties of an
owl:Ontology
instance
referring to rdf:about=""
(i.e., the current
document).
This data does not receive any further
semantics, but is meaningful to POWDER tools when deciding
whether a POWDER document as a whole should be taken into
account or discarded.
The only exception is the POWDER aboutregex
element, as
discussed in Section 4.5 below.
With the explicit exception of abouthosts
, child elements of
the attribution
POWDER element are reproduced as
OWL annotation properties in the POWDER-S instance. This is always possible as these POWDER
elements are required to have either resource references or datatype values.
This general rule applies to the POWDER elements issuedby
, issued
,
validfrom
, validuntil
, certifiedby
and supportedby
where the only transformation necessary
is to make their (transformed) namespace explicit. In each case the
same string is used as their element name and wdrs
property name. The wdrs:issuedby
property is treated in
the same manner, but is noteworthy as it is required for all POWDER
documents.
POWDER provides a shortcut to avoid the automatic need to declare the rdf
namespace
in all POWDER documents. Where child elements of the attribution
element of a POWDER document
point to an IRI, this is provided as the value of a src
attribute. The GRDDL transformation
renders such attributes as values for rdf:resource
.
Example 2-1 shows the generic semantics of the attribution
element.
POWDER [XML]
1 <attribution> 2 <ex:property1>value</ex:property1> 3 <ex:property2 rdf:resource="http://example.org/foo.rdf#frag" /> 4 <ex:property3 src="http://example.com/bar.rdf#frag" /> 5 </attribution>
1 <owl:Ontology rdf:about=""> 2 <ex:property1>value</ex:property1> 3 <ex:property2 rdf:resource="http://example.org/foo.rdf#frag" /> 4 <ex:property3 rdf:resource="http://example.org/foo.rdf#frag" /> 5 </<owl:Ontology>
As noted above, some elements within the POWDER namespace that are treated differently or have noteworthy semantics:
issuedby
element in POWDER documents MUST
contain an external reference to an RDF resource. This resource
SHOULD identify the creator of the POWDER document; a POWDER
processor MAY use this information to evaluate the trust-worthiness
of the document. There is no restriction on the range of the
wdrs:issuedby
property, but POWDER authors are
advised to use well-known and widely-used vocabularies, such as
Dublin Core [DC] or FOAF [FOAF],
and refer to instances of dc:Agent
or
foaf:Agent
, respectively.issued
, validfrom
,
and validuntil
elements in POWDER documents MUST
contain
a value conformant with the XML dateTime datatype. The
transformation to POWDER-S consists of simply creating annotation
properties in the wdrs
namespace with these values.
The value of issued
SHOULD be the date and time of
formal issuance (e.g., publication) of the document.
The values of validfrom
and validuntil
SHOULD be specifying the validity period of the document.certifiedby
and supportedby
elements in POWDER documents MUST have a src
attribute that has an IRI as its value.abouthosts
element is discussed
in Section 4.5 below.
Example 2-2 below shows all the POWDER-specific attribution
elements. Note that there is no abouthosts
element in the
example, as it will be discussed in
Section 4.3 below.
POWDER [XML]
1 <attribution> 2 <issuedby src="http://example.org/company.rdf#me" /> 3 <issued>2007-12-23T00:00:00</issued> 4 <validfrom>2008-01-01T00:00:00</validfrom> 5 <validuntil>2008-12-31T23:59:59</validuntil> 6 <certifiedby src="http://authority.example/powder.xml" /> 7 <supportedby src="http://service.example.com?id=abc" /> 8 </attribution>
1 <owl:Ontology rdf:about=""> 2 <wdrs:issuedby rdf:resource="http://example.org/company.rdf#me" /> 3 <wdrs:issued>2008-12-23T00:00:00</wdrs:issued> 4 <wdrs:validfrom>2008-01-01T00:00:00</wdrs:validfrom> 5 <wdrs:validuntil>2008-12-31T23:59:59</wdrs:validuntil> 6 <wdrs:certifiedby rdf:resource="http://authority.example/powder.xml" /> 7 <wdrs:supportedby rdf:resource="http://service.example.com?id=abc" /> 8 </owl:Ontology>
There is one final POWDER element that is transformed into an
annotation of the POWDER-S document: the more
element. This may occur as a child
of the root (powder
) element and provides a link from one POWDER document to another.
It is simply transformed into a rdfs:seeAlso
property of the POWDER-S document
(within the ontology header).
Description Resources use vocabularies defined in RDF and/or plain string literals (tags) to describe resources de-referenced from instances of the IRI set. Since descriptor set elements are not involved in the specification of the IRI set itself, they are transferred verbatim from POWDER to POWDER-BASE. Example 3-1 below shows a generic example of a DR in which the IRI set has been elided for clarity (the semantics of the IRI set is discussed in Section 4 below).
1 <dr> 2 <iriset>…</iriset> 3 <descriptorset> 4 <ex:finish rdf:resource="http://example.org/vocab#shiny"/> 5 <ex:shape>square</ex:shape> 6 </descriptorset> 7 <tagset> 8 <tag>red</tag> 9 <tag>light</tag> 10 </tagset> 11 </dr>
The ex:finish
element specifies that the ex:finish
relation
holds between all resources specified by iriset
and the
http://example.org/vocab#shiny resource.
The content of ex:shape
is interpreted as a string literal. The
ex:shape
element specifies that all resources in iriset
have the value "square" for the ex:shape
dataproperty.
tag
is a string property defined by POWDER. Its content is a
single string literal, possibly including spaces.
The overall description of the resources in iriset
is the union of
the descriptions in the descriptorset
and the tagset
. In our example these are:
We formally interpret the above as follows: there is an OWL class
containing all resources that share all of these properties, and there
is an OWL class of all resources denoted by iriset
, and the latter
is a subset of the former. In POWDER-S we say:
1 <owl:Class rdf:nodeID="iriset_1"> 2 all resources specified by <iriset>...</iriset> 3 </owl:Class> 4 <owl:Class rdf:nodeID="descriptorset_1"> 5 <rdfs:subClassOf> 6 <owl:Class> 7 <owl:intersectionOf rdf:parseType="Collection"> 8 <owl:Restriction> 9 <owl:onProperty rdf:resource="http://example.org/vocab#finish"/> 10 <owl:hasValue rdf:resource="http://example.org/vocab#shiny"/> 11 </owl:Restriction> 12 <owl:Restriction> 13 <owl:onProperty rdf:resource="http://example.org/vocab#shape"/> 14 <owl:hasValue>square</owl:hasValue> 15 </owl:Restriction> 16 </owl:intersectionOf> 17 </owl:Class> 18 </rdfs:subClassOf> 19 </owl:Class> 20 <owl:Class rdf:nodeID="tagset_1"> 21 <rdfs:subClassOf> 22 <owl:Class> 23 <owl:intersectionOf rdf:parseType="Collection"> 24 <owl:Restriction> 25 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#tag"/> 26 <owl:hasValue>red</owl:hasValue> 27 </owl:Restriction> 28 <owl:Restriction> 29 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#tag"/> 30 <owl:hasValue>light</owl:hasValue> 31 </owl:Restriction> 32 </owl:intersectionOf> 33 </owl:Class> 34 </rdfs:subClassOf;> 35 </owl:Class> 36 <owl:Class rdf:nodeID="iriset_1"> 37 <rdfs:subClassOf rdf:nodeID="descriptorset_1"/> 38 <rdfs:subClassOf rdf:nodeID="tagset_1"/> 39 </owl:Class>
It is possible to have more than one iriset
element, in which case
a resource receives all of the descriptions by belonging to any
one of the corresponding IRI sets. For example:
1 <dr> 2 <iriset>.1.</iriset> 3 <iriset>.2.</iriset> 4 <descriptorset xml:id="silver"> 5 <ex:finish rdf:resource="http://example.org/vocab#shiny"/> 6 </descriptorset> 7 </dr>
receives the following semantics:
1 <owl:Class rdf:nodeID="iriset_1"> 2 all resources specified by <iriset>.1.</iriset> 3 </owl:Class> 5 <owl:Class rdf:nodeID="iriset_2"> 6 all resources specified by <iriset>.2.</iriset> 7 </owl:Class> 8 <owl:Class rdf:ID="silver"> 9 <rdfs:subClassOf> 10 <owl:Class> 11 <owl:intersectionOf rdf:parseType="Collection"> 12 <owl:Restriction> 13 <owl:onProperty rdf:resource="http://example.org/vocab#finish"/> 14 <owl:hasValue rdf:resource="http://example.org/vocab#shiny"/> 15 </owl:Restriction> 16 </owl:intersectionOf> 17 </owl:Class> 18 </rdfs:subClassOf> 19 </owl:Class> 20 <owl:Class rdf:nodeID="iriset_1"> 21 <rdfs:subClassOf rdf:resource="#silver"/> 22 </owl:Class> 23 <owl:Class rdf:nodeID="iriset_2"> 24 <rdfs:subClassOf rdf:resource="#silver"/> 25 </owl:Class>
Examples 3-3 and 3-4 also show that if a descriptorset
element has an ID of its own, this is used in the POWDER-S document.
This is reflected in the way that the sub class relationship is asserted.
Where no xml:id
attribute is set in the original POWDER document, the transform assigns rdf:nodeID
identifiers for
the blank nodes. As a result, rdf:nodeID
attributes are used within the POWDER-S document in the sub class
assertion (see lines 36 - 39 in Example 3-2). However, where the original POWDER document
includes an xml:id
attribute, as in line 4 of Example 3-3, the sub class assertions in lines 21 and 24
of Example 3-4 is correctly asserted using the rdf:resource
attribute.
A POWDER processor is free to choose any traversal policy for treating multiple iriset
elements in
a DR: first match wins, last match wins, shortest iriset
first, and so on, as long as all iriset
elements are tried before deciding that DR does not apply to a candidate resource (candidate resource is defined in the Grouping of Resources document [GROUP]). However, DR authors may use the
order of the iriset
elements to suggest an efficient scope evaluation strategy, by putting the iriset
with the widest coverage first, so that a processor that chooses to follow the iriset
elements in document order
is more likely to terminate the evaluation after fewer checks.
A POWDER document may have any number of DRs, all of which are simultaneously asserted and ordering is not important. So, for example:
1 <powder> 2 <dr> 3 <iriset>.1.</iriset> 4 <descriptorset> 5 <ex:shape>square</ex:shape> 6 </descriptorset> 7 </dr> 8 <dr> 9 <iriset>.2.</iriset> 10 <descriptorset> 11 <ex:finish rdf:resource="http://example.org/vocab#shiny"/> 12 </descriptorset> 13 </dr> 14 </powder>
receives the following semantics:
1 <owl:Class rdf:nodeID="iriset_1"> 2 all resources specified by <iriset>.1.</iriset> 3 </owl:Class> 4 <owl:Class rdf:nodeID="descriptorset_1"> 5 <rdfs:subClassOf> 6 <owl:Class> 7 <owl:intersectionOf rdf:parseType="Collection"> 8 <owl:Restriction> 9 <owl:onProperty rdf:resource="http://example.org/vocab#shape"/> 10 <owl:hasValue>square</owl:hasValue> 11 </owl:Restriction> 12 </owl:intersectionOf> 13 </owl:Class> 14 </rdfs:subClassOf> 15 </owl:Class> 16 <owl:Class rdf:nodeID="iriset_1"> 17 <rdfs:subClassOf rdf:nodeID="descriptorset_1"/> 18 </owl:Class> 19 <owl:Class rdf:nodeID="iriset_2"> 20 all resources specified by <iriset>.2.</iriset> 21 </owl:Class> 22 <owl:Class rdf:nodeID="descriptorset_2"> 23 <rdfs:subClassOf> 24 <owl:Class> 25 <owl:intersectionOf rdf:parseType="Collection"> 26 <owl:Restriction> 27 <owl:onProperty rdf:resource="http://example.org/vocab#finish"/> 28 <owl:hasValue rdf:resource="http://example.org/vocab#shiny"/> 29 </owl:Restriction> 30 </owl:intersectionOf> 31 </owl:Class> 32 </rdfs:subClassOf> 33 </owl:Class> 34 <owl:Class rdf:nodeID="iriset_2"> 35 <rdfs:subClassOf rdf:nodeID="descriptorset_2"/> 36 </owl:Class>
The owl:intersectionOf
of a singleton collection in both descriptor sets, although redundant, is a result of the GRDDL transformation.
As noted above, syntactically different but semantically equivalent representations are equally valid.
Note that iriset_1
and iriset_2
are not necessarily disjoint — some resources may be both shiny AND square.
A POWDER document may have an ol
element which is an ordered list of DRs. Such a list receives first-match semantics, that
is, when seeking the description of a candidate IRI, processors extract the descriptor set from the first DR in the ordered list in which it
is in scope. ol
elements allow the easy expression of exceptions to more general rules. So, for example:
1 <ol> 2 <dr> 3 <iriset>.1.</iriset> 4 <descriptorset> 5 <ex:shape>square</ex:shape> 6 </descriptorset> 7 </dr> 8 <dr> 9 <iriset>.2.</iriset> 10 <descriptorset> 11 <ex:shape>round</ex:shape> 12 </descriptorset> 13 </dr> 14 <dr> 15 <iriset>.3.</iriset> 16 <descriptorset> 17 <ex:shape>triangular</ex:shape> 18 </descriptorset> 19 </dr> 20 </ol>
receives the following semantics, where belonging to description_1 automatically precludes belonging to description_2 and description_3; and belonging to description_2 automatically precludes belonging to description_3:
1 <owl:Class rdf:nodeID="iriset_1"> 2 all resources specified by <iriset>.1.</iriset> 3 </owl:Class> 4 <owl:Class rdf:nodeID="iriset_1_not"> 5 all resources not specified by <iriset>.1.</iriset> 6 </owl:Class> 7 <owl:Class rdf:nodeID="descriptorset_1"> 8 <rdfs:subClassOf> 9 <owl:Class> 10 <owl:intersectionOf rdf:parseType="Collection"> 11 <owl:Restriction> 12 <owl:onProperty rdf:resource="http://example.org/vocab#shape"/> 13 <owl:hasValue>square</owl:hasValue> 14 </owl:Restriction> 15 </owl:intersectionOf> 16 </owl:Class> 17 </rdfs:subClassOf> 18 </owl:Class> 19 <owl:Class rdf:nodeID="iriset_1"> 20 <rdfs:subClassOf rdf:nodeID="descriptorset_1"/> 21 </owl:Class> 22 <owl:Class rdf:nodeID="iriset_2"> 23 <owl:equivalentClass> 24 <owl:Class> 25 <owl:intersectionOf rdf:parseType="Collection"> 26 all resources specified by <iriset>.2.</iriset> 27 <owl:Class rdf:nodeID="iriset_1_not" /> 28 </owl:intersectionOf> 29 </owl:Class> 30 </owl:equivalentClass> 31 </owl:Class> 32 <owl:Class rdf:nodeID="iriset_2_not"> 33 all resources not specified by <iriset>.2.</iriset> 34 </owl:Class> 35 <owl:Class rdf:nodeID="descriptorset_2"> 36 <rdfs:subClassOf> 37 <owl:Class> 38 <owl:intersectionOf rdf:parseType="Collection"> 39 <owl:Restriction> 40 <owl:onProperty rdf:resource="http://example.org/vocab#shape"/> 41 <owl:hasValue>round</owl:hasValue> 42 </owl:Restriction> 43 </owl:intersectionOf> 44 </owl:Class> 45 </rdfs:subClassOf> 46 </owl:Class> 47 <owl:Class rdf:nodeID="iriset_2"> 48 <rdfs:subClassOf rdf:nodeID="descriptorset_2"/> 49 </owl:Class> 50 <owl:Class rdf:nodeID="iriset_3"> 51 <owl:equivalentClass> 52 <owl:Class> 53 <owl:intersectionOf rdf:parseType="Collection"> 54 all resources specified by <iriset>.3.</iriset> 55 <owl:Class rdf:nodeID="iriset_1_not" /> 56 <owl:Class rdf:nodeID="iriset_2_not" /> 57 </owl:intersectionOf> 58 </owl:Class> 59 </owl:equivalentClass> 60 </owl:Class> 61 <owl:Class rdf:nodeID="descriptorset_3"> 62 <rdfs:subClassOf> 63 <owl:Class> 64 <owl:intersectionOf rdf:parseType="Collection"> 65 <owl:Restriction> 66 <owl:onProperty rdf:resource="http://example.org/vocab#shape"/> 67 <owl:hasValue>triangular</owl:hasValue> 68 </owl:Restriction> 69 </owl:intersectionOf> 70 </owl:Class> 71 </rdfs:subClassOf> 72 </owl:Class> 73 <owl:Class rdf:nodeID="iriset_3"> 74 <rdfs:subClassOf rdf:nodeID="descriptorset_3"/> 75 </owl:Class>
The GRDDL transformation does a lot of work here so let's break it down:
For each IRI set in the DR, two classes are defined: one that represents all resources that are members of the IRI set (as in the earlier examples) and another that defines all the resources that are not members of the IRI set (how this is done is the subject of Section 4). In the example these are given the nodeIDs iriset_n and iriset_n_not.
It should be noted any iriset_n_not class includes the resources that are not included in the raw IRI set definition, as opposed to the iriset_n class which excludes the resources in the previous irisets (see lines 27, 55 & 56).
The following assertion is made: the intersection of the iriset of the current DR and the 'not' irisets from all preceding DRs is subsumed under the descriptorset (or tagset) of the current DR. (Note that there must be only one IRI set generated for each DR, possibly using owl:unionOf, regardless of how the POWDER/XML original is expressed.)
It follows that the first DR in the list yields a simple sub class relationship between its IRI set(s) and descriptor set(s); and that the final DR in the list's 'iriset_not' is not used and may safely be omitted.
A descriptor set contains RDF properties that have fillers that are not blank nodes and that do not identify either a class or a property, as shown in Example 3-9 below. Subsumption of descriptorsets is expressed as discussed in Section 3.2.2 below.
POWDER [XML]
1 <descriptorset> 2 <ex:shape>square</ex:shape> 3 <ex:finish rdf:resource="http://example.org/vocab#shiny"/> 4 </descriptorset>
1 <owl:Class rdf:nodeID="descriptorset_1"> 2 <rdfs:subClassOf> 3 <owl:Class> 2 <owl:intersectionOf rdf:parseType="Collection"> 3 <owl:Restriction> 4 <owl:onProperty rdf:resource="http://example.org/vocab#shape"/> 5 <owl:hasValue>square</owl:hasValue> 6 </owl:Restriction> 7 <owl:Restriction> 8 <owl:onProperty rdf:resource="http://example.org/vocab#finish"/> 9 <owl:hasValue rdf:resource="http://example.org/vocab#shiny"/> 12 </owl:Restriction> 13 </owl:intersectionOf> 14 </owl:Class> 15 </rdfs:subClassOf> 16 </owl:Class>
rdf:type
RelationshipAsserting the rdf:type
property, i.e. that all elements within an IRI set are instances of a particular OWL or RDFS Class,
is achieved most easily using the typeof
element which takes the IRI of the class as the value of its src
attribute
as shown in Example 3-10 below. The POWDER-S translation of the descriptorset
element
intersects typeof
classes with the property
restrictions (if any) in the descriptorset
.
POWDER [XML]
1 <descriptorset> 2 <typeof src="http://example.org/vocab#Conformance_Class" /> 3 <ex:shape>square</ex:shape> 4 </descriptorset>
1 <owl:Class rdf:nodeID="descriptorset_1"> 2 <rdfs:subClassOf> 3 <owl:Class> 4 <owl:intersectionOf rdf:parseType="Collection"> 5 <owl:Class rdf:about="http://example.org/vocab#Conformance_Class" /> 6 <owl:Restriction> 7 <owl:onProperty rdf:resource="http://example.org/vocab#shape"/> 8 <owl:hasValue>square</owl:hasValue> 9 </owl:Restriction> 10 </owl:intersectionOf> 11 </owl:Class> 12 </rdfs:subClassOf> 13 </owl:Class>
This is particularly useful in the context of the POWDER use cases [USECASES] when claiming that resources on a Web site conform to a published set of criteria. In such situations, multiple criteria can be grouped together by defining the class of resources that satisfy all the criteria as the intersection of a number of property restrictions; series of increasingly stricter conformance levels can be defined as a subsumption hierarchy of such classes.
If used directly, the rdf:type
property will be treated in the same way as
the typeof
element in the POWDER to POWDER-S transform.
A descriptor set may defer to a second descriptor set in another
POWDER document using the src
attribute. The transformation uses the
value of the src
attribute directly in the sub class relationship as shown below.
POWDER [XML]
<descriptorset src="http://remote.example.org/powder2.xml#d1" />
<owl:Class rdf:nodeID="iriset_1"> <rdfs:subClassOf rdf:resource="http://remote.example.org/powder2.xml#d1"/> </owl:Class>
There are two POWDER elements that can be included as child elements of descriptorset
that
are mapped to property restrictions in POWDER-S. In both cases the same string is used as the element
name in POWDER and vocabulary term in POWDER-S:
sha1sum
certified
xsd:boolean
used when a DR certifies another resource.The usage of both sha1sum
and certified
is shown in
section 5.2 of the Description Resources document [DR].
We define further elements that can be included as child elements of descriptorset
that, when transformed into POWDER-S, become annotation properties of the descriptive OWL class (not property restrictions).
displaytext
wdrs:text
. The text
supplied as the value of this element may be displayed in user
agents.displayicon
src
attribute, the value of which is a URI
(or IRI) u which, in POWDER-S, becomes
wdrs:logo rdf:resource="u"
. The
referred-to image may be displayed in user agents.seealso
, label
, comment
rdfs
vocabulary
with which it shares a local name. For the avoidance of doubt:
<seealso src="http://www.example.com/page.html" />
<label>An example to us all</label>
<comment>Comments make code easier to read</comment>
are transformed into:
<rdfs:seeAlso rdf:resource="http://www.example.com/page.html" />
<rdfs:label>An example to us all</rdfs:label>
<rdfs:comment>Comments make code easier to read</rdfs:comment>
Usage of these elements is exemplified in the following section. As with rdf:type
, they
are provided as shortcuts within POWDER — the direct use of rdfs:seeAlso
,
rdfs:comment
and rdfs:label
will be rendered in exactly the same way (as annotations and not property restrictions)
by the transform.
No other property from the rdfs
namespace receives any
special treatment. If it is meaningful, in a POWDER document, to use
terms from the rdfs
vocabulary other than those mentioned
above, the POWDER author should be aware that they will be transformed
into OWL property restrictions in exactly the same manner as
properties from any other namespace.
POWDER [XML]
1 <tagset> 2 <label>Tags for the London landmark</label> 3 <tag>London</tag> 4 <tag>Swiss Re</tag> 5 <tag>gherkin</tag> 6 <seealso src="http://encyclopaedia.example.com/gherkin.html" /> 7 <seealso src="http://photo.example.com/gherkin.jpg" /> 8 <comment>Tags are linked to specific resources that contextualize them</comment> 9 </tagset>
1 <owl:Class rdf:nodeID="tagset_1"> 2 <rdfs:label>Tags for the London landmark</rdfs:label> 3 <rdfs:subClassOf> 4 <owl:Class> 3 <owl:intersectionOf rdf:parseType="Collection"> 4 <owl:Restriction> 5 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#tag" /> 6 <owl:hasValue>London</owl:hasValue> 7 </owl:Restriction> 8 <owl:Restriction> 9 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#tag" /> 12 <owl:hasValue>Swiss Re</owl:hasValue> 13 </owl:Restriction> 14 <owl:Restriction> 15 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder#tag" /> 16 <owl:hasValue>gherkin</owl:hasValue> 17 </owl:Restriction> 18 </owl:intersectionOf> 19 </owl:Class> 20 </rdfs:subClassOf> 21 <rdfs:seeAlso rdf:resource="http://encyclopaedia.example.com/gherkin.html" /> 22 <rdfs:seeAlso rdf:resource="http://photo.example.com/gherkin.jpg" /> 23 <rdfs:comment>Tags are linked to specific resources that contextualize them</rdfs:comment> 24 </owl:Class>
The previous sections have shown that the semantics of several elements of a POWDER document can be obtained by applying the GRDDL transform associated with the namespace to generate native RDF/OWL as POWDER-S. This is not so for the IRI set element which, although transformed into valid RDF/OWL syntax, does not express the full semantics.
The IRI constraints defined in the POWDER Grouping of Resources document [GROUP] are given regular-expression semantics by the first part of the GRDDL transform from POWDER to POWDER-BASE. Regular-expression IRI groups are, in their turn, given semantics using datarange restrictions by the POWDER-BASE to POWDER-S transformation. It is noteworthy that the value space of POWDER's IRI constraints is, for the most part, a white space separated list of alternative values. This makes POWDER in its XML form relatively simple, but the implications for the semantics are substantial.
Many elements of a POWDER IRI set definition have white space separated lists of strings as their value. 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. The GRDDL transform associated with the POWDER namespace converts these into components of a regular expression for use in POWDER-BASE and POWDER-S by following the steps set out below:
. \ ? * + { } ( ) [ ] ! " # % & ' , - / : ; = > @ [ ] _ ` ~
The resulting string is used in a template regular expression to give the element and list's desired semantics. For example
<includehosts>example.com example.org </includehosts>
becomes
<owl:Restriction>
<owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
<owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com|example\.org)(\:([0-9]+))?\/</owl:hasValue>
</owl:Restriction>
POWDER's use cases involve information resources available on the Web, identified by IRIs containing host names, directory paths,
IP addresses, port numbers, and so on. To make it as easy as possible to create IRI sets we define a series of IRI constraints in
the Grouping of Resources document [GROUP]. These all receive semantics through being mapped to
includeregex
and excluderegex
elements in POWDER-BASE.
Re-visiting the example given in the previous section, the POWDER element
<iriset> <includehosts>example.com example.org</includehosts> </iriset>
is expressed in POWDER-BASE as:
<iriset> <includeregex>\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com|example\.org)(:([0-9]+))?\/<includeregex> </iriset>
IRIs are always interpreted as strings, even if they include numerical parts such as ports and IP numbers as shown in the following example:
POWDER: [XML]
<iriset> <includehosts>example.com example.org</includehosts> <includeports>80 8080 8081 8082</includeports> </iriset>
POWDER-BASE: [XML]
<iriset> <includeregex>\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com|example\.org)(\:([0-9]+))?\/</includeregex> <includeregex>\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)*[^\:\/\?\#\@]+\:(80|8080|8081|8082)\/</includeregex> </iriset>
This approach is applied to several of the POWDER IRI set elements. The following table shows these and their associated template regular expressions. In each case, var means the value of the POWDER element after processing as defined in Section 4.1.
POWDER IRI Constraint ( include/exclude... | POWDER-BASE Regular Expression (used in includeregex/excluderegex ) |
---|---|
schemes | ^var\:\/\/ |
hosts | \:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?var(\:([0-9]+))?\/ |
ports | \:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)*[^\:\/\?\#\@]+\:var\/ |
exactpaths | \:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]*)(\:([0-9]+))?var($|\?|\#) |
pathcontains | \:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]*)(\:([0-9]+))?\/[^\?\#]*var[^\?\#]*[\?\#]? |
pathstartswith | \:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]*)(\:([0-9]+))?var |
pathendswith | \:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]*)(\:([0-9]+))?\/[^\?\#]*var($|\?|\#) |
resources | ^var$ |
Note that the Grouping of Resources document [GROUP] sets out a
data processing and canonicalization process that must be followed. This
has particular implications for the ihost
component of IRIs as the regular
expressions must match their IDNA ASCII representation [RFC 3490], whereas
for the rest of the IRI components the regular expressions must match
their Unicode representations. Furthermore, where the port number is
constrained, default port numbers for the relevant scheme must be taken
into account.
Two further pairs of IRI set constraints defined in the Grouping of Resources document undergo additional processing when transformed
from POWDER to POWDER-BASE: includequerycontains
and includeiripattern
(and their 'exclude' counterparts). Each of
these maps to multiple elements in the POWDER-BASE document as shown in the following subsections.
includequerycontains
and excludequerycontains
take a single value, not a white space separated list of values.
Furthermore, an attribute delimiter
takes a single character that delimits the name/value pairs in the query string. If
no such attribute is set, the ampersand (&
) character is used as the default. To transform these elements from
POWDER to POWDER-BASE regular expressions the following steps are carried out:
includeregex
or excluderegex
as appropriate
using the following regular expression template:
\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]*)(\:([0-9]+))?\/[^\?\#]*\?([^\#]*d)?q(d|$)
This transformation is exemplified below.
POWDER: [XML]
<iriset> <includehosts>example.org</includehosts> <includequerycontains>id=123456&group=abcdefg</includequerycontains> </iriset>
POWDER-BASE: [XML]
<iriset> <includeregex>\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.org)(\:([0-9]+))?\/</includeregex> <includeregex>\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]*)(\:([0-9]+))?\/[^\?\#]*\?([^\#]*\&)?id=123456(\&|$)</includeregex> <includeregex>\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]*)(\:([0-9]+))?\/[^\?\#]*\?([^\#]*\&)?group=abcdefg(\&|$)</includeregex> </iriset>
includeiripattern
and excludeiripattern
also take a single value, not a white space separated list of values,
and generate includeregex
and excluderegex
elements in POWDER-BASE as follows:
(([^:/\?\.]+):)?(//)?([^:/\?#@]+)(:([0-9]+))?
from which $2 is a constraint on the scheme, $4 is a constraint on the host and $6 is a constraint on the port (the host is always constrained, $2 and $6 may be empty).
[A-Za-z]+
(\:[0-9]+)?
,
else let p be \:
p
Else if h matches the regular expression
^\*\.(.*)
then let h be
([^\:\/\?\#\@]+\.)+$1
([^\:\/\?\#\@]+\.)*h
<includeregex>^s\:\/\/hp</includeregex>
The following example shows these steps.
POWDER: [XML]
<iriset> <includeiripattern>http://*.example.org:8080</includeiripattern> </iriset>
POWDER-BASE: [XML]
<iriset>
<includeregex>^http\:\/\/([^\:\/\?\#\@]+\.)+example.org:8080</includeregex>
</iriset>
Incidentally, the IRI set defined here is 'all resources on all subdomains of example.org (but not on example.org) accessed via HTTP through port 8080.'
Providing OWL/RDF semantics for iriset
elements is not directly
possible, since RDF does not provide any means for accessing or
manipulating the string representation of an IRI.
POWDER-S uses two OWL DatatypeProperties
(wdrs:matchesregex
and wdrs:notmatchesregex
) to relate resources
to regular expressions which that resource matches. While
POWDER-S uses OWL classes to group resources, any engine determining if a resource
belonged in one of these OWL classes would need to be able to test a resource against
a regular expression.
wdrs:matchesregex rdf:type owl:DatatypeProperty . wdrs:matchesregex rdfs:range xsd:string . wdrs:notmatchesregex rdf:type owl:DatatypeProperty . wdrs:notmatchesregex rdfs:range xsd:string .
We further stipulate that <x, reg> is in IEXT(I(wdrs:matchesregex)) if and only if:
and that <x, reg> is in IEXT(I(wdrs:notmatchesregex)) if and only if:
It is now possible to express includeregex
and excluderegex
as
owl:hasValue
restrictions [OWL] on
wdrs:matchesregex
and wdrs:notmatchesregex
respectively
and build up an OWL Class to represent the IRI set in the POWDER-S encoding. Furthermore,
asserting a rdfs:subClassOf
relationship between an iriset and a
descriptorset expresses the claim that the resources in the former are described
by the latter.
The following example takes a complete example POWDER document through POWDER-BASE to POWDER-S. Note that the only change from POWDER to POWDER-BASE is in the elements within the IRI set.
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 example.org</includehosts> 11 <excludeports>8080 8081 8082</excludeports> 12 </iriset> 13 <descriptorset> 14 <ex:color>red</ex:color> 15 <ex:shape>square</ex:shape> 16 <displaytext>Everything on example.org and example.com is red and square</displaytext> 17 <displayicon src="http://example.org/icon.png" /> 18 </descriptorset> 19 </dr> 20 </powder>
POWDER-BASE [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 <includeregex>\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com|example\.org)(\:([0-9]+))?\/</includeregex> 11 <excluderegex>\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)*[^\:\/\?\#\@]+\:(8080|8081|8082)\/</excluderegex> 12 </iriset> 13 <descriptorset> 14 <ex:color>red</ex:color> 15 <ex:shape>square</ex:shape> 16 <displaytext>Everything on example.org and example.com is red and square</displaytext> 17 <displayicon src="http://example.org/icon.png" /> 18 </descriptorset> 19 </dr> 20 </powder>
1 <?xml version="1.0"?> 2 <rdf:RDF 3 xmlns:wdrs="http://www.w3.org/2007/05/powder-s#" 4 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 5 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" 6 xmlns:owl="http://www.w3.org/2002/07/owl#" 7 xmlns:ex="http://example.org/vocab#"> 8 <owl:Ontology rdf:about=""> 9 <wdrs:issuedby rdf:resource="http://authority.example.org/company.rdf#me" /> 10 <wdrs:issued>2007-12-14</wdrs:issued> 11 </owl:Ontology> 12 <owl:Class rdf:nodeID="iriset_1"> 13 <owl:equivalentClass> 14 <owl:Class> 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|example\.org)(\:([0-9]+))?\/</owl:hasValue> 19 </owl:Restriction> 20 <owl:Restriction> 21 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#notmatchesregex" /> 22 <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)*[^\:\/\?\#\@]+\:(8080|8081|8082)\/</owl:hasValue> 23 </owl:Restriction> 24 </owl:intersectionOf> 25 </owl:Class> 26 </owl:equivalentClass> 27 </owl:Class> 28 <owl:Class rdf:nodeID="descriptorset_1"> 29 <rdfs:subClassOf> 30 <owl:Class> 31 <owl:intersectionOf rdf:parseType="Collection"> 32 <owl:Restriction> 33 <owl:onProperty rdf:resource="http://example.org/vocab#color" /> 34 <owl:hasValue>red</owl:hasValue> 35 </owl:Restriction> 36 <owl:Restriction> 37 <owl:onProperty rdf:resource="http://example.org/vocab#shape" /> 38 <owl:hasValue>square</owl:hasValue> 39 </owl:Restriction> 40 </owl:intersectionOf> 41 </owl:Class> 42 </rdfs:subClassOf> 43 <wdrs:text>Everything on example.org and example.com is red and square</wdrs:text> 44 <wdrs:logo rdf:resource="http://example.org/icon.png" /> 45 </owl:Class> 46 <owl:Class rdf:nodeID="iriset_1"> 47 <rdfs:subClassOf rdf:nodeID="descriptorset_1"/> 48 </owl:Class> 49 </rdf:RDF>
It should be noted that excluderegex
is expressed as a
wdrs:notmatchesregex
restriction as opposed to the complement of
a wdrs:matchesregex
restriction for the following reason:
according to OWL open-world semantics, the absence of a
wdrs:matchesregex
triple does not entail membership in the complement
of a wdrs:matchesregex
restriction. Furthermore, it is practically
impossible to enumerate the possible regular expressions and use
owl:DataRange
to locally close the interpretation and be
able to infer membership in the complement of hasValue
restrictions.
Similarly, the union of wdrs:notmatchesregex
restrictions is used to define the complements of iriset classes, for
the purpose of expressing ordered lists of DRs
(see Section 3.1 above). In this manner,
the iriset_1_not
and iriset_2_not
classes
of Example 3-8 are defined as follows:
1 <owl:Class rdf:nodeID="iriset_1_not"> 2 <owl:equivalentClass> 3 <owl:Class> 2 <owl:unionOf rdf:parseType="Collection"> 3 <owl:Restriction> 4 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#notmatchesregex" /> 5 <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com)(:([0-9]+))?\/</owl:hasValue> 6 </owl:Restriction> 7 <owl:Restriction> 8 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#notmatchesregex" /> 9 <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]*)(\:([0-9]+))?\/foo</owl:hasValue> 12 </owl:Restriction> 13 </owl:unionOf> 14 </owl:Class> 15 </owl:equivalentClass> 16 </owl:Class> 17 <owl:Class rdf:nodeID="iriset_2_not"> 18 <owl:equivalentClass> 19 <owl:Class> 20 <owl:unionOf rdf:parseType="Collection"> 21 <owl:Restriction> 22 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#notmatchesregex" /> 23 <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com)(:([0-9]+))?\/</owl:hasValue> 24 </owl:Restriction> 25 <owl:Restriction> 26 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#notmatchesregex" /> 27 <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]*)(\:([0-9]+))?\/bar</owl:hasValue> 28 </owl:Restriction> 29 </owl:unionOf> 30 </owl:Class> 31 </owl:equivalentClass> 32 </owl:Class>
Software can distinguish those RDF graphs to
which the extended semantics apply by testing for the appearance of
either the wdrs:matchesregex
or the
wdrs:notmatchesregex
resource as the object of a
triple. For instance, in Example 4-4 the following class description
suffices to recognize a document that uses the semantic extension:
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|example\.org)(\:([0-9]+))?\/</owl:hasValue> 19 </owl:Restriction>
POWDER and, consequently, POWDER-BASE documents might
include descriptorset
elements that are not
inside a dr
element but directly subsumed by the
document's root. Such descriptions are not meant to be implicitly
applied to any IRI groups, but are only made available by explicit
reference by resources, as explained in Section 2.5 of
the Description Resources document [DR].
In POWDER-S, such descriptions are translated into classes, but no
subsumption of an IRI group is asserted, as shown in Example 4-5. Note, however,
that as shown in Section 3, each derived OWL class
is given an rdf:ID
equivalent to the xml:id
in the original
POWDER document, not an rdf:nodeID
, so that it can be referred to from outside.
POWDER [XML]
1 <descriptorset xml:id="square"> 2 <ex:finish rdf:resource="http://example.org/vocab#shiny"/> 3 <ex:shape>square</ex:shape> 4 </descriptorset> 5 <descriptorset xml:id="round"> 6 <ex:finish rdf:resource="http://example.org/vocab#matt"/> 7 <ex:shape>round</ex:shape> 8 </descriptorset> 9 <descriptorset xml:id="hexagonal"> 10 <ex:finish rdf:resource="http://example.org/vocab#eggshell"/> 11 <ex:shape>hexagonal</ex:shape> 12 </descriptorset>
1 <owl:Class rdf:ID="square"> 2 <rdfs:subClassOf> 3 <owl:Class> 4 <owl:intersectionOf rdf:parseType="Collection"> 5 <owl:Restriction> 6 <owl:onProperty rdf:resource="http://example.org/vocab#finish"/> 7 <owl:hasValue rdf:resource="http://example.org/vocab#shiny"/> 8 </owl:Restriction> 9 <owl:Restriction> 10 <owl:onProperty rdf:resource="http://example.org/vocab#shape"/> 11 <owl:hasValue>square</owl:hasValue> 12 </owl:Restriction> 13 </owl:intersectionOf> 14 </owl:Class> 15 </rdfs:subClassOf> 16 </owl:Class> 17 <owl:Class rdf:ID="round"> 18 <rdfs:subClassOf> 19 <owl:Class> 20 <owl:intersectionOf rdf:parseType="Collection"> 21 <owl:Restriction> 22 <owl:onProperty rdf:resource="http://example.org/vocab#finish"/> 23 <owl:hasValue rdf:resource="http://example.org/vocab#matt"/> 24 </owl:Restriction> 25 <owl:Restriction> 26 <owl:onProperty rdf:resource="http://example.org/vocab#shape"/> 27 <owl:hasValue>round</owl:hasValue> 28 </owl:Restriction> 29 </owl:intersectionOf> 30 </owl:Class> 31 </rdfs:subClassOf> 32 </owl:Class> 33 <owl:Class rdf:ID="hexagonal"> 34 <rdfs:subClassOf> 35 <owl:Class> 36 <owl:intersectionOf rdf:parseType="Collection"> 37 <owl:Restriction> 38 <owl:onProperty rdf:resource="http://example.org/vocab#finish"/> 39 <owl:hasValue rdf:resource="http://example.org/vocab#eggshell"/> 40 </owl:Restriction> 41 <owl:Restriction> 42 <owl:onProperty rdf:resource="http://example.org/vocab#shape"/> 43 <owl:hasValue>hexagonal</owl:hasValue> 44 </owl:Restriction> 45 </owl:intersectionOf> 46 </owl:Class> 47 </rdfs:subClassOf> 48 </owl:Class>
abouthosts
and aboutregex
The value of abouthosts
is a whitespace-separated list
of hosts. This list receives identical semantics to the value of
the includehosts
grouping element. In consequence, the
transformation from POWDER to POWDER-BASE
transforms the abouthosts
elements into an
aboutregex
element using the same processing steps as for
transforming includehosts
into includeregex
,
as described in
Section 4.2 above.
The aboutregex
element of POWDER-BASE documents sets an
outer limit on the resources described by the DRs within the document.
That is to say, it restricts the resources that
may receive a description not only implicitly (via subsumption by an
IRI set) but also explicitly as described in Section 2.5 of
the Description Resources document [DR].
In order to capture these semantics, the POWDER-BASE to POWDER-S
transformation must
add an implicit restriction to all descriptor sets in the
document, effectively
subsuming all resource classes created by descriptorset
elements under the resource class that is created by the
aboutregex
element. In this manner, the implicit or explicit
assignment of a description to a resource (cf. Section 2.5 of
the Description Resources document [DR]) will
create an inconsistency if the resource lies outside the
aboutregex
class.
It should be noted that iriset
classes
are not implicitly intersected with the aboutregex
class, and it is the responsibility of the POWDER document author to
ensure that all IRI sets in the document are within the scope
defined by abouthosts/aboutregex
.
This process is demonstrated by Example 4.7. Notice that in the POWDER-S document, each descriptor class is intersected with the 'aboutset' (lines 31, 51 and 63). A logical inconsistency will arise (i.e. an error) if an IRI set is not a subset of the aboutset class.
POWDER Document [XML]
1 <attribution> 2 <issuedby src="http://authority.example.org/company.rdf#me" /> 3 <abouthosts>example.org example.com</abouthosts> 4 </attribution> 5 <dr> 6 <iriset> 7 <includehosts>square.example.org</includehosts> 8 </iriset> 9 <descriptorset> 10 <ex:shape>square</ex:shape> 11 </descriptorset> 12 </dr> 13 <dr> 14 <iriset> 15 <includehosts>round.example.com</includehosts> 16 </iriset> 17 <descriptorset> 18 <ex:shape>round</ex:shape> 19 </descriptorset> 20 </dr> 21 <descriptorset xml:id="silver"> 22 <ex:finish rdf:resource="http://example.org/vocab#shiny"/> 23 <ex:shape>square</ex:shape> 24 </descriptorset>
POWDER-BASE Document [XML]
1 <attribution> 2 <maker ref="http://authority.example.org/company.rdf#me" /> 3 <aboutregex>\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.org|example\.com)(\:([0-9]+))?\/</aboutregex> 4 </attribution> 5 <dr> 6 <iriset> 7 <includeregex>\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(square\.example\.org)(\:([0-9]+))?\/</includeregex> 8 </iriset> 9 <descriptorset> 10 <ex:shape>square</ex:shape> 11 </descriptorset> 12 </dr> 13 <dr> 14 <iriset> 15 <includeregex>\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(round\.example\.com)(\:([0-9]+))?\/</includeregex> 16 </iriset> 17 <descriptorset> 18 <ex:shape>round</ex:shape> 19 </descriptorset> 20 </dr> 21 <descriptorset xml:id="silver"> 22 <ex:finish rdf:resource="http://example.org/vocab#shiny"/> 23 <ex:shape>square</ex:shape> 24 </descriptorset>
POWDER-S Document [RDF/XML,TURTLE]
1 <?xml version="1.0"?> 2 <rdf:RDF 3 xmlns:wdrs="http://www.w3.org/2007/05/powder-s#" 4 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 5 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" 6 xmlns:owl="http://www.w3.org/2002/07/owl#" 7 xmlns:ex="http://example.org/vocab#"> 8 <owl:Ontology rdf:about=""> 9 <wdrs:issuedby rdf:resource="http://authority.example.org/company.rdf#me" /> 10 <wdrs:issued>2007-12-14</wdrs:issued> 11 </owl:Ontology> 12 <owl:Class rdf:nodeID="aboutset"> <!-- From the abouthosts element --> 13 <owl:equivalentClass> 14 <owl:Class> 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\.org|example\.net)(\:([0-9]+))?\/</owl:hasValue> 19 </owl:Restriction> 20 </owl:intersectionOf> 21 </owl:Class> 22 </owl:equivalentClass> 23 </owl:Class> 24 <owl:Class rdf:nodeID="iriset_1"> 25 <owl:equivalentClass> 26 <owl:Class> 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">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(square\.example\.org)(\:([0-9]+))?\/</owl:hasValue> 31 </owl:Restriction> 32 </owl:intersectionOf> 33 </owl:Class> 34 </owl:equivalentClass> 35 </owl:Class> 36 <owl:Class rdf:nodeID="descriptorset_1"> 37 <rdfs:subClassOf> 38 <owl:Class> 39 <owl:intersectionOf rdf:parseType="Collection"> 40 <owl:Class rdf:nodeID="aboutset"/> 41 <owl:Restriction> 42 <owl:onProperty rdf:resource="http://example.org/vocab#shape"/> 43 <owl:hasValue>square</owl:hasValue> 44 </owl:Restriction> 45 </owl:intersectionOf> 46 </owl:Class> 47 </rdfs:subClassOf> 48 </owl:Class> 49 <owl:Class rdf:nodeID="iriset_1"> 50 <rdfs:subClassOf rdf:nodeID="descriptorset_1"/> 51 </owl:Class> 52 <owl:Class rdf:nodeID="iriset_2"> 53 <owl:equivalentClass> 54 <owl:Class> 55 <owl:intersectionOf rdf:parseType="Collection"> 56 <owl:Restriction> 57 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" /> 58 <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(round\.example\.com)(\:([0-9]+))?\/</owl:hasValue> 59 </owl:Restriction> 60 </owl:intersectionOf> 61 </owl:Class> 62 </owl:equivalentClass> 63 </owl:Class> 64 <owl:Class rdf:nodeID="descriptorset_2"> 65 <rdfs:subClassOf> 66 <owl:Class> 67 <owl:intersectionOf rdf:parseType="Collection"> 68 <owl:Class rdf:nodeID="aboutset"/> 69 <owl:Restriction> 70 <owl:onProperty rdf:resource="http://example.org/vocab#shape"/> 71 <owl:hasValue>round</owl:hasValue> 72 </owl:Restriction> 73 </owl:intersectionOf> 74 </owl:Class> 75 </rdfs:subClassOf> 76 </owl:Class> 77 <owl:Class rdf:nodeID="iriset_2"> 78 <rdfs:subClassOf rdf:nodeID="descriptorset_2"/> 79 </owl:Class> 80 <owl:Class rdf:ID="silver"> 81 <rdfs:subClassOf> 82 <owl:Class> 83 <owl:intersectionOf rdf:parseType="Collection"> 84 <owl:Class rdf:nodeID="aboutset"/> 85 <owl:Restriction> 86 <owl:onProperty rdf:resource="http://example.org/vocab#finish"/> 87 <owl:hasValue rdf:resource="http://example.org/vocab#shiny"/> 88 </owl:Restriction> 89 <owl:Restriction> 90 <owl:onProperty rdf:resource="http://example.org/vocab#shape"/> 91 <owl:hasValue>square</owl:hasValue> 92 </owl:Restriction> 93 </owl:intersectionOf> 94 </owl:Class> 95 </rdfs:subClassOf> 96 </owl:Class> 97 </rdf:RDF>
As discussed in Section 3.2.3, a DR MAY refer to descriptorset
elements
in other POWDER documents. In such a situation, although it is not possible using XSLT (the technology used to effect the POWDER transforms) to
generate aboutregex
elements for POWDER-BASE as shown in the previous example, a conformant POWDER Processor
MUST take account of abouthosts
elements in both documents. The abouthosts
element is designed to place an
outer limit on the scope of any description in a POWDER document so that publishers descriptions retain effective control
over the assertions made using their descriptions, even when such
assertions are not attributed to them. For example, publishers of
descriptions can use abouthosts
to state that their
descriptions are only meaningful for a particular set of domains, and
may not be used to describe anything else.
At the time of this writing, the OWL 2 [OWL2] working draft provides for user-defined datatypes, using the restriction facet mechanism in XSD 1.1 [XSD]. As this includes regular expression patterns, it is possible to translate POWDER into OWL 2 requiring a simpler extension than the one in Section 4.3.
More specifically, we extend RDF semantics
[RDF-SEMANTICS]
with a functional datatype property hasIRI
, defined as:
wdrs:hasIRI rdf:type owl:DatatypeProperty .
wdrs:hasIRI rdf:type owl:FunctionalProperty .
wdrs:hasIRI rdfs:range xsd:anyURI .
and the further stipulation that:
<x, sss> is in IEXT(I(wdrs:hasIRI)) if and only if there exists URI reference uuu such that:
Such an extension makes it possible to provide semantics to iriset
by
constructing an RDF datatype for each iriset
and restricting the values of
hasIRI
to this datatype's range.
In this manner, the POWDER-S translation of
Example 4-4 becomes as shown in
Example 4-7, where iriset_1
is a class of abstract resources, the concrete IRI string of which is
within a user-defined datatype (lines 20-29 and 37-46).
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:xsd="http://www.w3.org/2001/XMLSchema-datatypes#" 7 xmlns:owl="http://www.w3.org/2002/07/owl#" 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 <wdrs:issued>2007-12-14</wdrs:issued> 12 </owl:Ontology> 13 <owl:Class rdf:nodeID="iriset_1"> 14 <owl:equivalentClass> 15 <owl:Class> 16 <owl:intersectionOf rdf:parseType="Collection"> 17 <owl:Restriction> 18 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#hasIRI" /> 19 <owl:someValuesFrom> 20 <rdfs:Datatype> 21 <owl:onDatatype rdf:resource="http://www.w3.org/2001/XMLSchema-datatypes#string"/> 22 <owl:withRestrictions rdf:parseType="Collection"> 23 <rdf:Description> 24 <xsd:pattern rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string"> 25 \:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com|example\.org)(\:([0-9]+))?\/ 26 </xsd:pattern> 27 </rdf:Description> 28 </owl:withRestrictions> 29 </rdfs:Datatype> 30 </owl:someValuesFrom> 31 </owl:Restriction> 32 <owl:Class> 33 <owl:complementOf> 34 <owl:Restriction> 35 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#hasIRI" /> 36 <owl:someValuesFrom> 37 <rdfs:Datatype> 38 <owl:onDatatype rdf:resource="http://www.w3.org/2001/XMLSchema-datatypes#string"/> 39 <owl:withRestrictions rdf:parseType="Collection"> 40 <rdf:Description> 41 <xsd:pattern rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string"> 42 \:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)*[^\:\/\?\#\@]+\:(8080|8081|8082)\/ 43 </xsd:pattern> 44 </rdf:Description> 45 </owl:withRestrictions> 46 </rdfs:Datatype> 47 </owl:someValuesFrom> 48 </owl:Restriction> 49 </owl:complementOf> 50 </owl:Class> 51 </owl:intersectionOf> 52 </owl:Class> 53 <owl:equivalentClass> 54 </owl:Class> 55 <owl:Class rdf:nodeID="descriptorset_1"> 56 <rdfs:subClassOf> 57 <owl:Class> 58 <owl:intersectionOf rdf:parseType="Collection"> 59 <owl:Restriction> 60 <owl:onProperty rdf:resource="http://example.org/vocab#color" /> 61 <owl:hasValue>red</owl:hasValue> 62 </owl:Restriction> 63 <owl:Restriction> 64 <owl:onProperty rdf:resource="http://example.org/vocab#shape" /> 65 <owl:hasValue>square</owl:hasValue> 66 </owl:Restriction> 67 </owl:intersectionOf> 68 </owl:Class> 69 </rdfs:subClassOf> 70 <wdrs:text>Everything on example.org and example.com is red and square</wdrs:text> 71 <wdrs:logo rdf:resource="http://example.org/icon.png" /> 72 </owl:Class> 73 <owl:Class rdf:nodeID="iriset_1"> 74 <rdfs:subClassOf rdf:nodeID="descriptorset_1"/> 75 </owl:Class> 76 </rdf:RDF>
Note how hasIRI
, being axiomatically functional, makes it
possible to use owl:complementOf
to express the semantics
of excluderegex
. This should be contrasted to the more
complex solution of the two complementary properties adopted in
Section 4.3.
The operational semantics of the POWDER processor are specified in
Section 3 of the Description Resources document
[DR], where the core functionality of the POWDER
processor is defined as the implementation of a function
describe(u)
,
which accepts as input an IRI and returns an RDF document describing the
resource denoted by the IRI.
Notwithstanding the processing and syntactic transformations
required to serialize and deliver an RDF document, the triples present
in the document can be formally specified using SPARQL queries with
exactly two variables in the SELECT
clause (predicate and
object, the subject being the resource denoted by u.)
More specifically, a POWDER processor must return:
SELECT ?p ?o WHERE { <u> ?p ?o }
SELECT ?p ?o WHERE { <u> rdf:type ?ds . ?ds ?p ?o . ?p rdf:type owl:AnnotationProperty . }
rdf:seeAlso
, rdfs:label
, and rdfs:comment
statements about the descriptorset itself:
SELECT ?o WHERE { <u> rdf:type ?ds . ?ds rdfs:seeAlso ?o . }
SELECT ?o WHERE { <u> rdf:type ?ds . ?ds rdfs:label ?o . }
SELECT ?o WHERE { <u> rdf:type ?ds . ?ds rdfs:comment ?o . }
noting that only the object is returned, since the property is hard-wired in the query.
In addition, the POWDER processor may return a triple with a u as subject,
wdrs:describedby
as property, and the IRI of the POWDER document from
which the description was obtained as object. If more than one POWDER document is
the source of the description then each should be the object o of a separate
<u> wdrs:describedby <o>
triple. If the processor can find no information about the candidate resource within the data
available at the time of the request, then it returns a single triple with
u as subject, wdrs:notknownto
as property, and the IRI of the
POWDER processor as object. This extra-logical behavior is handled by the serialization
and delivery shell, based on the SPARQL query's result set being empty or not.
The Working Group would like to thank Jeremy Carroll for his substantial contribution to the development of the semantics of POWDER. Michael Schneider provided valuable assistance and expertise concerning the definition of the semantic extension.
<maker>
and foaf:maker
replaced by <issuedby>
and wdrs:issuedby
in all examples. This is defined in the WDRS vocabulary as a sub property of both foaf:maker
and dcterms:creator
so that
Agent classes from both vocabularies may be used. Support for both now included. See e-mail thread.dcterms/foaf:Agent
class can be included directlyrdf:nodeID
corrected throughout following comments by Masahide Kanzaki and Ivan Herman.typeof, seealso, label and comment
elements. Blank
nodes no longer forbidden but their usage is strongly discouraged. Text flows from e-mail
discussion.ref
attribute removed in favor of using seealso
.rdf:ID
identifiers cf. rdf:nodeID
s.abouthosts
. Reference is now to section 3.2.3 of this document cf. the DR document.rdf:Description
to describe the POWDER-S document changed to owl:Ontology
primarily to work around RDF's lack of named graphs, The ontology instance can be described using ontology headers.owl:complementOf
in Example 3-8 and related examples corrected following comment from Ivan Hermanattribution
and descriptorset
elements flagged as a Feature at Risk - see Status section.wdrs:matchesregexp
with
wdrs:matchesregex
following
e-mail comment
by Peter Patel-Schneider.
wdrs:certifiedby
wdrs:supportedby
following
e-mail comment
by Peter Patel-Schneider.notmatchesregex
; rationale provided inline.
This also influenced ordered lists of DRs (Section 3.1).owl:FunctionalProperty
axiom to the definition of
wdrs:hasIRI
in Section 4.6.more
element.iripattern
transforms in Section 4.2.