Re: powder wg f2f meeting report

I've written a short blog entry on Semantic Web News and a longer one in
the POWDER blog; Ivan has alerted the SWCG - so your post to this list
essentially underpins all that with extended semantics of "has a
demonstrably better idea what he's talking about."

I can safely speak for the WG and, again, Thank you.

Phil.


Jeremy Carroll wrote:
> 
> 
> 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
> http://www.w3.org/2007/OWL/wiki/POWDER#Example_Definitions
> 
> These extensions are relevant primarily to POWDER-S.
> 
> Trust
> =====
> 
> 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]
> 
> Validity
> ========
> 
> 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
> 
> Ontology(imports(d))
> 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.
> 
> 
> Implementations
> ===============
> 
> 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.
> 
> 
> OWL DL
> ======
> 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 
> them.
> 
> 
> 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.
> 
> Jeremy
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> [1] minutes (so far)
> http://www.w3.org/2008/01/31-powder-minutes.html
> http://www.w3.org/2008/02/01-powder-minutes.html
> 
> 
> 
> 
> 

-- 
Phil Archer
Chief Technical Officer,
Family Online Safety Institute
w. http://www.fosi.org/people/philarcher/

Received on Wednesday, 6 February 2008 14:45:55 UTC