W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > June 2002

Re: literals, again.

From: pat hayes <phayes@ai.uwf.edu>
Date: Fri, 28 Jun 2002 10:56:31 -0500
Message-Id: <p05111b2fb9422b9d4ae6@[]>
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: w3c-rdfcore-wg@w3.org

>I support the "gist" of essentially all that you are saying
>below, but would offer an even more simplified proposal.
>Rather than
>>  Jenny ex:age _:y "10" .
>>  _:y "10" xsd:number _:x .
>>  Jim ex:age _:x .
>Jenny ex:age _:y"10" .
>_:y rdf:type xsd:integer .
>Jim ex:age _:y .

OK, but bear in mind that the subject of the second triple is the 
very same node as the object of the first triple, and so it still has 
the "10" literal label, even though you didn't mention it. So this is 
exactly the same graph as:

Jenny ex:age _:y "10" .
_:y "10" rdf:type xsd:integer .
Jim ex:age _:y "10".

Now, that would be nice, but...

>so that datatyping is no different than "normal" RDF
>typing, and the above works perfectly in conjuction
>with rdfs:range. E.g.

....seems to me that it doesn't work, and that we have been here 
before. In fact this is very much like the old P++ proposal that you 
shot down, on the excellent grounds that mere membership in the value 
space cannot be the trigger of a datatype check since two datatypes 
with different lexical2value mappings can have exactly the same value 
space. Which is why we decided to make the actual range itself be the 
trigger, rather than an rdf:type conclusion from the range. (Have you 
changed your mind on that point??)

>    ex:age rdfs:range xsd:integer .
>Likewise, rather than
>>  _:x"10"  rdf:sourceDeclaration  "xml version="1.0"" .
>>  _:x"10"  rdf:xmlLang  "FR"  .
>_:x"10" rdf:type rdf:XML .
>_:x"10" xml:lang  _:z"fr"  .

Yes, that is better.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Friday, 28 June 2002 11:59:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:13 UTC