qudt:unit versus qudt:hasUnit

[mitchellfaulk]

I recently noticed that qudt:unit has been designated as "deprecated" and is "replacedBy" qudt:hasUnit. I am confused about this choice for a few reasons.

1. According to the overview, in the last diagram, there is already an object property qudt:hasUnit, whose domain is qudt:SystemOfUnits and whose range is qudt:Unit. Whereas the object property qudt:unit originally had domain of qudt:QuantityValue or qudt:Quantifiable and range of qudt:Unit.
2. In point 1, the latter of these predicates seems functional to me: for each quantity value, there can be at most one qudt:Unit associated to it. On the other hand, the former predicate does not seem functional: a system of units may have many units associated with it.
3. To me it seems confusing to conflate these predicates that mean such different things into one. Moreover, I like the convention that the non-functional predicate is distinguished from the functional one by its prefix of "has", which suggests that this predicate may point to more than one entity. I may be wrong, but it seems to be to be a common convention to use "has" to denote non-functional predicates.

[steveraysteveray]

I understand your points, and it is true that our diagrams are getting a little out of date.

However, the OWL restriction classes, and the SHACL property shapes, enforce the distinct cardinality constraints when qudt:hasUnit is used by qudt:QuantityValue and qudt:Quantifiable, versus being used by a qudt:SystemOfUnits.

It's a valid position to want distinct property names for the two contexts, but it was causing problems with some users who were asking for qudt:hasQuantityKind and qudt:hasUnit naming consistency. Additionally, we don't maintain the population of any system of units pointing to all of its units. We do try to maintain the other direction using qudt:applicableSystem, so you get the same functionality by following the inverse path.