|
|
| (68 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| Home > [[LD.LOD|Leipzig Open Data]] und [[LD.Datenprojekt]] | | Home > [[LD.LOD|Leipziger Initiative für Offene Daten]] |
|
| |
|
| [[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. Ein erster Ansatz für ein solches Vokabular ist mit der [[LD.Ontologie]] vorgelegt. Der relevante Abstimmungsprozess soll und wird im Rahmen der [[LD.LD|Leipzig Data]] Aktivität wenigstens für längerfristig persistente Datenbestände auf der [https://groups.google.com/forum/?fromgroups#!forum/apileipzig apileipzig] Liste zügig weiter vorangetrieben werden.
| | Mehr zur Leipzig Ontology nun im [https://leipzigdata.github.io/LDO Leipzig Data Wiki]. |
| | |
| === 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/<Paketname>/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 den fixID-Regeln in reine ASCII-Strings transformiert.
| |
| | |
| Alle Modellbegriffe haben Bezeichner aus dem Paket ''Data'', 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. Namensräume innerhalb von leipzig-data.de haben stets ein Präfix der Form leipzig-data.de/Data/<Paketname>/, allerdings werden Pakete auch zu anderen Strukturierungszwecken verwendet, so dass es nicht notwendig zu jedem Paketnamen URIs mit einem solchen Präfix gibt. Typischerweise ist der Paketname im Plural, der Namensraumpräfix der damit organisierten Instanzen 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.
| |
| | |
| * Adressen.ttl - Instanzen von ld:Adresse und ld:Strasse
| |
| * AlteAdressen.ttl - Instanzen von ld:AlteAdresse (Adressen aus dem [[LD.Datenprojekt]] - zu ersetzen)
| |
| * 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)
| |
| * '''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.
| |
| ** Öffentliche Informationen zu Personen, weitere Informationen werden im internen Datenbestand des Projekts gesammelt und nicht veröffentlicht.
| |
| ** '''Eigenschaften''': ld:hasAPIId - Literal. Host.Id bei API Leipzig.
| |
| * '''ld:JuristischePerson''' - Namensschema ist noch festzulegen
| |
| ** 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.
| |
| * '''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]] ===
| |
| | |
| Verwendete Teil-Ontologien
| |
| * zak = ZAK-Namensraumpräfix
| |
| * cal = [http://www.kanzaki.com/docs/ical ical-Ontologie]
| |
| * xsd = [http://books.xmlschemata.org/relaxng/relax-CHP-19.html xsd Datentyp-Beschreibungen]
| |
| | |
| Beschreibung der Domänen und Prädikate:
| |
| * Alle Einträge haben die '''Literale''' rdf:about (req., single), rdfs:label, rdfs:comment
| |
| | |
| * '''ld:AlteAdresse''' mit Datenbasis Adressen.rdf- eine Post-Adresse (später durch eine geeignete Standard-Ontologie zu ersetzen)
| |
| ** Inhalts-Literale zak:behindertengerecht, zak:Empfaenger (nur wenn verschieden von rdf:label), zak:Erreichbarkeit (mehrfach), zak:Strasse, zak:PLZ, zak:Ort
| |
| ** Orga-Literale: zak:hasOEN_id, zak:hasUW_id
| |
| | |
| * '''zak:Bundle''' mit Datenbasis Orte.rdf - zentraler Einstiegspunkt, längerfristig existierendes Bündel von Angeboten, das meist an einen Ort gebunden ist
| |
| ** zak:contactPerson zak:Person - Ansprechpartner
| |
| ** zak:engagedPerson zak:Person - weitere mit dem Bündel verbundene Person
| |
| ** zak:hasAddress zak:Address - Adresse des Bündels (req.)
| |
| ** zak:hasSupplier zak:Supplier - Träger
| |
| ** zak:hasTag zak:Tag - Klassifizierung (Konsolidierung der literalen Werte von zak:Art und zak:Bereich)
| |
| ** zak:Langinformation zak:InfoRecord - Inforecord mit einer längeren (externen) Information zum Bündel im XHTML-Format
| |
| ** Orga-Literale zak:e-mail, zak:Fax, zak:hasURL, zak:Telefon
| |
| ** Inhalts-Literale (alle mehrfach möglich) zak:Art (obsolet), zak:Arbeitsformen, zak:Auszeichnungen (mehrfach), zak:Bereich (obsolet), zak:Finanzierung, zak:Hintergrund, zak:Kosten (mehrfach), zak:Kurzinformation (mehrfach), zak:Leistungsangebot (mehrfach), zak:Oeffnungszeiten (mehrfach), zak:Teilnahmebedingungen, zak:Zielgruppe, zak:Zielstellung
| |
| :Listen in der Leistungsbeschreibung MINT-Broschüre werden in Mehrfacheinträge umgewandelt.
| |
| | |
| * '''zak:Event''' (definiert in Events.rdf) - einzelne Events, weiter zu spezifizieren
| |
| ** zak:contactPerson zak:Person - Ansprechpartner für das Event
| |
| ** cal:description (war zak:eventdetail) Literal - kurze Beschreibung des Events
| |
| ** cal:location (war zak:ort) zak:Address - Adresse des Events
| |
| ** cal:organizer zak:Bundle oder zak:Traeger - Veranstalter des Events
| |
| *** hgg 5.7.2012: kein zak:Angebot mehr, to do: Schulbiologiezentrum zu Träger, Untereinheiten zu Bundle verschieben.
| |
| *** kann ggf. über E zak:zurReihe R; R zak:hasSupplier S inferiert werden.
| |
| ** zak:Ortzusatz Literal - genauere Bezeichnung innerhalb von cal:location
| |
| ** zak:zurReihe zak:Offer - Reihe des Events (Bug cal:zurReihe in den Daten gefixt - 5.7.2012. hgg)
| |
| ** Orga-Literale zak:hasOEN_id, zak:hasUW_id
| |
| ** Literale: zak:date (redundant), zak:hasURL, rdfs:label (war zak:titel), zak:untertitel, zak:Kosten
| |
| ** Literale: cal:dtstart, cal:dtend (xsd:date oder xsd:datetime)
| |
| | |
| * '''zak:Foerderung''' mit Namensmuster F.2011.<lfdNr> - Förderung lt. "Förderung Freie Träger 2011"
| |
| ** zak:beantragt xsd:float - beantragter Förderbetrag (In der Datenbasis zu fixen!)
| |
| ** zak:bewilligt xsd:float - bewilligter Förderbetrag (In der Datenbasis zu fixen!)
| |
| ** zak:forProject zak:Project - gefördertes Projekt
| |
| ** zak:zumLeistungsbereich zak:Leistungsbereich - Leistungsbereich lt. SGB VIII lt. "Förderung Freie Träger 2011"
| |
| ** zak:zumStadtbezirk zak:Stadtbezirk - Stadtbezirk lt. "Förderung Freie Träger 2011"
| |
| ** Literale: zak:hasLfdNr, zak:year
| |
| | |
| * '''zak:InfoRecord''' (definiert in Tags.rdf) - längerer externer Info-Record
| |
| ** zak:hasURL - Ressourcen-ID, Beschreibung des Zwecks unter rdfs:comment
| |
| | |
| * '''zak:Leistungsbereich''' mit Namensmuster L.<nr>.<Kuerzel> lt. Nomenklatur der Stadt - Leistungsbereich lt. SGB VIII lt. "Förderung Freie Träger 2011" (zu ergänzen)
| |
| | |
| * '''zak:Offer''' mit Datenbasis Angebote.rdf - Angebot eines Trägers aus einem Bündel oder wie auch immer
| |
| ** zak:contactPerson zak:Person - Ansprechpartner
| |
| ** zak:engagedPerson zak:Person - weitere mit dem Angebot verbundene Person
| |
| ** zak:hasAddress zak:Address - Adresse des Angebots
| |
| ** zak:hasSupplier zak:Supplier - Träger
| |
| ** zak:hasTag zak:Tag - Zurodnung des Angebots (Konsolidierung der literalen Werte von zak:Art und zak:Bereich)
| |
| ** zak:hasType zak:Type - Typ des Angebots (Konsolidierung der literalen Werte von zak:Art und zak:Bereich)
| |
| ** zak:relatedBundle zak:Bundle - Zuordnung zu Bündel
| |
| ** Orga-Literale zak:e-mail, zak:Fax, zak:hasUW_id, zak:hasURL, zak:Telefon
| |
| ** Inhalts-Literale (alle mehrfach möglich) zak:Art, zak:Arbeitsformen, zak:Auszeichnungen, zak:Bereich, zak:Finanzierung, zak:Hintergrund, zak:Kosten, zak:Kurzinformation, zak:Teilnahmebedingungen, zak:Zielgruppe, zak:Zielstellung
| |
| | |
| * '''zak:Person''' mit Datenbasis Personen.rdf (öffentlich) sowie PersonenIntern.rdf (intern, dort ggf. auch private Adressen)- eine real existierende Person
| |
| ** (intern) zak:hasAddress zak:Address - Adresse der Person
| |
| ** (intern) Literale: zak:Name, zak:Vorname, zak:Titel, zak:e-mail, zak:Fax, zak:hasURL, zak:Telefon
| |
| | |
| * '''zak:Program''' mit Namensmuster Prog.<name>
| |
| ** zak:hasURL - Ressourcen-ID, Verweis auf die Webseite des Programms
| |
| | |
| * '''zak:Project''' mit Namensmuster P.nr (nr = Lfd. Nummer aus "Förderung Freie Träger 2011")
| |
| ** zak:hasSupplierNumber - Vereinsnummer des Trägers lt. "Förderung Freie Träger 2011"
| |
| | |
| * '''zak:Property''' mit Namensmuster Property.<name> und Datenbasis Tags.rdf - Allgemeine Eigenschaft
| |
| | |
| * '''zak:Stadtbezirk''' mit Namensmuster SB.<name> lt. Nomenklatur der Stadt - Stadtbezirk oder "stadtweit"
| |
| | |
| * '''zak:Supplier''' mit Datenbasis Traeger.rdf - (juristischer) Träger eines Angebots oder Orts
| |
| ** zak:contactPerson zak:Person - Ansprechpartner
| |
| ** zak:engagedPerson zak:Person - weitere mit dem Träger verbundene Person
| |
| ** zak:hasAddress zak:Address - Adresse der Organisation
| |
| ** zak:hasSupplierNumber - Vereinsnummer lt. "Förderung Freie Träger 2011"
| |
| ** Literale: zak:e-mail, zak:Fax, zak:hasURL, zak:Hintergrund, zak:Kurzinformation, zak:Telefon
| |
| | |
| * '''zak:Tag''' mit Datenbasis Tags.rdf - Tag (Schlüsselwort), um Zuordnung eines Angebots oder Bündels zu klassifizieren.
| |
| | |
| * '''zak:Type''' mit Datenbasis Tags.rdf - Typ, um Angebote selbst zu klassifizieren.
| |
