DR structure debate: summary and conclusion

There has been a healthy discussion on this list about the 'new' 
structure of a Description Resource. This e-mail attempts to offer a 
summary of that discussion and the thinking behind the eventual proposed 
model.

In the abstract: a Description Resource consists of two OWL classes. 
One, which for shorthand we still refer to as the Descriptors, carries 
the properties a user agent might be interested in, such as 'mobileOK',
'Child Safe', 'accessible', 'about Gustav Mahler' etc. Such a class will 
typically have one or more data type properties and some associated 
documentation (rdfs:label, rdfs:seeAlso etc) but probably not much else 
(as an aside, mobileOK only has documentation and no data type properties).

The second class represents what we have hitherto called the Resource 
Set, that is, the things we want to describe. Again this class will have 
data type property restrictions but unlike the Descriptors, these will
be 'necessary and sufficient' to determine that a given resource is or 
is not an instance of this class.

Finally, there is a triple that says that the Resource Set is a 
subClassOf the Descriptor class. Importantly, this triple will have 
reified statements, as a minimum using foaf:maker, that identify who or 
what is making the claim that all instances of the Resource Set class 
are also instances of the Descriptor class.

In the following example, we wish to say that 'All resources on 
example.org are blue. Line numbers are provided for easy reference in 
the text that follows.

1  <owl:Class rdf:ID="ResourceOnExampleDotOrg">
2    <owl:equivalentClass>
3      <owl:Class>
4        <rdfs:subClassOf>
5          <owl:Restriction>
6            <owl:onProperty
rdf:resource="http://www.w3.org/2007/05/powder#includeHost" />
7            <owl:hasValue>example.org</owl:hasValue>
8          </owl:Restriction>
9        </rdfs:subClassOf>
10     </owl:Class>
11   </owl:equivalentClass>
12 </owl:Class>

13 <owl:Class rdf:ID="BlueResource">
14   <rdfs:comment>The set of all things that are blue</rdfs:comment>
15   <rdfs:subClassOf>
16     <owl:Restriction>
17       <owl:onProperty rdf:resource="http://colour.example#hue"/>
18       <owl:hasValue>blue</owl:hasValue>
18     </owl:Restriction>
20   </rdfs:subClassOf>
21 </owl:Class>

22 <rdf:Description rdf:about="#ResourceOnExampleDotOrg">
23   <rdfs:subClassOf rdf:resource="#BlueResource"
                       rdf:ID="claim1" />
24 </rdf:Description>

25 <rdf:Description rdf:about="#claim1">
26   <foaf:maker rdf:resource="http://www.example.com/foaf.rdf#david" />
27   <dcterms:issued>2007-11-27</dcterms:issued>
28   <wdr:validUntil>2008-11-26</wdr:validUntil>
29 </rdf:Description>

Lines 1 - 12 is the class of resources to be described - the Resource 
Set (we may change this name). Note the use of the equivalent class 
construct in line 2 which means that processors able to identify that a 
'thing' that matches the property restriction of having a host of 
example.org has the sufficient condition for it to be considered an 
instance of this class.

More sophisticated Resource Set definitions are possible with 
restrictions on paths, schemes etc. - a substantially revised version of 
the  Grouping of Resources document [1] will need to be created but the 
essence will remain and the flexibility it provides will be retained. It 
looks as if the negative properties from that document (excludeHosts for 
example) will not be needed now since the OWL complementOf construct is 
adequate.

Lines 13 - 21 is the Descriptive class. This example is meant to convey 
the idea of a set of 'all things that are blue' - a very large and 
unbounded set.

Line 23 is the key to the whole thing. It is where the declaration is
made that ResourceOnExampleDotOrg is a sub class of BlueResource. Since 
whatever is true of a class is true of its sub classes, 
ResourceOnExampleDotOrg inherits the properties of the BlueResource class.

It is therefore this line that makes the claim that any instance of the 
ResourceOnExampleDotOrg class is blue (that is anything on example.org 
is blue). Reification is used to give details of who made the claim, so 
notice that line 23 includes rdf:ID="claim1". _That_ is the identifier 
for the conceptual unit we call a Description Resource.

Lines 25 - 29 make statements about that claim.

Line 26 is the foaf:maker property so we can see that the person
described at http://www.example.com/foaf.rdf#david is the one who made
the claim and we can also see when the claim was made and when it will
expire.

Strictly speaking the data in lines 26 - 28 say:

[someone says] david is the maker of the claim
[someone says] the claim was made on the 27th of November 2007
[someone says] that the claim is valid until 26th November 2008

Further reification may be added if the DR creator wishes to make it 
explicit who says that David says that everything on example.org is 
child safe, who says the claim was issued on the given date etc. If an 
application wishes to authenticate that David stands by the claim made 
in his name, dereferencing http://www.example.com/foaf.rdf#david will 
return more triples about him, including a pointer to any look up system 
that he may make available through which automated checks can be made.

