Re: Re: Request for two new media types submitted

* Stasinos Konstantopoulos <konstant@iit.demokritos.gr> [2008-12-18 08:06+0200]
>
> On Dec 16, 2008, at 8:13 PM, Eric Prud'hommeaux wrote:
>
>> * Stasinos Konstantopoulos <konstant@iit.demokritos.gr> [2008-12-10  
>> 23:32+0200]
>>>
>>> Eric, hi.
>>>
>>>
>>> On Dec 8, 2008, at 5:30 PM, Eric Prud'hommeaux wrote:
>>>
>>>> Minor nit:
>>>> [[
>>>> We extend RDF with the datatype properties ...
>>>> ]] — http://www.w3.org/TR/2008/WD-powder-formal-20081114/#SE
>>>>
>>>> would imply to me that the RDF machinery must be extended, as  
>>>> opposed
>>>> to the application interpreting the RDF graph. Maybe something like:
>>>> "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."
>>>
>>> No, not at all, it is the underlying RDF representation where the
>>> explicit data lives that is being extended; the inference layer is
>>> not affected. Of course inference engines that directly manipulate
>>> RDF data need to implement the extension, but in situations where a
>>> clean interface exists between the two, the inference engine does
>>> not need to know why the wdrs:matchesregex triples are asserted.
>>
>> 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

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

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

> The normative document (and our reference implementation) prefers the  
> former, as it
> preserves a syntactic symmetry with cases where multiple classes are  
> intersected. This symmetry
> makes the transform cleaner (avoiding unnecessary if-then branches in  
> the document) and thus easier
> to implement and check.

OK, I guess the balance is between a simpler transformation algorithm
and simpler output whic will be more scanable by folks who know OWL.
Poking around in http://www.w3.org/TR/2008/WD-powder-dr-20081114/ , I
didn't find the actual GRDDL transform. I found
  http://www.w3.org/2007/powder/powderBase2powderS
on the POWDER WG home page; is that the one? If so, I can see how code
like
[[
  <owl:intersectionOf rdf:parseType="Collection">
  <xsl:apply-templates select="*" />
  </owl:intersectionOf>
]]
would be much more complex if it were forced to test how many times *
fired.

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.


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.

> s

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