Response to the I18N Checklist for the RDF specifications

[pchampin]

I18n checklist

https://www.w3.org/International/i18n-drafts/techniques/shortchecklist

If the spec or its implementation...	... then:
... contains any natural language text that will be read by a human (this includes error messages or other UI text, JSON strings, etc, etc),	... ensure that there’s metadata about and support for basic things such as language and text direction → user-facing text is represented in RDF with (directional) language tagged strings which include language and (optionally) text direction metadata.
... allows content authors to produce typographically appealing text, either in its own right, or in association with graphics.	... take into account the different typographic styles used around the world (for things such as line-breaking, text justification, emphasis or other text decorations, text selection and units, etc.) → RDF users will usually use the rdf:HTML datatype to represent typographically appealing text, and therefore have access to all the internationalization features of HTML.
... allows the user to point into text, creates text fragments, concatenates text, allows the user to select or step through text (using a cursor or other methods), etc.	N/A
... allows searching or matching of text, including syntax and identifiers	... understand the implications of normalisation, case folding, etc → Term equality in RDF is explicitly defined based on the equality of code point sequences. RDF does not define any other kind of text matching.
... sorts text	N/A
... captures user input	N/A
... deals with time in any way that will be read by humans and/or crosses time zone boundaries	... ensure that it will represent time as expected in locales around the world, and manage the relationship between local and global/absolute time. → RDF users will usually use the XML Schema builtin datatypes to represent time-related information, and all these datatypes support the expression of time offset. Other datatypes, supporting time zones, could be defined and used in RDF as well (provided that they are identified by IRIs).
... allows any character encoding other than UTF-8	.. make sure you have a convincing argument as to why, and then ensure that the character encoding model is correct → All concrete syntaxes delivered by the WG, but one, only allow UTF-8. The exception is RDF/XML, which inherits the flexibility of XML regarding encoding.
... defines markup	N/A
... deals with names, addresses, time & date formats, etc	N/A
... describes a format or data that is likely to need localisation	... ensure that there’s an approach in place which allows effective storage and labelling of, and access to localised alternatives for strings, text, images, etc → User-facing texts in RDF are typically represented with (directional) language-tagged strings, and RDF vocabularies exist to provide alternative labels in different languages (e.g. SKOS).
... makes any reference to or relies on any cultural norms	... ensure that it can be adapted to suit different cultural norms around the world (ranging from depictions of people or gestures, to expectations about gender roles, to approaches to work and life, etc). → Some examples may be slightly culturally tinted (e.g. reference to Monna Lisa or Spiderman), but should remain globally understandable and could easily be adapted to other cultural backgrounds.

Scope

This self-assessment applies to the whole family of RDF 1.2 specifications:

• RDF12-NEW
• RDF12-CONCEPTS
• RDF12-N-QUADS
• RDF12-N-TRIPLES
• RDF12-PRIMER
• RDF12-SCHEMA
• RDF12-SEMANTICS
• RDF12-TRIG
• RDF12-TURTLE
• RDF12-XML

[aphillips]

A few quick responses.

... allows searching or matching of text, including syntax and identifiers (marked as N/A)

I'm surprised that this is marked N/A, since I expect there to be identifier matching (IRIs are identifiers). I am not suggesting that there is necessarily an issue to be solved. Only that you do have some matching.

→ RDF users will usually use the XML Schema builtin datatypes to represent time-related information, and all these datatypes support the expression of timezones.

Actually, the XSD types support the expression of time zone offsets. New or evolving standards support actual time zones. For too much information, see Working with Time and Timezones

[pchampin]

thanks @aphillips, those are good points, I will update the responses accordingly.

[pchampin]

Changelog: I just edited the initial text of this issue with the following change:

• changed the URL at the top with the correct one
• respond to the question about matching strings, as suggested above by @aphillips
• improve the response about dealing with time

[lisp]

more detailed than this?

rdf12-refs.pdf