Support units in Table Schema

[rufuspollock]

Move the units draft spec http://specs.okfnlabs.org/units/ back to FD specs

/cc @pwalsh

[pwalsh]

@rufuspollock before we move it here, it would be good to discuss how it is to be implemented. Is the proposal to implement this spec, as is, as part of Table Schema?

[rufuspollock]

@pwalsh open to suggestions. I was thinking of keeping it separate but adding support for referencing it from table schema but not sure what is best.

[Stephen-Gates]

I've drafted a pattern #607 and started a discussion on the forum https://discuss.okfn.org/t/table-schema-units-pattern/6573

[rufuspollock]

Notes from thread in the PR #607

@Stephen-Gates wrote:

@rufuspollock I put this up to stimulate conversation. I guess we need to resolve if we adopt the suggestion on the forum about using an existing specification UCUM, ISO 80000, BIPM.

@rufuspollock wrote back

@Stephen-Gates have you looked at any of those specs in detail? UCUM seems pretty heavy duty - is there a subset of that we could adopt / summarize?

We really just want something relatively simple that fits the 80/20 rule ...

Re ISO 80000 - is that open? If not that would be an issue for us ...

The BIPM stuff looks good though very physically oriented and fundamental.

/cc @dr-shorthair

@dr-shorthair wrote

UCUM may look heavy duty (though I don't think it is, really). But it provides an approach to build any unit-of-measure-symbol from the atomic elements.

This gets over the problem that any static set will come up short. A static list might look like 80-20, but what do you say to the people that need one of the 20 (which is still a lot of applications!).

[rufuspollock]

@Stephen-Gates (/cc @dr-shorthair) I think our aim is to see if we can extract a subset of UCUM that gives us 80/20 and then say if you want more go to UCUM.

I have to say i think this could / should go in 2 stages:

1. Move the spec back here (as it is - even if flawed)
2. Then start upgrading it ... (this can be a new issue ...)

This keeps things clean. wdyt? And if so would that mean we could merge #607 as it is?

[rufuspollock]

@Stephen-Gates any luck here on progressing this?

[Stephen-Gates]

Sorry been focussed a new release of Data Curator. Haven’t forgotten

[lwinfree]

Hi @Stephen-Gates (and also @rufuspollock + @pwalsh)! I wanted to let you know that @mbomhoff from Planet Microbe has been working with data packages for their oceanographic data and has been thinking about what units specs would work best for them. I wanted to tag Matt so he can keep updated on the specs units conversation, and also intro y'all in case you want to connect and discuss what units ideas Matt has. Thanks both 😄

[mbomhoff]

@lwinfree Thanks Lilly! Our data packages are in https://github.com/hurwitzlab/planet-microbe-datapackages. For the time being we added a custom property unitRdfType.

[Stephen-Gates]

@mbomhoff are you ok with the direction the draft PR was taking if we address the comments above?

[Stephen-Gates]

@rufuspollock do you have any concerns about using UCUM given its licence?

[dr-shorthair]

Item 2. in the license is problematic:

Users shall not modify the Licensed Materials and may not distribute modified versions of the UCUM table (regardless of format) or UCUM Specification. Users shall not modify any existing contents, fields, description, or comments of the Licensed Materials, and may not add any new contents to it.

Unfortunately UCUM now appears to be an infrastructure orphan - I've not been able to make contact with Guenther Schadow for a couple of years now. Possibly retired. I'll try again.