ValueFlows release v.3

You are right, ISO’s closeness is a bad match for next-economy projects.
I found this as well, from the UCUM Organisation, with the Unified Code for Units of Measure:

The Unified Code for Units of Measure is inspired by and heavily based on ISO 2955-1983, ANSI X3.50-1986, and HL7’s extensions called “ISO+”

It seems they have done a decent effort to integrated many initiatives in some way. I can’t say anything about the quality, but it least this spec is open.

The UCUM is interesting, and skimming through, looks pretty complete, thanks. I also like the effort to use other initiatives.

I’m not sure where to take the unit of measure discussion right now. If we are going to change from QUDT, this would be a good time to do it, before the current round of projects using VF get too far. But I also think it is not a trivial task to do a reasonably thorough investigation, including understanding by whom the options are currently used. I don’t see that in my immediate future, unfortunately. Like I said elsewhere, I have started that a couple times, and haven’t been able to finish it due to other priorities. (Mikey of VF first suggested QUDT, and I don’t think there is much record of what investigation he did. My only experience with units is organizations setting up their own, so I would be more comfortable getting some actual experience with a standard.)

One way to do it is to keep the data structure as it is in QUDT, and just swapping in for unit:xxx as needed. But I’m open to whatever the group interested in units wants to do - OM has a different data structure, for example.

As a review of the requirements, here is what I see off the top of my head:

  • A reasonably complete list of units that includes common “business” related units in addition to scientific ones. And prefer to also include currencies, although we can add those too.
  • A related list of “kinds” or “categories” of units.
  • Conversion formulas between units.
  • Prefer to have linked open data source available.
  • Open spec. Preferably also an actively maintained spec.
  • Reasonably clear documentation. (QUDT is not so good on this one.)

If nobody sees it as a personal priority to pursue this, I’d suggest we just stick with QUDT for now, understanding we can swap in other unit sources into the base model later as needed. And understanding that we will do a review of this current smallish round of projects after they get some concrete practice, and may need to do some conversions if changes are needed to VF. Although I am very comfortable that the core model is solid, it would be very unrealistic to think that VF is perfect now. And I think that the next best step to making it better is to get some practice with a handful of new groups.

SPARQL could help here.

Well, I pinged the author of OM to see what their sense is and will loop back on Github if any changes seem worthwhile right now.

Boom! <3 @samrose

I don’t know that this means any immediate action on my part however, at least not until considering production readiness for HoloREA. @fosterlynn do you see it as part of maturity of VF0.3? Would just be good to know, in case that prompts anyone to take on the job. Basically what I would need is a JSON or YAML or GraphQL version (whatever really, so long as keys & values are apparent) that details what we should change the Unit and QuantityValue structs to.

Re. Unit and QUDT:

do you see it as part of maturity of VF0.3?

(Sorry, lost this question.) I don’t see Unit source as required for v.3. Of course it would be nice, if we have the time and can get enough knowledge to make a more informed decision. But this can be one of the handful of things which we will hope to understand better based on experience with this round of implementations.

And @samrose thanks for you help on this!

Putting this here even though it is the wrong title, doesn’t really warrant a new topic. We got a window of time from the implementing projects (including HoloREA thanks @pospi ) to investigate the QUDT issue, and decided to switch to OM for quantities/units. A really nice aspect of that is that the OM people are happy to talk to us and answer questions!

Between that and some improvements suggested by @yeff (thanks!) we decided to bump to another release, v.4. That is out now in https://valueflo.ws. Now we really are putting a pause on new releases, although we will do fixes of course.

Further to that, there’s now official releases of the ValueFlows GraphQL spec on NPM! :smiley:

1 Like

Thanks Lynn. That was a really nice simple introduction to REA. I’ve heard about it ever since I’ve been a part of the Holochain community, but not really understood it. This makes it easier to begin the learning process.

2 Likes