Interoperabilität raumbezogener Daten mit CIDOC CRM

Transkript

1 Wolfgang Schmidle (DAI Berlin), Dominik Lukas (Topoi) Interoperabilität raumbezogener Daten mit CIDOC CRM Beispiele in Topoi und am DAI THE FORMATION AND TRANSFORMATION OF SPACE AND KNOWLEDGE IN ANCIENT CIVILIZATIONS

2 1. Forschungsdaten am Exzellenzcluster 264 Topoi 2. Vorbereitung der Daten für FDZ-IANUS 1. Evaluierung möglicher Datenmengen 2. Testbed: C-III Acts (Bronzezeitliche Hortfunde) 3. Geodatenressource (topoigdr) 1. Minimaldatenset 2. Kombination heterogener Datenmengen 4. idai.gazetteer 5. Modellierung mit CIDOC CRM 1. Geodaten-Ressource 2. idai.gazetteer 3. Was ist der Mehrwert? 4. Ausblick: DAI-Gesamtstrategie

3 Topoi: Ancient Understanding of Space and Knowledge Topoi is a research network with a focus on the study of the ancient world. In Topoi, more than 200 researchers from diverse disciplines investigate how space and knowledge were formed and transformed in ancient civilizations.

4 Topoi: Research Groups Phase 2 ( )

5 Topoi: Research Groups Phase 1 ( )

6 1. Forschungsdaten am EXC Topoi heterogene Datenmengen (unterschiedliche, interdisziplinäre Projekte mit diversen Forschungsansätzen) Sachdaten, Geodaten

7 1. Forschungsdaten am EXC Topoi heterogene Datenmengen (unterschiedliche, interdisziplinäre Projekte mit diversen Forschungsansätzen) Sachdaten, Geodaten Zugang zu den Datenmengen: SQL-Queries, spezifische Datenbankschnittstellen (z.b. FileMaker)

8 1. Forschungsdaten am EXC Topoi heterogene Datenmengen (unterschiedliche, interdisziplinäre Projekte mit diversen Forschungsansätzen) Sachdaten, Geodaten Zugang zu den Datenmengen: SQL-Queries, spezifische Datenbankschnittstellen (z.b. FileMaker) Geographische Informationssysteme (Webmapping Services, PostGIS-Layer, Attributtabellen/-views, ArcGIS- Integration)

9 1. Forschungsdaten am EXC Topoi heterogene Datenmengen (unterschiedliche, interdisziplinäre Projekte mit diversen Forschungsansätzen) Sachdaten, Geodaten Zugang zu den Datenmengen: SQL-Queries, spezifische Datenbankschnittstellen (z.b. FileMaker) Geographische Informationssysteme (Webmapping Services, PostGIS-Layer, Attributtabellen/-views, ArcGIS- Integration) Internetbrowser (PHP-Frontend, webgis.topoi.org, externe Webapplikationen mit entsprechenden Schnittstellen)

10 2. Vorbereitung der Daten für FDZ-IANUS Zielsetzung! Evaluierung der Forschungsdaten zur langfristigen Speicherung am FDZ! Möglichkeit nachhaltiger Vorhaltung und Nutzung der Datenmengen Erste Schritte Analyse der Datenstrukturen (Sachdaten und Geodaten) aus den Projekten in TOPOI 1 einheitliche Struktur der Geodaten Verknüpfung von Sachdatenkomponenten (minimales Set) Problem Geodaten tendenziell ähnlich gespeichert Sachdaten grundsätzlich heterogen

11 2. Vorbereitung der Daten für FDZ-IANUS 2.1 Evaluierung möglicher Datenmengen (reine/explizite) Geodaten! 15 ArcGIS-Projekte (ArcGIS-Database) hauptsächlich Areas A und C Implizite Geodaten! 6 Datenbanken mit zumindest inhaltlicher Geoinformation (Ortsnamennennung aber auch teilweise geographische Koordinaten) Sachdaten (ohne geographischen Bezug)! zunächst nicht beachtet => Ziel ist die standardisierte Übergabe der Datenmengen/-pakete (Geodatenbanken) an IANUS und Integration in die dortige im Aufbau befindliche Datenhaltung

12 2. Vorbereitung der Daten für FDZ-IANUS 2.1 Testbed: C-III Acts (Bronzezeitliche Hortfunde) MS-Access- Datenbank Excel-Exporttabellen ArcGIS-Projekt mit Rasterlayern => Fallbeispiel zur Integration von Geodaten und Sachdaten [Forschungsprojekt: Dissertation von Daniel Neumann (Topoi/ RGK)]

13 3. Geodatenressource (topoigdr)

14 3. Geodatenressource (topoigdr) 3.1 Minimaldatenset Ergebnis der Evaluierung aller Datenmengen Felder in topoigdr sollten vollständig mit allen möglichen Datenbanken gemapped werden können Metainformation der GDR (z.b. Level of Detail, Genauigkeit) werden in der Phase der Data Curation bestimmt nicht integrierbare Felder werden nur extern in der jeweiligen Datenbank vorgehalten (Verknüpfung via Nachweis) => topoigdr als Index für heterogene Forschungsdaten

