Fix Incomplete linkage between units and systems of units? #640
Comments
|
You are bringing up a topic that has long been on our list of things to clean up in QUDT. Thanks for this. Speaking personally, I would welcome at least a simple association (qudt:systemOfUnit) with the relevant system of units, for every unit that has such an association. Of course, some units are not referenced by any system of units at all, and thus would have no such relation. I am a bit confused by your units-associated-with-sou-si.txt file, which has three sections:
Is the first category for units that are implicitly AND explicitly associated with SI? Regardless, I'm wondering why something like unit:A-HR fits? So, again, from my personal perspective, I would suggest we proceed as follows:
We can then decide whether to expand the relations to the other relations (qudt:baseUnitOfSystem, qudt:derivedUnitOfSystem, etc.) or to expand the range to other systems first. I do believe that the linkage to the system of units is a powerful, and possibly unique, feature of QUDT. I would welcome input by others on this topic. |
|
The original intent of QUDT was to support all SOUs and all SOQs so we should fix things that are broken rather than any other option. For units and quantity kinds that aren’t associated with a known SOU or SOQ we should create an ‘other’ group do that we can have a consistent implementation.Jack Hodges, Ph.D.Arbor StudiosOn Feb 3, 2023, at 6:43 AM, steveraysteveray ***@***.***> wrote:
You are bringing up a topic that has long been on our list of things to clean up in QUDT. Thanks for this. Speaking personally, I would welcome at least a simple association (qudt:systemOfUnit) with the relevant system of units, for every unit that has such an association. Of course, some units are not referenced by any system of units at all, and thus would have no such relation.
I am a bit confused by your units-associated-with-sou-si.txt file, which has three sections:
implicitly assocated with sou:SI
explicitly assocated with sou:SI:
only implicitly assocated with sou:SI
Is the first category for units that are implicitly AND explicitly associated with SI? Regardless, I'm wondering why something like unit:A-HR fits?
So, again, from my personal perspective, I would suggest we proceed as follows:
agree on the criteria for inclusion, and make the definition of the relations clear
populate just qudt:baseUnitOfSystem for SI (your option 2)
We can then decide whether to expand the relations to the other relations (qudt:baseUnitOfSystem, qudt:derivedUnitOfSystem, etc.) or to expand the range to other systems first. I do believe that the linkage to the system of units is a powerful, and possibly unique, feature of QUDT.
I would welcome input by others on this topic.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Sorry for not having been entirely verbose about this. In short: implicitly OR explicitly associated with SI. The actual way to get there involves multiple preparation steps (determining factor units, scalingOf triples), then some additional triples are added that cannot be derived from the existing qudt data alone, like J consisting of factors N.m, or HR is a scaling of SEC (the latter is needed to determine that With that, the algorithm to check whether unit U is assocated with system S is as follows: |
|
Regarding identifying coherent units, I'd like to point out that not only does it depend on the system of units, but also on the context (in QUDT that means QuantityKind), as described in Wikipedia here: "the same coherent SI unit may be a base unit in one context, but a coherent derived unit in another. For example, the ampere is a base unit when it is a unit of electric current, but a coherent derived unit when it is a unit of magnetomotive force.[1]: 140" Thus, I suggest we stick with For your algorithm, I'm not confident about your steps 3 and 4, since we haven't nailed down exactly what is meant by qudt:isScalingOf. |
|
Sorry, meant to say stick with qudt:unitOfSystem. |
I know. I am not sure we should open that can of worms again. I actually was expecting this property to drop out of QUDT. |
|
Indeed, I'm on the verge of deprecating the qudt:isScalingOf relation. The last detail we are resolving is whether we need to create a "retirement home" for things we remove, and if so, whether it should contain just definitions, or also all the triples that contain a retired concept. So many questions... |
|
With that caveat out of the way, and just looking at the result, not the algorithm, do you see any false positives or false negatives in (or missing from) the suggested 'implicit' list? |
|
@fkleedorfer, in thinking about your notions of explicit and implicit associations with systems of units, it seems like these relations will not be very useful, since almost all units are related to SI units by a constant factor (qudt:conversionMultiplier). Therefore, all such units will be "associated" with sou:SI. Am I missing something? By the way, in reviewing coherent and derived units because of this issue, I have found 7 errors, which I will be fixing very soon! |
The conversion factor is not taken into account in the selection of the units implicitly associated with the SOU. Only those units are included whose factors are base units or have been determined to be implicitly associated already. None of the imperial units, for example, are thus found for SI, and vice versa ( I belive, I haven't checked formally, but the printouts looked that way). |
|
OK. In the end, here's what I think makes sense. If the other Board members agree, then we can proceed:
|
|
@fkleedorfer, we discussed this topic at the Board today, and we want to proceed with the top three bullets in my previous comment above. One question that came up regarding false positives is how we consider the "minute" (unit:MIN) and other units for time other than unit:SEC. According the Wikipedia, "although not an SI unit, the minute is accepted for use with SI units.[2]." So the question is whether we state I'm inclined to say no, since it is not an SI unit. But is that too strict? I'd be interested in your thoughts on this. Why did your algorithm decide unit:MIN is explicitly associated with SI? Secondly, given the system-dependent and contextual nature of whether a unit is considered coherent and/or derived, we intend to remove all those triples and replace them with the top property qudt:isUnitOfSystem alone. Thoughts? |
|
The time inits are found because i explicitly add them as scalings of sec: https://github.com/qudtlib/qudtlib-java/blob/main/qudtlib-data-gen/src/main/resources/triples-to-add-to-units.ttl For my use case, it's desirable to be able to determine units that are loosely permissible in an si or imperial context. I am not sure at this point if we need to include common time units like hour and minute in a construction industry context, but I think so. I added all time units for consistency. I'll ask the domain experts and get back to you. |
|
@fkleedorfer, any updates on this? I'd like to have QUDT move forward with just the qudt:isUnitOfSystem predicate and remove the other ambiguous predicates, but I think your algorithms will do the best job of choosing the correct units. |
|
Thanks for the nudge. The domain expert says, they would expect any scalings of second up to a week or maybe a month and year - although at that scale, obviously, it starts getting iffy because months have different lengths. I'd say there will probably have to be some edge case handling in any application using such time units, but having them available in an SI context would be a plus. |
|
Is there anything else you need from my side for you to move forward with this? |
|
... i.e, I could generate all the |
|
That would be perfect! Yes please. |
|
Ok here are 2949 triples: unit-sou.txt - actually a ttl file |
|
this is based on the 2.1.25 release, to which I add many triples, including these qudt:isScalingOf ones: ... in case you are wondering how some of these results are possible. |
|
I think this is a great start, and have created PR #653 to include your isUnitOfSystem triples. Thanks so much. I will give my colleagues a chance to review, of course, before merging. My understanding of your approach is to err on the side of inclusiveness for units like GM and HR being part of SI, and KiloGM and HR being part of CGS. I agree with this. |
|
There are still tweaks, of course. For example, I notice that the only time units associated with sou:IMPERIAL are
...but no SEC (or any other time units). But I feel this is still great progress. |
|
oh. thanks, will check! |
|
In that particular case, these 4 units are explicitly associated with the Imperial in QUDT. |
|
next attempt: unit-sou2.txt |
|
2 changes:
that explains how now, we have ~3670 new triples up from 2950 or so |
|
Great! I have updated the PR. |
|
@fkleedorfer, I just tried the following query and see that we still have some work to do: |
|
For the record, here is the resultof that query (adding a sort) on my current data. |
|
There are multiple things here that need to be done, I believe. |
|
I just tried to tweak the algorithm to associate a unit with a system, if at least one of its factor units is associated with it, and none of the remaining factors is associated with another system, but that generates too many associations, I think. We have to sort things out more manually. |
|
I agree with the direction you are going, to which I would add:
Let's see what others think, and then we can execute. |
|
After discussion by the Board, we have agreed to proceed, with a few adjustments:
Results so far are in PR #656 |
I want to be able to differentiate between systems of units, to allow for removing units from selection lists that do not make sense in an SI or Imperial context.
Looking at the vocabulary, there seems to have been the impetus to make these connections for units in general, but the actuall links from units to systems of units are quite sparse.
As I have access to all factor units (and scalings) for each unit, I can do the recursive calculation and determine if all basic factors are in the same system of units. Determining whether a unit can be linked to a system of units this way, I will call 'implicit'.
Some units are associated with systems of units using a
qudt:property. I obtain them via this SPARQL snippet (because I don't want to use inference at this point):The links thus discovered I will call 'explicit'.
The attached file units-associated-with-sou-si.txt shows which units are explicitly and implicitly linked to
sou:SI, and which ones are only implicitly linked and thus could be called 'missing links'.Note that the file also contains the units I generate as factor units (see #638), which may not be of interest to this project. However, the amount of legitimate SI units not explicitly assocated with
sou:SIsuggests one of three decisions:For option 2., I can probably make a PR, but we'd have to talk about the concrete property to use in which case.
If option 1 is the better choice for this project, that's fine with me
The text was updated successfully, but these errors were encountered: