Writing up the Carroll Format

I've tried to make a start on writing up the work that Jeremy's been 
doing on OWL-POWDER by putting it into a version of the DR doc.

In so doing I think some of our open questions have been answered, but 
there are still plenty to look at.

I began by trying to summarise the 2 representations as a 'Design 
Introduction' thus:

The use cases present a challenge to Semantic Web technologies which 
typically support the assertion of simple facts about individual 
resources. Those facts can be aggregated and inferences drawn from them 
but the central concept is that of a triple:

Subject —> has property —> value

A Description Resource is a more complex data structure, typically of 
the form:

If today's date is between —> (start date and end date) —> then —> Joe 
Lambda —> believes that —> {all resources on example.org} —> have 
properties —> values (and outside those dates this may still be true but 
don't complain to Joe if it isn't).

Support for this relatively complex structure is provided through the 
use of a sub class relationship between an OWL Class that encapsulates 
the resources to be described (as identified by their URIs) and one that 
encapsulates the description. The sub class relationship is asserted in 
the usual way but we define an extension to the semantics of RDF that 
allows that relationship to be conditional on external factors (such as 
the date).

It is clear from the preceding discussion that representing a 
Description Resource in a semantically-consistent manner necessitates 
the use of a relatively complex construct. However, this goes against an 
important design consideration, namely that DRs should be simple to use 
in an operational environment. Although not a formal requirement, it is 
felt to be highly desirable that it should be possible to edit a DR by 
hand and therefore that the data structure should be intuitive. For this 
reason we define two representations of a Description Resource. An 
operational DR, known as a DR-O, is an RDF/XML instance with a simple 
structure that has relatively loose semantics and some limitations on 
its expressivity. A defined transformation can be applied to any such 
instance to yield a semantic DR (DR-S). Since the transformation is tied 
to the POWDER namespace, a semantic Description Resource always entails 
an operational Description Resource.

                       -------

Then I took a look at the generic example of a DR (example 2-1) and have 
re-written it a little using the rdf:parseType attribute to create blank 
nodes for the URIset and Descriptors. These blank nodes will be typed by 
virtue of the range of the hasScope and hasDescriptor properties, so we 
get this:

1  <wdr:DR rdf:ID="DR_1">

2    <foaf:maker rdf:resource="http://authority.example.org/foaf.rdf#me" />
3    <dcterms:issued>2007-12-14</dcterms:issued>
4    <wdr:validFrom>2008-01-01</wdr:validFrom>
5    <wdr:validUntil>2008-12-31</wdr:validUntil>

6    <wdr:hasScope rdf:parseType="Resource">
7      <wdr:includeHosts>example.org</wdr:includeHosts>
8    </wdr:hasScope>

9    <wdr:hasDescriptors rdf:parseType="Resource">
10     <ex:shape>square</ex:shape>
11     <ex:color>blue</ex:color>
12   </wdr:hasDescriptors>

13   <dc:description>Textual information to display to end 
users</dc:description>

14 </wdr:DR>


This gives the appearance of losing the 'striping' ( of 
class-property-class-property) but actually preserves it - just in fewer 
lines of angle brackets.

Notice that I've also changed 'ex:property1' to ex:shape' etc. This is 
because I remember getting comments to the effect that using abstract 
names like property 1= = value 1 put up an extra barrier to 
understanding. No problem, everything on example.org is now blue and square!

Phil.

Received on Thursday, 17 January 2008 16:08:46 UTC