LEO – Die Leipzig Ontology

Das Leipzig Data Projekt hat sich das Ziel gestellt, einen gewissen Grundstock an Referenzdaten und insbesondere URIs zu sammeln, mit denen sich Ereignisse und Aktiviäten in der Leipziger Stadtlandschaft referenzieren und damit beschreiben lassen. Mit Blick auf die geringen verfügbaren Ressourcen liegt der Schwerpunkt dabei auf Daten mit geringem Änderungsbedarf, die in unserem RDF Data Store vorgehalten werden.

Kern dieses Datenbestands sind aktuell Orte, Adressen und Geodaten, die zusammen ein System von White Pages bilden, mit denen Geolokalität auf einheitliche Weise referenzierbar (und damit auch aufeinander beziehbar) wird. Basis dieses Systems sind die aus dem API-Leipzig Projekt und damit letztlich von der Stadt Leipzig übernommenen und weiter aktualisierten über 65.000 Datensätze Adressdaten, von denen knapp 63.000 mit Geokoordinaten (Übernahme aus Nominatim mit anschließender weiterer Konsolidierung und Qualitätssicherung) versehen sind. Damit lassen sich Leipziger Orte an Geodaten binden und so auf Karten lokalisieren. Die höhere Qualität gegenüber eine reinen Referenzierung der Geokoordinaten etwa über die Google-API ergibt sich aus der vorgenommenen Disambiguierung, die etwa dem Unterschied zwischen der Verwendung von Rechneradressen und Rechnernamen entspricht, sowie der Möglichkeit, an diese Adress- oder Orts-URIs weitere Information zu binden.

Leipzig Data ist nicht das einzige Projekt mit diesem Anspruch. So kennt etwa API Leipzig ebenfalls eine größere Zahl von “Hosts” und “Venues” und OpenStreetMap taggt als “Ways” im Kartenmaterial präsente Gebäude mit Zusatzinformationen. Für Referenzzwecke ist es wichtig, hier entsprechende Übersetzungstabellen vorzuhalten und zu verwalten, was für API Leipzig mit den “API-References” und für OSM mit einem geonames:nearbyFeatures Verweis nach linkedgeodata.org erfolgt.

Diese White Pages werden vor allem im Leipzig Data Event Projekt fortgeschrieben.


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 Leipzig Data Initiative wenigstens für längerfristig persistente Datenbestände im Leipzig Data Seminar verhandelt.


Änderungen

Probleme

  • Das Adressverzeichnis ist nicht vollständig, es fehlt zum Beispiel die gesamte Georg-Schwarz-Straße.

Noch auszuführende Änderungen

  • Traeger.ttl nach org:Organization transformieren
    • 2014-06-21 Ausgeführt für die Bürgervereine und diese in extra RDF-Graphen Buergervereine.ttl ausgelagert

Vorgenommene Änderungen

  • ld:inOrtsteil aus API-Quellen extrahiert und in Adressen.ttl ergänzt (HGG – 20.07.2014)
    • gefixt 09.02.2015,
    • 07.03.2015: letzte 11 fehlenden Einträge ergänzt, OrtsteilZuAdressen.ttl damit obsolet und gelöscht
  • Adress-URIs einheitlich in die Form Data/<plz>.<ort>.<strasse>.<nr> gebracht, Straßenübersicht aus Adressen.ttl entfernt (HGG – 20.10.2013)
  • ld:hasMD5Sum für NEU-Events ergänzt.
  • ical:sentBy foaf:Agent ergänzt. foaf:Agent Instanzen bei Traeger.ttl ergänzt (HGG – 24.03.2013)
  • ld:relatedBundle hat als rdfs:range nun ld:Ort oder ld:Traeger (HGG – 17.03.2013)
  • ical:contact als Literal für Kontaktinformation
  • Jugendhilfe.ttl angelegt, dorthin die URIs der Planungsräume übertragen und die Koordinatoren nachgetragen (HGG – 14.03.2013)
  • Strassenverzeichnis.ttl aus Adressen.ttl extrahiert (HGG – 10.03.2013)
  • WeitereAdressen.ttl enthält nun nur Instanzen von ld:ExterneAdresse (HGG – 10.03.2013)
  • WeitereAdressen.ttl angelegt und Namensraum-Präfix Data/ExterneAdressen eingearbeitet (HGG – 25.02.2013)
  • Personen nach foaf transformiert (HGG – 14.02.2013)
  • 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)

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
  • Adressen:
    • weitere Literale ld:hasCity, ld:hasStreet bei ExterneAdressen
    • 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. Es gibt dabei zwei Ordnungsgesichtspunkte:

  • Es gibt Pakete mit Einträgen 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/Orte/ für das Paket und leipzig-data.de/Data/Ort/ als Namenspräfix für Instanzen von ld:Ort, die in Orte.ttl aufgelistet sind.
  • Es gibt Pakete, in denen Informationen aus einer Quelle zusammengefasst sind. Hier steht typischerweise die Frage einer weiteren Datenintegration in die Gesamtsammlung im Vordergrund – die Daten sind zunächst im RDF-Format erfasst, die weitere (auch schrittweise) Integration in Leipzig Data ist zu diskutieren.

