- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Wed, 07 Sep 2011 19:30:49 +0100
- To: public-rdf-wg@w3.org
On 07/09/11 17:42, Pierre-Antoine Champin wrote: > Following todays's discussion, let me rephrase the rationale of each > "family" of solution: Thanks. Pat gives teh details; this is good to discuss the general intent of each approach. > > 1. Don't change anything: literals will have *either* a datatype or a > literal. > > In the following options, we unify literals by ensuring that every > literal has a datatype. > > 2. The language tag is still "outside" the (lexical/value) mechanism of > the datatype; the various sub-options differ in how this > extra-information is introduced in the system. > > In the following options, we unify literals even more by making > language-tagged literals a special case of datatyped literal. > > 3. The language tag is attached to the by the datatype. > > 4. The language tag is attached to the lexical form. A RDF 1.0 literal has three parts: (lexical form, language tag, datatype) with lang and datatype being optional. Options 2, 3 and 4 remove the optionality on datatype. Option 2 still has optional language tag; there is a single datatype for lang-tag literals. Option 3 removes the lang slot and encodes it into the URI. (or requires a dereference). Option 4 removes the lang slot and encodes it into the lexcial form. For 3 vs 4, if you emphasis datatypes more than lexical forms, you like 3 and conversely, if you emphasis lexical forms, 3 is preferable to 4. Options 3 and 4 reduce the dimensionality to 2 by encoding. All options make language tags "special" in some way. Option 2 does it bypassing L2V; options 3 and 4 rely on micro-parsing (further parsing a string). Andy
Received on Wednesday, 7 September 2011 18:31:18 UTC