W3C home > Mailing lists > Public > public-owl-dev@w3.org > January to March 2008

powder wg f2f meeting report

From: Jeremy Carroll <jjc@hpl.hp.com>
Date: Tue, 05 Feb 2008 10:58:47 +0000
Message-ID: <47A84167.2080404@hpl.hp.com>
To: Owl Dev <public-owl-dev@w3.org>
CC: "Booth, David (HP Software - Boston)" <dbooth@hp.com>, Public POWDER <public-powderwg@w3.org>

Formally this is a report to the OWL WG, but made on this list because 
it may be of more general interest (and is perhaps of less specific 
interest to the OWL WG).

There was a F2F meeting of the POWDER WG last week, to which I was invited.

The main business was to consider my efforts to modify the design to 
better meet the requirement for interoperation with other parts of the 
Semantic Web.

 From an RDF perspective POWDER can be seen as doing rdf:aboutEachPrefix 
correctly. A sample operation in POWDER is --includeHosts-- or 
--includePorts--. These match the appropriate part of a normalized URI.

New Design Sketch

The new design is approximately as follows:
- the main POWDER format is an XML format.
- there are a few places in the XML format where arbitrary RDF/XML can 
be used (while we haven't had it as an explicit goal, I believe the 
corresponding RDF graph will be consistent with the intended semantics 
of the POWDER document)
- GRDDL is used on the POWDER namespace.
- the GRDDL result is called the POWDER-S document.
- the XML POWDER format is given an operational semantics (similar to in 
the current POWDER WDs), which, given a URI can produce a piece of RDF 
that describes that URI. The end application can then use this RDF to 
determine appropriate behaviour, for example,  in response to an input URI.
- the POWDER-S version has a formal semantics following RDF and OWL
- the formal semantics is such as to correspond to the operational 
semantics, so that the operational semantics can be seen as implementing 
the formal semantics.
- it is possible to write POWDER-S documents without a corresponding 
POWDER document - but then implementations that use the operational 
semantics will not work with such a document.
- the basic form of a POWDER-S document is
   = attributions and metadata about the document itself
   = a class description of some resources defined by a class of URIs 
defined by an intersection of restrictions concerning patterns of 
components in the URIs
   = a class description defined typically by an intersection of 
hasValue restrictions, giving a set of property values that every 
resource in the class has
   = a subclass relationship between the above two descriptions

Various issues

Semantic Extensions

Two operations in POWDER have no obvious correspondence in RDF or OWL:
- the relationship between a resource and a URI that identifies the 
resource (while this is the I function in the RDF semantics, for 
example, it is inaccessible)
- the complex pattern matching rules (on URIs and URI componenets) that 
are the heart of POWDER

The agreed design treats both of these as semantic extensions, as in

These extensions are relevant primarily to POWDER-S.


Different applications draw on one or more POWDER documents. Each POWDER 
document has an attribution block saying who wrote it, etc.
An application looks at various POWDER documents in turn, and decides 
whether or not it will use that document in a pragmatic step, before 
either applying the formal semantics or the operational semantics.
This step can be done either with POWDER documents or POWDER-S documents.

This is applicable at a document by document basis, and not on a 
document section basis. Hence a complex POWDER description of a large 
site, may be advantageously published as multiple descriptions, with 
different attribution, since some applications may wish to trust only 
part of the complex description.

[This is in part inspired by the Named Graphs, Provenance and Trust paper]


Two of the parts of the metadata about a POWDER document that may be 
present are a validFrom and validUntil fields.
These are understood as being performative speech acts, which can be 
used either in a document to constrain its own validity, or to report 
the validity constraints made in some other document. This performative 
semantics permits closed world reasoning with a default of validity 
(validFrom defaulting to the big bang, validUntil defaulting to the heat 
death of the universe). Thus a document d is valid at a time *now* if 
the ontology

Type(d,allValues(validFrom, <now))
Type(d,allValues(validUntil, >now))

is consistent (apologies for the syntax).

Note that since a POWDER-S document includes a subclass triple there is 
a certain amount of finessing going on when we are considering such a 
document at a time at which it is not valid. The expectation is that the 
pragmatic trust decision either would reject the invalid document, and 
hence the problematic subclass triple, or accept the invalid document, 
and hence the heart of the claim which has either not yet come into 
force or timed out.


We briefly considered CR exit criteria.
I think there was (informal) consensus that there should be 2 XML based 
POWDER implementations and 1 RDF based POWDER-S implementation.

At some level the design seems fundamentally at odds with OWL DL, since 
the defintion of say includeHosts is as a relationship between strings 
and strings (hence violating the DL separation between the abstract and 
concrete domains).
I think this can be worked around by having a class within the abstract 
domain of URIProxy, and in the DL view having hasURI as a property 
linking the complementOf(URIProxy) with URIProxy. The pattern matching 
properties then have range in string, and domain in URIProxy.
However, that is work to do, rather than done.

Also the semantic extensions are essentially all about Regexs so that, 
at least in principle, it is possible to compare class expressions using 

I think the POWDER WG intends to publish new WDs with the design, and 
ask on this list for review of the POWDER-S aspects, that are not in the 
current WDs. After such a review, the POWDER WG is hoping to be able to 
move to last call.


[1] minutes (so far)
Received on Tuesday, 5 February 2008 10:59:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:58:16 UTC