Re: Re: Request for two new media types submitted

* Stasinos Konstantopoulos <konstant@iit.demokritos.gr> [2008-12-21 07:14+0200]
>
> On Dec 20, 2008, at 6:38 PM, Eric Prud'hommeaux wrote:
>
>> * Stasinos Konstantopoulos <konstant@iit.demokritos.gr> [2008-12-18  
>> 08:06+0200]
>>>
>>> On Dec 16, 2008, at 8:13 PM, Eric Prud'hommeaux wrote:
>>>> An unextended RDF parser, database, and SPARQL query engine can  
>>>> parse,
>>>> store and return assertions like:
>>>> _:redRestriction wdrs:matchesregex "^http://foo.example/ 
>>>> redStuff.*" .
>>>> <http://foo.example/redStuff/redShoe> wdrs:matchesregex
>>>> "^http://foo.example/redStuff.*" .
>>>
>>> Exactly.
>>>
>>>> Telling people that they require an extended RDF is misleading.
>>>
>>> Telling people otherwise would be misleading. The extension is  
>>> necessary
>>> in order to
>>> have the wdrs:matchesregex triples that the query engine or OWL  
>>> reasoner
>>> will retrieve
>>> and act upon.
>>
>> 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?

>>>              Note how in Section 4.3 of the Formal doc a pair <u,re> 
>>> is
>>> in the
>>> extension of wdrs:matchesregex IFF the string representation of the  
>>> IRI
>>> identifier of
>>> resource <u> matches regular expression <re>; there is no requirement
>>> that anything
>>> has been explicitly asserted for wdrs:matchesregex to have <u,re> in 
>>> its
>>> extension.
>>>
>>> Of course one is welcome to manually assert wdrs:matchesregex  
>>> triples,
>>> as long as
>>> this is done consistently with the requirements of the definition in
>>> Section 4.3. In this
>>> case one has become a wetware implementation of the extension.
>>
>> I was just pointing out that the expression of the restriction, as  
>> well
>> as its conclusions, are compatible with the conventional RDF data  
>> model.
>
> Of course they are; we are extending RDF rather than replacing it.
>
> POWDER-S is valid RDF, but only extended RDF machinery will get the
> full meaning of POWDER-S documents. Vanilla RDF machinery will
> get the bits that use rdf: vocabulary but loose the meaning of the wdrs:
> vocabulary that establishes the connection between a resource and the
> regexps that match (or do not match) the string representation of its
> reference.
>
> 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. 

>>>> I also noticed
>>>>       <owl:intersectionOf rdf:parseType="Collection">
>>>>         <owl:Restriction>
>>>>            ...
>>>>         </owl:Restriction>
>>>>       </owl:intersectionOf>
>>>>
>>>> which is an intersection of one class. How about this instead?
>>>>
>>>>     <owl:Restriction>
>>>>        ...
>>>>     </owl:Restriction>
>>>
>>> The two are semantically equivalent, and the Formal doc explicitly
>>> allows your implementation
>>> to use either or any other syntactic variation.
>>
>> 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.

> The reader is warned in Section 3.1 [1], right after the first  
> occurrence of
> a singleton intersection.
>
>> Concearned that some OWL implementations may not be complete with
>> respect to this corner case, I found that that Positive Entailment
>> Test 006
>>  http://www.w3.org/TR/owl-test/byFunction#cardinality-006
>> has a conclusion
>>  http://www.w3.org/2002/03owlt/cardinality/conclusions006
>> with a single constraint (a restriction) inside an intersectionOf.
>> That's something I'd stick in an issues list as it's the sort of
>> issue that others may raise.
>
> My turn to not be sure what it is you're arguing; surely appearing in
> the conclusions of a positive entailment test cannot mean that a
> construct is not supported.

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.

> Either way, OWL syntax explicitly permits zero or more arguments
> for intersectionOf [2]:
>
>   description ::= classID
>               | restriction
>               | 'unionOf(' { description } ')'
>               | 'intersectionOf(' { description } ')'
>               | 'complementOf(' description ')'
>               | 'oneOf(' { individualID } ')'
>
> OWL semantics [3] seems to require one or more arguments for something
> like EC(c_1) \cup ... \cup EC(c_n) to be meaningful, but I see no  
> requirement
> that n > 1.

I agree with this, just wanted to write your point down somewhere.

>> Is this actually a "reference implementation", does it provide the
>> authoritative record of the transformation of the algorithm? I think
>> that means that all implementations have to be bug-compatible, which
>> is unusual. I assume then that any algorithm expressed in words would
>> be not significantly clearer than powderBase2powderS. I suppose that
>> errata and updates can apply just as well to the XSLT code. I wish
>> you good luck and an easy path.
>
> We consider singleton intersections neither a bug nor an error in the  
> document,
> but a design choice and, in fact, a wise one.

I'm not saying that this in particular is a bug, but that when you call
something a "reference implementation", any other implementation must
exhibit the same behavior, bugs included.

> But, since you asked, only the text is normative. The XSLT scripts are  
> consistent
> with the normative text in this document, but their syntactic specifics 
> are not
> normative.

Ahh, then I'd call it an "example implementation".

>            A POWDER processor MAY use different transforms to produce
> syntactically different but semantically equivalent OWL/RDF [4].
>
>> I wish you good luck and an easy path.
>
> cheers,
> s
>
>
> [1] http://www.w3.org/TR/2008/WD-powder-formal-20081114/#multiDRsemantics
> [2] http://www.w3.org/TR/2004/REC-owl-semantics-20040210/syntax.html#2.3.2.2
> [3] http://www.w3.org/TR/owl-semantics/direct.html#description-interpretations
> [4] http://www.w3.org/TR/2008/WD-powder-formal-20081114/#intro

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