- 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