15 3. Geodatenressource (topoigdr) 3.1 Minimaldatenset Geodaten_ID: Primärschlüssel Typ (Typ_ID): Punkt (point), Linie, Polygon, etc. (PostGIS-Tabelle in 1:n- Relation) gazetteer_id: eindeutige Zuordnung eines Ortes im idai.gazetteer (implizite Geodaten explizite Geodaten) Objekt: aggregierte Information aus Original-DB Datierung: inhaltliche Information (Time-Gazetteer?) Nachweis: Verweis auf Original-DB

16 3. Geodatenressource (topoigdr) 3.1 Minimaldatenset

17 3. Geodatenressource (topoigdr) 3.1 Minimaldatenset

18 3. Geodatenressource (topoigdr) 3.1 Minimaldatenset

19 3. Geodatenressource (topoigdr) 3.1 Minimaldatenset

20 3. Geodatenressource (topoigdr) 3.2 Kombination heterogener Datenmengen heterogene Datenmengen (unterschiedliche, interdisziplinäre Projekte mit diversen Forschungsansätzen) Sachdaten und Geodaten über topoigdr integriert

21 3. Geodatenressource (topoigdr) 3.2 Kombination heterogener Datenmengen QGIS: PostGIS-Layer

22 3. Geodatenressource (topoigdr) 3.2 Kombination heterogener Datenmengen QGIS: PostGIS-Layer ArcSDE: webgis.topoi.org (ArcGIS-Projekt; als WMS verfügbar)

23 3. Geodatenressource (topoigdr) 3.2 Kombination heterogener Datenmengen

24 4. idai.gazetteer Referenzsystem, Basisdienst für Geodaten des DAI und für Kooperationspartner Verbindung zu Arachne, Zenon, einfache Klassifikation (z.b. Siedlung / admin. Einheit) objektive Daten

25 4. idai.gazetteer flexibel standardisiert GeoServer / ArcGIS-Server Geodaten- Ressource idai. gazetteer alle Daten beliebig detailliert auch ohne weitere Struktur alle Daten, runtergekocht dafür Standardisierung klare Semantik (runterkochen ist einfacher als modellieren) Referenzsystem ( sprechen wir über das gleiche Ding? ) gut gepflegte Daten zitierbare URIs Granularität: ab Bauwerken Tools für Eingabe und Korrektur

26 5. Modellierung mit CIDOC CRM Ontologie für Dinge im Museum Event-basiert recht allgemein ( Man-Made Object statt Vase ): gleichzeitig Vor- und Nachteil Erweiterungen, z.b. für Grabungen (CRMarchaeo) Ziel: semantisch explizite Daten ( was bedeutet das Feld GrNr? ) wichtig für Ressource und Gazetteer!

27 5. Modellierung mit CIDOC CRM 5.1 Geodaten-Ressource Datenfelder der Ressource: Object Dating Classification Description Link2Source Project (im Gazetteer)

28 5. Modellierung mit CIDOC CRM 5.2 idai.gazetteer has type populated place? (bei administrative units passt Feature nicht, und unterschiedliches Verhalten über Zeit)

29 5. Modellierung mit CIDOC CRM 5.2 idai.gazetteer Was bedeutet es, wenn jemand eine Gazetteer-ID verwendet: ist gleich, ist in? ist gleich als Standardbedeutung? ist in : falls within (zufällig), forms part of (semantisch bedeutsam)? Unterscheidung automatisierbar? Rolle der Zeit: Period statt Place? Stand der letzten Änderung im Gazetteer? Verbindung: meint zur Zeit des Textes (antikes Athen aus Volltext), oder zur Zeit der Link-Erstellung? Berlin getrennt als Siedlung oder administrative Einheit, und neutrales Berlin? aber: glatter Übergang von un-semantischer Verwendung des Gazetteers Forschungsfragen: chronontology (time gazetteer), startet Januar 2015

30 5. Modellierung mit CIDOC CRM 5.3 Was ist der Mehrwert? Erstmal: semantische Explizitmachung geht über Semantic Web hinaus: Arachne 4 Geodaten-Ressource: heruntergekocht, also weniger Semantik, aber dafür überhaupt Semantik Ziel: Zusammenbringen von Daten innerhalb von Topoi und DAI, und zusammen Semantisierung in größerem Maßstab Design-Empfehlungen für Datenbanken, um sie semantisch modellieren zu können: Verbindungen nur möglich, wo man über das gleiche Ding spricht: Referenzsysteme! z.b. Gazetteer-IDs, und nachdenken über die Bedeutung der Verbindung

31 5. Modellierung mit CIDOC CRM 5.3 Ausblick: DAI-Gesamtstrategie 1. Netz von Services: Arachne, Gazetteer, time gazetteer 2. alle Daten als Linked Open Data 3. übergreifendes CIDOC CRM als theoretischer triple store 4. Linkage Service vergleichbar mit Geodaten-Ressource

32 Vielen Dank!