Konzeption Kontakt-Daten

Konzeption Kontakt-Daten

Bisher gibt es kein einheitliches Kontakt-Konzept für SiteKit und CityGov. Mit der Neukonzeption von Kontakt-Daten soll eine Basis geschaffen werden, die zu einem späteren Zeitpunkt auch von CityGov genutz werden kann.

Damit CityGov dieses Konzept auch nutzen, kann müssen dessen Anforderung direkt in der Konzeptions-Phase mit berücksichtigt werden.

Einführung

Für eine Kontaktaufnahme sind bestimmte Informationen erforderlich. Dies kann z.B. eine Telefonnummer oder eine E-Mail-Adresse sein. Ein Kontakt kann entweder allgemein mit einer Organisation (Behörde, Amt, Verein, Firma, …) aufgenommen werden oder direkt mit einer Person. Diese Person kann (muss aber nicht) die Kontakt-Person einer Organisation sein.

Für eine Kontakt-Aufnahme sind weitere Informationen hilfreich. Hierzu gehören

  • Adresse
  • Raumnummer
  • Anfahrts-Beschreibung (z.B Routenplaner)
  • Öffnungszeiten, Sprechzeiten, Service-Zeiten, …
  • Informationen zur barrierefreien Erreichbarkeit
  • …

Kontakt-Daten können aus einer einfachen Telefonliste für Personen bestehen. Aber auch aus komplexeren Strukturen mit Verknüpfungen zwischen Personen und Organisationen, bei denen Daten wie z.B. die Adresse oder Öffnungseiten für die Person von der Organisation übernommen wird. Weiter können in dieser Konstellation auch noch Daten an der Verknüpfung enthalten sein. Beispielsweise die Funktion der Person für diese Organisation (Leiter des Amtes). Die Person kann in einer anderen Organisation eine anderer Funktion haben.

Im nachfolgenden werden die Teilbereiche beschrieben aus denen sich die Kontakt-Date zusammensetzten können.

Adressen

Hier kann es verschiedene Typen von Adressen geben

  • Besucheradresse (Dies ist die “normale” Adresse), ggf mit GEO-Daten
  • ggf. Abweichende Postadresse (kann auch eine Postfach-Adresse sein)
  • Privat-Adresse (Zusätzliche Adresse bei einer Person, die die Adresse einer Organisation übernimmt), ggf mit GEO-Daten

Kommunikations-Kanäle

  • Telefonnummern
    • Festnetznummern
    • Mobilfunknummern
    • Faxnummern
  • E-Mail Addressen
  • Web-Links

Öffnungszeiten

Wochenblöcke für verschiedene Arten von Öffnungszeiten wie

  • Allgemeine Öffnungszeiten
  • Besuchszeiten
  • Servicezeiten
  • Anmeldezeit
  • Kernzeit
  • …

Person

Eine Person ist der persönliche Ansprechpartner für eine Kontakt-Aufnahme mit Daten wie

  • Anrede (ggf. gender-neutral)
  • Title
  • Vorname
  • Nachname
  • Namenszusatz
  • Bild

Eine Person sollte die Zugehörigkeit zu einer Organisation über ein Verknüpfung aber auch über ein einfachen Text angeben können.

  • Verknüpfung zu einer Organisation
    • Adresse(n) wird/werden übernommen
    • Öffnungszeiten werden übernommen
  • Direkte Angaben zu einer Organisation ohne Verknüpfung
    • Name der Organisation
    • Adresse(n)
    • Öffnungszeiten

Die Kommunikations-Kanäle einer Person werden immer direkt angegeben und nicht von der Organisation übernommen. Ggf kann die Person einen Link zur Organisation bereit stellen um auf die Organisation zu verweisen.

Organisation

Eine Organisation kann entweder direkt als Kontakt-Punkt dienen oder als einheitliche Datenbasis für Personen die mit Organisationen verknüpft sind. Organisation stelle folgende Daten bereit

  • Name der Organisation
  • Bild
  • Adressen
  • Öffnungszeiten
  • Kommunikations-Kanäle (werden nicht von Personen übernommen)

Umgang mit Importen

Ein gängiger Anwendungsfall ist die Datenübernahmen von Kontakt-Daten über importe. Diese können einmalige Importe sind, aber auch regelmäßige Datensynchronisationen. In einigen Fällen ist es dann auch noch notwendig die Importierten Daten redaktionell weiter zu bearbeiten. Z.B. um Bilder oder Telefonnummern zu ergänzen.

Daher soll es vorgesehen werden, das die Importierten Daten in der redaktionellen Oberfläche gekennzeichnet werden. Es soll dafür gesorgt werden, dass diese Daten nicht geändert werden können. Welche Felder das betrifft ist je nach import unterschiedlich und muss individuell konfigurierbar sein.

Weiter muss die Möglichkeit bestehen importierte Daten zu ergänzen. Das ist bei den Felder, die die Daten als Liste aufnehmen etwas schwieriger. In diesem Fall nimmt eine Liste die Importierten Daten auf. Hier muss es dann eine weitere Liste geben, die die redaktionellen Ergänzungen aufnimmt.

Implementierung

