Einheiten (cm, kg...) in RDF

Formate & Standards
1

Wir bekommen im Rahmen von NFDI4Objects Daten mit Einheiten, die allerdings nur als Zeichenkette („cm“, „g“, „l“…) angegeben sind. Macht es Sinn, dass in RDF die Einheiten als RDF-Datatype anzugeben und wenn ja mit welchem Vokabular? Ich habe folgende Ontologien oder Vokabulare für Einheiten gefunden:

So richtig prächtig wird die RDF-Modellierung mit Einheiten erst wenn die SPARQL-Engine auch damit umgehen kann, d.h. in den Daten steht „5cm“ oder „10mm“ " und ich kann die Abfrage „0.05m“ verwenden. Bei Datumsangaben hat SPARQL ja spezielle Funktionen - funktioniert das irgendwie auch für andere Werte mit Einheiten z.B. über eine SPARQL-Erweiterung?

2 „Gefällt mir“
2

Nach bisherigem Feedback scheinen sowohl QUDT als auch UCUM verbreitet zu sein. UCUM ist nicht direkt RDF aber UM ist eine (inoffizielle) Ontologie dem UCUM-Modell. Daneben gibt es LINDT, was die Verwendung von Custom Datatypes for Quantity Values (CDT) propagiert und exprimentellen SPARQL-Support bietet.

Zusammengefasst gibt es drei Möglichkeiten, Werte mit Einheiten in RDF zu kodieren:

@prefix cdt: <https://w3id.org/cdt/>
@prefix om: <http://www.ontology-of-units-of-measure.org/resource/om-2/>

# 1. Wert und Datentyp
_:x my:weight "10"^om:kilogram . 

# 2. UCUM
_:x my:weight "10 kg"^^cdt:ucum .

# 3. Knoten mit Wert und Datentyp
_:x my:weight [
  my:value 10 ;
  my:unit om:kilogram 
] .

Letztere Variante wird übrigens CIDOC-CRM verwendet, ich gehe aber davon aus, dass in echten Daten aus der Praxis alle drei Varianten gemischt vorkommen, und sowieso vereinheitlicht werden müssen.

3

@nichtich ich kann sagen das UCUM auch im Rahmen von NFDI4Health genutzt werden soll. Hast du dich mit dem Thema seit August noch weiter beschäftigt? Dein Beitrag hier ist immerhin auf platz 1 bei Google wenn man ucum und rdf eingibt.

4

UCUM ist noch immer beste Wahl, aber da muss noch einiges aufgeräumt werden. So zähle ich mindestens drei Varianten, UCUM als SKOS-Vokabular auszudrücken:

Die erste ist mein Favorit, da der eindeutige Code (z.B. A) Teil der URI ist, aber diese Variante gibt es keine API, die Cocoda unterstützt (z.B. Skosmos oder zumindest Reconciliation API). Erst dann können wir beginnen, in Daten die wir bekommen, Einheiten mit UCUM abzugleichen.

1 „Gefällt mir“
5

Hast du mal versucht, das hier zu laden, um eine Reconciliation-Schnittstelle zu bekommen: https://reconcile-publish.skohub.io/ ? (Siehe auch Supporting the Reconciliation Service API for SKOS vocabularies .)

6

Hast du mal versucht, das hier zu laden, um eine Reconciliation-Schnittstelle zu bekommen […]

Das Problem ist nicht technischer Natur sondern zu klären, wer die API bereitstellt und für Updates sorgt, damit wir sie dauerhaft einbinden können. Ist zwar nur ein kleines Konvertierungsskript nach SKOS und ein cronjob aber auch den muss jemand einrichten und das möchte nicht ich sein. :grimacing:

1 „Gefällt mir“
7

Ok, verstehe. Es geht dir wahrscheinlich insbesondere um die Betreuung und nicht das einmalige Aufsetzen, oder? Ggf. könnte sowas ja auch bei KIM gemeinschaftlich gepflegt werden. Dann würden wir unter DINI AG KIM · GitHub ein Repo aufzsetzen und die Automatisierung mit GitHub Actions machen.

Wäre vielleicht eine Frage für die KIM-Sitzung beim KIM Workshop 2025 (Mannheim), ob es sinnvoll ist, neben statischer Vokabulare und Metadatenschemas/-profile auch manche APIs via KIM anzubieten und gemeinsam für einen dauerhaften und verlässlichen Betrieb zu sorgen…