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

Re: Minutes of F2F

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Thu, 07 Mar 2002 15:47:28 +0000
Message-Id: <>
To: Brian McBride <bwm@hplb.hpl.hp.com>
Cc: RDF Core <w3c-rdfcore-wg@w3.org>
At 10:03 PM 3/6/02 +0000, Brian McBride wrote:
>Hi Folks,
>I've added the decisions made to the face to face page at:
>   http://www.w3.org/2001/sw/RDFCore/20020225-f2f/
>and notes from the i18n meeting.

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

Shouldn't that be *NOT* start with a combining character?

>I18N suggests that comparison of URI's behaves as if they are UNICODE 
>normalised, but not does require that such normalization is performed.

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

>There was some dicussion of RDFCore concerns of lack of implementation of 
>charmod and other specs delaying completion of RDFCore.

I think there was also a concern that the relevant I18N specs would not be 
at the appropriate recommendation status when the RDF specs are ready to 
move forward.


Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
Received on Thursday, 7 March 2002 10:47:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:56 UTC