Evaluate integrating QUDT

[zazuko]

Evaluate integrating QUDT

[steveraysteveray]

Hi, Steve here. I'm currently working on QUDT, and am happy to discuss.

are there clashes between the two versions?
There shouldn't be. However, we are currently in the process of upgrading how we handle dimension vectors. We will keep the existing data in place, but will be transitioning to a numerator vector and a denominator vector, rather than just a single vector. This is so that we can properly handle dimensionless quantity kinds (e.g. relative humidity). This will allow constraints so that one doesn't try to combine dimensionless values that are not commensurate.

why are they split among files even though there seems to be only one namespace used?
This was simply a pragmatic way of staying organized, as well as allow multiple people to stay out of each other's way.

what namespaces & files should be sourced?
This depends on what you are trying to do, whether your application is embedded, whether it is specialized or general purpose, etc. More discussion is needed here.

[VladimirAlexiev]

@ktk We use QUDT extensively in the BigDataGrapes EU project. See https://rawgit.com/BigDataGrapes-EU/ontology/master/QUDT-notes/README.html for some explanations and diagrams.

Even though QUDT2 has some incomplete areas, it subsumes QUDT1.1 so there's no need to present QUDT1.1.
The two are not compatible, see https://rawgit.com/BigDataGrapes-EU/ontology/master/QUDT-notes/README.html#Incompatibility.

@steveraysteveray I understand what you mean by numerator vs denominator. I think it may be useful not just to distinguish dimensionless units, but also to distinguish some customary dimensioned units from the respective standard unit. Eg see this example https://rawgit.com/BigDataGrapes-EU/ontology/master/QUDT-notes/README.html#gram_per_liter: even though gram-per-liter has the same dimensions as kilogram-per-cubic-meter and identity conversion factor 1.0, it's a different unit.

[ktk]

Hi Steve, great to talk to you.

Let me explain a bit what we work on and why we are interested in QUDT:

This repository rdf-vocabularies is mainly sourcing existing RDF vocabularies. It also provides some integration into JavaScript/node.js as we work in this stack for large parts. But we also use the sourced vocabularies in other code, for example Java. The purpose is to make it simpler to provide things like auto-completion in tooling like IDEs. Some vocabularies are not easy to dereference so it simplifies the process for developers that want to provide vocabulary based features.

An example usage is this service which we are finishing right now. You can search for an existing term and it will give a simple but easily readable definition in RDF.

I would like to integrate QUDT as I think it is extremely useful but at the moment IMO very hard to browse. With the search-feature provided on prefix.zazuko.com it should be easy to find the right quantities and units. We plan to use them for publishing RDF data cubes from Swiss government agencies for example.

So based on your feedback I would:

• integrate the already available QUDT release 2 files
• the additional vocabs mentioned that are used to describe them
• and, if it makes sense in your opinion, also V1.1

Not really related to this question but one remark regarding QUDT: It's been a while that I last tried using them but I found it very hard to understand how I would use them in real world examples. Did I miss docs that give an idea of how to use it?

[steveraysteveray]

Adrian,
Everything that is in Release 1.1 is also in Release 2, so no need to integrate 1.1.
The prefix.zazuko.com service is interesting. For that, you might be able to get away with just the unit vocabularies to start. We're currently working on preparing the quantity kind vocabularies (think "Pressure", "Torque", "MassFlowRate", etc.) that are associated with the units - we're scrubbing them to eliminate duplicates, ensure consistent names, etc.
Once that is published, you would be able to list all units for a given quantity kind, for example.

Your last question is a good one. There are some examples, such as finding all commensurate units (i.e. having the same dimensionality), or just doing unit conversions, that are documented in "Semantic Web for the Working Ontologist" by Allemang and Hendler. A third edition will be coming out soon that works with Release 2. Nevertheless, we should definitely document some additional examples. I'll add it to our "to do" list!

[ktk]

Great thanks Steve, I will keep this issue up to date with my progress.

I will have a look at Semantic Web for the Working Ontologist, bought this long time ago. I did not know they have some samples, thanks for the hint!

[ktk]

Would you mind checking out this commit @steveraysteveray. That's the proposal for the files sourced for the moment.

[vhf]

Published https://www.npmjs.com/package/@zazuko/rdf-vocabularies/v/2019.6.27

[ktk]

I think we have to refactor this one again. I find the following prefixes mentioned in these Turtle files:

