Range for schema:unitText

[siuc-nate]

In CTDL, the range of https://credreg.net/ctdl/terms/unitText is ceterms:CredentialAlignmentObject.
In QData, the range of https://credreg.net/qdata/terms/unitText is skos:Concept.

This mismatch could be a problem at some point. We should fix it before we run into that point.

@mparsons-ce Do we have any data in the system that uses this property in either schema?

Semi-related: #903

[siuc-nate]

Additional twist:
https://schema.org/QuantitativeValue has both

• https://schema.org/unitCode for when there is something to reference and
• https://schema.org/unitText for when there isn't.

We seem to be using unitText to reference something, either directly or indirectly.

There's also the matter of something very common like https://schema.org/currency which is currently only a property of https://schema.org/MonetaryAmount, but it seems silly to have an entire class for that when https://schema.org/QuantitativeValue should be equally capable of handling amounts/percentages/ranges of money in addition to other kinds of amounts.

[philbarker]

Yeah, we seem to have unitText when unitCode would make more sense given a wider view. Would keeping unitText as Alignment Object and adding unitCode as Concept be at all feasible? Rationale: the alignment object lets you "contextualise" the text value better than a skos:Concept does. Also, backward compatibility.

Don't worry about Schema.org, everyone involved acknowledges that as it has grown and evolved it has acquired some oddities, but that hasn't stopped it becoming the most widely used linked data vocabulary. FWIW I think money is important enough to get its own treatment -- the real oddity is that there is https://schema.org/PriceSpecification with priceCurrency as well as the MonetaryAmount with currency.

[siuc-nate]

My additional argument for using QuantitativeValue (or well, maybe ceterms:ValueProfile instead?) for money in addition to everything else is that it gives us one class for all kinds of values, so that the range of QData properties (namely those in DataProfile) can always be that one single kind of class regardless of what kind of amount is being described. Given that a lot of the things we describe in QData have something to do with money, but not always, then it seems like you would get more benefit out of having that kind of flexibility.