Another attempt at 'cascading DRs'

The basic POWDER model has a resource that describes a lot of other 
resources. A processor may start at the descriptive resource (the POWDER 
document) and discover the resources it describes. To aid discovery of 
the description, a resource may link to to the POWDER document that 
describes it.

In some important circumstances however this doesn't work. POWDER's 
Grouping mechanism [1] (currently under revision with a new draft due 
for publication v. soon) assumes that by examining a URI, one can deduce 
which description of a collection applies to it. If URIs don't follow a 
particular pattern, such as numerical URIs generated by some content 
management systems, we need a different mechanism: we must rely on the 
link from the described resource to point to the correct description.

We've discussed this a lot, most recently in Athens, and we know we need 
to solve it. We also know that it's impractical in a commercial workflow 
to need to edit the POWDER document continually, adding in lists of 
exceptions to rules. We need to work more along the CSS model where 
there is a central file that carries the defined styles. Which style, 
indeed, which stylesheet, is applicable, is defined within the document 
for which it contains the styles. HTTP and client caching ensures that 
stylesheets need only be accessed once until updated.

A Package of DRs, as currently defined at [2], has an attribute 
'aboutHosts'. The structure of packages is going to be modified a little 
in the near future but this feature is a very useful one for processing 
efficiency. The plan now is to make it so that, where present, the 
aboutHosts guarantees that the DRs in the package do not cover any 
resources on domains other than those listed (it doesn't guarantee that 
all resources on those domains are described by the way, just that if 
the aboutHosts property lists example.org then you can be sure that it 
does not describe anything on example.com).

OK, hold on to that and look at this:

1  <?xml version="1.0"?>
2   <POWDER xmlns="http://www.w3.org/2007/05/powder#"
3           xmlns:ex="http://example.org/vocab#"
4           xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

5    <attribution>
6      <maker>http://authority.example.org/foaf.rdf#me</maker>
7      <aboutHosts>example.org</aboutHosts>
8    </attribution>

9    <Descriptors xml:id="red">
10     <ex:color>red</ex:color>
11   </Descriptors>

12   <Descriptors xml:id="blue">
13     <ex:color>blue</ex:color>
14   </Descriptors>

15 </POWDER>

This is POWDER doc with its required attribution. Line 7 adds in an 
aboutHosts element.

But there are no DRs here, just two descriptions (and if there are no 
DRs there is no requirement for a URISet). A 'red page' on example.org 
would include a link element with an href attribute of 
"...powder.xml#red", blue pages would have #blue as the fragment 
identifier. The aboutHosts element prevents other domains pointing to 
this POWDER doc and claiming (quite possibly falsely) that the entity 
described at http://authority.example.org/foaf.rdf#me described them - 
that is, the POWDER doc author has a mechanism for restricting the scope 
of the descriptions without actually having a URISet.

But... what's the POWDER-S version of this, i.e. the output of the GRDDL 
transform with formal semantics? Well, I guess it ends up just being:

<rdf:Description rdf:about="">
   <foaf:maker rdf:resource="http://authority.example.org/foaf.rdf#me" />
</rdf:Description>

<owl:Class rdf:nodeID="red">
   <owl:intersectionOf rdf:parseType="Collection">
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://example.org/vocab#color" />
       <owl:hasValue>red</owl:hasValue>
     </owl:Restriction>
   </owl:intersectionOf>
</owl:Class>

<owl:Class rdf:nodeID="blue">
   <owl:intersectionOf rdf:parseType="Collection">
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://example.org/vocab#color" />
       <owl:hasValue>blue</owl:hasValue>
     </owl:Restriction>
   </owl:intersectionOf>
</owl:Class>

Notice that a) the aboutHosts element is not copied from the operational 
semantics - it's not needed here and, I think I'm right in saying, won't 
be of any value in the ordered list in a POWDER-S doc either. It could 
be included but I'm not sure that it will add a great deal.
b) there is no subClassOf relation asserted - which is good because
c) there is no URIset to be a sub class of the descriptors.


Three questions for people with the appropriate knowledge:

So the XSLT here must only assert the sub class relationship if there is 
a URISet. Doable?

I understand that, formally, creating a blank node in an RDF graph means 
that the universe is so arranged that there is at least one resource 
that has the properties given by those of the blank node. Does creating 
an OWL class in this way get us off this hook?

How does this look, Kai?

N.B. I'm trying to avoid having to create server-side software that 
returns triples with the described resource's URI as the subject - 
that's clearly the semantically pure way, but it's impractical.

I'm asking all this because it obviously affects the rules on what MUST 
and SHOULD and MAY be in a POWDER doc - something Andrea's poised to 
encode in the schema and Kevin is poised to enshrine in the XSLT.

Phil.



[1] http://www.w3.org/TR/2007/WD-powder-grouping-20071031/
[2] http://www.w3.org/TR/2007/WD-powder-dr-20070925/#package-structure

Received on Tuesday, 12 February 2008 12:17:25 UTC