Folgende Pakete sind aktuell im RDF Data Store verfügbar

  • AdministrativeGliederung.ttl – Instanzen von ld:Ortsteil (63), ld:Stadtbezirk (10), ld:Wahlkreis2014
  • Adressen.ttl – Instanzen von ld:Adresse
    • HGG 2015-02-09: Zuordnung zu Ortsteilen aus API-Leipzig erneut und diesmal korrekt übernommen.
    • HGG 2013-10-20: URIs nach einheitlichem neuen Konzept umgesetzt
    • HGG 2013-03-10: Externe Adressen sind in WeitereAdressen.ttl ausgelagert und gehören nun zu einer eigenen Klasse ld:ExterneAdresse.
  • Angebote.ttl – Instanzen von ld:Angebot – zu überarbeiten
  • 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
    • HGG 2015-02-09: Zuordnung APIId und StadtId für Stadtteile ergänzt.
  • Buergervereine.ttl – Instanzen von ld:Buergerverein < org:Organization.
    • ld:Person org:headOf ld:Buergerverein
    • ld:Buergerverein org:hasMember ld:Person
  • EEG_Stammdaten_2012.ttl – EEG-Anlagenstammdaten, zusammengetragen im Projekt Energie-13
  • Events.ttl – Instanzen von ld:Event. Verweildauer solcher Instanzen in den Daten bis 90 Tage nach Veranstaltungsdatum.
  • GeoDaten.ttl – Geo-Koordinaten (Initial von Claus Stadler über nominatim aus OSM extrahiert, weiter ergänzt und aktualisiert)
  • JH-Planungsraeume.ttl – Instanzen von ld:Planungsraum (Zuschnitt der 7 JH-Planungsräume)
    • ld:Planungsraum ld:containsOrtsteil ld:Ortsteil
  • MINTBroschuere2012.ttl – Instanzen von mint2012:Ortsbeschreibung (noch genauer aufzuarbeiten, Inhalt der beiden WTUV-Broschüren aus dem Jahr 2012)
  • Orte.ttl – Instanzen von ld:Ort
  • Projekte.ttl – Instanzen von ld:Projekt – zu überarbeiten
  • Personen.ttl – Instanzen von foaf:Person
  • Schulen.ttl – Schulen der Stadt Leipzig
  • Stadtbezirke.ttl – Instanzen von ld:Stadtbezirk und Zuordnung zu ld:Planung
  • Strassenverzeichnis.ttl – Instanzen von ld:Street
    • ld:Street ld:ld:hasStadtRef StadtID/Street.(Zahl) mit Zahl (fünfstellig mit führender 0) entsprechend der Straßennummer im städtischen Straßenverzeichnis
    • HGG 2014-07-20: StadtLeipzig-Referenzen.ttl wurde aufgelöst
  • Tags.ttl – Instanzen von ld:Tag
  • Traeger.ttl – Instanzen von ld:Traeger, sind nach org:Organization und foaf:Agent zu transformieren

Namensräume und Klassen

Orte, Angebote, Projekte und Events sind Aktivitäten verschiedener Dauerhaftigkeit (Ort > Angebot > Projekt > Event). Die Frage der genauen Abgrenzung ist noch zu spezifizieren.

