W3C home > Mailing lists > Public > public-rdf-comments@w3.org > April 2013

Re: [PROPOSAL: Turtle: EDITORIAL. Concepts: Non-ED] Language Tag Case Conflict (between RDF1.1 and BCP47)

From: Jeremy J Carroll <jjc@syapse.com>
Date: Tue, 2 Apr 2013 09:48:20 -0700
Cc: eric@w3.org, David Wood <david@3roundstones.com>, "Eric Prud'hommeaux" <ericw3c@gmail.com>, gavin@carothers.name, Ivan Herman <ivan@w3.org>, public-rdf-comments Comments <public-rdf-comments@w3.org>
Message-Id: <7C517E53-798F-46C5-9F3F-B37D5333FEA8@syapse.com>
To: Hong Sun <hong.sun@agfa.com>


On Apr 2, 2013, at 1:46 AM, Hong Sun <hong.sun@agfa.com> wrote:

> 
> 2. It is better to use "text"@en-gb in RDF 1.1 


As an aside, speaking for myself, the clear philosophy in RDF 1.0 was to not answer the equivalent question. How an implementator chooses to represent any item of the RDF abstract syntax was simply not something that that recommendation would address. The abstract syntax is a model that informs the test cases that informs the implementator whether their external behavior is correct or not. The specs carefully avoided requiring any particular concrete representation of anything, for example, of the case of lang tags - thus, the only person who can answer your question is you. I think several of the active participants in that WG (the 2004 one) were influenced by this text:


===

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

===


To the extent that the offending text in RDF 1.1 violates this guidance, I feel some editorial attention is merited

Jeremy J Carroll
Principal Architect
Syapse, Inc.


Received on Tuesday, 2 April 2013 16:48:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:59:32 UTC