Skip to content

Advanced User Guide

steveraysteveray edited this page Jan 30, 2023 · 40 revisions

Contents

1. Integrating QUDT into your application

2. Customizing the QUDT ontology

3. Discussion of absolute and difference measurements

4. Computing applicable units for a QuantityKind

5. Using the SHACL schema instead of the OWL schema

1. Integrating QUDT into your application

The simplest way of using QUDT in an application was given in the Simple use case. In this section we will step through some increasingly complex examples that illustrate how to extend and customize the QUDT ontologies and vocabularies.

A. Extending the qudt:QuantityKind vocabulary

What if you are measuring or controlling some property that is not defined in the qudt:QuantityKind vocabulary? Or what if the qudt:QuantityKind is too general for your needs? This is where you might want to define your own quantity kinds. However, because qudt:QuantityKind is a class with many properties you might not want to deal with, there is a simpler class called qudt:UserQuantityKind. All you need to do is to create an instance of qudt:UserQuantityKind to meet your needs.

Here's an example. Perhaps the concept of the triple-point temperature is relevant and useful to you. Currently QUDT does not define such a quantity kind.

In your specialized vocabulary graph, you would define your specialized QuantityKind - call it TriplePointTemperature.

myQuantityKinds:TriplePointTemperature
  rdf:type qudt:UserQuantityKind ;
  qudt:hasQuantityKind quantitykind:Temperature ;
  rdfs:label "The triple point temperature for a given substance" ;
  skos:broader quantitykind:Temperature ;
.

The qudt:hasQuantityKind property allows your new quantity kind to be "plugged in" to the QUDT population, with the appropriate dimension vectors, etc. The skos:broader property further asserts that your new quantity kind is a specialization of quantitykind:Temperature (rather than, say, just your own alias).

You could also define your own Quantity subClass for your measurements - let's call it MeasuredTriplePoint. You will make instances of this class when you store measurements. (As in the Simple Use Case, you could just directly make instances of qudt:Quantity, but it might be harder to deal with them as a set that way).

mySchema:MeasuredTriplePoint
  rdf:type owl:Class ;
  rdfs:label "The set of triple point measurements" ;
  rdfs:subClassOf qudt:Quantity ;
.

...and in your measurement data graph, you store your measurements:

myMeasurements:TriplePoint_Propane
  rdf:type mySchema:MeasuredTriplePoint ;
  qudt:hasQuantityKind myQuantityKinds:TriplePointTemperature ;
  rdfs:label "Propane triple point" ;
  qudt:unit unit:DEG_C ;
  qudt:value "-187.68" ;
.

Triple point diagram Note that in this diagram, your own definitions are shown in orange, and the QUDT definitions are in blue. Classes are ovals, instances are rectangles.

2. Customizing the QUDT ontology

Some users have expressed a desire to tweak the behavior of the QUDT ontology. To support this, we have built an extension mechanism that works as follows:

  • The QUDT schema graph imports an extensions import graph (base URI http://qudt.org/2.1/schema/extensions/imports) located in the schema/extensions/imports.ttl file. In the normal release, this file does nothing.
  • In the same folder, there are additional files that modify the behavior of any QUDT classes by asserting additional triples. One such file is schema/extensions/skos.ttl (base URI http://qudt.org/2.1/schema/extensions/skos) that declares the qudt:Concept class to be an rdfs:subClassOf skos:Concept, plus other skos-related assertions.
  • To use any extensions in your own application, simply import the desired extension files into your local copy of imports.ttl.
  • If you would like to have any other extensions available to the broader community, please submit a pull request with your new extensions file in the extensions folder. Please choose an intuitive file name and base URI. You can use the skos.ttl file as a template.

3. Discussion of absolute and difference measurements

Please follow link

4. Computing applicable units for a QuantityKind

The core QUDT schema pattern shown in the Introductory User Guide shows the relation from a Unit instance to a QuantityKind instance using the qudt:hasQuantityKind property. But how do you find out all the units that are commonly used to measure a given QuantityKind? It would be unmanageable for every applicable Unit to point to every relevant QuantityKind. Instead, the QUDT ontology includes an algorithm (implemented in both OWL and SHACL) that calculates the applicable units for a quantity kind according to the algorithm below.

image

In the abbreviated view shown in the figure, the applicable units for Power are BTU/Hour and Watt, because both of those units point to the quantity kind Power via the qudt:hasQuantityKind relation. Moving down the skos hierarchy, the applicable units for Electrical Power are derived from those of Power, because no units explicitly reference Electrical Power. One step further down, Complex Power has only Volt-Amp as the applicable unit, and not BTU/Hour or Watt, because of step 2 of the algorithm described in the figure. Similarly, applicable units for Reactive Power are only Volt-Amp Reactive, while applicable units for Active Power are only Watt.

Please note that the figure is a simplified example. Indeed, if you, the reader, feel that an applicable unit is missing, please contact us by registering a GitHub Issue.

Using the above algorithm, the values for qudt:applicableUnit are inferred and asserted in the Quantity Kind graph.

The use of the applicableUnit property in a query is straightforward. Here's a simple example:

SELECT ?unit
WHERE {
quantitykind:ElectricPower qudt:applicableUnit ?unit.
}

On our EDG server, the applicableUnit values are displayed when viewing any QuantityKind.

5. Using the SHACL schema instead of the OWL schema

(Important note: As of the January 2023 Release, the default schema was switched to the SHACL graph instead of the OWL graph. This GitHub repository Facade file contains this change as of 2023-01-10)

One powerful aspect of the QUDT architecture is that you can use the vocabularies with either the OWL QUDT schema or with the SHACL QUDT schema. This is because the vocabularies are simply RDF graphs. If you want to use the OWL schema and not the SHACL schema for QUDT, you will need to change the import statement within schema/SCHEMA-FACADE_QUDT-v2.1.ttl (Graph URI is http://qudt.org/2.1/schema/facade/qudt) from

  owl:imports <http://qudt.org/2.1/schema/shacl/qudt> ;

to

  owl:imports <http://qudt.org/2.1/schema/qudt> ;

This file is part of the QUDT Release set, and can be found in the schema folder.

Once you have made this change, you are back to running in an OWL world.