|
|
| (61 dazwischenliegende Versionen von 2 Benutzern 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]. |
| | |
| === Vorhaben in Progress ===
| |
| | |
| * Tagging in Richtung Key-Value-Paare weiterentwickeln wie bei den OSM Map Features http://wiki.openstreetmap.org/wiki/Map_Features
| |
| ** Claus Stadler fragen
| |
| | |
| === 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.
| |
| | |
| * AlteAdressen.ttl - Instanzen von ld:AlteAdresse (Adressen aus dem [[LD.Datenprojekt]] - zu ersetzen)
| |
| * WeitereAdressen.ttl - Instanzen von ld:Adresse, die nicht in Adressen.ttl enthalten sind
| |
| * Personen.ttl - Instanzen von ld:NatuerlichePerson
| |
| * Orte.ttl - Instanzen von ld:Ort, aus dem [[LD.Datenprojekt]] übernommen
| |
| * Stadtbezirke.ttl - Instanzen von ld:Stadtbezirk
| |
| * Tags.ttl - Instanzen von ld:Tag
| |
| * Traeger.ttl - Instanzen von ld:Traeger, aus dem [[LD.Datenprojekt]] übernommen, sind noch in die neuen Unterstrukturen von ld:JuristischePerson zu integrieren
| |
| | |
| === Namensräume und Klassen ===
| |
| | |
| ld = leipzig-data.de/Data/Model/ - alle relevanten Modellbegriffe (Klassen, Prädikate)
| |
| | |
| | |
| Allgemeine Prädikate:
| |
| * Alle Klassen haben die '''Literale''' rdf:about (req., single), rdfs:label, rdfs:comment als Prädikate.
| |
| ** ld:hasAPIId - Literal. Id bei API Leipzig.
| |
| | |
| Einzelne Klassen:
| |
| * '''ld:Adresse''' (definiert in Adressen.ttl) - URIs haben die Struktur ''leipzig-data.de/Data/Adresse/plz.strasse.nummer'' mit Postleitzahl ''plz'', ''strasse'' der fixId-transformierte Straßenname und Hausnummer ''nummer'' (incl. ggf. Zusatz).
| |
| * '''ld:NatuerlichePerson''' (definiert in Personen.ttl) - URIs haben typischerwise die Struktur ''leipzig-data.de/Data/Person/Nachname_Vorname'' nach fixID-Transformation und enthalten öffentliche Informationen zu Personen. Weitergehende Informationen werden im internen Datenbestand des Projekts gesammelt und nicht veröffentlicht.
| |
| * '''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.
| |
| ** Derzeit sind dies ausschließlich Instanzen von ld:Traeger (aus Traeger.ttl), die aus der LD.Datenbasis importiert wurden. Die URIs müssen zügig weiter normiert werden.
| |
| * '''ld:Stadtbezirk''' (definiert in Stadtbezirke.ttl) - Als URI wird ''leipzig-data.de/Data/Stadtbezirk/stadtbezirk'' verwendet, wobei ''stadtbezirk'' der fixId-transformierte Name des Stadtbezirks verwendet.
| |
| ** '''Eigenschaften''': ld:hasAPIId, ld:hasStadtId Literal - Id's in den Stadtdaten bzw. Daten von API Leipzig.
| |
| * '''ld:Strasse''' - (definiert in Adressen.ttl) Als URI wird typischerweise ''leipzig-data.de/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).
| |
| ** '''Eigenschaften''': ld:hasStreetKey - Literal. Straßenschlüssel der Stadt Leipzig.
| |
| * '''ld:Tag''' - (definiert in Tags.ttl) Genormtes Schlagwort zur Klassifizierung (noch zu präzisieren)
| |
| ** Die genaue Behandlung dieser Strukturen muss noch diskutiert werden. Instanzen von ld:Tag dienen auf jeden Fall dazu, Tagwolken aufzubauen.
| |
| | |
| === Aus dem [[LD.Datenprojekt]] ===
| |
| | |
| Orte, Angebote und Projekte sind Aktivitäten verschiedener Dauerhaftigkeit (Ort > Angebot > Projekt). Die Frage der genauen Abgrenzung ist noch zu spezifizieren.
| |
| | |
| Verwendete Teil-Ontologien
| |
| * cal = [http://www.kanzaki.com/docs/ical ical-Ontologie]
| |
| * xsd = [http://books.xmlschemata.org/relaxng/relax-CHP-19.html xsd Datentyp-Beschreibungen]
| |
| | |
| * '''ld:AlteAdresse''' (definiert in AlteAdressen.ttl) - eine Post-Adresse aud der LD.Datenbasis. Veraltet, ist durch ld:Adresse zu ersetzen, die weiteren Prädikate dem Ort zuzuordnen
| |
| ** Inhalts-Literale ld:behindertengerecht, ld:Empfaenger (nur wenn verschieden von rdf:label), ld:Erreichbarkeit (mehrfach), ld:Strasse, ld:PLZ, ld:Ort
| |
| ** Orga-Literale: ld:hasOEN_id, ld:hasUW_id
| |
| | |
| * '''ld:Angebot''' (definiert in Angebote.ttl) - Angebot eines Trägers an einem Ort oder wie auch immer
| |
| ** ld:contactPerson ld:Person - Ansprechpartner
| |
| ** ld:engagedPerson ld:Person - weitere mit dem Angebot verbundene Person
| |
| ** ld:hasAddress ld:AlteAdresse - Adresse des Angebots (altes Format)
| |
| ** 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:hasUW_id, ld:hasURL, ld:hasTelefon
| |
| ** Inhalts-Literale (alle mehrfach möglich) ld:Art (obsolet), ld:Arbeitsformen, ld:Auszeichnungen (merhfach), ld:Bereich (obsolet), ld:Finanzierung, ld:Hintergrund, ld:Kosten (mehrfach), ld:Kurzinformation (mehrfach), ld:Teilnahmebedingungen, ld:Zielgruppe, ld:Zielstellung
| |
| | |
| * '''ld:Event''' (definiert in Events.ttl) - einzelne Events, weiter zu spezifizieren
| |
| ** ld:contactPerson ld:Person - Ansprechpartner für das Event
| |
| ** cal:description Literal - kurze Beschreibung des Events
| |
| ** cal:location ld:Adresse - Adresse des Orts, an dem das Events stattfindet
| |
| ** cal:organizer ld:Ort oder ld:Traeger - Veranstalter des Events
| |
| *** kann ggf. über E ld:zurReihe R; R ld:hasSupplier S inferiert werden.
| |
| ** ld:Ortzusatz Literal - genauere Bezeichnung innerhalb von cal:location
| |
| ** ld:zurReihe ld:Angebot - Reihe des Events
| |
| ** Orga-Literale ld:hasOEN_id, ld:hasUW_id, ld:hasAPIId
| |
| ** Literale: ld:hasURL, rdfs:label, ld:untertitel, ld:Kosten
| |
| ** Literale: cal:dtstart, cal:dtend (xsd:date oder xsd:datetime)
| |
| | |
| * '''ld:Ort''' (definiert in Orte.ttl) - längerfristig existierendes Bündel von Angeboten, das meist an einen Ort gebunden ist
| |
| ** ld:contactPerson ld:Person - Ansprechpartner
| |
| ** ld:engagedPerson ld:Person - weitere mit dem Ort verbundene Person
| |
| ** ld:hasAdresse ld:Adresse - Adresse des Orts (req.)
| |
| ** ld:hasAnschrift Literal - Anschrift, Postfach oder so, wenn kein has:Adresse
| |
| ** 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:hasURL, 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:Projekt''' (definiert in Projekte.ttl) - Projekt an einem Ort oder innerhalb eines komplexeren Angebots
| |
| ** ld:contactPerson ld:Person - Ansprechpartner
| |
| ** ld:engagedPerson ld:Person - 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:hasURL, 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:InfoRecord''' (definiert in Tags.ttl) - längerer externer Info-Record
| |
| ** ld:hasURL - Ressourcen-ID, Beschreibung des Zwecks unter rdfs:comment
| |
| | |
| * '''ld:Traeger''' (in Traeger.ttl) - (juristischer) Träger eines Angebots oder Orts
| |
| ** ld:contactPerson ld:Person - Ansprechpartner
| |
| ** ld:engagedPerson ld:Person - weitere mit dem Träger verbundene Person
| |
| ** ld:hasAddress ld:AlteAdresse - Adresse der Organisation (altes Format)
| |
| ** ld:hasSupplierNumber - Vereinsnummer lt. "Förderung Freie Träger 2011"
| |
| ** Literale: ld:hasEmail, ld:hasFax, ld:hasURL, ld:Hintergrund, ld:Kurzinformation, ld:hasTelefon
| |
| | |
| * '''ld:Tag''' (in Tags.ttl) - Tag (Schlüsselwort), um Zuordnung eines Angebots oder Orts zu klassifizieren.
| |
| ** Ist in Überarbeitung.
| |
