Advanced User Guide
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 allow you to define your own subClasses of QUDT classes.
In the Simple use case, we described a scenario where you create an instance of qudt:Quantity, naming it whatever you like. Let's consider the case where you have a variety of measurements or settings that you plan to support, and don't want to rely on just naming conventions to organize them (which is a good way to proceed!). In this scenario, we recommend you define your own subClasses of qudt:Quantity so that you can easily find them later with a query. Here are some examples:
In your schema file:
example-schema:ThermostatSetting
rdf:type owl:Class ;
rdfs:label "My thermostat settings" ;
rdfs:subClassOf qudt:Quantity ;
.
...and in your data file:
wiki-examples:DaytimeSummer2020
rdf:type example-schema:ThermostatSetting ;
qudt:hasQuantityKind quantitykind:Temperature ;
qudt:unit unit:DEG_F ;
qudt:value "68"^^qudt:valueUnion ;
rdfs:label "Daytime thermostat setting" ;
.
wiki-examples:NighttimeSummer2020
rdf:type example-schema:ThermostatSetting ;
qudt:hasQuantityKind quantitykind:Temperature ;
qudt:unit unit:DEG_F ;
qudt:value "62"^^qudt:valueUnion ;
rdfs:label "Nighttime thermostat setting" ;
.
In future queries, you could just look for instances of example-schema:ThermostatSetting to get all your thermostat settings, rather than instances of qudt:Quantity.
Moving forward one more level of complexity, you may notice that the above instances still identify what kind of thing is being quantified by means of the qudt:hasQuantityKind property, which is pointing to quantitykind:Temperature. 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. 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 ;
.
As in the previous example, you could 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 before, 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 example-schema:MeasuredTriplePoint ;
qudt:hasQuantityKind myQuantityKinds:TriplePointTemperature ;
rdfs:label "Propane triple point" ;
qudt:unit unit:DEG_C ;
qudt:value "-187.68" ;
.
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).
Now you can proceed to store instances of quantities that have values and units, as before.
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.