POWDER

OWL/POWDER Liason

--JeremyCarroll 02:29, 10 January 2008 (EST) is using this page to draft material in the liason with the POWDER WG.

The goal is to provide better formal foundations for the design published in:

• Grouping of Resources
• Description Resources

understood in conjunction with the other POWDER WG documents.

Design overview

The main goal is to provide a formal treatment corresponding to the operational semantics while making little or no change to the operational details. This is based on the example 2.1, quoted here:

<wdr:DR>
   <foaf:maker rdf:resource="http://authority.example.org/foaf.rdf#me" />
   <dcterms:issued>2007-07-02</dcterms:issued>
   <wdr:validFrom>2008-07-07</wdr:validFrom>
   <wdr:validUntil>2008-07-07</wdr:validUntil>

   <wdr:hasScope>
     <wdr:ResourceSet>
       <wdr:includeHosts>example.org</wdr:includeHosts>
     </wdr:ResourceSet>
   </wdr:hasScope>

   <wdr:hasDescriptors>
     <wdr:Descriptors>
       <ex:property1>value 1</ex:property1>
       <ex:property2>value 2</ex:property2>
     </wdr:Descriptors>
   </wdr:hasDescriptors>

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

Briefly the operational semantics is that any resource matching the rules in the wdr:ResourseSet (in this case, all resources from hosts with domains ending example.org) has property values as given in the wdr:Descriptors item.

POWDER Lite, POWDER Full, RDF/XML and GRDDL

