Forschungsdatenmanagement mit Open-Source-Software
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Untertitel |
| |
| Serientitel | ||
| Anzahl der Teile | 47 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/15868 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
2
4
7
9
11
14
16
17
21
25
27
28
29
31
34
35
36
44
45
47
00:00
Open SourceDatenmanagementVorlesung/Konferenz
00:39
DatenmanagementComputeranimation
01:05
Uniformer RaumComputeranimation
02:09
DatenbankDatenbankDatenmanagementInformationsmodellierungComputeranimation
03:18
DatenmanagementRDF <Informatik>Apple KeynoteWeb ServicesDatenformatDatenmanagementZugbeanspruchungInterface <Schaltung>MomentenproblemComputeranimation
05:35
DatenmanagementAbbildung <Physik>DateisystemRechenzentrumDatenmanagementErzeugendeDatenbankComputeranimationFlussdiagramm
07:13
DatenbankWEBRDF <Informatik>PDF <Dateiformat>Abbildung <Physik>DatensatzRollbewegungOntologie <Wissensverarbeitung>Textur-MappingDatenstrukturComputeranimation
08:53
DatenintegrationDatensatzTextur-MappingGeodätische LinieMathematische ModellierungWeb-SeiteAnwendungssoftwareInterface <Schaltung>LiteraturdatenbankDateiformatDatenbankDownloadingApp <Programm>DateisystemInformationsmodellierungDatenbanksystemSwitch <Kommunikationstechnik>ZahlenbereichRohdatenVideodatRelationale DatenbankTabelleMetadatenComputeranimationFlussdiagramm
13:07
EURONET-DIANEAbbildung <Physik>Open SourceComputeranimation
13:30
ServerMAPProxy ServerDienst <Informatik>DatenbankGeodätische LinieGeometrieChipkarteNoten <Programm>QuellcodeProxy ServerAbbildung <Physik>CMSGEOLOGComputeranimation
14:45
Data DictionaryInternetWeb-ApplikationUploadingWeb-AnwendungMomentenproblem
16:23
WEBDatensatzInternetVerschlingungSchreiben <Datenverarbeitung>MetadatenLinked DataInformationsmodellierungComputeranimation
18:53
Graphic WorkshopSchwingungSPARQLEXCELPrototypingFilter <Informatik>DatensatzAudiovisualisierungDatenformatMomentenproblemComputeranimation
20:11
DatenbankComputeranimation
21:00
Open SourceSCI <Informatik>DatenbankSkriptspracheDatensatzFunktionalitätMetadatenSicherungskopieGooglePolygonNormalvektorRelationale DatenbankTabelleRechenzentrumSoftwareRohdatenDienst <Informatik>Geodätische LinieGeometrieWeb ServicesInferenz <Künstliche Intelligenz>MediaWikiAbfrageMomentenproblemSchreiben <Datenverarbeitung>DownloadingRDF <Informatik>DateiTypoScriptMySQLPostgreSQLContent <Internet>PHPDatenintegrationElementargeometrieSemantic WebVorlesung/Konferenz
Transkript: Deutsch(automatisch erzeugt)
00:00
Vielen Dank. Ja, schönen guten Tag zusammen. Ich berichte in diesem Vortrag von einem Forschungsprojekt und der Implementation des Datenmanagements für dieses Forschungsprojekt, dass meine Haupttätigkeit
00:23
im Rahmen meines Doktorandestudiums in diesem Forschungsprojekt ist. Und zunächst werde ich eine kurze Einführung geben. Dann das Datenmanagement, wie es von der Deutschen Forschungsgemeinschaft, durch das das Forschungsprojekt finanziert wird, gefordert
00:41
ist. Erläutern. Dann werde ich erläutern, wie wir das implementieren. Dann den zweiten Aspekt, die Forschungsdatenbank und die Implementation der Forschungsdatenbank erläutern und erste Ergebnisse und ein Fazit vorstellen. Also ganz kurz einführen zu dem
01:04
Forschungsprojekt. Es ist ein Sonderforschungsbereich der Deutschen Forschungsgemeinschaft. In diesem Sonderforschungsbereich sind über 100 Wissenschaftler beteiligt, von drei Universitäten, der Uni Köln, der Uni Bonn und der Universität Aachen. Und es ist ein interdisziplinäres Forschungsprojekt
01:27
aus der Archäologie, den Geowissenschaften und den Kulturwissenschaften. Das Forschungsprojekt behandelt die Fragestellung nach der Ausbreitung des modernen Menschen nach Mitteleuropa,
01:45
also wie der anatomisch moderne Mensch, wo man in diesem Forschungsprojekt von der Fragestellung her ausgeht, im heutigen Äthiopien sich entwickelt hat und wie er von dort nach
02:00
Mitteleuropa sich ausgebreitet hat. Genau, in diesem Forschungsprojekt wird eine Forschungsdatenbank entwickelt durch meine Person bzw. durch unsere Arbeitsgruppe. Die auch Teil dieses Forschungsprojekts ist und diese Forschungsdatenbank soll zwei Hauptaspekte
02:24
erfüllen. Zum einen soll sie als Publikationsplattform und Datenarchiv für die in dem Forschungsprojekt entstandenen Daten, für die im Forschungsprojekt entstandenen Daten dienen.
02:43
Zum zweiten soll sie eine integrierte Datenbasis, die den Forschern Daten zur Verfügung stellt, um ihre Forschung mindestens zu unterstützen, bereitstellen. In dieser Datenbank geht es
03:14
um den Datenmanagement. Die DFG, die Deutsche Forschungsgemeinschaft, fordert von jedem
03:21
Sonderforschungsbereich ein Datenmanagement, wo sichergestellt werden muss, dass alle Daten, die in seinem Forschungsprojekt erzeugt werden, auch sicher archiviert werden und zusätzlich. Also das ist der reine sozusagen formelle Teil meiner Arbeit, diese Punkte zu
03:46
implementieren. Der Hauptaugenmerk dieser Implementation ist, dass die Daten halt lange vorhaltbar sein müssen und für bis zu 22 Jahre abrufbar sein müssen. Das resultiert
04:02
daraus, dass ein Sonderforschungsbereich immer in vierjährigen Phasen genehmigt wird bzw. beantragt wird und ein Sonderforschungsbereich maximal drei Phasen durchlaufen kann, was sich zu zwölf Jahren ergibt und zusätzlich müssen die
04:21
Daten mindestens zehn Jahre nach Ablauf des Forschungsprojektes zugreifbar sein, was dann eine Mindestlaufzeit von 22 Jahren ergeben kann. Im Falle, dass das Forschungsprojekt halt drei Phasen durchlauft. Im Moment sind wir in der ersten Phase, im dritten Jahr in der ersten Phase, also fast dritten Jahr in der ersten Phase. Als
04:46
Konsequenz daraus haben wir uns natürlich dafür entschieden, das ist in keiner Weise vorgeschrieben von der DFG übrigens, dass wir ausschließlich halt standardisierte Datenformate und Schnittstellen verwenden zum Zugriff, die gut dokumentiert sind und somit
05:04
auf profitäre Datenformate, wo es geht, verzichten. Und wir haben uns jetzt entschieden halt für OGC, Open Web Services und RDF, Resource Description Framework, der die Keynote vom
05:21
Anub Kristl heute Mittag gehört hat, der hat davon auch schon geredet und meinte, das wäre die Zukunft. Das sehe ich natürlich auch so, deswegen haben wir das als Datenformat gewählt. Das Datenmanagement habe ich mal eine kleine Abbildung zugebaut. Also wir haben
05:42
Webfrontend, gibt es hier einen Pointer oder so? Also eine Webseite, da kann man die und die werden einmal in einem Backend auf dem Server, ganz normal im Dateisystem, das ist hier das Andrew-Filesystem, technisches Detail, wie es im Rechenzentrum in einem verteilten
06:05
Dateisystem abgespeichert wird. Und zusätzlich werden die Daten halt auch in RDF modelliert. Das ist ungefähr das, was man im bisherigen Implementationsansatz als Metadatenmanagement bezeichnen würde, dass man das dann in einem ISO 1.9.115 Fachschale speichert. Wir
06:27
speichern das einfach in RDF ab und haben damit auch unsere Daten beschrieben und sogar noch semantisch referenziert, kann man so sagen. Und das Frontend holt sich dann die
06:47
Webextension, die erlaubt, Frontends zu bauen, die im Backend Spark-Rule-Queries erzeugen. Also nicht wie das bisher so ist, mit normalen SQL-Queries auf einer Datenbank, sondern Spark-Rule-Queries
07:04
auf einem RDF-Store, um die Daten zuzugreifen. Die Forschungsdatenbank, da sieht das ein bisschen anders aus. Hier integriere ich halt Daten aus diesen verschiedenen Datendomains, Archäologie, Paleoumwelt und Geoarchäologie. Und dazu modelliere ich erstmal im Rahmen
07:39
diese werden in meinem Fall in AOL, also Ontology Web Language, implementiert und
07:54
die dienen dazu halt, um solche Datenstrukturen für RDF formell zu definieren. Die Datenintegration,
08:05
die ist nicht automatisiert oder so, also das ist in keinem Fall Rocket Science von der Seite her, weil ich schreibe für jeden neuen Datensatz, der integriert wird, ein kleines Python-Skript, wo ich zum Beispiel wenn ein Datensatz eine Excel-Datei, was sehr
08:23
oft der Fall ist, dann wird erstmal die Excel-Datei eingeladen und es wird ein Mapping in Python-Code formuliert auf RDF-Abbildung. Also da habe ich dann meine URIs definiert in meinem AOL, in meinen Ontology Web Language Notation, habe ich die Beziehung
08:44
definiert und mappe dann die Daten nach RDF und speichere sie in meinen RDF-Store. Dieses vom Ablauf her sieht das halt so aus, habe ich hier schematisiert dargestellt, ich habe hier eine neue Datenquelle, also wie gesagt, häufigst der Fall sind Excel-Tabellen,
09:08
können aber auch alles mögliche sein, Geodaten auch, Shapefiles etc., XML-Daten, alles Mögliche, Datenbanken, Relationale Datenbanken, da formuliere ich dann halt
09:24
und baue halt diesen Custom-Reader und mache dann für die Daten ein Mapping und wenn in diesem Datensatz jetzt neue Semantiken vorkommen, also irgendwelche Begriffe, die vorher noch nicht abgedeckt waren, dann update ich halt hier mein Domain-Model und füge diesen
09:44
Domain-Model ganz einfach, dynamisch diesen neuen Begriff zu, das ist nämlich der Vorteil an Semantik Web-Technologien und RDF, es ist schemafrei, ich kann jederzeit das Schema ändern und es beeinflusst nicht das Applikationslevel, also alle anderen
10:01
Applikationen, die können halt weiter damit arbeiten, weil die Daten, wie sie bisher darin sind, sind halt nicht angefasst, es ist nur erweitert worden und diese zusätzlichen Daten können dann in weiteren Applikationen zusätzlich verwendet werden oder halt auch
10:20
nicht, also der Riesenvorteil ist halt, dass ich direkt integriert habe und abfragbar vorhanden habe, ohne irgendetwas anderes zu beeinflussen, was schon implementiert ist Hier ist nochmal eine andere Sicht auf die Implementation dieser Datenbank, also wir
10:48
haben hier einmal die Eingabeseite, die Datenquellen, also sie können entweder direkt über das Frontend sein, oft von der Webseite oder halt Datensätze, die an mich herangetragen werden, die ich dann so ein Pysonscript schreibe, diese Daten werden halt in diese
11:06
Modellierungen modelliert, aber auch weitere, wie zum Beispiel für Literaturdaten, wir haben auch eine Literaturdatenbank für die Forscher zum Durchsuchen in RDF modelliert, also wo einfach halt Aufsätze im Bibtex-Format aus dem Bibtex-Vokabular, in unserem Fall
11:22
vom MIT Simulib-Projekt modelliert werden. Es können auch bisherige Metadatenfachschalen auch gemapped werden in verschiedene RDF-Darstellungen, kann man 1 zu 1 Mappings machen
11:43
und gespeichert werden die ganzen Daten im RDF-Store und zusätzlich speichere ich halt auch die ganzen Quelldaten und zum Teil auch für Datei-Downloads, für die
12:03
Geodaten, zum Beispiel Shapefiles und Geotips einfach im Dateiformat, im Dateisystem, die werden dann auch verlinkt über RDF, die Download-Ressourcen, vor allem halt für Archäologen und Geowissenschaftlern im Forschungsprojekt, die halt jetzt, dem
12:25
man jetzt nicht zumuten kann, mit Sparkool, Geo Sparkool in seinen Anwendungen zu arbeiten, dass die dann halt ihren Shapefile haben können, um damit zu arbeiten oder halt ihr Geotiff. Ja und dann haben wir halt diese Schnittstellen, wie gesagt OGC-Services
12:44
auch noch für, also wo wir dann auch nochmal die Rastadaten und die Geodaten über WMS, WFS, WCS anbieten, den Sparkool Endpoint und dann entwickeln wir auch noch weitere Schnittstellen webbasiert, wie zum Beispiel so ein Geo-Ex-basiertes Webgiz, was ich vielleicht noch kurz zeigen
13:06
wollte. Das sind jetzt nur ein paar Zahlen, die schon jetzt integrierten Daten, also ungefähr über 20.000 oder um die 20.000 archäologische Artefakte, circa 10.000 Paleo-Modelle sind
13:24
drin. Geoarchäologische Daten habe ich hier jetzt noch nicht aufgelistet, das sind bisher knapp 20.000. Dann haben wir hier ja eine Abbildung mit den Open Source Softwareprojekten, die wir eingesetzt haben, also das Webfrontend ist ein typo 3 basiertes, also basiert auf dem typo 3 CMS.
13:46
Für WMS-Dienste benutzen wir den Map-Server vor allem. Die Geodaten werden als Backend für den Map-Server, also die Feature-Geodaten in der Postges-Datenbank gespeichert. Für Degree
14:02
probieren wir gerade mit dem Catalog-Service, den wollen wir nämlich auch noch einsetzen, damit wir eine CSW-Note haben für die Daten. Wir cashen ein paar der Dienste, ein paar WMS-Dienste mit dem Map-Proxy, ein paar externe Dienste, auch wie zum
14:20
Beispiel geologische Karten, die wir zum Beispiel vom BGR cashen, um die bei uns in das WebGIS einzubinden. Dann benutzen wir den Season Store von OpenRDF für den RDF-Store und GeoX OpenLayers für das WebGIS. Dann wollte ich hier mal den aktuellen
14:47
Entwicklungsstand von der Web-Anwendung zeigen, das jetzt hier im Internet ist, weil das hier ist, muss das geladen werden. Das ist hier ein ganz einfacher Datenkatalog,
15:03
hier kann gesucht werden, hier kann gefiltert werden nach verschiedenen Uploadern. Im Moment ist das nur das Z-Projekt, ich meine, wenigstens ein Z-Projekt, sieht man hier, ist mein Name, ich hab das hochgeladen. Das sind im Moment auch noch nicht wirklich die richtigen Beschreibungen, wie das im Endeffekt sein soll. Hier kann man dann jetzt zum
15:22
Beispiel so ein Vompalio Model Intercomparison Project 2, LGM 21k für heute, Ocean Atmosphere Vegetation Model runterladen. Also, hab ich auch schon reingeladen. Jetzt laden ich das gerade runter, 2,6 MW. Kann man hier filtern, also ganz einfaches User-Interface,
15:47
kriegt jeder nicht zu IT-affine User bedient, also für die ganz einfachen Daten. Dann haben wir noch ein WebGIS-Interface, das lädt jetzt leider etwas länger, das hab ich noch überhaupt
16:03
nicht optimiert, das ist noch keine Minify JavaScript, das ist alles noch halt in Regimentationsphase, deswegen, das dauert jetzt wahrscheinlich zu lang. Das sind auch einige Megabyte, die er dann lädt. Dann können wir schon zum Fazit. Also, die Vorteile durch
16:31
den Einsatz von RDF, also Semantic Web Technology, sind halt, jetzt kurz aus meiner Sicht, also semantisch sind die Daten klar und eindeutig modelliert. Also, man entwickelt halt seine eigenen
16:45
Tupes und kann die dann durch sogenannte Linked Data Methoden mit schon definierten Modellen referenzieren, verbinden und hat somit semantisch definiert. Dadurch werden
17:03
die halt auch interoperal. Man kann zum Beispiel ein ISO 19115 in RDF modellieren und kann dann durch diesen Linking alle Daten, die in diese Beschreibung passen, dadurch halt auch abfragen.
17:21
Wie gesagt, also das erspart mir den mühsamen Einsatz zum Metadatenverbrauchen. Ich muss jetzt nicht meine Daten in dieser Fachschale mühsam, in Anführungszeichen, modellieren und alle Daten eingeben. Ich kann halt nur das, was ich gerade habe, in RDF modellieren und später dann diese URIs nach ISO-Mappen. Und dadurch sind alle Daten, die ich so eingegeben habe,
17:47
automatisch referenziert. Genau, das was ich gerade gesagt habe. Und die Integration in externe Projekte, die dann halt auch Semantik Webtechnologie einsetzen, ist um einiges einfacher
18:04
dadurch. Und kann ohne große zusätzliche Metadatenbeschreibungen, wie wenn man es jetzt, wenn ich jetzt zum Beispiel von irgendeinem Archäologen seine Excel-Datei bekomme, wo dann kurze Sachen, kurze Abkürzungen über jeder Spalte stehen, muss ich dann erst mal
18:28
das hier ordentlich modellieren kann. In RDF hat man halt direkt seinen Link auf diese Resource, womit das referenziert ist. Man kann es dann da im Internet nachlesen, was es ist. Und es ist halt direkt klar und man kann es direkt wiederverwenden. Und zwar genauso,
18:44
wie es gemeint ist von demjenigen, der den Datensatz erstellt hat. Vorausgesetzt, er hat es so modelliert, wie er es gemeint hat. Wie gerade schon angedeutet, den Wissenschaftlern selber, also den Archäologen und Geowissenschaftlern, werden die Daten über
19:05
möglichst einfache Interfaces dargestellt, die da im Moment sind halt ein Webgist. Dann möchte ich ein Exhibit, das sind Timeline-Visualisierungen direkt auf RDF-Daten setzen. Da kann ich dann,
19:24
ist ja innerent, raumzeitlich dieses Forschungsprojekt, halt zeitlich einen Filter auf die Daten anwenden. Ich habe auch schon Prototypen entwickelt, wo ich zeitliche Filter in einem Webgist-Frontend drin habe. Den werde ich dann auch noch da reinbringen,
19:43
in absehbarer Zukunft. Ja, dann halt über die OGC-Webservices, Sparkle Endpoint für die User, die es nutzen können. Teilweise werden die Daten halt auch in populären Datenformaten wie Shapefiles und Excel-Tabellen dargestellt, weil es halt doch das ist, womit die Wissenschaftler
20:04
arbeiten wollen und nicht mit RDF-Serialisierungen. Ja, vielen Dank für die Aufmerksamkeit.
20:39
Die Symantec-Web-Typo-3-Extension, die formuliert, man kann den RDF-Store dann halt als Backend
20:50
verwenden, wie man jetzt normalerweise eine MySQL-Datenbank anwenden würde. Man kann sich dann über ein Backend-Formular Queries zusammenbasteln. Man gibt eine Sparkle-Query
21:06
ein in ein Backend-Formular und kann sich daraus ein Frontend zusammenbasteln. Und diese Webgist-Funktionalität, ist die Bestandteil auch einer Typo-3-Extension oder wurde die
21:22
mit OpenLayers doch mal da integriert? Ne, das haben wir hier ganz einfach in GeoExt entwickelt und dann über Typoscript die JavaScript-Bibliotheken eingebunden. Also es ist keine eigene Extension. Also man muss ein Typoscript dann externe Skripte
21:45
definieren. Also gerendert wird das dann hier so. Das sind dann hier die Dateien für das Webgist, dass sie halt eingebunden werden in den Datei. Ok, danke. Ja. Habe
22:14
ich jetzt akustisch nicht verstanden nochmal. Das Software-Projekt, das ist das CSYM-RDF-Store
22:25
von, die Seite heißt OpenRDF.org. Das wurde mir jetzt gesagt, ich war letzte Woche in Münster auf einer anderen, kleineren Tagung. Da wurde mir gesagt, da werde ich
22:43
sehr wahrscheinlich Probleme kriegen, wenn es jetzt ein bisschen größere Datensätze sind, weil der wohl sehr unperformant wäre. Da sollte ich mal nach Jena gucken. Das werde ich jetzt demnächst mal tun. Habe ich bisher noch keine Zeit. Oder in einer herkömmlichen relationalen Datenbank wie Postgre oder MySQL Backend speichern und dann
23:04
nur nach, halt durch Zwischensoftware, PHP zum Beispiel, Triplify heißt das, auf der Datenmarkthaltern arbeiten. Also wenn einfach diese Triples, das sind ja immer nur Subjekt,
23:21
Prädikatobjekt, also immer nur drei Werte in einer Tabelle pro Zeile in einer normalen relationalen Datenbank. Da wird zwar halt die relationale Möglichkeit nicht genutzt, aber es ist trotzdem performanter, also anscheinend. Hast du Erfahrungen mit Semantic Media Wiki? Hast du sowas integriert? Wie funktioniert das? Also ich weiß,
23:43
was es ist. Ich habe es mir auch schon mal angesehen, aber jetzt wirklich viel damit gearbeitet habe ich noch nicht. Also ich weiß halt, dass man da seinen Content mit, auch mit RDFS beschreiben kann, Markup eingeben kann. Bezieht sich diese Semantik Web jetzt
24:22
nur auf die Metadaten oder kann man damit auch geografische Semantik definieren oder abfragen machen oder aus der Schlussfolgerung wirklich innerhalb der geografischen Daten ziehen? Also die eigentlichen Geometrien modelliere ich jetzt bis auf einfache Punktdaten noch nicht in RDF. Also ich modelle jetzt keine Polygone in RDF. Es gibt aber Forschungsprojekte
24:46
dazu und es wird auch schon entwickelt, auch zum Teil bei Google. Es nennt sich Geo Sparkle und da wird daran entwickelt, dass es dafür Technologien gibt, auch richtig Geodaten in RDF zu nutzen, aber soweit ist es halt im Moment noch nicht, um das wirklich produktiv
25:04
einzusetzen. Aber also ich habe das so, dass ich die Metadaten wie eine Baunehmbox zum Beispiel zu meinen räumlichen Datensätzen in RDF modelliere und dann halt den Download zu dem eigentlichen Geodatensatz dann halt angebe und dann kann man sich diesen herkömmlichen
25:26
Geodatensatz halt nach diesen Beschreibungen unterlagen. Die Rohdaten werden immer vorgehalten
25:51
in diesem doppelt und dreifach abgesicherten Andrew-File-System, das vom Rechenzentrum garantiert betrieben wird mit zu, ja, mit also Doppel-Rate und allen möglichen Absicherungen.
26:06
Also das ist wirklich extrem sicher. Das läuft seit zig Jahren schon, kann man sagen, also weit über zehn Jahren ohne Datenverlust und da liegen die Eingangsdatensätze
26:20
und ich tue das ja nur zur Datenintegration und so, dass man halt zum Beispiel so Abfragen machen kann, wie gib mir alle Datensätze aus der Datenbank aus Südspanien zum Zeitraum des Last-Glacian-Maximums. Kann man dann anfangs eine Endzeit angeben und kommt dann aus der Datenbank die Datensätze und im Endeffekt lädt man sich dann,
26:44
zumindest wie es im Moment noch implementiert ist, dann das Shapefile oder den Geotiff oder die OWS-URL bekommt man dann geliefert.