oparl:Person - weitere Eigenschaften

[sterni24]

Neben dem Eigenschaft "gender", die nur das Geschlecht ausdrückt, schlage ich vor weitere Felder für die korrekte Schreibweise von Namen aufzunehmen:

• Anrede - Herr oder Frau
• Titel - bereits als "title" vorhanden
• Anredetitel - z. B. Bürgermeister, Pfarrer o. ä.
• Namenszusatz - jun., sen., MdL usw.

[akuckartz]

@sterni24 Die Anrede "Herr" / "Frau" ergibt sich aus gender, deshalb keine eigene Eigenschaft dafür.

Gibt es RIS-Beispielseiten mit Verwendung solcher Anredetitel und Namenszusätze?

[sterni24]

@akuckartz Dann bitte ich um Darstellung von "Herr" und "Frau" in der Eigenschaft "gender". In der Funktion steht auch nicht "Chairman" sondern "Vorsitzender".
Manche Verwaltungen stellen auch "Ratsherr" und "Ratsfrau" als Anrede dar. Ein Grund mehr eine eigene Eigenschaft für Anrede einzufügen.

Beispiele zu den o.a. Eigenschaften finden Sie unter http://wwwsvc1.stadt-kassel.de/sdnet4/

Und hier noch etwas zum Nachlesen unter http://www.protokoll-inland.de/PI/DE/AnschriftenAnreden/anschriftenAnreden_node.html

oder als PDF

http://www.protokoll-inland.de/SharedDocs/Downloads/PI/DE/Allgemeines/Anschriften.pdf;jsessionid=3BD3E654FAE5A2136DB18F6F95D72CF4.1_cid364?__blob=publicationFile

[akuckartz]

Ich vermute, dass ich das in die Zeit nach 1.0 verschieben muss - falls ich keine saubere und einfache Lösung dafür finde. Sicherlich sind einfache AdHoc-Lösungen möglich. Die sollen aber nicht in den Standard.

Der Hinweis auf den "Ratgeber für Anschriften und Anreden" ist interessant.

[akuckartz]

Der "Bürgermeister" taucht auch in #45 auf, dort allerdings als status, nicht als Anredetitel [korrigiert].

[sterni24]

Der "Bürgermeister" gehört nicht in die Anrede, sondern wenn überhaupt in den Anredetitel (s. o.).

Ich gehe davon aus, dass ein Client alle vom RIS gefüllten Felder auch ausliest und so darstellt, dass eine "Dr. Dr. Max Mustermann"-Situation nicht vorkommen kann.

#45 zielt auf eine allgemeine Zuordnung der Person ab, hier als "Status" bezeichnet und in unserem RIS als "Personenkreis". Diese Merkmale sind keine Anrede-, Titel-, Anredetitel oder Namensbestandteile, sondern eine grundsätzliche Einordnung der Person. Da es hier in der Praxis auch zu Doppelbelegungen kommen kann, z. B. Ratsmitglied und Ortsbeiratsmitglied, wird es mit der Selektion solcher Status schon schwieriger. Es müsste dann Mehrfachzuordnungen geben.

[akuckartz]

In der Spezifikation war gendernicht aktuell. Dafür sind gegenwärtig Werte wie vcard:Male und vcard:Femalevorgesehen.

Ein Kriterium für die Spezifikation sollte sein, dass ein Client für gleichartige Personen z.B. identische Anreden anzeigen kann und nicht für ein Ratsmitglied einer Kommune "Herr | Frau" und für ein Ratsmitglied einer anderen Kommune "Ratsherr | Ratsfrau". Die Entscheidung muss deshalb der Client-Seite überlassen bleiben. Gleichzeitig ist die Menge der möglichen Werte von gender einstellig und fest, also für den Client auch unproblematisch. Das ist eine andere Situation als z.B. bei den möglichen Namen von Ausschüssen, wo die parallele Existenz z.B. von Namen wie "Finanzausschuss" und "Ausschuss für Finanzen" gegenwärtig (leider) nicht vermeidbar ist.

Ich bin deshalb nach aktuellem Stand dagegen, Anreden wie "Frau", "Herr", "Ratsherr", "Ratsfrau" in OParl aufzunehmen.

[akuckartz]

Für Anreden ist nun die optionale Eigenschaft formOfAddress vorgesehen.

[akuckartz]

Anredetitel und Namenszusatz werden unter #38 mit behandelt.

Deshalb schliesse ich dieses Issue.

[black-snow]

@akuckartz "Gleichzeitig ist die Menge der möglichen Werte von gender einstellig und fest, also für den Client auch unproblematisch."

Ich nehme an die Angabe "Kardinalität: 0 bis *" ist falsch auf Seite 51 bei der Eigenschaft gender von oparl:Person? Mit den zusätzlichen Optionen von none, other und unknown sollten mehrere Geschlechter pro Person nicht nötig sein.