'ThingsNotStrings' in RDF

Um google 'Things, not strings' von 2012 einmal aus anderer Perspektive zu betrachten: 

Warum werden in vielen Ontologien, wie z.B. gist, Elemente wie Adressen oder Adressbestandteile nicht als Strings, sondern als Objekte dargestellt.

Das zwingt uns, an diese Objekte wiederum Strings zu hängen. Wie unpraktisch. Ein Hop mehr, um an die druckbare Adresse zu kommen.

Ich wurde das schon oft gefragt, und erinnere mich gut daran, dass mich das bei meiner ersten Beschäftigung mit RDF auch irritiert hat.

Ich meine damit, dass statt 

@prefix ex: <http://example.org/exampleOnt/>.

ex:_HubertMayer ex:hasAddress "Mayerstr. 1, 99999 Mayerstedt" .	

etwas wie

@prefix ex: <http://example.org/exampleOnt> ,

ex:_HubertMayer ex:hasAdress ex:_HuberMayersAdressse .
ex:_HuberMayersAdresse ex:uniqueString "Mayerstr. 1, 99999 Mayerstedt" .

geschrieben wird.

Viele Beispiele zeigen die erste, einfachere Version, sowohl in Büchern über das Semantic Web, als auch auf Webseiten. Es ist einfacher zu verstehen - gerade für Neulinge, und es erlaubt es den Autoren, die Aufmerksamkeit der Leser auf einen anderen Punkt zu lenken, der an der Stelle demonstriert werden soll.

In der Praxis ist das aber oft eine weniger gute Art, Daten in RDF zu modellieren.

Denn Strings sind in RDF keine Things, d.h. ich kann über Daten, also Strings, Zahlen, Datumsangaben keine weiteren Aussagen machen. In RDF können wir nur über "Dinge" Aussagen tätigen, und das sind für RDF IRIs, nicht Daten.

Wenn wir also sagen wollen, dass diese Adresse Herrn Mayers Privatadresse ist, dann können wir das in der einfachen Form nicht ausdrücken. Wir müssen in dem Fall die Adresse als eigenes Objekt, mit eigener IRI modellieren:

@prefix ex: <http://example.org/exampleOnt> .

ex:_HubertMayer ex:hasAdress ex:_HuberMayersAdressse .
ex:_HuberMayersAdresse ex:uniqueString "Mayerstr. 1, 99999 Mayerstedt" .

ex:_HubertMayersAdresse ex:addressType ex:privatAdresse ;
  ex:validFrom "1999-01-01T09:00:00+01:00"^^xsd:dateTime .

Hier habe ich gleich noch angefügt, ab wann diese Adresse eine gültige Adresse für Herrn Mayer ist - auch das kann nützlich sein.

Meine naive Vergabe von ex:_HubertMayersAdresse in diesem Beispiel ist dann wieder dem Beispielcharacter dieses Textes geschuldet. In einem operativen Einsatz würde solch ein Name automatisch generiert, und wie er sinnvollerweise gestaltet wird kann ein eigenes Thema sein. Hier kann eine einfache UUID oder ULID vergeben werden, oder es wird tatsächlich eine sprechende IRI erzeugt, obwohl das aus meiner Sicht den Aufwand nicht wert ist. 

Übrigens: die Klassifirzierung ex:privatAdresse ist wieder ein eigenes Thema. Solch ein Ausdruck sollte Teil einer eigenen Taxonomie sein, außerhalb der Ontologie. Taxonomien werden oft schneller verändert als Ontologien, werden von anderen Leuten verwaltet und sollten deshalb auch getrennt gedacht werden. 

Dazu gibt es ein gutes Video von Dave McComb: "How Gist marries Ontologies & Taxonomies". Sehenswert.

Wir verwenden Cookies auf unser Webseite um die Benutzererfahrung zu verbessern.

Es werden keine Dienste zur Analyse Ihres Verhaltens genutzt, wir tracken sie nicht.