Re: Writing up the Carroll Format

Phil Archer wrote:
> 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).

That's the approach I have been advocating. Alternative approach is not 
to assert the subClassOf in the usual way, but to assert it as part of 
the formal semantics of POWDER.

Do you want to put together in a single RDF/XML file DRs asserted by 
many different people, and permit interpretations in which Mary Mu is 
creditable but Joe Lambda is not?

For me these issues to do with trust and creditability (like the issues 
to do with time) lie beyond what RDF is currently designed for, and are 
best off being dealt with somewhere other than the formal semantics 
layer: but that takes us into the named graphs approach, for which there 
isn't adequate support in things like serializations.

Jeremy


> 
> 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.
> 
>                       -------
> 

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

It might be possible to have the rdf:parseType="Resource" attributes 
added by a DTD or Schema ....


> 
> 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!
> 


fine

Jeremy

Received on Thursday, 17 January 2008 18:22:36 UTC