@prefix dimension: <http://qudt.org/vocab/dimension/> .
@prefix quantitykind: <http://qudt.org/vocab/quantitykind/> .
@prefix qudt: <http://qudt.org/schema/qudt/> .
@prefix qudtv: <http://qudt.org/vocab/qudt/> .
@prefix voag: <http://voag.linkedmodel.org/schema/voag#> .
@prefix unit: <http://qudt.org/vocab/unit/> .

(I deleted the ones that are not a problem)

qudt seems fine, qudtv is probably wrongly assigned. First I thought this is all unit but then again the URIs in the files point to http://qudt.org/2.0/vocab/unit/ which has 2.0 in it unlike the one specified in the prefixes.

I guess quantitykind would come as soon as you release the files as mentioned earlier in this thread.

Then I would still miss:

• qudtv
• voag
• dimension

Could you check that and point to the right files for the wrongly and/or missing prefixes @steveraysteveray

[steveraysteveray]

Let me look into these. Right away, I agree that the qudtv prefix is wrong, and we don't use it. I will remove it from the one file (VOCAB_QUDT-UNITS-MATHEMATICS-v2.0.ttl) where it occurs.

I'm currently working on automating the generation of non-versioned URIs that will resolve to the latest published version. Unit vocabularies should be complete today.

For the others, I'll need to go back and check.

[ktk]

@steveraysteveray ok thanks let me know when the new URIs are generated so I would change qudtv to unit in the unversioned prefix.

[steveraysteveray]

Here's an update:
qudtv has been removed as a prefix. Originally we were going to use that for all our vocabularies, but have since decided to break it down into unit:, quantitykind:, dimension, etc.

Of course, simply defining a prefix should be harmless. The qudtv and the dimension prefixes were both defined, but never used. dimension was defined for our future use, when we publish the dimension vectors for all the quantity kinds.

Your question on voag is different, though, because we do use various voag properties. The voag schema is documented at http://linkedmodel.org/, both the schema and the software licenses. I'm afraid the http://voag.linkedmodel.org/schema/voag# URI does not resolve, but for now you could have the prefix point to http://voag.linkedmodel.org/2.0/schema/SCHEMA_voag-v2.0.ttl.

Finally, all the unit vocabularies now resolve, such as http://qudt.org/vocab/unit/mechanics, without a version number. It will always point to the latest version. We still need to make the individual unit definitions resolve as well.

[ktk]

Excellent Steve, thanks! I will update everything and see if I have/understand everything now. Thanks for voag override, that is supported in our fetch method. It's not the only vocabulary out there that does not resolve properly ;)

[ktk]

@steveraysteveray I'm still confused by unit, see Victors pull request here.

I'm confused by the correct namespace to use:

• prefix.cc says http://qudt.org/vocab/unit#
• V1.1 Turtle says @prefix unit: <http://qudt.org/vocab/unit#> .
• However, the website that points to it says Base URI for unit is http://qudt.org/1.1/vocab/unit
• And in the files Victor sourced in his pull request unit points to http://qudt.org/vocab/unit/(with no # at the end): @prefix unit: <http://qudt.org/vocab/unit/> .

So what would be correct?

[VladimirAlexiev]

http://qudt.org/vocab/unit/ should be correct, because it doesn't have a version, and because trailing slash (not hash) is recommended for large collections of resources.

[ktk]

@VladimirAlexiev I agree with slash vs hash but I doubt that's what was used so far.

[steveraysteveray]

I’m traveling for 2 weeks, so may not be able to get to this right away. Apologies.

[ktk]

No worries, have a good trip!

[ktk]

@steveraysteveray any chance for an update? :)

[steveraysteveray]

We have been busy refactoring our units, quantitykinds and dimension vectors, and will be publishing the results as release 2.1. You can get a sneak peak at http://www.qudt.org/2.1/catalog/qudt-catalog.html, but be aware that some of the new filenames and prefixes are still in flux for just a bit longer. What you will see is that all the units are now in a single graph. Same for all the quantity kinds. I'm currently working on consolidating all the dimension vectors.

[ktk]

@steveraysteveray been a while, what is the status? Is this stable meanwhile? I would really like to integrate that in our lookup service.

[steveraysteveray]

@ktk, Release 2.1 is stable. We have several new features in development, which will be compatible additions. In the case of any incompatible upgrade, we will keep 2.1 available and release a new version number. Please see qudt.org for the latest.

[ktk]

@vhf could you integrate the following URIs with according prefixes: https://gitlab.ldbar.ch/pipelines/lindas-metadata/-/blob/master/config.sh#L7-14

That's the ones we source for the cube-curator for BAFU.