- From: Phil Archer <parcher@icra.org>
- Date: Thu, 17 Jan 2008 16:08:32 +0000
- To: Public POWDER <public-powderwg@w3.org>
- CC: Jeremy Carroll <jjc@hpl.hp.com>
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