IS:additionalName ocp

additionalName
 

Scheme description / Schemenbeschreibung

Position of additionalName in the XML-Tree / Position von additionalName im XML-Baum

• Parent: <ocp>
• Children: None

Multiplicity / Anzahl

[0..∞]

Semantics / Bedeutung

The element <additionalName> provides additional names with descriptions in other languages, dialects, encodings...

One <ocp> can have an unlimited number of <additionalName> elements.

Attributes of additionalName / Attribute von additionalName

• name: Established, human-readable short string, giving the <ocp> object a name. Not intended for machine interpretation, please see our notice on human interpretable data fields.
  Etablierte, menschenlesbare kurze Zeichenkette, die das <ocp> Objekt benennt. Nicht zur maschinellen Interpretation bestimmt, siehe Hinweise zu menschenlesbaren Datenfeldern.
• description: Human-readable, more detailed description as addition to the name. It should give additional explanations or hints to the contents of the this <ocp> element. Not intended for machine interpretation, please see our notice on human interpretable data fields.
  Menschenlesbare, detailliertere Beschreibung als Ergänzung zu name. Sie soll zusätzliche Erläuterungen oder Hinweise auf den Inhalt dieses <ocp> Elements geben. Nicht zur maschinellen Interpretation bestimmt, siehe Hinweise zu menschenlesbaren Datenfeldern.

• xml:lang (introduced with version 2.1): This is a unique identifier of language. It uses basically the language standard IETF BCP 47 (external link) which may be different to ISO 639-1 (external link) or ISO 639-2 (external link). For mapping hints see relation to other standards (external link).
  This defines the language used for name and description. Examples for the usage of xml:lang in <additionalName> elements can be found in the Best practice section of IS:additionalName ocp.

Syntactic Constraints / Syntaktische Beschränkungen

• name xs:string.

• description xs:string

• xml:lang: xs:language, language identification, optional

Best practice & Examples / Empfohlene Anwendung & Beispiele

None.

Notes / Anmerkungen

None.

Open issues / Offene Punkte/Pendenzen

