Architecture and Road Map, follow-up Potsdam

Hallo, ich poste hier mal ein E-Mail von Daniel Janz, das an ein paar ausgewählte Leute ging. Ist für Dokumentationszwecke und “openness” sicher sinnvoller, wenn wir die Diskussion hier weiterführen:

On 15/01/15 00:41, Daniel Janz wrote:

Servus zusammen,

da wir leider am Montag nicht mehr genügend Zeit hatten, um das Thema
ausgiebig zu besprechen, beschreibe ich hier einfach mal grob meinen
Vorschlag für eine Transformap Server-Software Architektur und wie
ich onYourWay darin eingebettet sehe.

Ich habe Oskar Hahn auf CC gesetzt, zu dem mir Helmut den Kontakt
vermittelt hat. Er hat Interesse am Backend von onYourWay und so weit
ich das verstanden habe generell im Backend mitzuarbeiten.

Hätte ich gewusst das ich so viel schreiben werde, hätte ich das
ganze gleich auf Discourse gepackt. Also seht es als Aufforderung die
Vorschläge zu Diskutieren und zu präzisieren. Das Ergebnis könnten
wir auf einer Wiki-Seite verewigen und dann dort weiterdiskutieren.

Architektur:

Da Transformap in einer Multi-Stakeholder Welt geboren wurde, ist es
unrealistisch anzunehmen das auf Dauer eine kleine Gruppe den Hut in
allen technischen Belangen aufbehalten kann. Transformap muss also
eine flexible Architektur bekommen deren Hauptaugenmerk auf der
Integration von Daten aus verschiedenen Quellen liegt. Transformap
ist nicht monolithisch so dass im Laufe der Zeit viele verschiedene
Datenbanken und auf diesen beruhende Services nebeneinander
existieren werden.

Dennoch soll Transformap natürlich eine Standadisierung für den
Zugriff auf das dahinterliegende System bieten. Das soll in erster
Linie durch die konsequente Anwendung von semantischen
Webtechnologien funktionieren. Die Daten sollen in offenen Formaten
(z.B.: GeoJSON, JSON-LD) an der API ausgegeben werden und die
einzelnen Services sollen unter einer Hypermedia-API
"zusammengefasst" werden.

Da das nicht von alleine passiert müssen alle Quellen erst
entsprechend aufbereitet werden. Hier liegt dann wahrscheinlich auch
der größte Aufwand begraben. Man braucht Adapter und Schema-Mappings
für jede Datenquelle um dann darüber die Daten in ein Datawarehouse
zu schaufeln.

Manche (vielleicht auch viele?) dieser Datenquellen werden
wahrscheinlich keine formale Definition haben auf der man aufbauen
könnte. Da würde dann die Optionen bleiben mit den Entwicklern
darüber zu sprechen (wohl meist auch nur wenn es keine komerziellen
Anbieter sind) oder reverse engineering zu betreiben. Screen scraping
ist auch eine Option die man bedenken sollte. Lizenzfragen sind in
diesem Zusammenhang garantiert auch nicht ohne.

Hier irgendwo kommt auch die Versionierung der Datensätze ins Spiel.
Sie ist eine Grundvoraussetzung für Datenintegrität in so einer
Umgebung. Wenn eine Quelle z.B. Echtzeitdaten liefert
(konituierlich/nicht kontinuierlich) und ein Ereignis z.B. auf einen
Datensatz aus dieser Quelle verweisen möchte, muss auf eine
spezifische Version verwiesen werden da es bereits wieder aktuellere
Datensätze geben wird.

Integriert werden sollen die so gewonnenen Daten dann durch eine
"gemeinsame" Ontologie. Jede Datenquelle bekommt eine Beschreibung
der Daten die sie liefert und eine Beschreibung wie sie anzusprechen
ist. Momentan denke ich dabei an RDFS, OWL, JSON- und XML-Schema. Für
den API-Part sollte man auf jeden Fall Hydra evaluieren. Für die die
WSDL kennen, es ist ein bisschen wie WSDL auf Steroiden und passt
wunderbar in die Linked Data Welt.

Da manche Daten mit anderen Datenquellen synchron gehalten werden
sollen, muss es auch einen “Rückkanal” geben. Wenn die
Datenintegration steht, sollte das ein wenig leichter fallen. Hier
ist wahrscheinlich die Latenz allerdings auch größer so dass es
eventuell auf diese Weise nicht möglich sein wird einen Echtzeit oder
nahezu Echtzeit Strom an Clients zu auszuliefern. Eventuell werden
hier je nach Anwendungsfall Speziallösungen notwendig werden.

