- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Mon, 29 Aug 2011 14:57:15 +0100
- To: public-rdf-wg@w3.org
On 29/08/11 09:09, Antoine Zimmermann wrote: > Richard, > > Le 27/08/2011 18:29, Richard Cyganiak a écrit : >> Hi Antoine, >> >> Your summary omits the option that I've been advocating recently: >> >> On 26 Aug 2011, at 16:22, Antoine Zimmermann wrote: >>> B. What if it is a datatype? >>> >>> If it's a datatype, rdf:LangString must have exactly all the >>> characteristics that all datatypes have. It must follow the >>> definition. Now, the definition can either be kept as is (as in RDF >>> 2004) or modified. B1: If we keep the RDF 2004 definition, I think >>> we can't really do any better than what the rdf:PlainLiteral spec >>> is doing. The difference is that we do not need to deal with >>> untagged plain literals, so the lexical form is quite >>> straightforward: "foo@en"^^rdf:LangString would be the abstract >>> syntax of "foo"@en. str("foo"@en) is already "foo" >> >> B1y: We keep the RDF 2004 definition of datatypes. rdf:LangString is >> a datatype with empty lexical space and empty L2V mapping. The value >> of a literal is given by the L2V mapping only if its datatype is not >> rdf:LangString. The value of an rdf:LangString literal is the >> tuple<lexicalform, langtag>. > > This is inconsistent. You cannot give a formal definition of datatypes, > then have an instance of datatypes that does not follow the definition. > It's like saying that prime numbers are numbers that are only dividable > by 1 and by themselves and that 9 is a prime number dividable by 1, 3 > and 9. It cannot be, it's broken. > > If you really want to keep the definition as of 2004, then > rdf:LangString must /either/ have a non-empty lexical space and an L2V > mapping /or/ it is not a datatype. There is no other possibility. owl:Real is a existing counterexample to the 2004 defn. "The owl:real datatype does not directly provide any lexical forms." The "non-empty lexical space" restriction seems to be artificial. Empty, and some other way to form values, works just as well albeit with specific rules for each datatype. Andy > > Then, you end up with the cases that I mentioned in my mail. > > > --AZ > > >> >> I see this as better than B1 because it doesn't introduce lexical >> forms and then forbids their use, like rdf:PlainLiteral does. >> >> I see this as better than either of the B2 options because it >> minimizes the deviation from RDF 2004 and doesn't disagree with XSD. >> >> Best, Richard >> >> >>> B2: If we change the definition of datatypes, I can see two ways: >>> *B2x: do as Pat suggested, that is, allow the lexical space to >>> contain tuples; then everything else follows the standard >>> definitions (DATATYPE("foo"@en) is as per the normal rule, the >>> semantics is as per the normal semantics of typed literals, etc) >>> *B2y: include in the definition of datatypes an exception, that is, >>> say "A datatype is either: (i) a combination of 3 parts: lexical >>> space, value space and L2V; or (ii) rdf:LangString. Then you have >>> to define the semantics of rdf:LangString literals differently from >>> other types, since there is no L2V. DATATYPE("foo"@en) would follow >>> the normal rule. >>> >>> Whichever path we choose, we could also introduce language-specific >>> datatypes. >>> >>> Personally, I have no problem with B1, it's straightforward, has >>> the advantages of rdf:PlainLiteral without the awkward "@" for >>> non-lang-tagged strings (since it does not deal with >>> non-lang-tagged strings at all) and it has a better name. Then I >>> prefer B2x over B2y, but could live with either solutions. >>> >>> >>> Hope this helps, -- Antoine Zimmermann Researcher at: Laboratoire >>> d'InfoRmatique en Image et Systèmes d'information Database Group 7 >>> Avenue Jean Capelle 69621 Villeurbanne Cedex France Tel: +33(0)4 72 >>> 43 61 74 - Fax: +33(0)4 72 43 87 13 Lecturer at: Institut National >>> des Sciences Appliquées de Lyon 20 Avenue Albert Einstein 69621 >>> Villeurbanne Cedex France antoine.zimmermann@insa-lyon.fr >>> http://zimmer.aprilfoolsreview.com/ >>> >> > >
Received on Monday, 29 August 2011 13:57:45 UTC