Note that there is no data in the example Description Resource to tell a 
user agent who created the Descriptive and Resource Set classes. If 
desired, this can be provided in a couple of ways. Firstly by further 
reification statements such as

<rdf:statement>
   <rdf:subject rdf:resource="#ResourceOnExampleDotOrg />
   <rdf:predicate rdf:resource="http://www.xmlns.com/foaf/0.1/maker" />
   <rdf:object rdf:resource="http://www.example.com/foaf.rdf#david">
</rdf:statement>

Alternatively, if it is true that all the data was created by the same 
entity, then one can simply include a description of the RDF instance 
itself thus:

<rdf:Description rdf:about="">
   <foaf:maker ....
   ...
</rdf:Description>

It may also be appropriate to use owl:Ontology but this should be done 
with caution since the statements about the key assertion that one class 
is a sub class of another is outside the the usual understanding of the 
term ontology. foaf:Document may be appropriate, however.

[Incidentally, I think we should say that even if a DR is published 
within a single, self contained, RDF instance that includes a 
description of itself, the sub class relationship triple (line 23 above) 
MUST still be the subject of reification since the creation of the RDF 
instance is not the same as asserting the relationship. Plus, we need to 
be able to validate DRs and looking for the reification triples is central.]

The example above has been made as simple as possible to show the key 
features of the DR model but we should note here some of the more 
complex scenarios. Let's begin with a real example.

For the most part, my organisation's Web site does not contain any 
potentially offensive material and so is described using the ICRA 
vocabulary [2] as 'none of the above' in all categories. However... we 
do have several Associate Members whose products and services are not 
accurately described this way, and since we describe them and link to 
them from our site, we need different descriptors on all pages where the 
path starts with /associates.

 From a POWDER perspective this means we have two sections of the same 
Web site that need to be sub classed to different Descriptors. Leaving 
out the detail we can achieve this by creating 4 classes:

1 Class of Resource on fosi.org AND NOT path starts with 'associates'

*Disjoint with*

2 Class of Resource on fosi.org AND path starts with 'associates'

3 Class 'Child safe'

4 Class 'not child safe'

1 is made a sub class of 3, 2 is a sub class of 4. It is important that 
class 1 is fully defined including details of the exception (i.e. that 
the path must not start with 'associates'). Not to include this would 
mean that resources on fosi.org/associates were both child safe and not 
child safe at the same time. The 'disjoint with' statement is therefore 
critical.

There are other situations where you _do_ want more than one DR to apply 
to a given resource and this is readily achieved. For example, the whole 
of example.org may be about Gustav Mahler however the content may only 
conform to mobileOK where the path starts with /mobile. Then you'd create:

1. Class of Resource on example.org

2. Class of resource on example.org and path starts with /mobile

3. Class of resources with the primary topic of Gustav Mahler

4. mobileOK Class

Then make 1 a sub class of 3 and 2 a sub class of 4. Class 2 is now both 
about Gustav Mahler AND mobileOK which is what we wanted.

Are we under-using OWL? We're certainly not using it's full 
expressivity. For example, it is possible to create closed world, 
processable data that says something like 'All resources that have 3 or 
more links to mobileOK content are themselves mobileOK'. This would 
encode not only the claim that a resource was mobileOK but why. This is 
outwith the scope of the group's work since it goes well beyond the use 
cases. There may be future work that would bring POWDER and the Rule 
Interchange Format [3] together in this way. WE recognise that rules are 
going to be important for interpreting the data in a DR.

Are we misusing OWL? I don't believe so. An OWL processor looking at a 
DR will not be able to make any inferences since, in Description Logic 
terms, the classes are not fully defined (reasoning isn't possible using 
data type properties). However, it is important to note that, since 
reasoners will not come to any conclusion, they won't come to the 
_wrong_ conclusion either. This is the central reason for moving to a 
structure for DRs different from the RDF-only model developed so far [4].

The WG plans to create revised drafts of its main tech documents in the 
very near future to reflect this new model so, as always, comments are 
very welcome. If we're missing something or making a big mistake - 
please tell us!


Phil.


[1] http://www.w3.org/TR/2007/WD-powder-grouping-20071031/
[2] http://www.icra.org/vocabulary/
[3] http://www.w3.org/2005/rules/
[4] http://www.w3.org/TR/2007/WD-powder-dr-20070925/#structure


-- 
Phil Archer
Chief Technical Officer,
Family Online Safety Institute
w. http://www.fosi.org/people/philarcher/

Register now for the first, annual Family Online Safety Institute
Conference and Exhibition, December 6th, 2007, Washington, DC.

Go to: http://www.fosi.org/conference2007/ today!

Received on Tuesday, 27 November 2007 10:30:44 UTC