More detail on internationalized strings

[howardtrickey]

In trying to redo the Best Practices Guide to use our latest decision on how to handle internationalized strings, I find I need help in identifying the relevant standards.

We have decided that we simply need say that: everywhere there is a CharacterString used, its multiplicity should be allowed to be greater than 1, and that the implementation technology (JSON, XML, etc.) will have its own mechanisms for tagging / annotating those strings with a language identifier.

I have two questions:

1. In XML, it appears the that the standard-defined way of doing this is to use an xml:lang= field on an xml element that we wish to so identify. I suppose this means that any CharacterString type equivalent in XML needs a element to enclose it, right? I guess this is OK but just wanted to check.

2. I am not able to find a standard-specified way to do this in JSON. Does someone have a reference to such a thing? If not, does that mean we have to specify in our JSON implementation spec for our standard how to do such identification? What would we be thinking of? Perhaps a structure like:
   {
   string = "some string",
   lang = "en"
   }

?

[geofizzydrink]

Need to enquire whether this issue has been discussed and/or addressed by INSPIRE

string identifiers in a POI represented as Internationalised text (i.e. multiple instances of the text object per language)

Check with Bart and Carl Reed.

[howardtrickey]

I've lately been looking at Apple's IMDF (indoor mapping format), which has addressed some of the issues we have been dealing with, but only from the point of a JSON encoding, where they have reached approximately the same solution as we had discussed early (language tags): see https://register.apple.com/resources/imdf/reference/type_designators#labels

It is also instructive to look at what they've done for categories https://register.apple.com/resources/imdf/reference/categories#occupant , hours https://register.apple.com/resources/imdf/reference/type_designators#hours , and POIs in general (which they call "occupant") https://register.apple.com/resources/imdf/types/occupant

[cmheazel]

Please review and comment on the Internationalized Text white paper. This white paper will be submitted to the OAB to inform their discussion on internationalized text. However, it is still a bit rough.

[geofizzydrink]

Notes from POI SWG meeting on 5 Dec 2024 Minutes-2024-12-05

