- From: Phil Archer <parcher@icra.org>
- Date: Tue, 27 Nov 2007 10:30:12 +0000
- To: Public POWDER <public-powderwg@w3.org>
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