LD.LEO: Unterschied zwischen den Versionen
HGG (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
HGG (Diskussion | Beiträge) (→URIs) |
||
Zeile 12: | Zeile 12: | ||
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. | 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 | :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. | Alle Modellbegriffe haben Bezeichner aus dem Paket ''Data'', Objektinstanz-Bezeichner verteilen sich auf verschiedene paketspezifische Namensräume. | ||
=== Pakete === | === Pakete === |
Version vom 15. November 2012, 17:04 Uhr
Home > Leipzig Open Data und LD.Datenprojekt
LEO - Leipziger Ontologie
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 Leipzig Data Aktivität wenigstens für längerfristig persistente Datenbestände auf der apileipzig Liste zügig weiter vorangetrieben werden.
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.
Namensräume:
- ld: leipzig-data.de/Data/Model/ - alle relevanten Modellbegriffe (Klassen, Prädikate)
- lda: leipzig-data.de/Data/Adressen/ - Adressen und administrative Einteilung in Leipzig
Klassen
- ld:Adresse - URIs haben typischerwise die Struktur plz.strasse_nummer, eine feinere Unterscheidung von Lokationsinformationen unter einer solchen Adresse erfolgt durch das Prädikat ld:hatAdressZusatz.
- ld:Person - URIs haben typischerwise die Struktur Nachname_Vorname nach fixID-Umwandlung