Re: Re: Re: Request for two new media types submitted

* Stasinos Konstantopoulos <konstant@iit.demokritos.gr> [2008-12-23 10:00+0200]
> 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.

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.

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

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

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
[[
<owl:Class>
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Restriction>
      <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
      <owl:hasValue  rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">(porn\.example)\/?</owl:hasValue>
    </owl:Restriction>
  </owl:intersectionOf>
</owl:Class>
]]
into
[[
<owl:Restriction>
  <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
  <owl:hasValue  rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#string">(porn\.example)\/?</owl:hasValue>
</owl:Class>
]]
but I'm content that the cost of a change like this would exceed the
benefits.

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

I wasn't arguing for the spec's sake, just for ease of tracking
important controversial points.

> > > [1] http://www.w3.org/TR/2008/WD-powder-formal-20081114/#multiDRsemantics
[PFS] http://www.w3.org/TR/2008/WD-powder-formal-20081114/#SE
[RS] http://www.w3.org/TR/rdf-mt/#ExtensionalDomRang
-- 
-eric

office: +1.617.258.5741 32-G528, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.