Re: Re: Request for two new media types submitted

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

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

s


> > [1] http://www.w3.org/TR/2008/WD-powder-formal-20081114/#multiDRsemantics

Received on Tuesday, 23 December 2008 08:01:02 UTC