RE: [comment] Formal Semantics, Section 4.3

Hi Stasinos!

Stasinos Konstantopoulos wrote:

>Michael, hi.
>
>Thank you for reviewing the POWDER formal doc.
>
>> 1) You write /sss^xsd:string/. It should be "^^". This error exists
>> several times in the document.
>
>This will be fixed in the next draft, thank you for spotting this.

I am fine with this.

>> 2) I don't think that the semantic condition for wdrs:matchesregex
>> is correct, or, at least, I do not understand it.
>
>The basic premise of POWDER is that it is useful to be able to assign
>properties to resources based on their name alone and, furthermore,
>that POWDER statements can be made about whole sub-spaces of the space
>of URI references regardless of whether these sub-spaces contain any
>resources.
>
>I believe that this clarifies that we are in total agreement about the
>fourth point in your email: it is not our intention to assign
>properties to the literal values themselves but to abstract
>resources. 

Ok.

>I shall now proceed to respond to the first three points,
>hopefully clarifying how the POWDER extension realizes this.

Short summary: I still believe that it is wrong. Please see my comment inline.

>> I would expect
>> that
>>
>>   < x , reg > in IEXT(I(wdrs:matchesregex))
>>
>> is meant to hold, if there is an IRI u in the vocabulary V of the
>> interpretation I, such that I(u) = x, and the string representation
>> of u matches the regular expression reg.
>
>This is, indeed, the intuition that we are formalizing. Unfortunately
>we cannot state this quite so simply as "uuu" would then at the same
>time be something that can be matched against a regexp (that is,
>a string) and something that can be an argument to IS (that is,
>a uri ref). So we need two things (a string and a URI ref) that are in
>1:1 correspondance.

Yes, this is true. And I probably wouldn't have written my original mail if
the document would have talked about a 1:1 correspondence between /IRIs/ and
strings. It's obvious that a 1:1 correspondence exists between IRIs and
their (regex-matchable) string representations.

>The "equivalence relation" chosen as "bridge" is the one of Sect 5.1
>of RDF Concepts [1] which provides a 1:1 mapping between strings
>and rdf:XMLLiteralS. 

I do not understand what this 1:1 correspondence for /XMLLiterals/ has 
in common with the 1:1 correspondence of /IRIs/ and their string 
representation you are interested in. Why do you refer to XMLLiterals, 
when you really want to talk about IRIs?

>rdf:XMLLiteralS have the property of being
>interpreted in a value space that is disjoint from literal strings
>but being able to represent URI refs, 

How can one represent a URI ref (or IRI) by an rdf:XMLLiteral? I do not see any obvious way to do this. 

>so that the IS branch of the definition of I [2] is applied 
>whenever uuu is a valid URIref (I see no restriction in RDF Semantics
>making URIrefs and rdf:XMLLiteralS disjoint).

No. Even if there would be a way to "represent" an IRI by means of an
rdf:XMLLiteral, this representation would still be distinct from the 
IRI itself. uuu refers to a lexical form in the lexical space of 
the datatype rdf:XMLLiteral. And both the RDF Semantics and 
RDF Concepts clearly state (both in their Section 5.1) that the 
instances of a datatype's lexical space are /character strings/. 
However, URIref's (or let's better talk about IRIs) are not strings, 
they are meant to be abstract and (mainly) opaque identifiers. 
So IRIs and strings are different, incomparable things. 

The bottom line is that one cannot simply take some lexical form of 
some datatype and apply the IS() mapping to it, even if this lexical 
form happens to have a character sequence equal to the string 
representation of some IRI. The IS() mapping can only be applied 
to a /real/ IRIs. Doing otherwise is technically illegal.

>I hope this clarifies things.

Here are my concrete suggestions:

(1) Do not longer talk about rdf:XMLLiterals, talk about /IRIs/ 
instead. In particular, talk about the 1:1 correspondence between 
IRIs and their string representation. Consider, optionally, to cite 
the IRI spec, where the string representation of IRIs is defined: 
<http://www.ietf.org/rfc/rfc3987.txt>.

(2) You should probably also avoid talking about 
"equivalence relations", since for equivalence relations the 
domain and range are normally the same, and, in particular, they 
are always reflexive, which is clearly not the case for the 
1:1 correspondence between IRIs and their string representation
(otherwise, the 1:1 correspondence would be redundant). Saying 
"1:1 correspondence" instead seems to me the better choice.
 
(3) In addition, I think it isn't necessary to talk about 
the "extension of" such a 1:1 correspondence. It seems redundant, 
since we are talking about a binary relation, anyway. It might 
also lead to confusion to RDF people, who are using the term 
"extension" to distinguish between properties as individuals on 
the one hand, and the extensionally defined binary relation
that is called the "property extension" on the other hand.
 
I would consider all these changes purely bug fixes and editorial, 
so no need to go through a fourth LC. :)

Best,
Michael

>Best,
>Stasinos
>
>[1] http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-
>XMLLiteral
>[2] http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#gddenot

--
Dipl.-Inform. Michael Schneider
Research Scientist, Dept. Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schneider@fzi.de
WWW  : http://www.fzi.de/michael.schneider
=======================================================================
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
=======================================================================