W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > March 2002

Re: Notes from RDFCore/I18N meeting

From: <Misha.Wolf@reuters.com>
Date: Tue, 12 Mar 2002 13:16:54 +0000
Message-Id: <200203121319.IAA32304@tux.w3.org>
To: Brian McBride <bwm@hplb.hpl.hp.com>
Cc: w3c-i18n-ig@w3.org, w3c-rdfcore-wg@w3.org

On 06/03/2002 22:00:41 Brian McBride wrote:
> Misha,
>
> The notes from the meeting are in our f2f minutes at:
>
>    http://www.w3.org/2001/sw/RDFCore/20020225-f2f/#i18n
>
> Please let me know whether you approve or whether there any errors or
> omissions.

Hello Brian,

Apologies for the delayed response.  See my suggested replacements below.

> 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].

> -  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 08:19:35 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:46:16 EDT