Remove variable unit in Entities (goods, consignment, constraint)

[bmeesters]

Type of request

• [ ] I'd like to add something to the OTM 5 spec
• [x] I'd like to change something in the OTM 5 spec

Is your feature request related to a problem? @BobZuidhoek proposed to add the temperature constraint in https://github.com/opentripmodel/otm5-change-requests/issues/37 together with the proposal to not use 'value-with-unit' but rather set the unit in the constraint itself. The obvious benefit would be that parties only have to do the conversion to the unit of the constraint instead of supporting multiple formats. The biggest downside would be that we would need to deprecate the current constraints that use it. Since there are some inconsistencies in the constraints (e.g. sizeConstraint has two unit fields) this might be a good time to fix it.

Describe the solution you'd like

• Create new constraints where the units are set. The value can be a decimal number so you can still go arbitrarily small.
• The old constraints are deprecated.

Specifially, this means adding:

• TemperatureCelsiusConstraint
• SpeedKMHConstraint (kilometer/hour)
• SizeConstraintInMeters with fields length, width and height
• WeightInKGConstraint

Also do the same thing for the measurements of goods and consignments

Describe alternatives you've considered Did you try to solve it with the current specification? If so, how? Please be as clear and concise as possible.

Alternatively we keep it as is and just ensure the value with unit is used consistently. We already talked about it and our preference is to go with this change since we think the uptake of constraints within OTM is fairly small yet and the benefits are pretty big.

Additional context Add any other context or screenshots about the feature request here.

[thomaskolmans]

Personally totally against this. While I understand the want for simplification it limits (international) adaptation. A simple converter of the ValueWithUnit does the job 9/10 times.

An example; what if you want to have the size constraints in millimetres? Could be the unit that is used and is more accurate. Now all of the sudden you'd have to use meters instead, which complicates it in the other direction.

Against this proposal.

[bmeesters]

I appreciate the feedback.

That said, I don't think this is a great example, going from meters to millimetres can still be done simply by doing multiplying or dividing by 1000. You don't lose any precision, and since OTM is meant for machines not humans I don't think the readability makes much of a difference. Whether you use millimetres or meters doesn't matter for expressiveness, since you express the same thing without any loss of information by setting the unit in this specific information.

The more choice you have the more chance that systems will actually not be able to communicate with each other without changing their implementation. For companies with good IT support these type of conversions will not be hard. However we would also like to increase adoption in parties that might have a lower IT budget.

In the end, I think this will simplify life and doesn't really impose limitations in expressing what you want, as long as you can do the conversion from your own unit to the chosen unit without any information loss. But if there are any examples where we will lose expressiveness that would be a problem. I currently do not have such examples, but if there are any that could indeed mean a no-go for this proposal.

edit: if you have any other examples on where you make use setting different units I would like to hear it.

[thomaskolmans]

Okay I understand that, what about systems that don't use the metric system as their basis? Should they then have to convert the units to the metric system when sending data? I understand that it simplifies life - for now - but my believe is that it limits the model quite significantly. The conversions have to be done either way, if they're needed, in this case the conversion is just happening in a different place.

Personally I see this as a limitation, beyond the above example, I can imagine that there will be plenty of examples where the units are just different and then have to be converted. It's a communication model, you want to communicate the data that is available.

For instance; within our system we've both got km/h and m/h as possible units. Yes these are easily converted, but why is that necessary? It just moves the complication - and I believe a model should communicate data as much "as is" without having to unit-convert before reading or sending. In this case we can now simply save this data "as is" and display it "as is". No need to look at units and we both support metric and imperial units, without having to convert twice.

[bmeesters]

I think the "as is" is a good point. In the end OTM5 is a data model first and foremost. That said, it was created to improve processes between communicating parties. So that makes this issue somewhat tricky.

For example: If party A uses decimetres, party B centimetres, and party C millimetres, then if all of them want to send messages to each other then each party needs to make two converters. Whereas if OTM5 enforces meters all of them would need only one conversion. Of course this is a bit of a silly example, but it does show that the amount of conversions quickly explode with when the amount of parties and units increase. Having the data as-is is nice, but it does result in more work.

Now, I admit, I am still on the fence on whether or not this is a good idea and actually was also opposed the first time it was brought to my attention. But I do see the appeal of avoiding ambiguities and removing the amount of converters that need to be created.

In any case, thanks for the feedback. Negative feedback is welcome as well. Let's see whether others want to chime in as well. It will not go silently through without any further discussion here.

[thomaskolmans]

For example: If party A uses decimetres, party B centimetres, and party C millimetres, then if all of them want to send messages to each other then each party needs to make two converters. Whereas if OTM5 enforces meters all of them would need only one conversion. Of course this is a bit of a silly example, but it does show that the amount of conversions quickly explode with when the amount of parties and units increase. Having the data as-is is nice, but it does result in more work.

In this scenario, yes! You can turn this around too however; think of 2 party's using mp/h now they both have to write converters in order to communicate.

Let me propose a solution, because I do see the need for avoiding ambiguities. A solution for that would work in my eyes is to have a suggestion like: "Always use the most logical denominator" with examples of sensor types and values for instance. It's one of the beautiful things about this models that it's able to handle so many things with so little - this would take a big part of that away in my eyes.

I'm always open to change my mind so I would like to see what others think on this one.

[BobZuidhoek]

Note that the imperial system is being phased out globally (slowly but steadily). The only countries still clinging onto it are the US and UK (UK is stuck in the middle). That's also for things like MPH. People from these countries will probably argue their system is best, but it's a losing battle. The metric system won, and rightfully so. They did win the most popular language contest though :-).

Maybe it's a sideline from this subject, but I think a new IT communication standard such as OTM should just ignore whatever is still going on in the imperial system. It makes it stronger to firmly choose 100% metric.

Then on topic and given the fact that I think the metric system is leading: I feel it's more optimal to hardcodedly put unit into the constraint. Within the metric system, all standard units are pretty clear (kmh for speed, kgs for weight, meters for length, celsius for temperature, etc).

[thomaskolmans]

While you're right about the metric system "winning"- it's in my opinion not an argument in regards to data-communication. We've got multiple units people are working with, so we should support it, regardless of opinion about the systems themselves. Unless the ambition is to only have OTM work for Europe, then sure, but for instance we're implementing in Pakistan and the US and spreading the news about OTM there too. Why limit that?

As we're working with a data-communication standard, I'd like to bring in another data standard where they had to tackle this issue: HL7 PHIR (mandatory in the EU). As you can see they've got the Quantity object (https://www.hl7.org/fhir/datatypes.html#quantity) - a unit is provided separately. And their CodeableConcept (https://www.hl7.org/fhir/datatypes.html#codeableconcept) also allows for the freedom of information unit exchange.

Look, if you would create an ideal world then I would fully support your argument. I however would argue for a system that communicates what the world is using, and it simply is not just 1 unit or system yet. So that is why I'm pleading so strongly for keeping it. If the conversions are a bottleneck, I'm happy to have my company contribute to an open-source converter module of some sort.

[bmeesters]

When @woutvandenheuvel, Menno Lambooy and me where discussing this we find it a difficult issue. On the one hand less conversions make things simpler and less likely to result in inconsistencies, typos, etc. On the other hand OTM is a data model and like Thomas said it would be nice if we can just communicate the data as-is. Also it is not that hard to do these conversions (and in a sense are not different than keeping a list of country codes, currencies, etc.).

To be honest, I personally am not completely satisfied with either, but we have to make a choice. For we now, we lean to keeping things as is (so have a variable unit that can be provided). There is no clear winner for either, but keeping things like before is the least disruptive.