POWDER formalisms

In two recent e-mails [1,2], Stasinos has presented a formalism of 
POWDER semantics. Since [2] revises a chunk of [1] I have copied and 
pasted the full revised text below for easy reference. The semantics of 
the descriptor set is clear and is inline with what we've been 
discussing recently and which for I have tried to derive generalised 
rules for the GRDDL (XSLT) transform [3].

However, what Stas is proposing for the IRI set semantics differs 
substantially from what is in the latest (member only) version of the 
Grouping Doc [4] (and the currently published one, [5]). And of course, 
it's the semantics of our IRI sets that sets POWDER apart from other 
parts of the Semantic Web.

Jeremy's solution, proposed on this list and discussed further in 
Athens, is to define a Semantic Extension for a property wdr:hasIRI that 
effectively maps "http://example.com/" to <http://example.com> and then 
says of other properties - see Semantic Extension above for details". It 
uses the same approach and mathematical terminology as used to define 
the formal semantics of RDF itself [6].

Stas is suggesting something much more detailed - and arguably more 
precise as a result. For example, under the Jeremy model we'd retain 
terms like 'includehosts' in POWDER-S. Stas says we can do away with 
that and (programmatically) reduce such elements to a regular expression 
- which I've been working on and, I think, proved [7] - at least for the 
string-based ones.

As I understand it, Stas has gone a little further and established a 
framework for the expression of POWDER-S in which the processing steps 
to be taken are made explicit through the use of elements from the XSLT 
2 and XSD namespaces. For each element it says "extract /this value/ 
from the candidate IRI and match is against /this/ value" - with regular 
expressions etc. provided. The same approach works for the string parts 
of a URI and the numerical ones (port numbers and CIDR blocks) - 
although the latter are, of necessity, complex. Note, even this approach 
requires the semantic extension that maps strings to IRIs.

So, on one reading of the Stasinos approach, is that a POWDER Processor 
must support XSLT 2. Kevin clarified that this is not the case [8] 
(thankfully!). So it seems to me that the XSLT 2 and XSD elements 
formalise the semantics and processing model for POWDER, but do not, of 
themselves, create a constraint on implementations.

OK - our task now is to decide what to do with all this. Bearing in mind 
that at our face to face in Athens in January we said we'd be ready for 
Last Call 'by Easter'. We hoped that we meant Occidental Easter but 
given the location of that meeting we really meant Orthodox Easter - and 
that means today, 25th April which is Good Friday by the Orthodox 
calendar. Whatever we do - we're already late and we are seriously 
running out of time. Our already extended charter expires at the end of 
the year (31st December by Orthodox and Occidental calendars!) - and we 
have the small matter of CR and PR to get through yet.

I see three possibilities - if you have a fourth, please say so.

1. We carry on as we are. The Semantic Extension in the grouping doc is 
cited as the formal basis for an IRI set and we quietly leave Stasinos' 
work to one side, perhaps using sections where appropriate for defining 
what 'A POWDER Processor' must do.

2. We incorporate Stasinos' work into the two primary tech documents, 
probably replacing the text semantic extension section of the grouping 
document at [5] (I'm not sure how to do this).

3. We discuss and tidy up Stas's work a little but essentially we 
already have 90% of a a new document called 'POWDER: Formal Semantics". 
We re-phrase the relevant sections of the DR and Grouping docs, passing 
the formalism off to this new doc.

Options 2 and 3 have two possible variants:

Variant a) POWDER-S includes all the XSLT 2 and XSD elements Stas has used.

Variant b) POWDER-S looks like it does in my 'try Again' e-mail [3] but 
the semantics of the terms regex (and, I think, portranges and ipranges) 
are defined in the Stasinos style. In other words we have a new layer to 
our semantics:

1. POWDER - Nice and friendly, mostly XML
2. POWDER-S - RDF/OWL* - i.e. it's OWL if you know what you've got
3. POWDER-Formal - What POWDER-S means

Of these we would only fully implement POWDER 1 and 2 as part of our CR 
work (as we plan now) but 3 would provide further underpinning for 
POWDER-S and for the implementation of it. We would surely have to do at 
least some testing using an XSLT 2 tool to give the formalism some 
validity - if only to check the angle brackets.

WDYT?

Phil.


[1] http://lists.w3.org/Archives/Public/public-powderwg/2008Mar/0017.html
[2] http://lists.w3.org/Archives/Member/member-powderwg/2008Apr/0044.html
[3] http://lists.w3.org/Archives/Public/public-powderwg/2008Apr/0054.html
[4] http://lists.w3.org/Archives/Member/member-powderwg/2008Apr/0041.html
[5] http://www.w3.org/TR/2008/WD-powder-grouping-20080324/#formalSemantics
[6] http://www.w3.org/TR/rdf-mt/
[7] http://lists.w3.org/Archives/Public/public-powderwg/2008Apr/0013.html
[8] http://lists.w3.org/Archives/Member/member-powderwg/2008Apr/0048.html

Received on Friday, 25 April 2008 14:12:02 UTC