• Review of Internationalization/Localization text document
  • CP [ACTION] - we need a new paragraph in abstract - rewrite the abstract
  • CP - we also need "POI" and "Localization" in the keywords
  • CP - Delete section IV (Security Considerations) - as not relevent to this particular document.
  • HT - section 1 - Internationalized Text - last sentence - should refer to "this document" rather than "this appendex" - also reword last 2 sentences into a single sentence (remove full stop after "...support"
  • CP - section 1.1.2 - rewrite/reconfigure sentences and references to figures.
  • HT - section 1.1.2 - the code example appears non-standard - Figure 1 should probably read like:
    name:enStatue of LIberty</name:en>
    name:frStatue de la Liberte</name:fr>
  • HT - general question/recommendation - we should use both xml and json examples in the document.
  • HT - 1.1.3.3 - need to either add details about PT_Locale or remove it all together from this document.
    • suggested text - para 2 - last sentence - "...at the file scope or via external resources and/or registries..."
  • ST & HT - example in 1.1.3.3 - some errors in the text - needs to be cleaned up.
  • CP - sentence above fig 6 remove "something"
  • ST - figure 6 - second line should have "locale" not "language"
  • CP - section 1.1.3.4 - replace references to "variant(s)" with "approach(es)" - CP will rewrite paragraph.
  • ALL [ACTION] - we should read over section 1.3 - Interational Standards
  • HT - the "conclusion" of section 1.3 is confusing in relation to the recomendation put forward in section 1.2 - needs to be reworked and harmonised.
  • CP - has created a google doc as a temporary edit space https://docs.google.com/document/d/1BCsUI8kIjYuDgzZq6bHpiwxgDra4CK-PQGLVkwXLcCA/edit?tab=t.0

CMH: I believe I have addressed all of these issues.

[cperey]

I have composed new text for the abstract. It is pasted here and you can also read and edit it in the Google Doc mentioned above.

The Points of Interest (POI) Conceptual Model Standard builds upon the Geospatial Feature and Geometry Standards developed by the Open Geospatial Consortium and ISO Technical Committee 211 (TC211). Its goal is to provide a model using a Unified Modeling Language (UML) object model which any system may adopt for the definition of basic entities, attributes and relations of POI, regardless of encoding language.

In developing the standard, the POI SWG has examined approaches for including in the POI data information in multiple languages without introducing confusion and with the lowest overhead (e.g., computational complexity). Through this report, the SWG members are communicating to the OAB and the geospatial community at large where and how internationalized text is implied in international standards and to make transparent to all concerned the approach the SWG recommends for the POI standard, as well as all other standards that seek to include internationalized text.

[cperey]

Feel free to edit in this document https://docs.google.com/document/d/1BCsUI8kIjYuDgzZq6bHpiwxgDra4CK-PQGLVkwXLcCA/edit?tab=t.0

[cperey]

Issue: POI (or Points of Interest) is missing from the list of keywords in this document.

RECOMMENDATION: Add POI or Points of Interest to keywords in front matter.

CMH: both have been added.

[cperey]

Issue: The document date still says Nov 29

RECOMMENDATION: Update the date in front matter section.

CMH: Received date is current, Issued and published dates will be updated when document is complete.

[cperey]

Issue: in abstract first paragraph, the statement reads "Some information may be of interest to people who speak multiple languages." It's not the multi-lingual people who are the issue. It's the multi-lingual POI publishers need to reach their audiences.

RECOMMENDATiON: Edit the text in abstract that, in fact, the information may be available to people in multiple langugages.

CMH: Abstract has been replaced by new content

[cperey]

Issue: Section on Security Considerations is not necessary. Plus there is a typo.

RECOMMENDATION: Delete this section. At least spell check.

CMH: deleted

[cperey]

Issue: Last sentence in the introduction, begins with "To make..." is not a complete sentence.

RECOMMENDATION: Rewrite to correct english.

CMH: Introduction has been deleted.

[cperey]

Issue: Sentence below the heading for 1.1.3.1 should not have "something" or like this.

RECOMMENDATION: Rewrite without ambiguity. The following is an example of...

CMH: corrected

[cperey]

"Something like this" appears in other sections where there are examples. Please rewrite to simply state that the following is an example.

CMH: Corrected

[cperey]

Issue: Section 1.1.3.4 begins with "This variant" Which variant?

RECOMMENDATION: rewrite to specify the topic of the section.

CMH: Done

[cperey]

Issue: there is not (I don't think) any mention of the issue with the techniques in XML not being easy to reproduce in other languages.

RECOMMENDATION: If the issue above has not been captured and it remains an issue, it needs to be described.

CMH: now addressed in conclusions

[cperey]

Here is the revised Abstract from the Google doc:

The Points of Interest (POI) Conceptual Model Standard builds upon the Geospatial Feature and Geometry Standards developed by the Open Geospatial Consortium and ISO Technical Committee 211 (TC211). Its goal is to provide a model using a Unified Modeling Language (UML) object model which any system may adopt for the definition of basic entities, attributes and relations of POI, regardless of encoding language.

In developing the standard, the POI SWG has examined approaches for including in the POI data information in multiple languages without introducing confusion and with the lowest overhead (e.g., computational complexity). Through this report, the SWG members are communicating to the OAB and the geospatial community at large where and how internationalized text is implied in international standards and to make transparent to all concerned the approach the SWG recommends for the POI standard, as well as all other standards that seek to include internationalized text.

[cmheazel]

Howard and Chuck approve the new abstract.
CMH: Abstract has been replaced by new content

[cperey]

In the introduction:
section 1 - Internationalized Text - last sentence - should refer to "this document" rather than "this appendex" - also reword last 2 sentences into a single sentence (remove full stop after "...support"
CMH: corrected "appendix", removed last sentence in the paragraph.

[cperey]

Read over and wherever there's "Variant" to "Approaches" where it appears...
CMH: removed all uses of "variant"

[cperey]

Issue: in section 1.2.3.2 "Locale" is missing an "e" at the end in several places.

RECOMMENDATION: fix typos

CMH: fixed

[cmheazel]

Add to conclusions - techniques which work well in one encoding may not work well, or even be possible in others. The limitations of the target encoding technology should be considered when selecting internationalization approaches.
CMH: done

[cperey]

Typos in the conclusion section: in second sentence, second paragraph
CMH: Sorry, not seeing it. Note that ISO 19115 is a multi-part standard. Thus the use of the plural "standards"

[cperey]

Typo in "capabilities" and "unfortunately" in Conclusion section
CMH: Fixed

[cmheazel]

Re-visit the templates to make sure we are still in conformance with the OGC template.
CMH: Done

[cmheazel]

Revisit recommendation table. Text still refers to "name" and may no longer reference the concepts in the text.
CMH: Updated