Logical locus of POWDER extension, WAS: Request for two new media types submitted

Eric, hi again.

it seems to me that we have settled most sub-threads of your original
email, except for the one about the exact nature and position of the
POWDER extension. Allow me to elaborate on the rationale behind this
decision.


On Sat Jan 10 19:14:55 2009 Eric Prud'hommeaux said:

> * Stasinos Konstantopoulos <konstant@iit.demokritos.gr> [2008-12-23 10:00+0200]
> 
> > On Mon Dec 22 21:26:34 2008 Eric Prud'hommeaux said:
> > 
> > > OK, here is the proposed wording:
> > > 
> > > "POWDER-S uses an <a href=
> > > "http://www.w3.org/TR/2004/REC-owl-semantics-20040210/syntax.html#owl_DatatypeProperty_syntax"
> > > >OWL DatatypeProperty</a> to relate a resource to a regular expression
> > > which that resource matches. While POWDER-S uses OWL classes to group
> > > resources, any engine determining if a resource belonged in one of
> > > these OWL classes would need to be able to test a resource against a
> > > regular expression."
> > > 
> > > What are you arguing is incorrect?
> > 
> > this bit here:
> > 
> > > "any engine determining if a resource belonged in one of these OWL
> > > classes would need to be able to test a resource against a regular
> > > expression."
> > 
> > Although that is one possible way to go about implementing a POWDER-S
> > processor, it is not the only one, so it is not that case that "any
> > engine ... would need".
> > 
> > One counter-example to the universal quantification in your wording
> > is the SemPP processor (http://transonto.sourceforge.net/).
> > In this approach the "engine determining if a resource belonged in one
> > of these OWL classes" (which in SemPP's case is vanilla Pellet) knows
> > nothing about regexps; the regexp matching is done at the RDF
> > layer where nothing is known about OWL classes or any other OWL
> > vocabulary.
> 
> I understand your point that the implementation seems like it is doing
> matching resources against regex patterns at the core level. I argue
> that the programmatic boundries don't coincide with the logical
> boundries, and that the behavoir is best described as a semantic
> extension. To wit, the POWDER Formal Semantics [PFS] asserts that
> [[
> <x, reg> is in IEXT(I(wdrs:matchesregex)) if and only if:
> 
>     * reg conforms with regular expression syntax, AND 
> ...
> ]]
> all of which is in the language set aside in RDF Semantics [RS] for
> semantic extensions (in fact, everything in the semext class in the
> document appears to be just that, a semantic extension). It's not that
> you *couldn't* define it as an extension to RDF core, it's just that
> it would be painful, and the behavoir of two such extensions would not
> be defined.

I totally agree that is has been painful, especially trying to
minimize the possibility of nasty and unforeseen interactions. Every
care has been taken to not demand and changes in the foundations of
RDF and monotonically build upon RDF semantics.

Nevertheless, one possible source of unfortunate interaction is the
long-distance dependency between resource names and owl:RestrictionS
that use wdrs:matchesregex properties. It is very unfortunate for
POWDER that OWL does not allow for regex-defined Datatypes, which
would also eliminate this dependency and only require a local and
"safer" wdrs:hasIRI extension. Section 4.6 [2] is written in
anticipation of regex-defined Datatypes in OWL2.

About the luck of alignment between logical and programmatic boundaries,
I assume that you are referring to situations where the inference engine
might keep its own records of the underlying RDF data, a record-keeping
that would also need to be POWDER-extended. I would expect any inference
engine implementing such optimizations to also provide for means to
update its internal records with changes in the underlying model.

My experience is that Pellet at least behaves admirably well in this
respect, and correcty rebinds to Jena RDF models that have been changed
under its feet, so one can happily pretend that the logical boundary
holds, regardless of any implementation particularites. Or did you mean
something totally different?

> > > > Machinery further up the application stack (RDFS and OWL reasoners)
> > > > can remain happily ignorant about what's happening underneath.
> > > 
> > > Ahh, I believe it is customary to treat DatatypeProperies like
> > > wdrs:matchesregex or my:isEvenInteger as extensions to the inference
> > > layer. 
> > 
> > Design choices are best made per application depending on each
> > application's specific needs. POWDER extends RDF and not RDFS or OWL.
> 
> To some degree, though RDF has some text which favors one path over
> another.

I must admit I have not spotted any particular passages to this
effect, but I can easily imagine that that would be the case.

Despite this, we see great value in POWDER's approach, because in
POWDER's case there is no need to push inference results back into the
extension mechanism; resources receive POWDER descriptions by merit of
their name only and not by merit of having other properties [3].

This characteristic of POWDER descriptions makes it possible to define
the extension at a lower level, gaining the advantage of catching many
inference birds at one go. To make this more concrete, our adding a
layer over Jena gave POWDER direct access (via the in-memory API) to
Pellet and the Jena micro and mini reasoners, and indirect access (via
files) to all inference engines that can interpret any of the
serializations that Jena can produce; adapting all these reasoners to
POWDER would have been much more difficult and error prone.

> Were you to be earlier in your process, I'd argue for a
> post-processing XSLT with a single rule for
> owl:class/owl:intersectionOf/owl:Restriction[count(/*) == 1]
> to change
>
> [...]
>
> but I'm content that the cost of a change like this would exceed the
> benefits.

The group is, in fact, going to provide such a tidy-up XSLT as part of
the POWDER toolset.


s

[PFS] http://www.w3.org/TR/2008/WD-powder-formal-20081114/#SE
[RS] http://www.w3.org/TR/rdf-mt/#ExtensionalDomRang
[2] http://www.w3.org/TR/powder-formal/#oxRegexSemantics
[3] http://www.w3.org/TR/2008/WD-powder-grouping-20080630/#design
    and especially bullets 1 and 2.
    Anonymous resources cannot be described by POWDER documents.

Received on Monday, 9 February 2009 15:12:56 UTC