|
|
| (16 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 3: |
Zeile 3: |
| [[Kategorie:Leipzig]] | | [[Kategorie:Leipzig]] |
|
| |
|
| ==LEO - Leipziger Ontologie== | | ==LDO - Leipzig Data Ontology== |
|
| |
|
| Zur Herstellung von Interoperabilität auf Datenebene ist es erforderlich, sich über das dabei verwendete Vokabular zu einigen. Der relevante Abstimmungsprozess soll und wird im Rahmen der [[LD.LOD|Leipziger Initiative für Offene Daten]] wenigstens für längerfristig persistente Datenbestände auf der [https://groups.google.com/forum/?fromgroups#!forum/apileipzig apileipzig] Liste verhandelt.
| | Mehr zur Leipzig Ontology nun im [https://leipzigdata.github.io/LDO Leipzig Data Wiki]. |
| | |
| ----
| |
| | |
| === Vorgenommene Änderungen ===
| |
| | |
| * Namensraum 'cal:' nach standardmäßiger Benennung 'ical:' umgesetzt.
| |
| * ld:Ortzusatz und ld:Ortszusatz ist obsolet zugunsten von ld:hasAddressAddendum (HGG - 24.01.2013)
| |
| * ld:hasAdresse in ld:hasAddress umgewandelt, ld:hasAdresse ist damit obsolet (AN - 24.01.2013)
| |
| * Personen nach foaf transformiert (HGG - 14.02.2013)
| |
| * WeitereAdressen.ttl angelegt und Namensraum-Präfix Data/ExterneAdressen eingearbeitet (HGG - 25.02.2013)
| |
| | |
| === Fragen und Vorhaben in Diskussion ===
| |
| | |
| * Tagging in Richtung Key-Value-Paare weiterentwickeln wie bei den OSM Map Features http://wiki.openstreetmap.org/wiki/Map_Features
| |
| ** Claus Stadler fragen, Muto-Ontologie anschauen
| |
| * Infos zu einzelnen Einträgen, die sich nicht strukturiert abbilden lassen, werden dem Eintrag als rdfs:comment zugeordnet.
| |
| | |
| Zu klärende Fragen:
| |
| * Sprechende Namen für Prädikate grundsätzlich(er) in Englisch.
| |
| * Einbindung weiterer ''verbreiteter'' Vokabulare
| |
| ** http://lov.okfn.org/dataset/lov/index.html - Linked Open Vocabularies (LOV)
| |
| ** Liste der Abkürzungen siehe http://prefix.cc
| |
| * Adressen:
| |
| ** Unterscheidung in Leipziger Adressen (Namens-Standard Data/Adresse/<plz>.<strasse>.<nr>) und externe Adressen (Namens-Standard Data/ExterneAdresse/<plz>.<ort>.<strasse>.<nr>)
| |
| ** weitere Literale ld:hasCity, ld:hasStreet bei externen Adressen
| |
| ** Gibt es eine sinnvolle externe Ontologie, die übernommen werden sollte? Wie löst das Open Street Map?
| |
| ** Straßen als Objekte außerhalb von Leipzig werden nicht eingeführt, im rdfs:label Straße und Hausnummer gemeinsam. ld:hasAddress als required bei ld:Ort auch außerhalb von Leipzig.
| |
| * Namensraumpräfixe konsolidieren (Tags sind ldtags oder ldt, letzteres aber auch Träger)
| |
| | |
| ----
| |
| | |
| === URIs ===
| |
| | |
| Über URIs (Unique Resource Identifier) werden Ressourcen identifiziert, über die RDF-Tripel (also letztlich Sätze) in der Wissensbasis gesammelt werden. In jedem RDF-Tripel sind die ersten beiden Einträge (Subjekt und Prädikat) unbedingt URIs, der dritte (Objekt) ein Literal (String) oder ebenfalls eine URI. Während URIs für Subjekte und Objekte (also Knoten im entsprechenden RDF-Graphen) im Normalfall Objektinstanz-Bezeichner sind und damit eine realweltliche Entsprechung haben, sind URIs für Prädikate Begriffs-Bezeichner und gehören zum Modell.
| |
| | |
| URIs dienen zwar dazu, Informationen in maschinenlesbarer Form vorzuhalten, es ist aber eine gute Regel, '''sprechende Namen''' als Bezeichner zu vergeben. Jeder Bezeichner soll deshalb die Gestalt leipzig-data.de/Data/<Präfix>/EinfacherBezeichner haben, wobei EinfacherBezeichner den regulären Ausdruck [-A-Za-z0-9._] matcht und CamelCase-Notation sowie '_' (minor variation) und '.' (major variation) als Trennzeichen die Lesbarkeit weiter verbessern. Für verschiedene Typen von Objektinstanzen gibt es feinere Namensgebungsregeln.
| |
| :Dazu werden Umlaute und andere Sonderzeichen nach fixID-Regeln in reine ASCII-Strings transformiert.
| |
| | |
| Alle Modellbegriffe haben Bezeichner mit dem Präfix ''Model'', Objektinstanz-Bezeichner verteilen sich auf verschiedene paketspezifische Namensräume.
| |
| | |
| === Pakete ===
| |
| | |
| Die Wissensbasis ist in Pakete unterteilt, in denen einzelne Teile der Wissensbasis nach Management-Gesichtspunkten zusammengefasst sind. Typischerweise enthält ein Paket alle Einträge zu Subjekten, die zur selben Klasse gehören. Der Paketname ist dabei typischerweise ein Wort im Plural, der Namensraumpräfix der damit organisierten Instanzen dasselbe Wort im Singular.
| |
| :Also etwa ''leipzig-data.de/Data/Personen/'' für das Paket und ''leipzig-data.de/Data/Person/'' als Namenspräfix für Instanzen von ''ld:Person'', die in ''Personen.ttl'' aufgelistet sind.
| |
| Allerdings werden Pakete auch zu anderen Strukturierungszwecken verwendet, so dass es nicht notwendig zu jedem Paketnamen URIs mit einem solchen Präfix gibt.
| |
| | |
| * Adressen.ttl - Instanzen von ld:Adresse und ld:Strasse
| |
| ** HGG 2013-01-17: Eine Reihe von URIs enthielten noch Sonderzeichen wie é. Das habe ich gefixt und außerdem eine Reihe von Prädikaten rausgenommen, die obsolet sind.
| |
| ** HGG 2013-02-25: Unterscheidung in Leipziger Adressen und externe Adressen. Aufbau einer Datenbasis WeitereAdressen.ttl.
| |
| * Angebote.ttl - Instanzen von ld:Angebot
| |
| * APILeipzig-Referenzen.ttl - Referenzen von LeipzigData-URIs auf APILeipzig-IDs
| |
| ** enthält alle Sätze mit dem Prädikat ld:hasAPIRef, deren Wert ein ld:APIRef ist
| |
| * Events.ttl - Instanzen von ld:Event (Verweildauer solcher Instanzen in den Daten ist zu klären)
| |
| * GeoDaten.ttl - Geo-Koordinaten (Claus hat das über nominatim aus OSM extrahiert), WeitereGeoDaten.ttl (weitere Geodaten zu Einträgen, die nicht über nominatim gewonnen wurden), beides OSM-Lizenz
| |
| * KontaktDaten.ttl - weitere nicht öffentliche Informationen zu Personen (nur im internen Repo)
| |
| * Orte.ttl - Instanzen von ld:Ort
| |
| * Projekte.ttl - Instanzen von ld:Projekt
| |
| * Personen.ttl - Instanzen von foaf:Person
| |
| * Stadtbezirke.ttl - Instanzen von ld:Stadtbezirk
| |
| * StadtLeipzig-Referenzen.ttl - Referenzen von LeipzigData-URIs auf IDs in den Datenbeständen der Stadt Leipzig
| |
| ** enthält alle Sätze mit dem Prädikat ld:hasStadtRef, deren Wert ein ld:StadtRef ist
| |
| * Tags.ttl - Instanzen von ld:Tag
| |
| * Traeger.ttl - Instanzen von ld:Traeger, sind noch in die neuen Unterstrukturen von ld:JuristischePerson zu integrieren
| |
| | |
| === Namensräume und Klassen ===
| |
| | |
| Orte, Angebote und Projekte sind Aktivitäten verschiedener Dauerhaftigkeit (Ort > Angebot > Projekt). Die Frage der genauen Abgrenzung ist noch zu spezifizieren.
| |
| | |
| Verwendete Teil-Ontologien
| |
| * foaf = [http://xmlns.com/foaf/spec/ foaf-Ontologie] zur Beschreibung von Personen
| |
| * ical = [http://www.kanzaki.com/docs/ical ical-Ontologie] zur Beschreibung von Terminen
| |
| * org = [http://www.w3.org/ns/org# org-Ontologie] zur Beschreibung von Organisationen
| |
| * xsd = [http://books.xmlschemata.org/relaxng/relax-CHP-19.html xsd Datentyp-Beschreibungen]
| |
| | |
| ld = leipzig-data.de/Data/Model/ - alle relevanten Modellbegriffe (Klassen, Prädikate)
| |
| | |
| Allgemeine Prädikate:
| |
| * Alle Klassen haben die '''Literale''' rdfs:label, rdfs:comment als Prädikate.
| |
| * owl:Thing ld:hasURL <URL>
| |
| * owl:Thing ld:relatesTo owl:Thing - nicht weiter formal spezifizierte Zuordnung
| |
| | |
| Einzelne Klassen:
| |
| * '''ld:Adresse''' (definiert in Adressen.ttl) - URIs haben die Struktur ''Data/Adresse/<plz>.<strasse>.<nummer>'' für Leipziger Adressen mit Postleitzahl ''plz'', ''strasse'' der fixId-transformierte Straßenname und Hausnummer ''nummer'' (incl. ggf. Zusatz) und analog ''Data/ExterneAdresse/<plz>.<ort>.<strasse>.<nummer>'' für externe Adressen .
| |
| ** Die standardisierten Adressen sind bis auf die Hausnummer aufgelöst. Weitere Informationen sind als Adresszusatz (ld:hasAddressAddendum) einzutragen.
| |
| ** ld:inStreet ld:Strasse (nur Leipziger Adressen, Straße als URI, um daran u.a. Geokoordinaten zu verankern. Haben auch Nummer in den städtischen Daten)
| |
| ** Literale ld:hasStreet, ld:hasCity Literale für externe Adressen
| |
| ** Literale ld:hasHouseNumber (Hausnummer, ggf. mit Zusatz), ld:hasPostCode (PLZ)
| |
| ** Q: Können Geokoordinaten aus ld:hasCity, ld:hasPostCode, rdfs:label inferiert werden
| |
| ** Muss auch vokabularmäßig stärker mit Open Street Map vernetzt werden.
| |
| ** In Geo-Koordinaten.ttl (eigenes Repo unter OSM-Lizenz) sind den Adressen Geokoordinaten zugeordnet (ld:nearby <linkedgeodata.org/triplify/URI>; geo:lat xsd:double; geo:long xsd:double)
| |
| | |
| * '''ld:Angebot''' (definiert in Angebote.ttl) - Angebot eines Trägers an einem Ort oder wie auch immer
| |
| ** ld:contactPerson ld:NatuerlichePerson - Ansprechpartner
| |
| ** ld:engagedPerson ld:NatuerlichePerson - weitere mit dem Angebot verbundene Person
| |
| ** ld:hasAddress ld:Adresse - Adresse des Angebots
| |
| ** ld:hasAddressAddendum Literal - Adresszusatz
| |
| ** ld:hasSupplier ld:Traeger - Träger
| |
| ** ld:hasTag ld:Tag - Zuordnung des Angebots (Konsolidierung der literalen Werte von ld:Art und ld:Bereich)
| |
| ** ld:relatedBundle ld:Ort - Zuordnung zu Ort
| |
| ** Orga-Literale ld:hasEmail, ld:hasFax, ld:hasTelefon
| |
| ** Inhalts-Literale (alle mehrfach möglich) ld:Art (obsolet), ld:Arbeitsformen, ld:Auszeichnungen (mehrfach), ld:Bereich (obsolet), ld:Finanzierung, ld:Hintergrund, ld:Kosten (mehrfach), ld:Kurzinformation (mehrfach), ld:Teilnahmebedingungen, ld:Zielgruppe, ld:Zielstellung
| |
| | |
| * '''ld:APIRef''' (keine Definition, Typ tritt ausschließlich als Objekt in API-Referenzen.ttl auf) - URIs haben die Struktur ''leipzig-data.de/Data/APILeipzig/prefix.nr'', wobei prefix für den Datentyp (derzeit Host, Venue, Event) und nr für den int-Index dieses Datums bei API Leipzig steht.
| |
| | |
| * '''ld:Event''' (definiert in Events.ttl) - einzelne Events, weiter zu spezifizieren
| |
| ** ld:contactPerson ld:NatuerlichePerson - Ansprechpartner für das Event
| |
| ** ical:description Literal - Beschreibung des Events
| |
| ** ical:summary Literal - kurze Beschreibung (max. 100 Zeichen) des Events
| |
| ** ical:location ld:Ort - Ort, an dem das Events stattfindet
| |
| ** Literale: ical:dtstart, ical:dtend (xsd:date oder xsd:datetime)
| |
| ** ical:organizer ld:Ort oder ld:Traeger oder ld:NatuerlichePerson - Veranstalter des Events
| |
| ** ld:hasAddressAddendum Literal - genauere Bezeichnung innerhalb von ical:location
| |
| ** ld:hasTag ld:Tag - Tags für das Event
| |
| ** ld:zurReihe ld:Projekt - Zuordnung zu einer Veranstaltungsreihe
| |
| ** Orga-Literale ld:hasAPIRef
| |
| ** Literale: ld:Kosten
| |
| | |
| * '''ld:JuristischePerson''' - Namensschema ist noch festzulegen, derzeit ld:Traeger (in Traeger.ttl)
| |
| ** Eine juristische Person kann weiteren Klassen wie ld:Verein, ld:Unternehmen zugeordnet werden, soll aber immer auch ld:JuristischePerson sein, um Inferenz längs Vererbungshierarchien zu vermeiden. URIs juristischer Personen haben die Gestalt ''Data/<OrgForm>/<name>'', wobei <OrgForm> auf die Organisationsform hinweist. Damit soll diese Information perspektivisch verfeinert werden.
| |
| ** Derzeit sind dies ausschließlich Instanzen von ld:Traeger (aus Traeger.ttl), die aus der LD.Datenbasis importiert wurden. Die URIs dieser Instanzen müssen zügig bzgl. der OrgaForm weiter normiert werden, indem der allgemeine Präfix Traeger/ durch Verein/ Unternehmen/ StadtLeipzig/ UniLeipzig/ HTWK/ usw. ersetzt wird (macht Andreas).
| |
| ** Abzubilden auf foaf:Organization
| |
| | |
| * '''foaf:Person''' (definiert in Personen.ttl) - URIs haben typischerwise die Struktur ''Data/Person/<Nachname_Vorname>'' nach fixID-Transformation und enthalten öffentliche Informationen zu Personen. Weitergehende Informationen werden in KontaktDaten.ttl gesammelt und nicht veröffentlicht.
| |
| ** Literal foaf:name (statt rdfs:label)
| |
| ** Literale foaf:phone, foaf:mbox (nicht öffentlich)
| |
| ** org:memberOf ld:Traeger
| |
| ** ld:relatedTo URI (nicht öffentlich)
| |
| ** ld:hasAddress ld:Adresse (nicht öffentlich)
| |
| | |
| * '''ld:Ort''' (definiert in Orte.ttl) - längerfristig existierendes Bündel von Angeboten, das meist an einen Ort gebunden ist
| |
| ** ld:contactPerson ld:NatuerlichePerson - Ansprechpartner
| |
| ** ld:engagedPerson ld:NatuerlichePerson - weitere mit dem Ort verbundene Person
| |
| ** ld:hasAddress ld:Adresse - Adresse des Orts (req.)
| |
| ** ld:hasAddressAddendum Literal - Adresszusatz
| |
| ** ld:hasAnschrift Literal - Anschrift, Postfach oder so, wenn der Ort keine ld:Adresse hat (Beispiel: LSGM)
| |
| ** ld:hasSupplier ld:Traeger - Träger
| |
| ** ld:hasTag ld:Tag - Klassifizierung (Konsolidierung der literalen Werte von ld:Art und ld:Bereich)
| |
| ** ld:Langinformation ld:InfoRecord - Inforecord mit einer längeren (externen) Information zum Ort im XHTML-Format
| |
| ** Orga-Literale ld:hasEmail, ld:hasFax, ld:hasTelefon
| |
| ** Inhalts-Literale (alle mehrfach möglich) ld:Art (obsolet), ld:Arbeitsformen, ld:Auszeichnungen (mehrfach), ld:Bereich (obsolet), ld:Finanzierung, ld:Hintergrund, ld:Kosten (mehrfach), ld:Kurzinformation (mehrfach), ld:Leistungsangebot (mehrfach), ld:Oeffnungszeiten (mehrfach), ld:Teilnahmebedingungen, ld:Zielgruppe, ld:Zielstellung
| |
| :Listen in der Leistungsbeschreibung der MINT-Broschüre von Lernen vor Ort werden in Mehrfacheinträge umgewandelt.
| |
| | |
| * '''ld:PlanungsRaum''' (definiert in Stadtbezirke.ttl) - Planungsraum der Stadt Leipzig. Als URI wird ''Data/Planungsraum/<name>'' verwendet, wobei ''name'' der fixId-transformierte Name des Planungsraums ist.
| |
| ** Die Jugendhilfeplanung teilt die 63 Stadtbezirke der Stadt Leipzig in 7 Planungsräume ein.
| |
| | |
| * '''ld:Projekt''' (definiert in Projekte.ttl) - Projekt an einem Ort oder innerhalb eines komplexeren Angebots
| |
| ** ld:contactPerson ld:NatuerlichePerson - Ansprechpartner
| |
| ** ld:engagedPerson ld:NatuerlichePerson - weitere mit dem Ort verbundene Person
| |
| ** ld:hasSupplier ld:Traeger - Träger
| |
| ** ld:hasTag ld:Tag - Klassifizierung (Konsolidierung der literalen Werte von ld:Art und ld:Bereich)
| |
| ** ld:relatedBundle ld:Ort - Zuordnung zu Ort
| |
| ** Orga-Literale ld:hasEmail, ld:hasFax, ld:hasTelefon
| |
| ** Inhalts-Literale (alle mehrfach möglich) ld:Arbeitsformen, ld:Auszeichnungen (mehrfach), ld:Finanzierung, ld:Hintergrund, ld:Kosten (mehrfach), ld:Kurzinformation (mehrfach), ld:Leistungsangebot (mehrfach), ld:Oeffnungszeiten (mehrfach), ld:Teilnahmebedingungen, ld:Zielgruppe, ld:Zielstellung
| |
| | |
| * '''ld:Stadtbezirk''' (definiert in Stadtbezirke.ttl) - Als URI wird ''Data/Stadtbezirk/<stadtbezirk>'' verwendet, wobei ''stadtbezirk'' der fixId-transformierte Name des Stadtbezirks ist.
| |
| ** ld:zuPlanungsRaum ld:PlanungsRaum - Zuordnung zu Planungsraum
| |
| | |
| * '''ld:StadtRef''' (keine Definition, Typ tritt ausschließlich als Objekt in StadtLeipzig-Referenzen.ttl auf) - URIs haben die Struktur ''leipzig-data.de/Data/StadtId/<prefix>.<nr>'', wobei prefix für den Datentyp (derzeit Street) und nr für den Index dieses Datums in den Datenbeständen der Stadt Leipzig steht.
| |
| | |
| * '''ld:Strasse''' - (definiert in Adressen.ttl) Als URI wird typischerweise ''Data/Strasse/<strasse>'' verwendet, wobei ''strasse'' der fixId-transformierte Straßenname ist und Mehrwortnamen zu Strings ohne Leerzeichen zusammengezogen werden. Existiert der Straßenname mehrfach, wird ''strasse.stadtbezirk'' verwendet (das ist noch einzubauen).
| |
| * ld:hasStreetKey - Literal. Straßenschlüssel der Stadt Leipzig (obsolet - nach StadtLeipzig-Referenzen.ttl verschoben)
| |
| | |
| * '''ld:Tag''' - (definiert in Tags.ttl) Genormtes Schlagwort, um Zuordnung eines Angebots oder Orts zu klassifizieren.
| |
| ** Die genaue Behandlung dieser Strukturen muss noch diskutiert werden. Instanzen von ld:Tag dienen auf jeden Fall dazu, Tagwolken aufzubauen.
| |
| ** In Überarbeitung. Überlegungen, stattdessen ein key-value-System wie bei Open Streetmap zu verwenden. Kopplung mit der Muto-Ontologie ist zu untersuchen.
| |
| | |
| * '''ld:Traeger''' (in Traeger.ttl) - (juristischer) Träger eines Angebots oder Orts, perspektivisch in ld:JuristischePerson umzubenennen, wenn Unterkategorien (siehe ld:JuristischePerson) eingearbeitet sind. (Abgleich mit foaf:Organzation erforderlich)
| |
| ** ld:contactPerson ld:NatuerlichePerson - Ansprechpartner
| |
| ** ld:engagedPerson ld:NatuerlichePerson - weitere mit dem Träger verbundene Person
| |
| ** ld:hasAddress ld:Adresse - Adresse der Organisation
| |
| ** ld:hasAddressAddendum Literal - Adresszusatz
| |
| ** ld:hasSupplierNumber - Vereinsnummer lt. "Förderung Freie Träger 2011"
| |
| ** Literale: ld:hasEmail, ld:hasFax, ld:hasTelefon, ld:Hintergrund, ld:Kurzinformation
| |
