W3C home > Mailing lists > Public > public-powderwg@w3.org > February 2008

Re: powder wg f2f meeting report

From: Phil Archer <parcher@icra.org>
Date: Wed, 06 Feb 2008 14:45:36 +0000
Message-ID: <47A9C810.4090907@icra.org>
To: Jeremy Carroll <jjc@hpl.hp.com>
CC: "Booth, David (HP Software - Boston)" <dbooth@hp.com>, Public POWDER <public-powderwg@w3.org>

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.


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:03 UTC