-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modeling Units of Values in NIDM-E #482
Comments
an alternative:
|
but more generally i think we should have label properties that have units and then use these properties with just values. as examples: https://github.com/incf-nidash/notebooks/blob/master/ttl_examples/fsterms.ttl#L23 https://github.com/incf-nidash/notebooks/blob/master/ttl_examples/fs_stats.ttl#L264 also for units, in bids, we are using (which is all ascii): https://people.csail.mit.edu/jaffer/MIXF/MIXF-10 @tgbugs knows of other efforts (from NIST) but their state seems to be a bit in flux. |
I did another check in on the state of things in Match as a follow up to our September 2018 exchange on the subject. Nothing much has changed as far as I can tell. My units parser is packaged, though I haven't fully managed to decouple it from the rest of my codebase yet. @dbkeator I am also working on a more useful python representation of the output format since at the moment it is just nested tuples. When I talked to Robert Stevens back in January I asked him about reasonable ways to represent units. His suggestion was more or less in line with both of the proposed formats. The primary issue though is that using iris for units has terrible composability and will prevent people from using anything but units that already have a url (getting new ids is nearly always a stumbling block in these cases). The approach that I use is to provide the units as a string with a specific datatype so that a parser that knows how to interpret that representation can convert into whatever internal representation it needs. """(param:unit-expr (/ (param:unit 'grams 'milli)
(/ (param:unit 'grams 'kilo)
(param:unit 'hours))))"""^^TEMP:protc:unit Basically I'd rather write a parser than try to mint uris for all possible unit expressions, but the scope of the problem I'm trying to solve may be larger. If you have a well understood and bounded set of units that you know will be used (and rarely extended, and definitely not extended by users) then the uri approach could work. With regard to the |
Update on this. I have most of native python representation for quantities working. It needs way more tests (just playing around for this comment has revealed a number of issues) but most of the basic operations on quantities with units are implemented as is direct export of quantities to an rdf representation. Implementing a I've split it into two files at the moment but I think I can safely merge them all back into the pyr file and still allow rdflib to be an optional dependency for those who don't need that functionality. An example. @prefix owl: <https://www.w3.org/2002/07/owl#> .
@prefix rdf: <https://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <https://www.w3.org/2000/01/rdf-schema#> .
@prefix unit: <https://uri.interlex.org/tgbugs/uris/readable/aspect/unit/> .
@prefix xsd: <https://www.w3.org/2001/XMLSchema#> .
### Axioms
[] a rdfs:Datatype ;
owl:onDatatype unit:weeks ;
owl:withRestrictions (
[ xsd:maxInclusive 14 ]
[ xsd:minInclusive 9 ] ) .
### Serialized using the pyontutils deterministic serializer v1.2.0 |
@tgbugs - very nice! will play with this as we build our tools. |
Thanks! In the mean time I did just enough implementation to understand that I didn't want to write a complete units system myself. The good news is that pint uses essentially the same approach that I was embarking on (and does a much better job of it). So the core python representation for the units is now pint plus a few helpers for things like ranges. My parser still goes in front since it has better coverage of the diversity of expressions encountered in the literature than the pint parser. I have subclassed pint's quantities and units to support export to rdf, json, and SI/NIST text formatting. Currently the python representation can be populated from my parser's s-expression ir or from a json representation. Populating from an rdf representation isn't implemented yet but I imagine the only hurdle will be figuring out the convention to use to mark subgraphs for conversion (e.g. owl:onDatatype being subClassOf some unit). One question about the representation of the units themselves. I am currently normalizing all quantities to be unprefixed (e.g. kg -> g, ms -> s) to normalize the graph representation to simplify engineering of the downstream search. There are a number of detractors to this approach around significant figures and loss of precision (among others), especially for the use case under discussion in this issue as well as for my protocols use case. The tradeoff seems to be that we would have to mint iris for every prefixed unit, or use a more complex graph representation for units. Do you think a more complex graphical representation is a viable solution to avoid having to mint tons of iris? |
This issue is to track the discussion on how to represent units in the data model. Background info is here:
General Discussion
OM - Ontology of units of Measure
UO - Units of Measurement Ontology (used with PATO)
In simplest terms, the question is whether to define datatype properties such that the units are embedded in the term (e.g., nidm:FOV_in_mm, essentially the standard CDE-type practice) or create qualified properties that include units in the qualification. Here is an example for an item called "item10245" and you want to record that it has a weight of 2.4kg. Then:
which, when written out fully is:
Note that here
exterms:weight
is a datatype property (and would often be written asexterms:hasWeight
The text was updated successfully, but these errors were encountered: