RE: ISSUE-101 (plainliterals): equating plain literals with no language tag to xsd:string

Hi Bijan!

Ah, ok, the issue was about semantics. I thought it was about comparing
literals at the syntax level. Thanks for the pointer.

I found another hint in the RDF semantics spec:

  <http://www.w3.org/TR/rdf-mt/#urisandlit>

  Plain literals are considered to denote themselves, 
  so have a fixed meaning. 

  The denotation of a typed literal is 
  the value mapped from its enclosed character string 
  by the datatype associated with its enclosed type.

So for plain literals the semantic interpretation is simply:

  I_{plain}("foo") = "foo"

The second statement about typed literals reads a bit weird, but I
understand it for xsd:string in the following way: The part /"foo"/ of
/"foo"^^xsd:string/ is mapped by the datatype (regarded as a mapping from
syntactical literals to values) to the string "foo", since the value space
of xsd:string consists of all strings. Thus:

  I_{xsd:string}("foo"^^xsd:string) = "foo"

So, although /intentionally/ the semantics of xsd:string and plain literals
differ (the interpretation functions are defined in different ways, and
their domains are obviously disjoint), /extentionally/ they are the same
(they produce the same output for "isomorphic" input).

Well, works for me! I hereby withdraw my proposal to reject this issue. :)

Cheers,
Michael

>-----Original Message-----
>From: Bijan Parsia [mailto:bparsia@cs.man.ac.uk] 
>Sent: Friday, March 14, 2008 12:00 PM
>To: Michael Schneider
>Cc: OWL Working Group WG
>Subject: Re: ISSUE-101 (plainliterals): equating plain 
>literals with no language tag to xsd:string
>
>On 14 Mar 2008, at 10:23, Michael Schneider wrote:
>
>> Oops, this time it was me who overlooked a newly raised issue... by  
>> Alan. :)
>>
>>> ISSUE-101 (plainliterals): equating plain literals with no
>>> language tag to xsd:string
>>>
>>> http://www.w3.org/2007/OWL/tracker/issues/
>>>
>>> Raised by: Alan Ruttenberg
>>> On product:
>>>
>>> RDF specifies that plain literals with no language tags are to
>>> be equated with xsd:strings.
>>
>> Hm, can someone tell me where RDF does specify this?
>>
>> Perhaps I misunderstand this issue, but I thought it was a well  
>> known fact that xsd:string builds a separate datatype from the  
>> plain literals (with or without a language tags), and that there is  
>> no defined way to compare elements from both sets.
>
>I thought it was well known the other way :) But it's not so easy for  
>find controlling text in the spec. The closest I found with a quick  
>perusal is:
>	http://www.w3.org/TR/rdf-mt/#D_entailment
>
>"""In particular, the value space and lexical-to-value mapping of the  
>XSD datatype xsd:string sanctions the identification of typed  
>literals with plain literals without language tags for all character  
>strings which are in the lexical space of the datatype, since both of  
>them denote the Unicode character string which is displayed in the  
>literal; so the following inference rule is valid in all XSD- 
>interpretations."""
>
>This text asserts that it follows from the semantics that they are  
>equivalent (and gives an argument for that assertion). Whether you  
>believe that assertion and argument is a different story :) Seems  
>solid to me.
>
>> What I can find is that the RDF Concepts spec says in [1]:
>>
>>     Two literals are equal if and only if all of the following hold:
>>
>>         * The strings of the two lexical forms compare equal,  
>> character by character.
>>         * Either both or neither have language tags.
>>         * The language tags, if any, compare equal.
>>     [!] * Either both or neither have datatype URIs.
>>         * The two datatype URIs, if any, compare equal, character  
>> by character.
>
>That's not semantic equality (i.e., sameAs). Consider that for this  
>equivalent relation "01"^^xsd:integer is not equal to (sameAs)  
>"1"^^xsd:integer. (or consider various ways of spelling boolean true)
>
>Consider as well that the nearby notion of graph equivalence is *not*  
>defined in terms of entailment (even for simple entailment as this  
>notion requires a bijection but simply equivalent graphs do not.)
>
>>> RIF makes the same choice. I think we should too.
>>
>> Provided that I have understood the issue, I disagree. In this case  
>> the main premise of this issue is wrong, so I would rather opt to  
>> reject this issue.
>
>Hope this helps. The concept document would have been more helpful to  
>entailment minded folks if it had used "isomorphic" instead of "graph  
>equivalent" there and some qualifier on "equal" for literals (or at  
>least pointing out that "lexically unequal" literals may be "value  
>equal"). (And then there's value equal under coercion :)).
>
>(BTW, it having struggled with things like this that is one of my  
>strong reasons for wanting the WG to be *very* cautious about  
>generating potentially redundant and alternative presentations and  
>explanatory text. It's not good to muddle the specification  
>picture...we should strive to make the *specification* as  
>approachable as possible while it being consistent with other  
>necessary spec virtues (like unambiguity).)
>
>Cheers,
>Bijan.
>

--
Dipl.-Inform. Michael Schneider
FZI Forschungszentrum Informatik Karlsruhe
Abtl. Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: Michael.Schneider@fzi.de
Web  : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555

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 Regierungspräsidium Karlsruhe
Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus