W3C home > Mailing lists > Public > public-rdf-wg@w3.org > August 2012

langstring, datatypes and semantics

From: Antoine Zimmermann <antoine.zimmermann@emse.fr>
Date: Wed, 22 Aug 2012 11:30:22 +0200
Message-ID: <5034A6AE.5000902@emse.fr>
To: Richard Cyganiak <richard@cyganiak.de>, Pat Hayes <phayes@ihmc.us>
CC: RDF WG <public-rdf-wg@w3.org>
Richard and Pat,


(minor issues related to concepts and semantics)


Langstrings are said to have a datatype IRI but no datatype is defined 
for them. Yet, the current spec refers to the "value space" of 
rdf:langString. So, it leaves me wondering, is rdf:langString denoting a 
datatype? If not, what's a value space of something which is not a 
datatype. If yes, whatever datatype it denotes does not follow the 
definition of datatype.

Anyway, putting aside the phrasing of RDF Concepts, should the following 
triple be axiomatic:

rdf:langString  rdf:type  rdfs:Datatype .

My opinion is no. However, there should be:

rdf:langString  rdf:type  rdfs:Class .


Another point is: can rdf:langString be used as a datatype IRI in 
non-langstring literals? The current draft of RDF Concepts does not 
dissallow it, so one can write:

<s> <p> "abc"^^rdf:langString .

I think this should be forbidden. So, it's not only that langStrings 
MUST have a datatype IRI equal to rdf:langString, but also that any 
literal with this datatype IRI MUST have a language tag.


This would have a consequence on the definition of datatype maps. If 
rdf:langString is not allowed for typed literals, then the following 
line should be added to Section 5.4:

"A datatype map MUST not contain the IRI rdf:langString, as it is 
reserved for language-tagged strings and no formal datatype is defined 
for this IRI."


Best,
-- 
Antoine Zimmermann
ISCOD / LSTI - Institut Henri Fayol
École Nationale Supérieure des Mines de Saint-Étienne
158 cours Fauriel
42023 Saint-Étienne Cedex 2
France
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66
http://zimmer.aprilfoolsreview.com/
Received on Wednesday, 22 August 2012 09:30:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:06 UTC