Not yet described. / Noch nicht beschrieben. {{ |notes_en = Concerning ocp's in the meaning of stations for railway access, there are often station names in more than one language due to local habit. Besides this, even in single-language regions, there may be a public name of a station different from the operational name.

• It is recommended to use the direct name attribute of an Template:IS:ocp for the operational name and to list any public name in Template:IS:additionalName elements.
• In cases where there is no difference between the operational and the only public name, or if public names are not relevant or not known, it’s ok to use the direct name attribute only.
• If necessary, the direct xml:lang attribute holds the language and/or script of the operational name if it differs from the semantical ‘natural’ or expected value. It is not common to specify the language of the operational names in RailML because this would mean a massive usage of xml:lang attributes throughout the files. Rather, if deemed necessary, a header value can be used (see CO:dc:language).
• As long as there is one Template:IS:additionalName element only (at one Template:IS:ocp), its xml:lang attribute can be omitted if the language and script are the same as the global operational.
• As soon as there is more than one Template:IS:additionalName, their xml:lang attribute shall be used to distinguish them whenever possible.
• As recommended in IETF BCP 47, it is not necessary to specify the script nor region sub-tags or any other sub-tags if they are the default values for the actual language (defined at [| IANA list, Internet Assigned Numbers Authority]). So for most cases in RailML, only the primary language tag is needed.
• Especially for station names in RailML it is not needed to specify the region sub-tag except it is really needed to distinguish between two regional dialects of the same language (which, concerning station names, is hard to imagine) but not to repeat the country where the station is situated.
• Since RailML files are normally coded in Unicode (UTF-8), there is never a real need to specify the script sub-tag - the script (character sub-set) follows implicitly from the characters used in the name. So, the only case when to use the script sub-tag is to distinguish between two Template:IS:additionalName elements of the same language. This is common in regions where the native station names are not written with Latin script for better international understanding (see examples below).
• Note that it is not possible (by definition) to use the script sub-tag to vary the character set of the RailML file (defined in <?xml encoding=…?> at the head line of the file). The script sub-tag is only a kind of hint for the reading software to assign the station name to a typical usage or give it a “right to exist”. But it does not change the behaviour of a RailML parser when decoding the file. So, if the file is not coded in Unicode for some reason, it is not possible to use other characters in names than defined by the character set of the encoding attribute.

|examples_en = Stations with public names in different languages:

(deprecated with version 2.1)

<ocp id='ocp_DBZ' name='Bautzen'>
  <propOther>
    <additionalName value='Bautzen' type='trafficName' xml:lang='de'/>
    <additionalName value='Budyšin' type='trafficName' xml:lang='hsb'/>
  </propOther>
</ocp>

(introduced with version 2.1)

<ocp id='ocp_DBZ' name='Bautzen'>
  <additionalName name='Bautzen' xml:lang='de'/>
  <additionalName name='Budyšin' xml:lang='hsb'/>
</ocp>

Since both operational and public names are identical in the default language of the file (German, de), it is not necessary to repeat the German public name. But it is recommended to do so for clarification especially from RailML 2.1 when type became deprecated.

Stations with simply a difference between operational and public name:

<ocp id='ocp_LF' name='Bft. Falkenberg (E) ob. Bf.'>
  <additionalName name='Falkenberg (Elster)'/>
</ocp>

No need to use the xml:lang attribute at all since there is no matter of different languages.

Sometimes, at stations of DB Netz AG, there is a kind of semi-difference between operational and public names because of some strange shortening of operational names of Deutsche Bahn due to the usage of out-dated software… There is no direct need to use the shortened names in RailML but sometimes it is necessary simple for exact data transfer.

<ocp id='ocp_BL' name='Berlin Hbf-Le Bf'>
  <additionalName name='Berlin Hauptbahnhof - Lehrter Bahnhof'/>
</ocp>

Stations with different operational and public names:

(deprecated with version 2.1)

<ocp id='ocp_DG' name='Görlitz'>
  <propOther>
    <additionalName value='Bft. Görlitz Pbf.' type='operationalName'/>
    <additionalName value='Zhorjelc' type='trafficName' xml:lang='pl'/>
  </propOther>
</ocp>

(introduced with version 2.1)

<ocp id='ocp_DG' name='Bft. Görlitz Pbf.'>
  <additionalName name='Görlitz' xml:lang='de'/>
  <additionalName name='Zhorjelc' xml:lang='pl'/>
</ocp>

Please note that there is never a defined nor guaranteed order of sequenced elements of the same type in RailML. So a reading software should not assume the first additional name to be the default one! In some cases, there even would not be an agreed default language for public station names.

<ocp id='ocp_CRU' name='Crianlarich upper'>
  <additionalName name='A’ Chrìon Làraich' xml:lang='gd'/>
  <additionalName name='Crianlarich' xml:lang='en'/>
</ocp>

”Foreign” stations outside the validity of the default language of the RailML file:

The following example shall be assumed to be part of a RailML file of mainly German stations with German as the default language.

<ocp id='ocp_XPKZG' name='Krzewina Zgorzelecka' xml:lang='pl'>
  <additionalName name='Krzewina Zgorzelecka' xml:lang='pl'/>
  <additionalName name='Ostritz' xml:lang='de'/>
</ocp>

Here, the xml:lang attribute of the parent element is used to declare that the language of the operational name is not the default language of the file. Again, this name is optionally repeated to clarify that there is no difference between operational and public name in Polish. At the German name, the usage of xml:lang='de' also is optional - since it is the default language - but recommended for clarification.

This example is very typical for border regions anywhere in the world of Railways. Nowadays, it is common for interactive public information systems (such as online timetable search machines) to accept all spellings of a station. (You can type “Prague” or “Prag” but do not need to know that the official spelling is “Praha”.) The example also shows that there is no objective ‘first’ additional language.

Station names in different scripts:

<ocp id='ocp_ΑΘΗΝ' name='ΑΘΗΝΑ'>
  <additionalName name='ΑΘΗΝΑ' xml:lang='el-Grek'/>
  <additionalName name='ATHINA' xml:lang='el-Latn'/>
</ocp>

Since ‘-Grek’ is the suppress-script sub-tag of Greek (‘el’), it would not be necessary to specify this sub-tag in the first additional name (Greek with Greek letters). Since (modern) Greek is assumed to be the default language of the file, the whole first xml:lang attribute could be omitted.

In Greece, it is even common up to now to distinguish between ancient and modern Greek. Combined with the spelling of some western ‘tourist’ languages, the all the names of Athens main station look like this:

<ocp id='ocp_ΑΘΗΝ' name='ΑΘΗΝΑ'>
  <additionalName name='Ἀθῆναι' xml:lang='grc'/>
  <additionalName name='ΑΘΗΝΑ' xml:lang='el-Grek'/>
  <additionalName name='ATHINA' xml:lang='el-Latn'/>
  <additionalName name='Athens' xml:lang='en'/>
  <additionalName name='Athen' xml:lang='de'/>
  <additionalName name='Athènes' xml:lang='fr'/>
</ocp>

And, finally, some cases where RailML currently does not help (not to be take too seriously):

There is currently no possibility to distinguish between an old and a new spelling of a renamed station in the same language:

<ocp id='ocp_PRMN' name='Praha Masarykovo nádraží'>
  <additionalName name='Praha Masarykovo nádraží' xml:lang='cs'/>	<!- 1919-1940, 1990 ff. ->
  <additionalName name='Praha střed' xml:lang='cs'/>		<!- 1953-1990 ->
  <additionalName name='Praha Hybernské nádraží' xml:lang='cs'/>	<!- 1940-1945 ->
  <additionalName name='Praha státní nádraží xml:lang='cs'/>	<!- 1862-1919 ->
</ocp>

There is also no possibility to specify ‘vernacular’ names:

<ocp id='ocp_DBW' name='Schiebock' xml:lang=’de-DD???’ >
  <additionalName name='Biskopicy’ xml:lang='hsb'/>
  <additionalName name='Bischofswerda' xml:lang='de'/>
</ocp>

And what to do with a (more or less) short and a (very!) long name version in the same language?

<ocp id='ocp_LLAN' name='Llanfair PG' xml:lang='cy'>
  <additionalName name='Llanfair Pwllgwyngyll’ xml:lang='cy'/>
  <additionalName name='Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch' xml:lang='cy'/>
</ocp>

}}