Inhalte durchsuchen
Neueste Kommentare
- Remote Arbeit im Team eGovernment Entwicklung bei
- Bandbreitenschonung bei der Nutzung von Webkonferenzsystemen bei
- Bandbreitenschonung bei der Nutzung von Webkonferenzsystemen bei
- Bandbreitenschonung bei der Nutzung von Webkonferenzsystemen bei
- Dynamische QR-Codes im MS-Office Word Serienbrief (Mac/Windows) bei
RSS-Feed abonnieren
Kategorien
- Allgemein
- Behörden-Webspeicher
- Clearingstelle
- Cloudcomputing
- CMS
- Datenschutz
- DeMail
- Dokumentenmanagement
- eGovernment
- eGovernment-Suite
- eSuite App
- eVerfahrensverzeichnis
- Formularserver
- Greetings
- GSA
- iWorks
- Konferenz
- LibreOffice
- Lotus Notes
- Meinung
- Mobil
- MS-Office
- nPA
- Off topic
- Office-Programme
- OpenData
- OpenGovernment
- OpenOffice
- OpenSource
- OZG
- Saperion Archiv
- Servicekonto
- Sitzungsdienst
- Smartphone
- Tablet
- Tipps und Tricks
- Virtuelle Poststelle
- VPS
- Web 2.0
- Workflow
Empfehlungen / Blogroll
Inhalt
Wer kann ckan?
„Die Welt wird nicht einfacher, auch mit OpenData nicht.“
Dies ist eine Erkenntnis aus dem gestrigen OpenData Workshop im KRZN, um die weitere Strategie in Bezug auf Datenbereitstellung zu erarbeiten. Ob sich diese Erkenntnis auf das Leben im Allgemeinen bezieht, lasse ich hier einmal unbeantwortet. Tatsächlich trifft das aber auf die technisch notwendige Infrastruktur zu, die uns zukünftig in Sachen Portalbereitstellung erwartet.
Wie bringt man offene Daten am besten an interessierte Firmen, Behörden, Bürgerinnen und Bürger? Gibt es Standardsysteme, die den Betrieb von Portalen zur Datenbereitstellung erleichtern? Was ist Pflicht, was ist Kür? Gibt es einen stufenweisen Einstieg? Welche Techniken muss man beherrschen, um einen Portalaufbau und einen Produktionsbetrieb bewerkstelligen zu können?
Als Zwischenfazit stellen wir fest, dass an ckan mangels standardisierter Alternativen und wegen sinnvoller Datenabgleiche mit anderen OpenData Portalen kein Weg vorbei führt. Wenn das etwas negativ klingt, dann hauptsächlich deshalb, weil ckan eigenlich in allen Bereichen der Installation Basistechniken erfordert, die heute in unserem Rechenzentrumsbetrieb noch nicht eingesetzt werden. Um die wichtigsten zu nennen:
- ckan basiert auf der Programmiersprache Python (kein PHP, kein JAVA)
- Solr wird als Suchengine benötigt (kein YaCy, keine GSA)
- Postgres SQL Server (kein MySQL, kein MariaDB, kein Oracle, kein DB2)
- Drupal als CMS Frontend (WordPress nur theoretisch, wir wären die ersten)
- Ninja Theming zum ckan-Oberflächen-Customizing (man ist nah am Core, wenig Möglichkeiten, macht keinen Spaß)
- Jetty Applikationserver (kein JBoss, kein Tomcat)
Legende: In Klammern das Jammern
Wenn man sich aber erst mal damit abgefunden hat, dass hier einiges an neuen Themen und Systemen auf uns zukommt (btw.: Neues macht ja auch manchmal Spaß), dann folgt die Planung von Know-How-Aufbau, Vereinfachung der Strukturen und die Erarbeitung geeigneter Stufenpläne. Dieser sieht als erster Entwurf für die Bereitstellung einer mandantenfähigen Portalstruktur dann so aus:
(eine etwas unstrukturierte Darstellung der zukünfigen ckan Struktur;-)
Im Klartext: ckan wird mandantenfähig implementiert, was mit der seit dieser Woche verfügbaren Version 2.0 mit den sogenannten „Organisationen“ möglich ist. Die Präsentation der Daten kann grundsätzlich mit einem Standardlayout einfach gehalten werden. Kommunen die ein individuelles Layout mit einer eigenen Einstiegsadresse anbieten möchten (http://offenedaten.kommunexyz.de), bekommen eine CMS-Anbindung. Hier scheint es am einfachsten zu sein, das vorhandene CMS (eGovernment-Suite/CMS) per Snippets/Datenquellen anzudongeln. Aufwändiger dürfte die Implementierung eines CMS wie Drupal oder WordPress sein. Das wird im Laufe der nächsten Zeit aber noch zu evaluieren sein. Die Königsdisziplin – Daten aus Fachanwendungen mittels Adapter zu pushen oder per Harvester zu sammeln und so in das ckan Portal zu pusten – wird uns danach (und dann vermutlich auch längere Zeit) beschäftigen, wenn das Basisportal erst mal sicher läuft.
Nicht alle Fragen konnten wir heute schon klären, aber einige Optionen für die weitere Vorgehensweise wurden herausgearbeitet. Diese Erkenntnisse werden jetzt noch strukturiert und in unserer verbandsinternen Arbeitsgruppe am 28.5.2013 mit den kommunalen Praktikern abstimmt. Unser Ziel bleibt, allen Kommunen im Verbandsgebiet einen kostengünstigen und einfachen Einstieg in die Bereitstellung von offenen Verwaltungsdaten zu ermöglichen.
Etwas Vorlaufzeit brauchen wir noch. Ich bin mir aber sicher, dass wir uns auf einem anspruchsvollen und erfolgversprechenden Weg befinden.
Schön, vor allem weil’s so alternativlos schein 😉 Wie geschrieben ist CKAN ein Quasi Standard für OGD-Portale.
Die von CKAN verwendete Software ist sicherlich nicht die, die im Rechenzentrum bisher Einsatz findet, doch nichtsdestotrotz ist die Software keine seltene, gerade Solr und Python erfreuen sich steigender Beliebtheit.
Nun zu meinen via Twitter angekündigten „Hää“? Wieso sollen die Daten in die eGovernment-Suite „eingedongelt“ werden, wenn es doch schon ein CMS (Drupal) gibt? Der Portal ist ja ohnehin eigenständig, hat also ähnlich wie der Blog keine direkte Verbindung an die eGov-Suite. Wäre es hier nicht einfacher, das einfach direkt auszuliefern statt nochmal durch ein CMS zu jagen?
Kommentar #1208 von Elmar Burke — 16.05.2013 um 09:17 Uhr