Generell sollte das System eher auf Event-Verarbeitung ausgelegt
werden und Bulk- und Batch-Verarbeitung sind Spezialfälle davon.

Auch die geographische Verteilung der Systeme auf denen die Software
nacher betrieben wird sowie die Zuverlässigkeit der Anbindung sollte
im Kopf behalten werden. Eigentlich sollte das System am besten keine
zentralen Abhängigkeiten haben und viel Redundanz ermöglichen (was
für den ersten Wurf allerdings ein wenig unrealistisch erscheint?).

Aus funktionalen und rechtlichen Gründen muss es eine Verwaltung für
Identitäten geben. Dieser Aspekt ist für mich besonders interessant
da ich mehr oder weniger keine Ahnung habe wie man mit Daten, die
echte oder pseudonyme Identitäten aus unbekannten Quellen
referenzieren anständig umgeht. Es stellen sich Fragen der
Datenintegrität und Qualität da man den Urheber der Daten sicherlich
in den meisten Fällen gar nicht eindeutig identifizieren kann und
dies auch nicht gewollt ist, andererseits muss man sich dennoch darum
bemühen die Daten den richtigen Urhebern (ob pseudonym oder nicht)
zuzuordnen. Es gibt im einfachsten Fall dann auch noch den
rechtlichen Aspekt der Namensnennung wie er in eigentlich allen
freien Lizenzen vorgesehen ist und sicherlich auch Regelungen wie mit
erhobenen Daten umzugehen ist.

So grob in den Raum geworfen würde ich dafür plädieren elf Pavlik’s
Ansatz der Personal Linked Profiles aufzugreifen und für jede
Identität auf dem Server ein solches Anzulegen. Da das Profil selbst
in JSON-LD gespeichert ist, lassen sich auch komplexe
Zugriffsbeschränkungen auf Server-Seite oder kryptographische
Verfahren für öffentliche Datenspeicher realisieren. Ich persönlich
würde einen kryptograohischen Ansatz und öffentliche Datenspeicher
bevorzugen wobei mir noch nicht richtig klar ist was für einen
Aufwand z.B. für die Schlüsselverewaltung und-verteilung das
wahrscheinlich bereits bedeutet wenn man nur einfach szenarien
umsetzen möchte.

Die Autorisierung sollten wir wahrscheinlich erstmal mit OAuth machen
wobei ich WebID sicherlich gerne mal ausprobieren würde. Wenn wir die
Quellen und Nutzerinformationen bei der Datenintegration richtig
zusammenhalten, dann sollten Nutzer ihr Profil später per OAuth
übernehmen können wenn die Quelle selbst ein OAuth-Provider ist?!

Der Frontend-Part felht in dieser Betrachtung noch. Es ist auch noch
nicht so ganz klar was so alles an UI-Wünschen auf uns zu kommen
werden. Sicher ist jedoch schonmal die Eingabemaske und eine
Kartendarstellung mit “diversen Filtermöglichkeiten” :slight_smile:

onYourWay und MindForest:

Da das oben beschriebene System noch ein ganzes Stück in der Ferne
liegt brauchen wir momentan Lösungen mit denen die ersten Erfahrungen
gesammelt werden können. onYourWay ist dabei meines Erachtens in
erster Linie als Benutzerschnittstelle konzipiert und kann zum
Suchen, Betrachten und Bearbeiten von einzelnen Datensätzen verwendet
werden.

Wie ja bereits vorgesehen wollen wir es zur manuellen Eingabe von
POIs verwenden. Momentan angedacht ist ein Speichern der
eingetragenen Daten, so weit passend, in OSM. Alle weiteren Daten die
nicht zur OSM passen würden in der onYourWay Datenbank gespeichert
werden.

Das Backend würde in diesem Fall aus einer Datenbank für alle
OSM-Fremden Daten und der Vollständigkeit halber natürlich auch aller
Daten die in OSM eingetragen wurden plus einem Read/Write-Adapter für
OSM bestehen. Voraussetzung für die Datenbank wäre also das sie
Geodaten unterstützt. Hier gibt es sicherlich ein paar Kandidaten wie
PostGIS, GeoCouch, Oracle, Sql-Server,… Ich denke das hier alle eine
OpenSource DB bevorzugen würden und meine erste Idee dazu war
aufgrund der Nähe zur jetzigen Datenbank Postgres zu wählen. Sollte
die Entscheidung jedoch für einen kopmlett neuen API Server
ausfallen, ist das ja auch alles nicht in Stein gemeißelt und man
kann theoretisch alles benutzen was den Anforderungen des
onYourWay-Frontends entspricht.

Bislang bin ich bei meinem Versuch der Portierung mangels Zeit noch
nicht über das Installieren eines PostGIS hinausgekommen :slight_smile:

Wir auch schauen wie weit die Integration gehen kann, da die
Zeitpläne der beiden Projekte wahrscheinlich zu unterschiedlich sein
werden und onYourWay sicherlich nicht auf viele Features des
Transformap-Systems warten kann oder möchte. Da sollte man mal
versuchen herauszufinden was die Projekte gemeinsam haben und was
verschieden ist.

Zusammen mit der OSM-Integration und der Transformap-Taxonomie (hier
ganz schön als Baum: http://metamaps.cc/maps/1165) sowie MindForest
zum Bearbeiten, würde das auch schon die erste Softwarekomponente der
der Transformap Architektur darstellen. Mit der Integration weiterer
Datenquellen werden wir dann aber früher oder später ein flexibleres
Werkzeug als die Taxonomie zum Mapping der Daten benötigen. Irgendwie
müssen wir es dabei schaffen, dass die dadurch steigende Komplexität
für die “Badgers” und die “Monkeys” noch handhabbar bleibt :slight_smile:

So weit ich Michael Maier verstanden hatte, muss es für die OSM
Integration (write) die Möglichkeit geben eine Overpass-query für den
zu editierenden Bereich zu erzeugen, die dann alle bereits in OSM
vorhandenen Objekte, auf die eine definierte Mindestmenge an Tags
zutreffen, ausgibt. Da dies, wie ich vermute, nicht die einzige
Overpass-Query bleiben wird, sollten wir uns ein geeignetes Maß an
Abstraktion für diese Stelle überlegen damit wir den Code und die
Queries wiederverwenden können (Was gibts da bereits?). Auch die
schreibende OSM-Komponente (was gibts da bereits?) sollten wir mit
Blick auf wiederverwendung Designen.

Comments?

1 Like

I moved 2 posts to an existing topic: Docu Potsdam 2015-1 meeting + Photos

Please also take the road map drafts from the Linked Data thread into account.

There is also a translation draft of the German architecture text above.

1 Like

Great to have this as a wiki. Would be awesome to have it in English to ensure it’s being useful for non-german speaking and also for faciliting its reuse in applications (eg. CHEST). :wink:
Then we should make this tech roadmap easy to find on the website.

English translation below:

On 01/15/15 00:41, Daniel Janz wrote:

Hello together,

because unfortunately, we did not have enough time on Monday to discuss the topic extensively, I am simply describing here my proposal for a Transformap server software architecture and how I see onYourWay embedded therein.

I set Oskar Hahn in CC. Helmut has made the contact. He is interest in the backend of onYourWay and as far as I understand wants to collaborate there.

Had I known that I would write so much, I would have all the same packed on Discourse. So it can see as an invitation to discuss the proposals and to refine. We could perpetuate on a wiki page and then discuss the result there.

Architecture:

Since Transformap was born in a multi-stakeholder world, it is unrealistic, that in the long run, a small group can keep going in all technical matters. Transformap must therefore get a flexible architecture which focuses on the integration of data from different sources. Transformap is not monolithic so that over time many different databases and services based on these exist side by side.

Nevertheless Transformap should naturally offer a standard to access the underlying system. That should work primarily through the consistent use of semantic web technologies. The data shall be delivered in open formats (eg: GeoJSON, JSON-LD) as output of the API and the individual services to be “summed up” under a “Hypermedia API”.

Since this does not happen by itself all sources have to be processed accordingly. There probably lies the biggest expense. You need adapters and schema mappings for each data source for shoveling the data into a data warehouse.

Some (perhaps many?) Of these data sources are likely to have no formal definition on which one could build. Then the options would remain to talk with the developers about it (probably only if they are no comercial providers) or to reverse engineer. Screen scraping is also an option that should be considered. License questions in this context are also for sure relevant.

Here also the versioning of records somewhere comes into play. It is a basic requirement for data integrity in such an environment. If a source provides (continuous / non-continuous) e.g. real-time data and an event e.g. draws attention to a record from this source, it must reference to a specific version because there are already more current records.

The data thus obtained should then be integrated, by a shared ontology. Each data source receives a description of the data it supplies, and a description of how it is to be addressed. At the moment I am thinking of RDFS, OWL, JSON and XML-Schema. For the part of the API, Hydra should definitely be evaluated. For those that know WSDL, it’s a bit of WSDL on steroids and fits wonderfully in the Linked Data world.

Since some data are to be kept in sync with other data sources, there must also be a ‘return channel’. If the data integration is set up, that should be a little easier. Probably the latency is larger, so it may not be possible to deliver real-time or near real time streams to clients. Special solutions may be necessary depending on the application.

In general, the system should be designed with more emphasis on event processing where bulk and batch processing are special cases of it.

The geographical distribution of the systems on which the software will be operated as well as the reliability of the connection should be kept in mind. Actually, the system should ideally have no central dependencies and enable much redundancy (which seems a little unrealistic for the first iteration?).

For functional and legal reasons there must be a management for identities. This aspect is particularly interesting for me, because I have more or less no idea how to properly deal with data that refer to real or pseudonymous identities from unknown sources. Questions of data integrity and quality arise, as the originators of the data certainly can not be clearly identified in most cases, as well as this is not wanted. On the other hand one must nevertheless still assign the data to the right owners (whether with a pseudonym or not). There is, in the simplest case, then also the legal aspect of attribution as in virtually all free licenses is provided and certainly regulations on how to deal with data collected.

So roughly sketched out, I would plead to pick up elf Pavlik’s approach of Personal Linked Profiles and apply one for each identity on the server. Since the profile itself is stored in JSON-LD, even complex access restrictions on server side or cryptographic procedures for public data storages can be implemented. Personally, I would prefer a cryptographic approach and public data storage, being not fully clear what kind of effort, e.g. access-management and -distribution already involves if you want to implement simple scenarios.

We should do the authorization probably first with OAuth, whereby I would certainly like to try WebID. If we stick the resources and user information in the data integration together correctly, users should be able to take their profile via OAuth later when the source is an OAuth provider itself?!

The frontend Part is yet missing in this consideration. It is also not entirely clear which wishes to the UI might come up. Already certain is an input mask and a map display with “various filter options” :slight_smile:

onYourWay and Mindforest:

Since the system described above is still quite a bit in the distance we currently need solutions to allow the first experience to be made. in my opinion onYourWay is primarily designed as a user interface and can be used for searching, viewing and editing of individual data records.

As already provided we want to use it for manual entry of POIs. Currently the idea is to store the entered data as far as suitable in OSM. All other data that do not fit the OSM would be stored in the database onYourWay.

The backend would be in this case, a database for all non OSM native data (that does not fit OSM-criteria), and for completeness of course all data which had been entered in OSM, plus a Read / Write adapter for OSM. Prerequisite for the database therefore is, it supports geodata. There are certainly a few candidates as PostGIS, GeoCouch, Oracle, SQL Server, … I think that we all would prefer an open source DB and my first idea was to choose Postgres because of its proximity to the current database. Should the decision, however, turn out for a completely new API server, nothing is set in stone and you can theoretically use everything that meets the requirements of the onYourWay frontend.

So far, for lack of time, I did not get any further in my attempt of porting, than installing a PostGIS :slight_smile:

We also look how far integration can go, because the schedules of the two projects are likely to be too different and onYourWay certainly can not and does not want to wait for many of the features for the Transformap system. We should try to find out what timing the projects have in common and what is different.

Along with the OSM integration and the Transformap taxonomy (here quite nice as a tree: http://metamaps.cc/maps/1165) as well as Mindforest for editing, that would already represent the first software component of the Transformap architecture. With the integration of other data sources sooner or later we will need a more flexible tool than the taxonomy for mapping the data. Somehow we have to succed to handle the resulting increase in complexity for “Badgers” and “Monkeys” and it remains manageable :slight_smile:

As far as I understood Michael Maier, for the OMS integration (write) an Overpass-query can be generated for the area to edit, which fetches all in OSM existing objects, that meet a defined minimum number and criteria of tags.

I suppose, this will not be the only Overpass-query, we should think about a suitable degree of abstraction for that part, to reuse the code and queries (what is already available in this area?). We should also design the writing OSM-component (What is available in that area?) with a view to make it reusable.

Comments?

1 Like

What’s the best summary description of the technology architecture for Transformap currently?
@almereyda @species

1 Like

Thanks @pmackay for your question. Guys who have overview on technical architecture, can you provide the right links/explanation also including where there are some dissent? @species @almereyda

Hello @pmackay probably the minutes from our meeting last week might be the best shot: 2015-12-03 unsceduled Monkey mumble-meeting

needs elaboration. Have a read and ask any question you like : )