Guidelines for the encoding of spatial data - localisedCharacterString #92
-
Dear Sir or Madam I hope you are all right. I have a question concerning the way of instatiating gmd:LocalisedCharacterString objects in datasets' GML, for instance as I want to express the nationalLevelName attribute of one AdministrativeUnit object. As you may know in Belgium we do have three national languages. That's why I have to add three times nationalLevelName within three different instantiations of gmd:LocalisedCharacterString. I will have to distinguish them by their respective languages and I cannot let these instantiations undefinied as most European countries may do. My question is: how could I identified the language of one instantiation. In ISO 19139 metadata record we do use that object type too and we identify the language with a "locale" XML attribute within the tag. The locale attribute's value is equal to a kind of internally definied URI of the language as you may see on the following images. This is a quite complex way of identifying the language of one gmd:LocalisedCharacterString tag and I don't think it's appropriate to use the same way in the GML files. How would you suggest to procede ? Do you know anything about any recommandations/requirment in this matter? I didn't find anything usefull in any TG. I could suggest to use one of the URI of the European Publication Office (http://publications.europa.eu/resource/authority/language) as the value of locale attribute of gmd:LocalisedCharacterString. Otherwise we could use the ISO URI. What do you think? Regards, |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
Dear @bfrichet3, you are right, in the GML it is not possible to implement the same encoding used for metadata. Since the dataType of the For the URI to be used, we would suggest the use of the same values required by TG MD 2.1, i.e. ISO 639-2/B code list. Two different URIs can be used: http://www.loc.gov/standards/iso639-2/ or http://id.loc.gov/vocabulary/iso639-2, with the difference that the reference to a specific language is encoded in a different way. Example for French:
Example for the GML encoding: <au:nationalLevelName>
<gmd:LocalisedCharacterString locale="http://id.loc.gov/vocabulary/iso639-2/fre">French name</gmd:LocalisedCharacterString>
</au:nationalLevelName> |
Beta Was this translation helpful? Give feedback.
-
Dear @fabiovinci Thank you very much for your answer. I will do so. It could be interessant to explicit that suggestion as a TG Requirement/recommandation in the INSPIRE Generic Model in order to clarify that for everybody. Regards, |
Beta Was this translation helpful? Give feedback.
-
Since the purpose of the the technical guidelines repository is the management of the change proposals to the TGs, I am moving this issue to the general helpdesk repository. More specifically, I will move it to the "Discussions" tab and classify it as "Q&A" |
Beta Was this translation helpful? Give feedback.
Dear @bfrichet3,
you are right, in the GML it is not possible to implement the same encoding used for metadata.
Since the dataType of the
locale
attribute isxs:anyURI
it is possible to use directly the URI of the related language.For the URI to be used, we would suggest the use of the same values required by TG MD 2.1, i.e. ISO 639-2/B code list.
Two different URIs can be used: http://www.loc.gov/standards/iso639-2/ or http://id.loc.gov/vocabulary/iso639-2, with the difference that the reference to a specific language is encoded in a different way.
In the first URI, the reference is encoded as a numeric code, in the second one, the reference is encoded with the three-letter code.
Exampl…