[emft-dev] Re: UOMo measurement and EMF

[Miles Parker <milesparker@xxxxxxxxx>]

Hi Grahame,

[I'm going to stop cc'ing EMFT after this..if folks want to follow along, please sub to AMP dev or just reply to Grahame and myself.]

I have a sense that I'm making some assumptions about the design and even scope of UOMo that I shouldn't be. Perhaps a usage example would be of help.

On Jul 5, 2010, at 4:46 PM, Grahame Grieve wrote:

> Hi Miles
> 
> 
>> Imagine I'm designing a model for an inventory system interfacing with CAD/CAM. I could define a BOM with an item that specifies a material that needs specific dimensions. Depending on how UOMo is designed I could a) define an attribute "dimensions" of type say VolumeCubicMeters or b) much better of type Volume and allow implementors to create an entry in any kind of measurement they wanted. Regardless of how I chose to represent or edit the values I would be confident that they could be safely and consistently translated into any measurement context. Which is again really a tremendously useful and reassuring thing to have *especially* if it can be done in a relatively light-weight way.
> 
> BOM = business object model?

Bill of Materials..but it's just an example.
> 
> I'm trying to get my head around this. In my current implementations,
> I define my object models to have a string field for units (since UCUM
> units are inherently human readable), and in the definition of the
> field I provide a canonical units for the field. Then, my object
> validation code checks that the provided unit can be converted to the
> canonical unit. This also makes for easy serialization / storage

So the units themselves aren't classes?

It seems to me that there are two (three?) main issues here that really are separate.. the language processing / parsing of various human-readable representations, and the sort of rarified representations themselves. So the deeper thing from a representational point of view is not how a standards body chooses to represent them in plain text, but what is being represented. Of course for it to be useful they need to map to those things.

So the EMF entities (EClasses) would represent the things being measured themselves, or at least I would think that would be the most useful representation.
> 
> Inherent in this notion is that I don't have any enumerations for
> useful ucum concepts. I think perhaps this is where my problem is. So
> let's pursue that.

> 
> UCUM defines a number of dimensions for basic measurement concepts of
> distance, mass, etc. And I do have an enumeration for them. But it's
> not very useful, because most real world measurements are some
> combination of them - volume, density, concentration, siemens, etc....
> and the number is infinite. For some useful combinations, there is a
> preexisting common use unit defined - but certainly not all of them.
> So I haven't tried to model a useful dimension in an enumeration.

I'll admit that I'm lost on what you mean by enumeration here as it is such an overloaded term. Again, a more real-world example than mine above might help us to understand one another.


> For slightly different reasons, I've not bothered creating
> enumerations for the pre-defined units either. The first is to do with
> change control - the UCUM implementation can accept any unit defined
> in the UCUM way, and uses the UCUM xml file. So any time a new version
> of UCUM is released, a user can simply substitute the XML file for the
> old one, and use any new units without having to recompile (and
> redistibute etc). It also means that they can define their own units

Oh, that's nice.

> in the xml file if they feel the need. The other reason is that having
> an enumeration for a unit isn't a very useful concept - it's quite a
> large list, but it's not something you can use directly - you have to
> use an expression. And the easiest way to build an expression is to do
> so in text

Yes I can see that for usage. And there are really neat tools that work with EMF such as XText that would greatly facilitate that process. My argument though is again that there are really strong benefits to having the ultimate model be more reified than a textual representation. But maybe supporting that kind of mapping in any kind of rigorous way would just be too much work.

> 
> it seems to me that your EMF examples really fall down to having and
> leveraging the dimensional enumeration, but I don't think that's a
> very useful idea.

No, again that was just an example. Any kind of measurement that is mappable or that has a functional relationship to any other measurement is fair game.

> 
> On the other hand, my implementation approach (data string + metadata
> canonical units + object validation) implies a custom object model
> editor. Since for me that's a given for other reasons, it's not been a
> problem. I don't know enough about EMF editors to know what the right
> way to approach that problem is.

So you have a custom object model editor now? The advantage of an EMF (or meta-object in general) approach is that it allows you to separate out the representational (in the deep sense) issues from the implementation / usage issues and the semantics of the meta-model are much richer than they can be with an XML schema. In this way the (meta)-model itself becomes a kind of bus around which appropriate human <-> representation relationships can occur. :) For example, one could build a text editor that allowed people to work with UCUM expressions or diagram editors or integrate with binary persistence mechanisms without going through step of conversion back and forth to XML.

I hope I'm beginning to make some sense here,

Miles