It really does not help with European and global interoperability to use German language identifiers. Use those identifiers which are already established by DCAT and other international standards.
Component
CodeCategory
improvement
Login or create an account to comment.
Comments
short reasoning for German Identifiers in English:
The OGD 2.0 indeed uses German identifiers for class names, but the specification document maps the German Identifier to English DCAT-AP URIs for the main classes, as it is done in several national DCAT-AP implementations. (e.g. see Italy). This German standard addresses public administration staff in Germany and therefore covers German semantic concepts like the AGS, Herausgeber, Urheber and features German codelist values for Themes and other descriptive metadata
long reasoning in German:
OGD 2.0 Entwurf deckt deutsche Anforderungen ab an eine Metadatenföderation innerhalb von Deutschland, respektiert bestehende CKAN und andere Installationen und sorgt gleichzeitig für internationale Anschlussfähigkeit.
Dazu verwendet OGD deutsche Bezeichner von Klassen, Attributen und Datentypen. Außerdem dokumentiert OGD 2.0 zeitgleich den Grad an Interoperabilität in der Kommunikationsrichtung OGD2.0 zum englischsprachigen DCAT-AP 1.1. in den Stufen GRÜN (exaktes Mapping möglich), GELB (Mapping mit Ungenauigkeiten möglich) oder ROT (kein sinnvolles Mapping möglich) und verwendet dabei englische DCAT-AP URIs und deren Häufigkeiten.
Wir finden, dass wir damit eine gute Balance für die Zielgruppe dieses Standards getroffen haben (deutsche Verwaltung) ohne dabei wegen der nationalen Aufgabe der Metadatenföderation die internationale Anschlussfähigkeit aus dem Blick zu verlieren.
Das Argument für englische Bezeichner im Sinne einer einfacheren Nachnutzung von OGD 2.0 durch nicht-deutschsprachige Interessenten spielte bei unseren Überlegungen bewusst eine untergeordnete Rolle.
Im Fokus unserer Motivation zu einem deutschsprachigen Austauschstandard standen Aspekte wie Kompatibilität zum deutschsprachigen XÖV, Verständlichkeit und verlustfreie semantische (und wiedererkennbare) Abbildungsfähigkeit deutscher Konzepte wie AGS, Rollen, etc.
(e.g. see Italy).
Yes and that is terrible and belongs to the worst practices regarding European and global interoperability.
While (almost) every German or Italian programmer understands English, how many of the German programmers understand Italian and how many of the Italian programmers understand German ?
EDIT: I reviewed DCAT-AP_IT (http://www.dati.gov.it/sites/default/files/DCAT-AP_IT_v10.pdf, http://www.dati.gov.it/webvowl/, http://www.essepuntato.it/lode/owlapi/lang=en/http://www.dati.gov.it/on…).
It uses English identifiers, not Italian ones. In other words: that example supports my POV.
Hello
The EU is a single market with many languages. It would greatly assist this project if English is used.
Cross border services and interoperability will be simpler if EU projects like this use English language.
Thank you
Alex
Andreas, Alex,
Concerning English or not please let me give a longer response, other responses might be shorter:
Please notice the following current situation:
a) Several German data portals already have implemented the German OGD 1.1
b) One of the requirements that was gathered prior to drafting the standard was to reuse existing German concepts (where appropriate) of the XÖV Framework, a German speaking semantic framework in continuous development since 2003. To get a first impression how those German concept are used and reused in the German standards, the XÖV-Interoperability Browser gives an impression: http://interopbrowser.xoev.de/#/
But this is not the main reasoning for using German in the standard
c) target audience: This standard mainly aims the responsibles of the 16 Länderdata portals and the potentially more than 11.000 municipalities and some dozens of portals at federal level. Those people are as a MUST and by German public administration definition definitely German speaking. Optionally a part of them might have sufficient in-depth business English knowledge to express their requirements, be able to discuss some of the concepts and semantic statements.
Whether or not those that finally implement the standard are able to read English is a completely different aspect. The semantic standard is used for harmonisation and agreement on the several different German and non German concepts and as you may agree language is crucial when talking about semantics
d) Several code lists and a few attributes simply do not exist as an exact match or closed match in English, which is completely natural when looking at the history and what one can understand as richness of culture and plurality in Europe.
Perhaps you can tighten the gap to English by finding the semantically exact equivalent of
a. übergeordnete Gebietskörperschaft (Bund und Länder)
b. allgemeiner Gemeindeschlüssel
c. Kreis und Bezirk, Diözese
d. Difference in German law between an Author and the Urheber (yes currently not yet included)
e. Note that on the legal interoperability side Germany created its own license because of differences between German and English law, called “Deutschland Lizenz 2.0” https://www.govdata.de/dl-de/by-2-0. Also a fixed set of licenses is to be used within the GovData federation - but yes, this is a fully legal interoperability issue that is even more linked to the native language issue.
e) As you may know a standards’ life cycle may include the drafting, the closed and/or public review and then the final publication of a first version of this standard. We currently use the Joinup platform for the the first phase: Discussing on the meanings of the concepts and values of the codelists. What are the arguments why the main target group (German eGovernment responsibles) should complicate the first semantic standardisation phases by not using their native language.
I do not want to do “Whataboutism”, but :) How many public administration standards in Great Britain use American English for the sake of better international reuse? Having past the last years in France, Luxembourg, Belgium and Germany I realise that mostly Germans are asking to Germans for Non-German things but yes - this is cultural interoperability.
I want to agree with you that once a standard is kind of bullet-proofed and working a mapping or a translation of this standard into English might be a good think for reuse and then the final version should be uploaded on repositories like Joinup also in English.
Also IF there is a match with already established concepts (like in DCAT-AP) those should be documented in the spec, this is exactly what we did.for the main classes and by the way why the specification page orientation moved to "landscape".
So in short:
English sounds like a must-do once the standard is finalised and implemented in the German portals.
Today in the past and current phase of “agreeing on the semantic concepts between about more than 100 German public administration officials” the requirement of an exact proper English match FIRST for every German term feels like a “overinternationalisation”.
Especially if you respect that with the few ressources the public administration in Germany has - the challenge of the inner-German federation and harmonisation needs to be solved first in order to make other Member States benefit from German open governmnent data.
This is why the MUST and SHOULD scope of OGD 2.0 role in the federation (illustrated in figure 1 in the specification) does not comprise communication to European Data Portal, to Inspire, Eurostat or other European portals.
+1
One of the main target audiences will be not only developers but machines! And semantic interoprability on a machine level will be endlessly complicated, if you require the software to translate terms into other languages. So in my view we should stick with English. Of course from a machine point of fiew it might be just numbers of random strings, but they have to be the SAME!
Additionally, both in German and in English many terms will need additional clarification in order to be assigned in a consistent manner. So I don't think the issue of "explanation needed" will arise anyway, whether we use English or German language.
Eine der wichtigen Zielgruppen werden nicht nur Entwickler, sondern Maschinen sein. Und semantische interoperabilität auf Maschinenebene wird endloss verkompliziert, sobald man der Software abverlangt, die Ausdrücke in andere Sprachen zu übersetzen. Aus daher sollten wir meiner Meinung nach bei Englisch bleiben. Aus Sicht der Maschine könnten es auch Zahlen oder Zufallszeichenfolgen sein, aber sie müssen die GLEICHEN sein!
Außerdem werden viele Ausdrücke sowohl in Deutsch wie in Englisch zusätzliche Erläuterungen benötigen, um in konsistenter Art und Weise angewandt zu werden. Daher wird der Punkt des "Erklärungsbedarfs" ohnehin auftreten, gleichgültig ob wir Deutsch oder Englisch verwenden.
Es sei noch eine Anmerkung zum AGS (Amtlichen Gemeindeschlüssel) gestattet, Herr Sklarß.
Gleichglültig, ob er nun auf Englisch oder auf Deutsch Eingang in diesen Standard findet. Er basiert auf einem etwas älteren Konzept und kann die deutschen Gebietskörperschaften nur unzureichend beschreiben.
Es ist statt eines Gemeindeschlüssels der Regionalschlüssel zu verwenden. Aus dem Regionalschlüssel kann der Amtliche Gemeindeschlüssel gebildet werden und sämtliche (!) Gebietskörperschaften einwandfrei abgebildet werden. Aus dem AGS ergeben sich nämlich keine Zugehörigkeiten einer Gemeinde zu einem Gemeindeverband, in Niedersachsen auch Samtgemeinde genannt.
Mit anderen Worten: Daten, Dokumente, Apps, die in Zusammenhang mit einer Samtgemeinde / Verbandsgemeinde stehen, können nach dem bisherigen Dokument im Standard OGD 2.0 nicht abgebildet werden, da ausschließlich auf den Amtlichen Gemeindeschlüssel und nicht auf den Regionalschlüssel abgehoben wird.
-------
Die Elementnamen können wirklich in Englisch verfasst sein. Es ist nicht anzunehmen, dass ein Nutzer dieses Standards jemals mit diesen Elementnamen konfrontiert wird, da er ja deutschsprachige Oberflächen für die Erfassung und für die Abbildung der Suchergebnisse nutzen wird. Elementnamen dienen der Maschinenkommunikation. Vielmehr müssen sämtliche Elemente und Codes in Deutsch übersetzt sein und diese deutsche Übersetzung gehört aus meiner Sicht in das Dokument, welches den Standard beschreibt. Damit ist der deutschen Sprache dann sicher Genüge getan.
Was mir nur aufgefallen ist, ist dass hier über einen deutschen Standard auf Englisch diskutiert wird. Es ist nicht anzunehmen, dass jeder, den es etwas angehen müsste, in der Lage ist, dieser offenen Diskussion in Englischer Sprache auch zu folgen. Das halte ich persönlich für bedenklicher als die Tatsache, dass man sich mit deutsch-ähnlichen Elementnamen der deutschen Sprache verpflichtet fühlt, auch wenn dies beim Datenaustausch offenkundig später zu Problemen führen mag.
(Testweise hab ich diesen Text gerade mal in den Google-Translator überführt. Das englischsprachige Endergebnis war allerdings in diesem Zusammenhang unbrauchbar.)
>> It really does not help with European and global interoperability to use German language identifiers. >> Use those identifiers which are already established by DCAT and other international standards.
Wir haben mit der Lösung DCAT-AP.de (http://www.dcat-ap.de/def/ ) unseres Standardisierungsbedarfs nun
1. deutsche Bezeichner (Beispiel „Eintrag“)
2. nutzen eine deutsche 1:1 Übersetzung der DCAT-AP Propertybeschreibungen („Die Beschreibung eines Eintrags…“) und übersetzte Teile der DCAT-AP Spezifikation
3. und referenzieren die englischsprachige URI (dcat:record)
We now have with our solution DCAT-AP.de (http://www.dcat-ap.de/def/ )
1. German identifier (Beispiel „Eintrag“)
2. Use a translation from English into German of dcat-ap properties and their description („Die Beschreibung eines Eintrags…“) and we include other translations of dcat-ap specification in the German Spec.
3. We refer to the English URI (dcat:record)
Vielen Dank für den Hinweis zum AGS, der uns später von DESTATIS auch direkt erreicht hat.
In DCAT-AP.de empfehlen wir nun die Verwendung des 12-stelligen Regionalschlüssels.
Dieser ist unter Verweis auf die konkrete RegionalschlüsselURI (http://www.dcat-ap.de/def/politicalGeocoding/regionalKey/) in das DCAT-AP.de eigene Feld „dcatde:politicalGeocodingURI“ abzubilden (damit auch Samtgemeinden) und zur Wahrung der internationalen Anschlussfähigkeit in das ISA² Programme Core Location Vocabulary unter dct:spatial oder auch optional unter https://www.w3.org/ns/locn locn:Adress unter locn:AdminUnitL2 zu spiegeln.
Eine Herausforderung aktuell bleibt das Mapping vom AGS auf den RS für eben diese Samtgemeinden / Verbandsgemeinden, da hier zusätzliche Informationen benötigt werden.