Verwendete Teil-Ontologien

ld = leipzig-data.de/Data/Model/ – alle relevanten Modellbegriffe (Klassen, Prädikate)

Allgemeine Prädikate

  • owl:Thing rdfs:label Literal – Für Menschen verständliche Benennung. Wird vom Ontowiki in der Anzeige verwendet.
    • foaf:name rdfs:subPropertyOf rdfs:label
  • owl:Thing rdfs:comment Literal
  • owl:Thing ld:hasURL <URL>
  • owl:Thing ld:relatesTo owl:Thing – nicht weiter formal spezifizierte Zuordnung
  • ld:contactPerson foaf:Person – Ansprechpartner
    • rdfs:domain ld:Ort, ld:Angebot, ld:Projekt, ld:Traeger, ld:Event
  • ld:engagedPerson foaf:Person – weitere mit dem Angebot verbundene Person
    • rdfs:domain:ld:Ort, ld:Angebot, ld:Projekt, ld:Traeger
  • ld:hasAddress ld:Adresse oder ld:ExterneAdresse- Adresse des Angebots
    • rdfs:domain ld:Ort, ld:Angebot, ld:Projekt, ld:Traeger
  • ld:hasAddressAddendum Literal – Adresszusatz
    • rdfs:domain ld:Ort, ld:Angebot, ld:Projekt, ld:Traeger, ld:Event
  • ld:hasTag ld:Tag – Zuordnung des Angebots (Konsolidierung der literalen Werte von ld:Art und ld:Bereich)
    • rdfs:domain ld:Ort, ld:Angebot, ld:Projekt, ld:Traeger, ld:Event

