Personenstruktur #38
Comments
|
Meine Meinung: Alle diese Daten sollten mittels OParl zugreifbar gemacht werden können. |
|
Für die Benennung der Attribute können wir die Orientierung an vCard vorschlagen: Für Bestandteile von Adressen ist insbesondere dieser Abschnitt relevant: Siehe auch Und ganz frisch: vCard Ontology Und nicht zuletzt gibt es FOAF: |
|
Die Ausgabe von Adress-und Kommunikationsdaten sollte normiert werden, da die zu Grunde liegenden Sitzungsdienst-Systeme in der Regel mehrere Adressdaten ( pivat, dienstlich, Arbeitgeber ) und mehrere Kommunikationsdaten -Telefon, Mail, Handy- ( privat, dienstlich, Arbeitgeber) speichern. |
|
Ich halte den Vorschlag von @BThie für sinnvoll. |
|
Das vCard-Format mit W3C--Ontologien zu verwenden erscheint sehr sinnvoll. Für die Normierung wären vielleicht noch Twitter-, Facebook-, XING-, LinkedIn- YouTube und Flickr-Accounts zu berücksichtigen. Bei der Erfassung der Daten auf kommunaler Ebene für abgeordnetenwatch.de hat sich gezeigt, dass ca. 10% Räte über mindestens einen Account verfügen. Es erscheint somit zeitgemäß, diese Informationen mit einzubinden, auch wenn sie noch nicht für vCard-OWL definiert sind. |
|
@BThie Eine Normierung wäre sehr gut. Würde es aber bei den Adressen nicht reichen, folgendes zu verwenden?
Welcher Verwaltungsmitarbeiter wäre denn auch noch in der der freien Wirtschaft tätig? |
|
In der vCard Ontologie kann zwischen privat und geschäftlich/dienstlich sauber mittels vcard:Home und vcard:Work unterschieden werden. Zur Angabe von Social Media Accounts mache ich noch einen Vorschlag, der nicht nur eine kleine Liste proprietärer Plattformen berücksichtigt. |
|
@akuckartz Könnte man bei den Social-Media-Accounts dann auch die Objekte, Gremien und Organisationen vielleicht gleich mit einbeziehen? Würde vCard (Organizational Properties) nicht vielleicht auch für die Objekte, Gremien und Organisation reichen? |
|
Eine weitere Möglichkeit, das Rad nicht neu zu erfinden, ist hier die Verwendung des Schemas http://schema.org/Person |
|
Workshop 22.01.2014 Bielefeld Gruppe B Vorschlag
|
|
Das offizielle vCard-Beispiel für JSON-LD zeigt, wie Addressen und Telefonnummern angegeben werden können: |
|
Der Übersichtlichkeit aus #123 übernommen:
|
|
Vorschläge der Stadt Bonn (alle optional):
|
|
Zu diesem Issue ist seit längerem nichts passiert. Mit Blick auf die Fertigstellung von 1.0 stelle ich fest, dass wir aktuell die folgenden Eigenschaften in oparl:Person vorsehen:
Die aktuellen Beschreibungen können https://github.com/OParl/specs/blob/master/dokument/master/chapter_8060.md entnommen werden. Ich entferne den Milestone 1.0 in der Annahme, dass für Version 1.0 aktuell nichts zu tun bleibt. |
|
@sterni24 Ich habe dieses Issue dem neuen Milestone "LD Version" zugewiesen. |
|
@marians Ich halte es nicht für sinnvoll, das Einarbeiten von benannten, elementaren Eigenschaften auf einen späteren Termin zu verschieben. |
|
@sterni24 In diesem Issue sind eine Menge Eigenschaften genannt worden, ohne dass diese näher erläutert worden wären. Können Sie mir sagen, welche Eigenschaften Sie mit "elementar" meinen? Dann können wir darüber im Einzelnen sprechen. |
|
Für die komplette Darstellung von Anreden und Namensbestandteilen sollten noch folgende Infromationen enthalten sein:
Als Adresse reicht mir zur Zeit die Standardadresse der Person. Komplizierter wird es bei der Ausgabe von Kontaktdaten für privat / dienstlich / Arbeitgeber. Hier müßte ggf. ein neues Objekt definiert werden. Allerdings sehe ich hier für OpenData keine Anwendung. Wir sollten es bei einem Merkmal belassen. Vielleicht werden die Daten seitens der Anwender auch gar nicht freigegeben. (siehe auch #116) |
|
Das, was Sie Anredetitel nennen, wird bereits von "formOfAddress" abgedeckt. Darüber hinaus SOLL ein Titel, wenn er im allgemeinen als Teil des Namens geführt, wird, auch in der Eigenschaft "name" enthalten sein. Beispiel: Beim Namenszusatz würde ich dagegen plädieren, diesen als eigene Eigenschaft zu deklarieren. Wenn es sich wirklich um einen Zusatz des Namens handelt, kann dieser auch über die Eigenschaft "name" ausgegeben werden. Z. B. Wir haben uns bei den Workshops in Bielefeld und Düsseldorf recht intensiv über Personendaten unterhalten und dort, wie Sie auch sagen, festgestellt, dass die genaue Abbildung aller möglichen Eigenschaften von Personen für die Zwecke von OParl nicht allzu wichtig ist. Das Schema ist an dieser Stelle auch eher einfach ausgefallen, eine Unterscheidung zwischen Heim- und Arbeitsanschrift gibt es z.B. nicht. Es obliegt den Betreibern, zu entscheiden, welche Adresse für OParl ausgegeben werden soll, sofern mehrere hinterlegt sind. |
|
Noch ein Hinweis: Es gibt das sog. Issue #1, das für eine zukünftige OParl-Version weiterhin zur Sammlung von Vorschlägen für Personen-Eigenschaften offen steht. |
|
Wenn Sie das so sehen, dann können auch die Eigenschaften |
|
Meine Meinung:
|
|
Popolo verwendet diese Namens-Eigenschaften: Besonders relevant sind vermutlich diese beiden:
|
|
Sicher sollten wir ins Dokument mehr Beispiele aufnehmen. Die Eigenschaften "familyName" (auf gut Deutsch der Nachname) und "givenName" (Vorname) spielen aus meiner Sicht eine besondere Rolle, weil sie
Mindestens der Nachname ist darüber hinaus ein Attribut, das häufig für die Sortierung von Personenlisten benötigt werden dürfte, da eine Sortierung von Personennamen nach Nachname weit verbreitet ist. Der Vorname ist darüber hinaus für die Erstellung von Namens-Darstellungen durch den Client von Bedeutung, beispielsweise so: Hierzu dient auch die Ausgabe des Titel, der als Teil des Namens geführt wird, über ein eigenes Attribut. @sterni24 Können Sie Beispiele liefern, was mit Anredetitel und Namenszusatz gemeint ist? |
|
siehe oben |
|
@sterni24 Danke, hatte ich übersehen. Ein "Bürgermeister" oder "Pfarrer" als Bestandteil des Namens scheint mir ungewöhnlich. Ich sehe darin eher so etwas wie eine Berufsbezeichnung, ähnlich wie "Bezirksschornsteinfegermeister". Hierfür haben wir aktuell kein Feld vorgesehen und benötigen es auch aus meiner Sicht nicht. Der Adelstitel leuchtet mir eher als Bestandteil des Namens ein. So könnte beispielsweise der Freiherr so ausgegeben werden: {
"givenName": "Rudolf",
"familyName": "Slatin",
"name": "Rudolf Freiherr von Slatin",
"title": ["Freiherr"]
}Beachte:
Gibt es Einwände oder weitere Beispiele, die wir ausformulieren sollten? |
|
Jetzt geht es ein wenig durcheinander. Hier ein paar komplette Beispiele. Damit läßt sich alles abbilden. {
"name": "Rudolf Freiherr von Slatin",
"formOfAddress": "Herr",
"title": "Bürgermeister",
"honoraryTitle": "",
"academicTitle": "Dr.",
"titleOfNobility": "Freiherr von",
"givenName": "Rudolf",
"familyName": "Slatin",
"nameAffix": "MdL"
}wobei z. B. der "Professor" eigentlich unter {
"name": "Manuela van der Schalk",
"formOfAddress": "Frau",
"title": "",
"honoraryTitle": "",
"academicTitle": "",
"titleOfNobility": "",
"givenName": "Manuela",
"familyName": "van der Schalk",
"nameAffix": ""
}Das Problem des vorstehenden Beispiel ist die Sortierung. "van der Schalk" wird unter "V" aufgeführt und nicht unter "S". Kann man so sehen, muss man aber nicht. {
"name": "Domkapitular Msgr. Dr. theol. Christoph Scherfenacker ",
"formOfAddress": "Herr",
"title": "Domkapitular",
"honoraryTitle": "Msgr.",
"academicTitle": "Dr. theol.",
"titleOfNobility": "",
"givenName": "Christoph",
"familyName": "Scherfenacker",
"nameAffix": "sen."
}Und hier noch für Interessierte: |
|
@sterni24 Wenn man die einzelnen Bestandteile zu einem vollständigen Namen zusammenbauen möchte, kann dann das Rezept für deren Zusammenbau für die Spezifikation formuliert werden? (Ist das eine einfache Reihenfolge oder ist das komplexer?) |
|
@akuckartz wenn ich das richtig sehe, müßte der Adelstitel hinter dem Vornamen stehen, dann können Sie das so stringen. Daraus folgt, das man die Eigenschaft "formOfAddress": "Herr", Diese Reihenfolge setzt natürlich voraus, dass die Körperschaft die Daten korrekt pflegt und der Serverimplemtierer die Daten entsprechend einstellt. |
|
Meine Meinung zum generellen Ansatz: Wir müssen gar nicht das Ziel verfolgen, den vollständigen Namen "programmatisch" aus allen Einzelteilen zusammen bauen zu können. Wir können einen viel einfacheren Ansatz verfolgen:
Was unbedingt notwendig ist, ist aktuell natürlich reine Spekulation. Meine Meinung: Das wichtigste sind Vor- und Nachname, dann kommt lange Zeit nichts mehr. Bei Titeln bin ich schon neutral. Würde ich einen Client entwickeln, würde ich dann für die Anzeige grundsätzlich die "name" Eigenschaft heranziehen. Für die Sortierung würde ich zunächst "familyName" und dann "givenName" nutzen. @sterni24 Es besteht weiterhin die Möglichkeit, herstellerspezifische Eigenschaften zu definieren. Wenn Sie also besonderen Wert auf detaillierte Abbildung der Namensbestandteile legen, wäre das auch eine Möglichkeit. Es scheint aber noch ein unterschiedliches Verständnis zur Eigenschaft "title" zu geben. Dieses ist aktuell in der Spezifikation als "Akademische(r) Titel" beschrieben. Kardinalität ist 0 bis *, das heißt es handelt sich um eine Liste, über die beliebig viele Titel angegeben werden können. Also z. B. Ich hätte nichts dagegen, die Beschreibung der Eigenschaft zu erweitern, so dass sie auch für Adelstitel genutzt werden kann. |
|
Ich halte hier nichts von herstellerspezifischen Angaben. Es handelt sich in meinen Beispielen um gültige und auch verwendetete Namensbestandteile. Wenn Sie das nicht einarbeiten möchten, dann reicht |
|
Ich halte hier auch nichts von herstellerspezifischen Angaben und "halbem Kram" (wie sonst auch nicht!). |
|
Zur momentanen Definition von Person würde ich die folgenden Veränderungen Vorschlagen:
|
|
@konstin Der Wertebereich für |
|
Im großen und ganzen finde ich diese Überarbeitungen gut, nur würde ich Kleine Randnotiz: Da es so viele unterschiedliche Titel und Abschlüsse gibt, kann die Angabe in diesem Feld gar nicht sinnvoll rationalisiert werden, es sei denn, wir sammeln die üblichen Formulierungen auf der ganzen Welt, was, mal wieder, den Fokus dieser Spezifikation übersteigt. |
|
Gibt es für |
|
Closed in 685bbf5 weil schadet nicht. |
Moin!
Nur als Hinweis, was ALLRIS alles so ausspuckt, hier das Beispiel für unseren OB:
Die Frage ist wahrscheinlich, ob man alle möglichen Felder (wie 6 Telefonnummern) optional aufnimmt oder man sich beschränkt. Generell wäre ich aber schon dafür, alle Informationen des Systems auch herauszugeben. Dazu müsste man aber wahrscheinlich schauen, was andere Systeme noch für Felder haben (vielleicht gibt ja auch eines noch pro Telefonnummer ne Beschreibung an).
kppartei muss übrigens dabei keine Partei sein, sondern kann auch Verein, Polizeipräsidium etc. sein.
The text was updated successfully, but these errors were encountered: