Remove all minCardinality 0 axioms

[rjyounes]

Currently there is one on ProductUnit. There may be others.

I propose that these hints belong either in domain-specific SHACL or in a domainIncludes annotation on the property.

[rjyounes]

There is only one min 0 (ProductUnit). We'll delete this and add a scopeNote.

Policy moving forward needs to be defined. Possibilities are:

• Use a scopeNote; since min 0 has no inferencing power a scopeNote is equivalent. Use SHACL for data validation if needed.
• Continue to use min 0.

Jamie: it's useful because we don't have SHACL for gist.

Issue #620 created to develop this policy.

[uscholdm]

I recommend that as a policy we do what we do for inverse properties. As a general rule, do not use min 0. If special cases arise when we think it is justified, the so be it. I don't think this will arise but once or twice for the rest of my career :-)

[rjyounes]

@uscholdm @marksem @JessSing @pwin Now that I'm looking at the PR, I'm wondering why we don't make this a cardinality of 1. The OWA allows us to require it even if not asserted, and surely it is required.

My other question is whether it should be a standardConversionFactor or a baseConversionFactor. As I understand it (I could be wrong, the definitions provide no help - another issue) baseConversionFactor is used for simple units of measure and standardConversionFactor for non-simple ones like area and volume. According to NIST, "The SI unit of area is the square meter (m2), which is a derived unit." See also the distinction between base and derived units at https://physics.nist.gov/cuu/Units/units.html. This is also what I understand from our definition of hasStandardUnit: "For a complex unit refers to a unit that has all the component parts in SI."

[wslooney]

A few questions/comments:

1. I'm very very puzzled by the distinction between standardConversionFactor and baseConversionFactor. Rebecca's understanding does make sense of why standardConversionFactor is a subproperty of baseConversionFactor, but the definition of standardConversionFactor mentions "Rankine" which, while derived, is still simple (i.e., it's not a product or ratio or power of other units). But even standardConversionFactor is supposed to apply to things like square meters or cubic meters, I'm curious when is that distinction important? The conversion from cubic feet to cubic meters and the conversion from feet to meters are both simple ratios. What value is added from having a subproperty?

2. Whatever we decide to do with conversion factors on productUnit, we should probably also do with ratioUnit. My understanding is that they're basically the same except instead of having a multiplicand and multiplier you have a numerator and denominator. The need (or lack of) for a requirement for a conversion factor should be the same.

3. I agree with Rebecca that we should use cardinality of 1 for conversion factor. The whole point of the standard units is that there's only one of them for each kind of magnitude, so there's exactly one conversion factor.

[rjyounes]

@wslooney: @uscholdm and I just discussed this. We agreed on the following:

• baseConversionFactor is a subproperty of standardConversionFactor (we got this right in making hasBaseUnit a subproperty of hasStandardUnit, interestingly enough).
• The class UnitOfMeasure should have cardinality restrictions of 1 for both standardConversionFactor and hasStandardUnit.

NB The distinction between base and standard is an industry-standard, as in the NIST documents I pointed to.

We will go ahead with the removal of the minCardinality 0 restriction in PR #621 just to keep these issues separate. I'll make a new issue for these other changes.

[wslooney]

I understand the distinction between hasBaseUnit hasStandardUnit. My question is specific to the conversion factors. Is it an industry standard to parse conversion factors in this way? I couldn't find anything online that suggested it was. I'm happy to accept that it is. I just want to ask the question.

[wslooney]

More explicit suggestion (after discussion on 2/4/22):

We don't need gist:baseConversionFactor as a subproperty of gist:standardConversionFactor. The distinction between Base Units and and Standard Units is already captured elsewhere in the ontology, and nothing is gained by additionally capturing it here. Having just one property gist:conversionFactor reduces the complexity of gist.

[rjyounes]

Copied comment to #624 as this is where the discussion will continue.