Einzelne Klassen

  • ld:Adresse (definiert in Adressen.ttl) Adressen in der Stadt Leipzig – URIs haben die (neue seit 2013-10-20) Struktur Data/<plz>.Leipzig.<strasse>.<nummer> mit Postleitzahl plz, strasse und Hausnummer nummer (incl. ggf. Zusatz).
    • 2015-02-08: Gelegentlich werden Orte ohne eine solche Adresse (etwa die “Landauer Brücke”) einer nahe gelegenen Adresse zugeordnet, um deren Geo-Referenzierbarkeit für das Event-Projekt zu gewährleisten.
    • 2014-05-20: Wir diskutieren die semantische Bedeutung einer solchen Adresse. Hausnummern sind Grundstücken zugewiesen, diese können aus mehreren Flurstücken bestehen. Verschiedene Gebäude auf einem solchen Grundstück werden durch URIs bezeichnet, die die Grundstücksadresse als Namenspräfix haben (Aktuell noch nicht umgesetzt). Damit folgt unsere Bezeichnung der im Kataster.
    • In Anwendungen (etwa den Events) sind die standardisierten Adressen bis auf die Hausnummer aufgelöst. Weitere Informationen sind als Adresszusatz (ld:hasAddressAddendum) einzutragen.
    • 2014-04: Hausnummern wie “10-11” werden grundsätzlich auf die URI mit der kleinsten Hausnummer aus diesem Intervall gemapt, die im Adressverzeichnis der Stadt angegeben ist, um die Anzahl der URIs nicht zu sehr aufzublähen.
    • ld:inStreet ld:Strasse verweist auf eine Strassen-URI im Straßenverzeichnis Leipzig.
    • Literale ld:hasHouseNumber (Hausnummer, ggf. mit Zusatz), ld:hasPostCode (PLZ)
    • In GeoDaten.ttl sind den Adressen Geokoordinaten zugeordnet (geonames:nearbyFeatures <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: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 oder ld:Traeger – Zuordnung zu Ort oder Träger (in ld:relatedTo umzubenennen)
    • Orga-Literale ld:hasEmail, ld:hasFax, ld:hasTelefon (nach foaf: zu transformieren)
    • 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 als rdfs:range von ld:hasAPIRef in API-Referenzen.ttl sowie Events.ttl auf) – URIs haben die Struktur leipzig-data.de/Data/APILeipzig/<prefix>.<nr> und beziehen sich auf die interne Bezeichnung der Objekte bei API Leipzig
    • Venue.<nr> – Referenz auf einen Ort
    • Host.<nr> – Referenz auf eine Person
    • Event.<nr> – Referenz auf ein Event (in Events.ttl)
  • ld:Event (definiert in Events.ttl) – einzelne Events, weiter zu spezifizieren
    • ld:contactPerson foaf:Person – Ansprechpartner für das Event
    • ical:contact Literal – Kontaktinformation als String
    • ical:description Literal – Beschreibung des Events
    • ical:location ld:Ort – Ort, an dem das Events stattfindet
    • ld:hasAddressAddendum Literal – genauere Bezeichnung innerhalb von ical:location
    • ld:hasMD5Sum String – MD5-Summe über DTSTART, SUMMARY und DESCRIPTION eines von NEU übernommenen ical-Events, um dieses später zu identifizieren.
    • ical:summary Literal – kurze Beschreibung (max. 100 Zeichen) des Events
    • Literale: ical:dtstart, ical:dtend (xsd:date oder xsd:datetime)
    • ical:organizer ld:Ort oder ld:Traeger oder ld:NatuerlichePerson – Veranstalter des Events
    • ical:sentBy foaf:Agent – Quelle der Eventinformation
    • ld:hasTag ld:Tag – Tags für das Event
    • ld:zurReihe ld:Projekt oder ld:Angebot – Zuordnung zu einer Veranstaltungsreihe oder einem Angebot
    • Orga-Literale ld:hasAPIRef
    • Weitere Literale: ld:Kosten
  • ld:ExterneAdresse (definiert in WeitereAdressen.ttl) – URIs haben die Struktur Data/<plz>.<ort>.<strasse>.<nummer>. Prädikate wie ld:Adresse, nur
    • weitere Literale ld:hasStreet (ersetzt ld:inStreet), ld:hasCity
    • Q: Können Geokoordinaten aus ld:hasCity, ld:hasPostCode, rdfs:label inferiert werden
  • Geodaten
    • In GeoDaten.ttl sind den Adressen Geokoordinaten zugeordnet
    • geonames:nearbyFeatures <http://linkedgeodata.org/triplify/URI> – Bezug auf eine OSM-Referenz, deren Geokoordinaten ausgewertet wurden
    • geo:lat xsd:double; geo:long xsd:double
    • geosparql:asWKT “Point(long lat)” – ermöglicht die Speicherung mehrerer Geokoordinaten aus verschiedenen Quellen. Ohne diese Tupel-Bildung ist nicht klar, welche lat-long zusammengehören. Notation gehört zum GIS-Standard.
  • 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 foaf:Agent 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).
    • Einige Instanzen von foaf:Agent angelegt mit Namenspräfix Agent/ (HGG – 24.03.2013)
    • Abzubilden auf org:Organization und foaf:Agent
  • ld:Ort (definiert in Orte.ttl) – längerfristig existierendes Bündel von Angeboten, das meist an einen Ort gebunden ist
    • 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.
  • 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: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:hasSupplier ld:Traeger – Träger
    • ld:hasTag ld:Tag – Klassifizierung (Konsolidierung der literalen Werte von ld:Art und ld:Bereich)
    • ld:relatedBundle ld:Ort oder ld:Traeger – Zuordnung zu Ort oder Träger
    • 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 als rdfs:range von ld:hasStadtRef in StadtLeipzig-Referenzen.ttl auf) – URIs haben die Struktur leipzig-data.de/Data/StadtId/<prefix>.<nr>:
    • Street.<nr> – Nummer einer Straße im städtischen Stra0ßenverzeichnis (Quelle: API Leipzig)
    • Stadtbezirk.<nr> – Nummer eines Stadtbezirks im städtischen Ortsteilverzeichnis (Quelle: API Leipzig)
  • 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: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 foaf:Agent oder org:Organization umzubenennen, wenn Unterkategorien (siehe ld:JuristischePerson) eingearbeitet sind.
    • ld:hasSupplierNumber – Vereinsnummer lt. “Förderung Freie Träger 2011”
    • Literale: ld:hasEmail, ld:hasFax, ld:hasTelefon, ld:Hintergrund, ld:Kurzinformation