LD.LOD.2012-10-26: Unterschied zwischen den Versionen
HGG (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
HGG (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
| Zeile 14: | Zeile 14: | ||
==Anmerkungen== | ==Anmerkungen== | ||
Zunächst stellte [http://bis.informatik.uni-leipzig.de/ClausStadler Claus Stadler] mit Sparqlify einen Ansatz vor, wie auf einer klassischen Datenbank-Quelle ein SPARQL-Endpunkt aufgesetzt werden kann, mit dem eine durch den Anbieter definierbare Sicht auf die dort verfügbaren und aktuell gehaltenen Daten im RDF-Format generiert werden kann, um die Daten in eine übergreifende Linked Open Data Struktur einzubetten. | Zunächst stellte [http://bis.informatik.uni-leipzig.de/ClausStadler Claus Stadler] mit '''Sparqlify''' einen Ansatz vor, wie auf einer klassischen Datenbank-Quelle ein SPARQL-Endpunkt aufgesetzt werden kann, mit dem eine durch den Anbieter definierbare Sicht auf die dort verfügbaren und aktuell gehaltenen Daten im RDF-Format generiert werden kann, um die Daten in eine übergreifende Linked Open Data Struktur einzubetten. | ||
Im Gegensatz zu den bisher stärker diskutierten Ansätzen der Transformation der Daten selbst hat ein solcher Zugang den Vorteil, bestehende Datenaktualisierungsprozesse für die SQL-Datenbank unmittelbar weiter nutzen zu können. | Im Gegensatz zu den bisher stärker diskutierten Ansätzen der ''Transformation der Daten'' selbst hat ein solcher Zugang den Vorteil, bestehende Datenaktualisierungsprozesse für die SQL-Datenbank unmittelbar weiter nutzen zu können. In der Diskussion wurde deutlich, dass für die weitere Entwicklung einer Leipzig Open Data Cloud die soziale Dimension der Datenmanagement-Prozesse zur ''Fortschreibung'' von Datenbeständen (primäre Daten) klarer berücksichtigt werden muss, und über Ansätze wie den hier vorgestellten auch ein ''Caching'' von Daten oder Teilen davon in der Leipzig Open Data Cloud möglich ist. Der Fokus verschiebt sich damit von den technischen zu den sozialen und rechtlichen Aspekten der Bereitstellung solcher Daten durch den jeweiligen Betreiber | ||
Im zweiten Teil des Seminars diskutierten wir intensiver über das weitere Vorgehen in der '''Leipziger Initiative für Offene Daten'''. Die bisherige englische Bezeichnung "Leipzig Open Data Initiative" wurde als Teil des Problems angesehen, mit der Endnutzergruppe der Konzepte ins Gespräch zu kommen, von der eine größere technische Affinität nicht vorausgesetzt werden kann und die durch ungewöhnliche Bezeichnungen eher irritiert ist. | Im zweiten Teil des Seminars diskutierten wir intensiver über das weitere Vorgehen in der '''Leipziger Initiative für Offene Daten'''. Die bisherige englische Bezeichnung "Leipzig Open Data Initiative" wurde als Teil des Problems angesehen, mit der Endnutzergruppe der Konzepte ins Gespräch zu kommen, von der eine größere technische Affinität nicht vorausgesetzt werden kann und die durch ungewöhnliche Bezeichnungen eher irritiert ist. | ||
Version vom 29. Oktober 2012, 13:52 Uhr
Home > Leipzig Open Data
Leipzig Open Data Seminar am 26. Oktober 2012
- ab 13 Uhr im Raum P-701, Paulinum, Augustusplatz
Agenda:
- Sparqlify - Claus Stadler (AKSW-Gruppe, Uni Leipzig)
- Stand "Open Innovation", Diskussion des weiteren Vorgehens
- Siehe dazu auch den Mailverkehr auf der Liste apileipzig
Anmerkungen
Zunächst stellte Claus Stadler mit Sparqlify einen Ansatz vor, wie auf einer klassischen Datenbank-Quelle ein SPARQL-Endpunkt aufgesetzt werden kann, mit dem eine durch den Anbieter definierbare Sicht auf die dort verfügbaren und aktuell gehaltenen Daten im RDF-Format generiert werden kann, um die Daten in eine übergreifende Linked Open Data Struktur einzubetten.
Im Gegensatz zu den bisher stärker diskutierten Ansätzen der Transformation der Daten selbst hat ein solcher Zugang den Vorteil, bestehende Datenaktualisierungsprozesse für die SQL-Datenbank unmittelbar weiter nutzen zu können. In der Diskussion wurde deutlich, dass für die weitere Entwicklung einer Leipzig Open Data Cloud die soziale Dimension der Datenmanagement-Prozesse zur Fortschreibung von Datenbeständen (primäre Daten) klarer berücksichtigt werden muss, und über Ansätze wie den hier vorgestellten auch ein Caching von Daten oder Teilen davon in der Leipzig Open Data Cloud möglich ist. Der Fokus verschiebt sich damit von den technischen zu den sozialen und rechtlichen Aspekten der Bereitstellung solcher Daten durch den jeweiligen Betreiber
Im zweiten Teil des Seminars diskutierten wir intensiver über das weitere Vorgehen in der Leipziger Initiative für Offene Daten. Die bisherige englische Bezeichnung "Leipzig Open Data Initiative" wurde als Teil des Problems angesehen, mit der Endnutzergruppe der Konzepte ins Gespräch zu kommen, von der eine größere technische Affinität nicht vorausgesetzt werden kann und die durch ungewöhnliche Bezeichnungen eher irritiert ist.
Die Bemerkungen sind weiter zu ergänzen.
Hans-Gert Gräbe, 28.10.2012
