- From: Brian McBride <bwm@hplb.hpl.hp.com>
- Date: Tue, 12 Mar 2002 14:39:37 +0000
- To: Misha.Wolf@reuters.com
- Cc: w3c-i18n-ig@w3.org, w3c-rdfcore-wg@w3.org
Hi Misha, At 13:16 12/03/2002 +0000, Misha.Wolf@reuters.com wrote: [...] > > Notes from I18N/RDFCore Meeting > > > > - I18N recommend that literals (strings) in the RDF graph be fully > > normalised UNICODE and should start with a combining character. > > - I18N recommend that literals (strings) in the RDF graph adhere to > the requirements of the Character Model for the World Wide Web > [CharMod], in particular chapter 4. One consequence is that they > should *not* start with a composing character [CompChar]. Yes. That was a typo and is now fixed. Regarding your other points, thanks for the clarifications. Our discussions in general and these followup points have been very helpful. Brian > > - I18N suggests that comparison of URI's behaves as if they are UNICODE > > normalised, but not does require that such normalization is performed. > > - I18N recommend that the RDF graph use Internationalized Resource > Identifiers [IRI] to identify nodes. > > > - I18N agree that RDFCore requires a transitive string comparison > > algorithm and requests that the specs do not mislead application > > developers into thinking they are not permitted to implement a more > > flexible string matching algorithm, e.g. on queries. > > - I18N agree that RDFCore requires a transitive string comparison > algorithm and requests that the specs do not mislead application > developers into thinking they are not permitted to implement a more > flexible string matching algorithm, e.g. on queries. In particular, > I18N requests that a note be included in the spec, drawing > developers attention to the language tag matching rules (see > [RFC 2616] and [RFC 3066]). > > > - I18N note that the strings defining languages occasionally change and > > suggests that RDFCore may choose to use URI's to name languages. RDFCore > > agree to consider. > > > > - I18N found the proposed solution of literals being a pair of a string > > and a language tag acceptable. > > - I18N found the proposed solution of literals being a pair of a string > and a language tag acceptable. The spec will, of course, have to deal > with the fact of mixed-language strings. Languages other than the > initial language of a string will probably be represented using an XML > fragment containing one or more instances of "xml:lang" and marked in > the graph as parseType="literal". > > > - I18N agree that n-triples is an internal tool for the WG and developers > > and is not subject to the same internationization concerns of more > > public syntaxes. I18N request that the specs make this limited role for > > n-triples clear. > > - I18N agree that *if* n-triples is an internal tool for the WG and > developers and *if* it is not to be used for data interchange, then > it is not subject to the same internationization concerns of more > public syntaxes. I18N request that the specs make this limited role > for n-triples *very* clear. > > > - There was some dicussion of RDFCore concerns of lack of implementation > > of charmod and other specs delaying completion of RDFCore. > >[CharMod] http://www.w3.org/TR/charmod/ >[CompChar] http://www.w3.org/TR/charmod/#sec-fully-normalized >[IRI] http://www.w3.org/International/2001/draft-masinter-url-i18n-08.txt >[RFC 2616] http://www.ietf.org/rfc/rfc2616.txt >[RFC 3066] http://www.ietf.org/rfc/rfc3066.txt > >Thanks, >Misha > > > > > >----------------------------------------------------------------- > Visit our Internet site at http://www.reuters.com > >Any views expressed in this message are those of the individual >sender, except where the sender specifically states them to be >the views of Reuters Ltd.
Received on Tuesday, 12 March 2002 09:41:33 UTC