Advanced User Guide
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
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.
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" ;
.
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.
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.
Please follow link
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.
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 derived from Complex Power.
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.
If you want to use the SHACL schema and not the OWL schema for QUDT, you will need to modify the graph URI for the SHACL graph from
http://qudt.org/2.1/schema/shacl/qudt
to
http://qudt.org/2.1/schema/qudt
...in the file SCHEMA_QUDT_NoOWL-v2.1.7.ttl
This is needed because all the vocabulary graphs import this URI. Depending on your environment, if it is not found, your IDE may go off to the web to find it, and it is out there as an OWL schema. Of course, you should NOT have the OWL schema in your environment either.