Re: Request for two new media types submitted

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

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

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

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.

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

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

Received on Sunday, 21 December 2008 05:15:41 UTC