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

Re: Re: Request for two new media types submitted

From: Stasinos Konstantopoulos <konstant@iit.demokritos.gr>
Date: Tue, 23 Dec 2008 10:00:10 +0200
To: Eric Prud'hommeaux <eric@w3.org>
Cc: Phil Archer <phil@philarcher.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, Public POWDER <public-powderwg@w3.org>, Ivan Herman <ivan@w3.org>, Ralph Swick <swick@w3.org>
Message-ID: <20081223080010.GA1517@iit.demokritos.gr>

On Mon Dec 22 21:26:34 2008 Eric Prud'hommeaux said:

> * Stasinos Konstantopoulos <konstant@iit.demokritos.gr> [2008-12-21 07:14+0200]
> >
> > On Dec 20, 2008, at 6:38 PM, Eric Prud'hommeaux wrote:
> >
> >> I'm not sure which of the following you are arguing:
> >>  1 "Extends RDF" could not be interpreted as "extends the RDF data  
> >> model"
> >>  2 my proposed clarification is incorrect
> >>  3 my proposed clarification is not an improvement
> >
> > #2
> 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

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

> >> Equivalent, sure, but it's distracting for the reader because the
> >> they start looking for an intersection where there is none, and.
> >
> > As already noted, there are good technical reasons for this  
> > inconvenience.
> The main reason I see for this is that the xml representation
> expresses intersections, but not other logical constructs such as
> unions or complements. I expect this represents the far majority of
> use cases, as regular expressions can already express both unions
> and if you feel like compiling them into a regex, complements.
> Thus, all patterns can be reduced to a pure conjunction, so there's
> less pressure for working group to include a step for simplification.

That's yet another interesting alternative for implementing POWDER-S.
But I don't think you would prefer to have to wade through
the single-regexp representation of a POWDER/XML <ol> element--even
with just two branches--in the document.

> I was just thinking that these details could go into an issues list.
> As editor, I found the value of the issues list was not just to
> document outstanding issues, but to serve as a bit of a FAQ. It's
> possible that others besides me will be struck by the complexity
> and search for the design decision.

Please see the relevant paragraph in Section 3.1 [1], right after the
first occurrence of a singleton intersection, and make an editorial
comment if you feel the explanation is not sufficient.


> > [1] http://www.w3.org/TR/2008/WD-powder-formal-20081114/#multiDRsemantics
Received on Tuesday, 23 December 2008 08:01:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:42 UTC