The key idea is that the example above is seen as an XML file, that is from a dialect which we can call 'POWDER Lite' say. (I don't like this name)

Key features of 'POWDER Lite':

• Every POWDER Lite file is an RDF/XML document, matching the typed node construct
• The root element of every POWDER Lite file is in the POWDER namespace
• A GRDDL transform is defined for the POWDER namespace.

Moreover for POWDER Lite documents that have root element wdr:DR the following also hold:

• There is exactly one top-level wdr:hasScope property element.
• There is exactly one top-level wdr:hasDescriptors property element.

Note these are syntactic constraints, on the file format; and not semantic constraints concerning description resources.

By the operation of GRDDL, then every POWDER document has two GRDDL results: itself (being an RDF/XML document), and the result of the POWDER transform applied to that document. It is also possible for a document author to specify further GRDDL transforms by using a grddl:transformation attribute on the root element. While permitted, this is however not encouraged.

The result of applying the POWDER transform is known as a POWDER Full document.

Sketch of Semantic Relationships

The design is intended to ensure that, given a POWDER Lite document L, and its corresponding POWDER Full document F, that:

1. the formal meaning of F entails the formal meaning of L (as RDF/XML)
2. the operational semantics of L implements the formal meaning of F
3. the formal meaning of L (as GRDDL) is implemented by the operational semantics of L

The third statement follows from the previous two. The notion of an operational semantics implementing a formal semantics is that the operational steps are reasonable given the formal semantics. Typically, a POWDER agent acts to either promote or restrict some resource based on its properties, and the desired properties of resources made available to the end User Agent. This act of promotion or restriction follows from the operational semantics of POWDER, and the semantic relationships are intended to ensure that a resource so promoted or so restricted necessarily has the desired or prohibited properties in the formal interpretations of the POWDER description.

(Aside: that's not to say that the POWDER description is necessarily correct. For example, it may well happen that a POWDER description states that all images from a particular server are pornographic, and then the operational treatment which prohibits access to some innocuous image implements the formal semantics, which does not correspond to the real world, because the particular POWDER description over-simplifies, probably appropriately).

Design Methodology

Working from the original examples, and its operational semantics, the POWDER Full version is developed.

From this the appropriate formal semantics is devised.

With these the POWDER Lite version is revised.

Finally the GRDDL transform is developed.

Some Design Limitations

It is also possible to directly write, by hand, a POWDER Full document. However, the operational semantics of POWDER is defined in terms of POWDER Lite, so that a hand-written POWDER Full document may not be intelligible to POWDER agents implementing the operational semantics.

Some Design Choices

URIs or Resources

There design considers wdr:ResourceSets as sets of URIs rather than resources. This is motivated in this e-mail message. I need to articulate an OWL DL perspective on this (while apparently breaking the separation between resources and literals, I think one can dance hard, on a pin-head, to solve this one).

RDF/XML + GRDDL or XML + GRDDL

It would be possible to have a POWDER document be something other than RDF/XML, and then to use just the GRDDL result to define the formal semantics.

This would allow various simplications, like omission of some namespaces in some places, and removal of some redundant stripes in the RDF striped syntax. However, it would still be necessary to specify a syntax not that dissimilar to RDF/XML to allow arbitrary annotation of description resources etc. etc. (I believe such annotation is a design goal).

XML with embedded RDF/XML

It might be possible to specify a grammar that is RDF/XML except for certain parts, which are handled separately. This would require:

• some specification of the syntax
• possibly a mime-type

A simplified version of the example might look like:

<DR xmlns="...powder...">
  <maker resource="http://authority.example.org/foaf.rdf#me" />
  <issued>2007-07-02</issued>
  <validFrom>2008-07-07</validFrom>
  <validUntil>2008-07-07</validUntil>
   
  <ResourceSet>
    <includeHosts>example.org</includeHosts>
  </ResourceSet>
   
  <Descriptors>
    <ex:property1>value 1</ex:property1>
    <ex:property2>value 2</ex:property2>
  </Descriptors>
 
  <description>Textual information to display to end users</description>
<DR>

with namespaces still needed for unanticipated items (e.g. ex: in the above)

Links to Discussion

David Booth argues for XML + GRDDL or XML + embedded RDF/XML + GRDDL and Jeremy Carroll argues for RDF/XML + GRDDL.

David

POWDER would want to use a much more custom XML notation in order to be easier for XML-only processors to handle, rather than looking like RDF/XML, which I would think would be harder for XML-only processors to handle.

Jeremy

we need to have GRDDL to meet the ease of use goal

GRDDL [provides] documentation of the formal meaning

the typical POWDER application will either be XML application or a light weight RDF application.

David

RDF/XML + GRDDL approach feels more like it is doing the opposite: embedding some special XML in an otherwise RDF document.

David suggests XML doc with RDF/XML section

<powder:powder ... >
  <powder:lite>
   [Standard POWDER Lite goes here]an 
  </powder:lite>
  <powder:additionalMetadata>
   [Any additional unconstrained RDF/XML goes here]
  </powder:additionalMetadata>
</powder:powder>

The "[Standard POWDER Lite goes here]" part could be required to be a constrained form of RDF/XML, so that it can either be interpreted directly as RDF or processed as XML.

Example as POWDER Full

Notes

1. I take includeHosts to relate a URI subject to a string object, where this holds if the subject has a host component that matches the string object according to the operational definition, (i.e. matching at least one of the values given in a white space separated list, that is to be included when interpreting a Resource Set definition.)
2. The DR hence has a scope consisting of a set of URIs and a descriptors consisting of a class
3. When the DR is valid (i.e. during the validity dates) then the class of resources with those URIs is a subclass of the descriptors.

Example

<rdf:RDF>
  <wdr:DR>
  <foaf:maker rdf:resource="http://authority.example.org/foaf.rdf#me" />
  <dcterms:issued>2007-07-02</dcterms:issued>
  <wdr:validFrom>2008-07-07</wdr:validFrom>
  <wdr:validUntil>2008-07-07</wdr:validUntil>
  <dc:description>Textual information to display to end users</dc:description>

  <wdr:hasScope>
    <wdr:URISet>
      <owl:intersectionOf rdf:parseType="Collection">
        <owl:Restriction>
          <owl:onProperty rdf:resource="&wdr;includeHosts" />
          <owl:hasValue>example.org</owl:hasValue>
        </owl:Restriction>
      </owl:intersectionOf>
    </wdr:URISet>
  </wdr:hasScope>
 
  <wdr:hasDescriptors>
    <owl:Class>
      <owl:intersectionOf rdf:parseType="Collection">
        <owl:Restriction>
          <owl:onProperty rdf:resource="&ex;property1" />
          <owl:hasValue>value 1</owl:hasValue>
        </owl:Restriction>
        <owl:Restriction>
          <owl:onProperty rdf:resource="&ex;property2" />
          <owl:hasValue>value 2</owl:hasValue>
        </owl:Restriction>
      </owl:intersectionOf>
    </owl:Class>
  </wdr:hasDescriptors>

 </wdr:DR>
</rdf:RDF>

The subclass relationship

<rdf:RDF>
 <wdr:URISet rdf:nodeID="URIs">
      <owl:intersectionOf rdf:parseType="Collection">
        <owl:Restriction>
          <owl:onProperty rdf:resource="&wdr;includeHosts" />
          <owl:hasValue>example.org</owl:hasValue>
        </owl:Restriction>
      </owl:intersectionOf>
 </wdr:URISet>
 
 <owl:Class rdf:nodeID="descriptors">
      <owl:intersectionOf rdf:parseType="Collection">
        <owl:Restriction>
          <owl:onProperty rdf:resource="&ex;property1" />
          <owl:hasValue>value 1</owl:hasValue>
        </owl:Restriction>
        <owl:Restriction>
          <owl:onProperty rdf:resource="&ex;property2" />
          <owl:hasValue>value 2</owl:hasValue>
        </owl:Restriction>
      </owl:intersectionOf>
 </owl:Class>

 <owl:Restriction>
   <owl:onProperty rdf:resource="&wdr;hasURI"/>
   <owl:someValuesFrom rdf:nodeID="URIs"/>
   <rdfs:subClassOf rdf:nodeID="descriptors"/>
 </owl:Restriction>
  
</rdf:RDF>

Overview of Formal Semantics

Validity and Dates

A description resource, ddd, a member of ICEXT(I(wdr:DR)) may be either date-valid, or date-invalid (but not both), depending on the current date (today!), as follows:

• If <ddd,f> is in IEXT(I(wdr:validFrom)) and f is after the current date, then

ddd is date-invalid.

• If <ddd,u> is in IEXT(I(wdr:validUntil)) and u is before the current date, then

ddd is date-invalid.

• Otherwise ddd is date-valid.

Additional constraints apply to interpretations of date-valid description resources, that do not apply to interpretations of date-invalid description resources. This step is regarded as pragmatic, lying on the border of the formal semantics.

What is a Semantic Extension to RDF?

Example Definitions

<uuu,sss> is in IEXT(I(wdr:includeHosts)) iff uuu is in the value space of xsd:anyURI, sss is a string. sss is understood as a space-separated list of strings lll, including an element hhh, such that when uuu is normalized as specified in section 2.1.3, the host part of uuu ends with hhh.

<x, uuu > is in IEXT(I(wdr:hasURI)) iff uuu is in the value space of xsd:anyURI, uuu is in the domain of I, with I(uuu)=x.

Semantic Relationships

Packages

The design of POWDER packages presents particular problems, addressed here: