Semantisch zusammenhängende Informationen und Wissensräume über Objekte in Museen und Ausstellungen

Durch die Digitalisierung des Polytechnischen Journals, welches von 1820 – 1931 herausgegeben wurde und viele technische Themengebiete diskutierte, steht ein riesiger Datenberg zur Verfügung. Als erste Herausforderung wurden die 72546 Artikel und 159243 Abbildungen für eine Webseite digitalisiert und aufbereitet. Somit ist es dem interessierten Leser möglich sich online durch die 346 Bände des Journals zu lesen. Da im Journal viele Themengebiete behandelt werden, die auch im direkten Bezug zu Exponaten in Museen stehen, ist es wünschenswert die Inhalte auch für mobile Geräte bereitzustellen. So wäre es dem Museumsbesucher möglich, während eines Aufenthalts im Museum selbstständig zu Themengebieten im Polytechnischen Journal mit einem mobilen Gerät nachzuschlagen. Dieses ist zwar auch über die Webseite möglich. Sie bietet aber nicht die Bedienbarkeit einer APP und setzt außerdem zwingend eine ständige Internetverbindung voraus.

Searchjpage

Ziel

Zum Abschluss dieses Forschungsprojektes sollen folgende Ziele erreicht werden:

  • Untersuchung der Möglichkeiten zur mobilen Suche innerhalb des Polytechnischen Journals
  • Möglichkeiten zur Offline-Bereitstellung des Polytechnischen Journals auf mobilen Endgeräten
  • Implementierungen eines multiplattform Prototyps der als Grundlage für weitere Projekte dienen kann

 

Grundlagen und Technologien

In diesem Abschnitt werden die Technologien vorgestellt, mit welchen das Polytechnische Journal arbeitet. Außerdem werden Suchmaschinen und plattformunabhängige Frameworks erläutert.

Polytechnischer Journal

Das „Polytechnische Journal“ wurde 1820 vom Augsburger Fabrikanten und Chemiker Johann Gottfried Dingler begründet. Mit einer Laufzeit von 111 Jahren ist diese Zeitschrift ein beispielloses, europaweites Archiv der Technik-, Wissens- und Kulturgeschichte.

Als Dingler-Online wurde in diesem Projekt des Instituts für Kulturwissenschaft der Humboldt-Universität zu Berlin – in Kooperation mit der Sächsischen Landesbibliothek – Staats- und Universitätsbibliothek Dresden (SLUB) und mit dem Digitalisierungs-Dienstleister Editura GmbH – der gesamte Bestand des »Polytechnischen Journals« digitalisiert und frei im Internet verfügbar gemacht.

Der gesamte Inhalt des Journals wurde mittels einer OCR-Software texterkannt. Der elektronische Volltext ist – konform zu dem für die geisteswissenschaftliche Forschung entwickelten XML-Standard – per TEI P5 ausgezeichnet und durch ein Metadatensystem klassifiziert. Dadurch entstand diese hochwertige, komfortable und öffentlich zugängliche Datenbank mit großem wissenschaftlichen Mehrwert gegenüber der gedruckten Version.[#Kass01]

Speicherformate

Das Journal liegt in folgenden Formaten vor.

  • Die Artikel stehen in HTML Form auf der Webseite des Polytechnischen Journals (www.polytechnischerjournal.de) bereit.
  • Die Inhalte eines Artikels in reiner Textform sind unter der Adresse: http://dingler.culture.hu-berlin.de/article/plain/abrufbar. Hierbei ist zu beachten, das nach dem „plain/“ das Band des Journals und der Artikel mit seiner Kodierung angegeben werden muss. z.B. ../plain/pj002/ar002005
  • Alle Artikel stehen im XML-Standard TEI P5 auf dem Server:http://141.20.150.36/~fw/dingler-articles/bereit. Die XML Dateien sind hierbei zwischen 3 und 979 Kilobyte groß. Alle Artikel zusammen haben einen Speicherplatzbedarf von ca. 1,1 Gigabyte.
  • Es steht ein Datenbankbackup einer Postgresql Datenbank mit 529 MB Speicherplatzbedarf bereit. Es beinhaltet alle Artikel, Autoren und Abbildungsverknüpfungen sowie deren Beziehungen untereinander.

Plattformunabhängige Frameworks

Eine Anwendung benötigt in der Regel immer eine sogenannte Laufzeitumgebung, in welcher sie zur Ausführung gestartet wird. Ist ein Programm plattformunabhängig, so kann in verschiedenen Laufzeitumgebungen gestartet werden. Diese können sich in Architektur, Prozessor, Übersetzer, Betriebssystem und weiteren Dienstprogrammen unterscheiden. Es existieren verschiedene Frameworks die eine Plattformunabhängigkeit auf dem Sektor der mobilen Geräte ermöglichen. Um die wichtigen Plattformen iOS, Android und Windows Phone abzudecken, kann zu Webanwendungen oder nativen Lösungen gegriffen werden. Webanwendungen bieten hierbei meist nur eingeschränkte Zugriffsmöglichkeiten auf die Hardware des jeweiligen Gerätes.

Xamarin (Mono)

Mono ist eine Open Source Software, die durch Xamarin entwickelt wird. Das Framework ist zu .NET kompatibel und nutzt die Programmiersprache C#. Mit Xamarin.iOS und Xamarin.Android wurden zwei unter kommerzieller Lizenz stehende Implementierungen für iOS und Android vorgestellt. Im Fall von iOS wird aus dem Monocode nativer iOS Code erzeugt. Für Android steht eine Mono Laufzeitumgebung bereit. Da C# als native Programmiersprache für Windows Phone genutzt wird, ist hier ebenfalls eine Nutzung möglich. In der Xamarin C# Umgebung kann auf alle nativen APIs der jeweiligen Plattformen zugegriffen werden. Somit sind Funktionalitäten wie Netzwerk, Kontakte, Events, Dateisystem, Geolokalisation und Benachrichtigungen möglich.[#CrossPlatformTimo]

Suchmaschinen

Die Suchmaschine ist eine Anwendung zur Recherche von Dokumenten, die in einem Computer, einer Datenbank oder einem Computernetzwerk gespeichert sind. Sie erstellen einen Schlüsselwort-Index für die Dokumentbasis, um Suchanfragen über Schlüsselwörter mit einer nach Relevanz geordneten Trefferliste zu beantworten. Nach Eingabe eines Suchbegriffs liefert eine Suchmaschine eine Liste von Verweisen auf möglicherweise relevante Dokumente zurück. Suchen können bei mächtigen Suchmaschinen feingranular angepasst werden, um eine möglichst hohe Treffergenauigkeit zu erlangen.

Die folgend aufgeführten Suchmaschinen Solr und ElasticSearch basieren auf Apache Lucene, welche für das Indizieren von auch unstrukturierten Daten zuständig ist. Lucene selbst bietet aber keine Möglichkeit der Administration und Replikation sowie weiterführende Features.

Apache Solr

Solr ist eine schnelle, skalierbare und einfach zu nutzende Java Open Source Server Suchtechnologie. Solr kann verschiedene Datenquellen indizieren. Darunter zählen Datenbanken die über JDBC abgefragt werden können, CSV Dateien, XML Dateien, Tika, URL’s und auch Word oder PDF Dokumente. Als Suchanfragen-Antwortformate sind XML, JSON, Python, PHP, CSV und selbst über Templates erzeugte HTML Formate möglich.[#klose2014Solr]

ElasticSearch

Elasticsearch basiert ebenfalls auf Lucene und ist als direkte alternative zu Apache Solr zu sehen. Bietet aber von Hause aus nur JSON und XML als Antwortformate. Es können aber mehr Datenquellen nativ als Indizierungsquelle genutzt werden. Zum Beispiel Rivers modules – ActiveMQ, Amazon SQS, CouchDB, Dropbox, DynamoDB, FileSystem, Git, GitHub, Hazelcast, JDBC, JMS, Kafka, LDAP, MongoDB, neo4j, OAI, RabbitMQ, Redis, RSS, Sofa, Solr, St9, Subversion, Twitter und Wikipedia.[#SolrVsElastic]

DTA OpenSearch Wrapper

Der OpenSearch Warpper des Deutschen Text Archivs ist unter „kaskade.dwds.de/dingleros/“ zu erreichen. Die Datensätze des Polytechnischen Journals sind dort bereits durch den Sphinx Search Server verschlagwortet. Suchen können über eine Query URL durchgeführt werden. In den Parametern der URL kann auch das Ausgabeformat mit angegeben werden. Hierbei werden HTML, KWIC, Histogram, Text, JSON, YAML, ATOM, RSS und raw respone data unterstützt.[#DDCOpenSearch] 3 Szenarios und Anforderungen

In diesem Abschnitt verschiedene Anwendungsszenarios aufgezeigt und die Anforderungen an das zu entwerfende System gestellt.

Anwendungsszenario

Folgende Anwendungsszenarios sind denkbar.

  • Die App wird zur Recherche an einem beliebigen Ort mit Internetverbindung genutzt. Der Nutzer nutzt die Suchfunktion, um Inhalte im Journal zu finden. Er findet mehrere interessante Artikel und speichert diese, um sie später zu lesen. Eine Internetverbindung ist nach dem Speichervorgang nicht mehr notwendig, da die Artikel im lokalen Speicher des Gerätes abgelegt werden.
  • Der Nutzer ist mit einem mobilen Endgerät im Museum und steht vor einem für ihn interessanten Exponat. Er nutzt die Suchfunktion der App, um weitere Informationen zu dem Thema und dem Exponat zu erhalten.
  • Der Nutzer ist mit einem mobilen Endgerät im Museum und wird durch die App auf Inhalte im Polytechnischen Journal aufmerksam gemacht. Dieses geschieht durch Drahtlostechnologien wie NFC oder Bluetooth (iBeacon).
  • Der Nutzer plant einen Museumsbesuch nach einem bestimmten Thema. Die App bietet verschiedene Touren an und führt den Nutzer thematisch durch das Museum.

Anforderungen

Damit die gewünschte App entworfen werden kann, müssen diverse funktionale und nicht-funktionale Anforderungen definiert sein. In diesem Abschnitt werden die gewünschten Anforderungen aufgelistet und die Möglichkeiten analysiert, wie diese zu realisieren sind. In den folgenden Kapiteln werden die verschiedene Lösungsvorschläge unter spezieller Betrachtung der festgelegten Anforderungen erforscht.

Nicht-funktionale Anforderungen

In diesem Abschnitt werden wichtige nicht-funktionale Anforderungen genauer analysiert. Neben den hier beschrieben nicht-funktionalen Anforderungen sollten alle anderen in der Realisierung auch berücksichtigt und erfüllt werden, wie:

  • Sicherheitsanforderung
  • Zuverlässigkeit
  • Korrektheit
  • Aussehen und Handhabung
  • Leistung und Effizienz
  • Skalierbarkeit
  • etc.

Flexibilität

Eine wichtige nicht-funktionale Anforderung ist die Flexibilität. Dies bedeutet, dass übliche Standards unterstützt werden und die App in verschiedenen Umgebungen funktionsfähig bleibt. Die zu entwerfende App sollte so gestaltet werden, dass sie nicht nur eine Plattform unterstützt, sondern auf allen gängigen mobilen Betriebssystemen funktionsfähig ist.

Kosten

Eine weitere wichtige nicht-funktionale Anforderung sind die Randbedingungen (Kosten). Diese sollten möglichst gering und im Rahmen der im Projekt verfügbaren Mittel liegen. Das Ziel dieses Forschungsprojektes ist es, ein App Prototypen zu entwerfen, welcher den Mehrwert aufzeigt, den der Polytechnischen Journal in Kombination mit mobilen Endgeräten haben kann.

Benutzbarkeit

Die Benutzbarkeit der App soll in der für einen Prototypen typischen Rahmen liegen. Das heißt, die Benutzeroberfläche wird erst bei Feststellung eines Mehrwert, durch die Kombination von Polytechnischen Journal und mobilen Endgerät, auf Benutzerfreundlichkeit hin optimiert.

Funktionale Anforderungen

Die funktionalen Anforderungen definieren die eigentliche Funktionalität der App. In den folgenden Unterkapiteln werden die verschieden Funktionalitäten beschrieben.

Suche

In der App soll es möglich sein die Datenbank des Polytechnischen Journals zu durchsuchen. Hierbei sollten sich die Suche nicht nur auf einfache Suchanfragen beschränken, sondern auch Komplexe Suchwortkombinationen erlauben. Dieses ist notwendig um, in den zehntausenden Artikeln schnell ein brauchbares Ergebnis zu erhalten. Um solche Anforderungen zu erfüllen, muss auf eine erweitere Suchintelligenz gesetzt werden. Ob diese lokal auf dem Gerät oder auf einem Server läuft, ist zu untersuchen.

Offline Artikel

Artikel müssen unabhängig von dem Netzwerkstatus des Gerätes abrufbar sein. Da die komplette Datenbank des Polytechnischen Journals sehr groß ist, soll eine durch den Benutzer definierte Auswahl an Artikeln offline zur Verfügung stehen. Die Artikel sind lokal auf dem Gerät vorzuhalten und dürfen nicht beim verlassen und wieder aufrufen des Programms verloren gehen.

Entwurf

Im Folgenden werden einige der wichtigsten Phasen im Entwurf der App genauer analysiert. Dabei wird der gewählte Lösungsweg näher beschrieben, die genutzten Technologien erläutert und auf mögliche Probleme sowie Lösungsansätze dazu verwiesen.

Multiplattform Design

Um der Anforderung einer multiplattform App gerecht zu werden, wird auf ein Mono Framework gesetzt. Die Open Source Programmiersprache, die durch Xamarin entwickelt wird, bietet unter einer kommerziellen Lizenz Unterstützung für iOS, Android und Windows Phone an. Der Programmcode kann dank Plattformunabhängigkeit zu großen Teilen unter allen Zielbetriebssystemen wieder verwendet werden. Die hierbei entstehenden Programme sind nativ, das heißt alle gerätespezifischen APIs sind direkt ansprechbar. Dieses ist wichtig, da so die App um alle denkbaren Funktionen, die die Kombination aus Gerätesensoren bieten, in späteren Versionen der App implementiert werden können.[#CrossPlatformTimo]

Xamarin kann durch eine mit Projektmittel finanzierbaren Studentenlizenz erworben werden. Die kosten hierfür betragen 198$

Artikelsuche in der Journal

Um in der Datenbank nach dem Suchwort entsprechenden Artikeln zu suchen, können verschiedene Ansätze Verfolgt werden.

Option #1

Eine Option ist die komplette Kovertierung der Postgresql Datenbank des Polytechnischen Journals in das Formal SQLite und die anschließende Übertragung auf das Mobilgerät. Die Formatkonvertierung ist nötig, da ein Postgresql Service nicht lokal auf mobilen Endgeräten lauffähig ist. Postgresql ist hierfür zu Ressourcen hungrig und würde außerdem eine eigene Implementierungen je Plattform benötigen.

SQLite wird durch Xamarin auf jeder Plattform unterstützt und ist somit universell einsetzbar. Eine Anleitung zum umwandeln von Posgresql zu SQLite Datenbanken findet sich hinter der Quelle.[#Posgres2Sqlite] Der Datenbank Dump der Posgresql Datenbank des Polytechnischen Journals ist 529 MByte groß. Daher ist die zu erwartende Größe der SQLite Datenbank ebenfalls in diesem Bereich. Dies bedeutet, dass die Datenbank nach dem Start des Programms auf das Mobilgerät geladen werden muss, da Apps durch Einschränkungen der jeweiligen Appstores in der Regel nicht größer als 50 Megabyte sein dürfen.

Die Datenbank umfasst nur die Texte und keine Abbildungen oder andere Inhalte. Somit wird trotz der lokal verfügbaren Datenbank eine Internetverbindung benötigt um Abbildungen nachzuladen. Alternativ können diese aber auch vorher lokal auf dem Gerät gespeichert werden. Lokal müssen dann aber bei 159243 Hochauflösenden Abbildungen mit einem geschätzten Größe von zwei Megabyte je Abbildung 311 Gigabyte Speicherplatz verfügbar sein.

Um die Datenbank effektiv zu durchsuchen, ist eine der Einsatz einer Suchengine wie Apache Solr oder Elasticsearch Sinnvoll. Beide Programme sind umfangreiche Serverprogramme, die nicht auf Mobilgeräten einsetzbar sind. Somit bleibt für die lokale Suche nur der Entwurf von SQL Abfragen auf die lokale SQLite Datenbank, welches bei dieser Größe viele Ressourcen (Zeit) benötigt und schlechtere Ergebnisse liefert als eine Suchengine. Durch die Arbeit mit der Kopie der original Datenbank des Polytechnischen Journals sind Änderungen in dieser erst nach erneutem Konvertieren eines Posgesql Datenbank Dumps zu SQLite und der darauf folgenden Verteilung auf die Mobilgeräte verfügbar.

Option #2

Eine weiter Möglichkeit ist die Nutzung der Originalen Datenbank des Politechnischen Journals zur Suche. Das erfordert zwar eine Internetverbindung, während des Suchvorgangs, ermöglicht so aber auch den Einsatz eines Suchservers um Ergebnisse zu erhalten. Die Datenbank wird dabei von dem Suchserver indiziert und Suchanfragen benötigen dann keine umfangreichen Abfragen auf die Datenbank.

Technologien zur Suche sind Elasticsearch und Apache Solr. Beide Technologien unterstützen das direkte indizieren einer Posgresql Datenbank und können somit Suchen auf den Originaldaten des Polytechnischen Journals durchführen. Außerdem bietet das Deutsche Textarchiv unter der URL http://kaskade.dwds.de/dingleros/ einen OpenSearch Warpper an, welcher den kompletten Inhalt des Polytechnischen Journals bereits verschlagwortet hat.

Alle Suchtechnologien bieten als Antwort XML, JSON und weitere Formate an. Suchanfragen können so an eine der Technologien gestellt und Antworten in der App dargestellt werden.

Unterschiedliche Suchergebnisse

Durch die Testinstallation von Apache Solr, mit Datenquelle Polytechnisches Journal, war es möglich Suchergebnisse zwischen Solr und dem Open Search Warpper zu vergleichen. Die Ergebnisse fallen, zum Beispiel bei dem Wort „Honig“, sehr unterschiedlich aus.

Der Open Search Warpper liefert zu jedem gefundenen Wort „Honig“, innerhalb eines Artikels, einen Sucheintrag zurück. Dies bedeutet das die Ergebnisliste Doppelungen enthält.

Solr liefert nur einen Eintrag je Artikel. Die Ergebnisliste unterscheidet sich von des Open Search Warppers nicht nur durch keine Doppelungen, sondern auch durch eine andere Wichtung (Sortierung) von Ergebnissen.

Welche der beiden Technologien die Inhaltlich besseren Ergebnisse liefert, kann erst nach genauerer Analyse der Ergebnislisten, durch Fachpersonal, festgestellt werden.

Offline Bereitstellung von Artikel

Um dem Nutzer ein lesen von Artikeln ohne Internetverbindung zu ermöglichen, müssen diese Lokal auf dem Gerät gespeichert sein. Im [sub:Artikelsuche-in-der] werden zwei Verfahren zur Haltung von Daten vorgeschlagen.

Für Option #1 müssen die dem Artikel zugehörigen Abbildungen, wenn nicht lokal vorhanden, nachgeladen und gespeichert werden. Mehr ist nicht notwendig, da alle Artikel auf dem mobilen Endgerät gespeichert sind.

Option #2 benötigt mehr Aufwand. Artikel müssen komplett mit Text sowie Abbildungen aus der Onlinedatenbank des Journals auf das Gerät übertragen werden.

In beiden Fällen ist eine vom Benutzer geführte Liste von Offline abrufbaren Artikeln zu führen. Die Offlineartikel sollten daher auf dem Gerät in einer extra Tabelle oder extra Datenbank abgelegt werden, damit die lokalen Originaldaten (Option #1) nicht verändert werden. Die Liste der Offlineartikel muss dem Nutzer ermöglichen Artikel vom Gerät zu löschen, um Speicherplatz freizugeben.

Benutzeroberfläche

Xamarin ist ein sehr mächtiges Werkzeug, um Multiplattform Apps zu schreiben. Es bietet unter anderen die Möglichkeit „Xamarin.Forms“ einzusetzen.[#XamForms] Dieses ist eine Technologie, um geräteunabhängig eine Benutzeroberfläche zu gestalten, die auf allen Geräten wie Nativ aussieht. [fig:Xamarin.Forms-Kartenapp] zeigt eine Kartenapp, die mit exakt dem selben Code für alle Plattformen generiert wurde. Die App hält das spezifische Betriebssystemlayout ein und ist dabei trotzdem über alle Plattformen portabel. Dieses Feature ermöglicht somit eine, für den Nutzer im Layout gewohnt dargestellte App, zu erzeugen.

Xamarin.Forms ist vom Funktionsumfang nicht so groß wie das native Programmieren mit Mono auf der jeweiligen Plattform. Es reicht aber aus, um alle Basiselemte der Benutzeroberfläche zu erzeugen. Die App kann später um systemspezifische Funktionen erweitert werden. Hierfür sind dann extra Codepfade je Plattform nötig.

Xamarin.Forms Kartenapp Quelle: xamarin.com/forms

Artikelaufbereitung

Die Artikel sollen im Prototyp nur als reine Textinformationen erscheinen. Der Prototyp soll aufzeigen dass das Journal einen Mehrwert im Museum oder unterwegs auf dem Mobilgerät erzeugen kann. Das heißt das Funktionalitäten wie Abbildungsanzeige und Verweisen zu Autoren bei Bedarf später Implementiert werden. Sofern möglich, werden im Prototypen schon Platzhalter vorgesehen.

Prototyp Implementierung

Der im Rahmen des Forschungsprojektes entstandene Prototyp basiert auf der Option #2 aus [sub:Artikelsuche-in-der] und allen darauf folgenden Bedingungen. Als Suchservice wird auf den vom Deutschen Textarchiv bereitgestellten Open Search Warpper zurückgegriffen. Option #2 ist aufgrund der nicht vorhanden Ressourcen auf mobilen Geräten und der eingeschränkten Durchsuchbarkeit der Daten gewählt worden. Auf den Search Warpper des Textarchives ist gesetzt worden, weil somit exakt das gleiche Suchsystem wie auf der Webseite des Technischen Journals eingesetzt wird. Eine Testinstallation von Apache Solr mit der Datenbank des Polytechnischen Journals als Quelle hatte gezeigt, dass die Suchergebnisse sich teils stark von denen des Open Search Warppers unterscheiden. Durch Nutzung des Open Search Warppers sind die Suchergebnisse auf allen Systemen identisch.

In den folgenden Kapitel werden die verschiedenen Implementierungen beschrieben.

Systemarchitektur

In [fig:Systemarchitektur] ist die Systemarchitektur schematisch dargestellt. Das System setzt sich aus fünf Geräten zusammen. Es besteht aus dem mobilen Endgerät, dem Open Search Server, dem Posgresql Server für die Produktiv Datenbank des Polytechnischen Journals, dem gespiegelten Postgresql Server für dieses Projekt und einen Webservice für Artikelanfragen.

Systemarchitekur

Systemarchitektur

Artikelsuche

Der Webdienst des Servers ist unter der URL kaskade.dwds.de/dingleros/ zu erreichen. Suchanfragen sowie Sucheinstellungen können über die URL übermittelt werden. Es ist möglich das Antwortformat, das Startelement der Antwortliste, die Länge der Antwortliste und die KWIC (Keywords in Context) Breite anzugeben. Für das Forschungsprojekt ist das Ausgabeformat RSS gewählt worden, da reines XML vom Open Search Warpper nicht unterstützt wird. RSS ist eine Unterart von XML und somit ohne weiteres mit Mitteln des Xamarin.Forms Framework zu parsen.

Posgesql Artikeldatenbank

Da ein direkter Zugriff auf die Produktivserver nicht möglich ist, wurde Mittels des Datenbank Dumps des Polytechnischen Journals eine Kopie des Produktivservers aufgesetzt. Nur der Open Search Warpper läuft auf den Produktivdaten. Xamarin.Forms benötigt eine Interface für den Zugriff auf die Posgresql Datenbanken. Die Wahl fiel auf ein XML Interface, da so Codebestandteile des XML Parsers für den Open Search Warpper wieder verwendet werden konnten. Das Interface selbst ist mit PHP implementiert. Dem Script wird die ArtikelID (z.B: ar10032) übergeben und dieses erzeugt als Ergebnis eine XML Datei mit allen Inhalten des Datenbankeintrags. Die XML Datei wird dann durch den Parser ausgewertet und in der App angezeigt. [fig:ER-Modell–] zeigt die Datenbankstruktur des Polytechnischen Journals auf.

ER Modell – Postgresql DB Polytechnischer Journal

Lokale SQLite Datenbank

Wird durch den Benutzer die Speicherung eines Artikels für die Offlinenutzung gewünscht, wird das Artikel Objekt in die lokale Datenbank des Mobilgerätes geschrieben. Die Daten sind dort dauerhaft gespeichert und auch nach Neustart der App ohne Internetverbindung verfügbar. SQLite wird nicht nativ von Xamarin.Forms unterstützt, somit ist es nötig eine eigene SQLite Klasse zu erstellen und je Plattform den Speicherort festzulegen.[#XamarinSQLite]

Die Datenbank besteht aus einer Tabelle in der Artikel mit einer eindeutigen ID gespeichert werden. Die Tabelle hat die gleichen Felder wie die „article“ Tabelle der Postgresql Datenbank.

Programmstruktur

Die Programmstruktur orientiert sich am „Model View Controller“ Konzept[#MVC]. Dieses ist besonders wichtig, da die Views sich von Plattform zu Plattform unterscheiden können. Das Modell und der Controller bleiben größtenteils gleich.

Die App besteht aus Controllern für die Datenbank und die XML Abfragen, verschiedene Views und die Modelle Article und ArticleSearchResponseItem. Das Modell Article stellt einen vollständigen Artikel des Journals dar. Das ArticleSearchResonseItem ist nötig, da sich Antworten des Open Search Warppers von der Struktur eines „Article“ Objekts unterscheiden. Der Controller ArticleDatabase implementiert die Funktionalitäten zum lokalen Speichern der Artikel. Der Controller XMLHandler kümmert sich um die Antworten des Open Search Warppers und um die des Datenbankinterfaces der Projektdatenbank. Der Controller TTSHandler ist für „Text To Speech“ Funktionalitäten zuständig. Er nimmt den vorzulesenden Text entgegen und bereitet diesen für die jeweilige Plattform auf. Dieses ist notwendig, da hier nicht Xamarin.Forms genutzt werden kann und für jede Plattform eine eigene Implementierung benötigt wird.

[fig:Klassendiagramm-des-Prototypen] zeigt das Klassendiagramm der C# Komponenten des Prototyps. Es ist unter anderen die Unterteilung in Model, View und Controller deutlich gemacht.

Klassendiagramm des Prototypen

Benutzeroberfläche

Durch den Einsatz von Xamarin.Forms sind einige Einschränkungen zu beachten. Es sind nicht alle Layout und Kontrollelemente wie bei der nativen Plattformprogrammierung vorhanden. Das Framework beschränkt sich hier auf die größtmögliche Schnittmenge zwischen den drei unterstützen Plattformen. Mit jedem Update durch Xamarin wird die Menge an möglichen Elemente erweitert.

Der Prototyp umfasst sechs Views, die jeweils einen eigenen Aufgabenbereich haben. Beim Entwurf wurde darauf geachtet, dass möglichst viele Komponenten mehrfach verwendet werden können. Folgend werden die wichtigsten Views kurz, inklusive Screenshot (Android und Windows Phone Version), beschrieben.

MenuPage

Die View ist für das Anzeigen des Menüs verantwortlich. Sie generiert eine so genannte „TabbedPage“. Das bedeutet, dass Inhalte, je nach Plattform, über Tabs am oberen oder unteren Rand der App angezeigt und angewählt werden können. Die MenuPage ist als Container zu sehen. Unter den Tabs werden SearchPage und ArticleSavedPage angezeigt. Außerdem sind Platzhalter für Einstellungen und weitere Funktionalitäten implementiert.

SeachPage

Eine Layout mit einem Suchfeld und Auswahlfeld. Der Suchbegriff und die KWIC (Keywords in Context) Breite wird nach Bestätigung an den Suchserver übergeben und anschließend die Ergebnisseite „ArticleSearchResponsePage“ aufgerufen.

Searchjpage SearchjpageWP

SearchPage (Android & Windows Phone)

ArticleSearchResponsePage

Diese Seite wird nach dem Absetzen einer Suche aufgerufen und führt gefundene Artikel in einer Liste. Durch berühren eines Listeneintrags wird die Page „ArticlePage“ aufgerufen.

Suchergebnisse SuchergebnisseWP

ArticleSearchResponsePage (Android & Windows Phone)

ArticlePage

Die Page zeigt den kompletten Textinhalt eines Artikels aus dem Polytechnischen Journal. Die Inhalte sind scollbar und im oberen Bereich befindet sich ein Schalter der signalisiert ob der Artikel offline gespeichert ist. Sollte das nicht der Fall sein kann durch umlegen des Schalters der Artikel offline verfügbar gemacht werden. Der Schalter ermöglicht auch das Löschen eines offline gespeicherten Artikels. Des Weiteren ist ein Button zum Vorlesen des Artikels integriert. Die Funktion nutzt die Sprachsynthese der jeweiligen Plattform um den Artikeltext vorzulesen.

ArticlePage ArticlePagePW

ArticlePage (Android & Windows Phone)

ArticleSavedPage

Es wird eine Liste offline gespeicherten Artikeln angezeigt. Durch Auswahl eines Eintrags wird die „ArticlePage“ mit dem entsprechenden Artikel aufgerufen.

SavedArticlepage SavedArticlepageWP

ArticleSavedPage (Android & Windows Phone)

Fazit

Dieses Forschungsprojekt demonstriert, welche Möglichkeiten die Inhalte des Polytechnischen Journals in Kombination mit dem multiplattform Framework Xamarin bieten kann. Der hierbei erarbeiteten Prototyp kann auf Android ab 4.0, Windows Phone ab 8.1 und iOS ab 6.2 genutzt werden. Somit ist die Anwendung sehr flexibel und kann in unterschiedlichen Umgebungen genutzt werden. Zudem wird demonstriert, wie man mit vielen Datenquellen umgehen kann. Das entwickelte System ermöglicht eine zuverlässige Suche innerhalb des Polytechnischen Journals. Der Vergleich der Suchen des Open Search Warppers und von Apache Solr haben gezeigt, dass hier teils unterschiedliche Ergebnisse entstehen. Es ist möglich, Artikel nach dem lokalen Speichern ohne Internetverbindung zu lesen und diese auch wieder aus der Datenbank zu entfernen. Der Prototyp ist so designt, dass er einfach um weitere Funktionen erweitert werden kann.

 

iOS Simulator Screen Shot 19.10.2014 20.15.39 Screenshot_2014-10-19-19-54-31 wpsearch

SearchPage (iOS, Android, Windows Phone)

Ausblick

Die App bietet viele Möglichkeiten. Es sollten als nächstes die Abweichungen in den Suchergebnissen untersucht werden. Womöglich bietet Apache Solr bessere Ergebnisse als das aktuell eingesetzte Verfahren. Des Weiteres sollte die App um Funktionen wie das Anzeigen von Abbildungen innerhalb der Artikel erweitert werden. Durch die Integrierung von Navigationstechnologien wäre es möglich, Artikeln Exponate zuzuordnen. Sobald dieses Feature vorhanden ist, besteht die Option, die App um Museumstouren zu erweitern.

Es zeigt sich, dass hier nur ein Grundstein für ein großes Bauwerk gelegt ist. Die weiteren Bausteine hinzuzufügen ist jetzt Aufgabe nachfolgender Projekte.

 

PDF Download

DOKU semantisch-zusammenhaengende-informationen-und-wissensraeume-ueber-objekte-museen-und-ausstellungen