Im ersten Schritt sollen nur Personen-Kontakte umgesetzt werden. Es soll nicht einen einzelnen Objekt-Typ geben. Sondern es soll möglich sein mit der bereit gestellten Technik eigene Objekt-Typen zu definieren, die diese Technik verwenden. Weiter soll es möglich sein diese ggf. Kundenspezifischen Objekt-Typen mit weiteren Kundenspezifischen Daten anzureichern.

Die in Punkt “Umgang mit Importen” angegebenen Techniken sollen noch nicht umgesetzt werden.

Die einzelnen Datenblöcke sollen wie folgt aufgeteilt sein.

Personen-Daten

Personen-Daten sollen in einer Subinformation sp_personData abgelegt werden.

  • Anrede sp_salutation, Wert: mr, mrs, keine Anrede
  • Title sp_title
  • Vorname sp_firstname
  • Nachname sp_lastname
  • Namenszusatz sp_nameappendix
  • Bild sp_image

Eingabe-Template soll als View-Template mit dem Name person.spml unter https://gitlab.sitepark.com/ies-modules/sitekit/-/tree/develop/sitekit-module%2Fsrc%2Fmain%2Fwebapp%2Ftemplates%2FsectionTypes%2Fviews angelegt werden.

Es soll ein Model-Getter-Template mit dem Namen getPersonData.spml unter https://gitlab.sitepark.com/ies-modules/sitekit/-/tree/develop/sitekit-module%2Fsrc%2Fmain%2Fwebapp%2Fmodels angelegt werden. Diese soll auch vom Aggregator verwendet werden.

Es soll ein PHP-PersonData-Model mit dem Namen PersonData.php unter https://gitlab.sitepark.com/apis/sitekit-php/-/tree/develop/php/SP/SiteKit/Model/Contact angelegt werden, das die Aggregierten Daten aufnimmt.

Adress-Daten

Hierzu existiert schon ein Eingabe-Template https://gitlab.sitepark.com/ies-modules/sitekit/-/blob/develop/sitekit-module/src/main/webapp/templates/sectionTypes/views/address.spml

Über diese können Strasse, Hausnummer, PLZ und Ort eingegeben werden. Diese soll verwendet werden, da hier auch der Adress-Service schon angebunden ist und Locality-Features bereit gestellt werden.

Hier existiert schon ein Model-Getter-Template hierfür https://gitlab.sitepark.com/ies-modules/sitekit/-/blob/develop/sitekit-module/src/main/webapp/models/getAddressData.spml

Dies reicht aber für die Adress-Daten noch nicht aus.

Wir benötigen noch ein zusätzliches View-Template adresses.spml um zukünftig auch Post-Adressen und andere Typen von Adressen bereit stellen zu können.

Zunächst benötigen wir nur die Besucher-Adresse.

Dazu muss es noch ein Eingabe-View-Tempalte visitorAddress.spml geben. Dies soll intern das Template address.spml verwenden und noch folgende weitere Daten aufnehmen.

  • Gebäudename
  • Bemerkung

Dazu muss es noch zwei Model-Getter-Templates geben

  • getVisitorAddress.spml
  • getAddresses.spml

Und noch zwei PHP-Models im Namespace \SP\SiteKit\Model\Contact

  • VisitorAddress
  • Addresses

Als Vorlage soll die mit diesem Konzept nicht mehr ganz aktuelle Java-Implementierung dienen:

Kommunikations-Kanäle

Hier ist es wichtig, das Listen von Telefonnummern, E-Mail-Adressen usw mit verschiedenen Typen unterstütz werden.

  • Liste von Telefonnummern
    • Type der Telefonnummer (Festnetz-Nummer, Fax-Nummer, Mobilfunk-Nummer)
    • Nummer
    • Anmerkungs-Feld
  • Liste von E-Mail-Adressen
    • Email-Adresse
    • Anmerkungs-Feld
  • Liste von Web-Links
    • URL
    • Link-Label
    • Anmerkungs-Feld

Anwendung in Kunden-Modulen

Kontakt-Modelle sind Kundenspezifisch. Hier können Personen oder Organisationen oder andere Einheiten gemeint sein. Daher wird kein Komplettes Modell von SiteKit bereit gestellt. Im Kunden-Modul wird ein Modell erzeugt, das die Bausteine vom SiteKit verwendet kann (PersonData, Communications, Addresses)

Hierzu stehen Templates-Views und SPML-Model-getter für die CMS-Seite und PHP-Models und Renderer-Helper für die Webserver-Seite bereit.

Existieren Seiten-Typen die diese Kontakt-Modelle repräsentieren, sollte hierzu eine eigene Resource-Implementierung bereit gestellt werden die über eine Getter-Methode das Kontakt-Model zurück liefern kann. Wenn Diese Resource-Klasse noch das Interface \SP\SiteKit\Model\Content\VCard\VCardResource implementiert, können aus den Daten auch VCard-Exporte bereit gestellt werden. Wenn das Model noch das Interface \SP\SiteKit\Model\JsonLdSerializable implementiert und für das Modell noch ein JsonLd-Controller bereit gestellt wird, können auch JSON-LD-Daten erzeugt werden.

Um aus dem Model z.B. einen Kontakt-Abschnitt zu rendern kann der Helper \SP\SiteKit\Renderer\Html\Helper\Contact verwendet werden.