W3C home > Mailing lists > Public > public-powderwg@w3.org > February 2009

Proposal wrt. semantic extension (was Re: Request for two new media types submitted)

From: Phil Archer <phil@philarcher.org>
Date: Thu, 26 Feb 2009 15:49:50 +0000
Message-ID: <49A6BA1E.4050809@philarcher.org>
To: Eric Prud'hommeaux <eric@w3.org>, Stasinos Konstantopoulos <konstant@iit.demokritos.gr>
CC: Public POWDER <public-powderwg@w3.org>, Ivan Herman <ivan@w3.org>, Ralph Swick <swick@w3.org>
Eric, Stasinos,

This thread has gone back and forth between the two of you for a while 
but remains essentially unresolved so can I please check that my 
understanding of the issue is correct ('cos we need to put this to bed).

The troublesome sentence is in the semantic extension, visible at 
http://philarcher.org/powder/formal/20090205.html#SE which says:

We extend RDF Semantics [RDF-SEMANTICS] with the datatype properties 
wdrs:matchesregex and wdrs:notmatchesregex as shown below:

followed by a formal treatment of the extension.

Eric's contention is that this phrasing suggests that the POWDER 
document has an impact on RDF as a whole such that /all/ RDF tools would 
need to be extended to support the matchesregex property. Correct?

It would satisfy Eric if that one sentence were replaced with

"POWDER-S uses an <a 
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 

And the formalism remains unchanged? If so, I'd like to add something 
simple like just "Formally:" to link the sentence to the formalism.

If this is what Eric is asking for, then IMO, it's an easy thing to do, 
consider it done! However... we seem to have lost any reference to the 
concept of an extension to anything - and that goes against what we were 
told by Jeremy C way back. Without the reference to an extension and the 
RDF-Semantics document, it's not at all clear where the formalism comes 

We know that if you put POWDER-S into an RDF/OWL tool-kit you _don't_ 
get the intended semantics. Stasinos's own POWDER Processor uses Jena 
and Pellet and works with POWDER. So whatever Transonto does, it seems 
to me that *that* is what we need to formalise.

As for the point about having an intersection on a singleton. With huge 
amounts of respect, admiration and thanks for your help with all this 
since we first met to talk about it in Tokyo all those years ago - come 
off it Eric. It honestly doesn't matter. Yes, a little XSLT that cleans 
these up would be good and we may yet produce such a thing but it's 
window dressing. The actual semantics are correct, even if the mark up 
is unnecessarily bloated. Or am I missing something more important?


Eric Prud'hommeaux wrote:
> * 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
Received on Thursday, 26 February 2009 15:54:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:05 UTC