Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » UOMo » Proposal feedback, interested party
Proposal feedback, interested party [message #542392] Thu, 24 June 2010 17:02 Go to next message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Hi all,

Congratulations on your proposal. A few thoughts..

1. Consider adding the Agent Modeling Project to related projects. As AMP and specifically the Agent Modeling Framework Acore representation are designed to model and simulate real world objects the need for standardized approaches to units of measurement is very clear. We are especially interested in defining model / sub-model level consistent relative measures and time-scales at hierarchical scales. We are interested primarily in representations that are not based on particular implementations (e.g. particular floating point constructs) but instead that rely on notionally "real" units of measurement.

2. Is a meta-model representation (i.e. EMF) contemplated? Such a representation would be very useful, and in fact could supersede or obviate the need for a Java representation per se, though of course support for actual transformations would need to be implemented in Java.

3. Have you considered other projects that might be combined or affiliated within this project? Again, taken with say the STEM project, AMP, etc.. we are all working with common representations that are a) model-based and b) working with real world objects. Perhaps it would be useful to be thinking about common representational schemes that go beyond the scope of units of measure.

cheers,

Miles
AMP Project (Incubation) Lead, Eclipse Modeling Project
Re: Proposal feedback, interested party [message #542665 is a reply to message #542392] Fri, 25 June 2010 14:46 Go to previous messageGo to next message
Werner Keil is currently offline Werner KeilFriend
Messages: 1087
Registered: July 2009
Senior Member
Miles,

Thanks a lot for your interest. I'll edit the proposal text and ask Anne to
update the live site.

An important part of UOMo is the implementation against a core Units of
Measure API, so unless EMF objects may use or extend the classes defined by
UOMo they could certainly implement the Core API in order to be compatible
with UOMo or other implementations.

Cheers,
Werner Keil
UOMo Project (Incubation) Lead
Re: Proposal feedback, interested party [message #542796 is a reply to message #542392] Sat, 26 June 2010 05:54 Go to previous messageGo to next message
Grahame Grieve is currently offline Grahame GrieveFriend
Messages: 76
Registered: July 2009
Member
hi Miles

How would EMF be useful? I maintain the existing UCUM code from which UOMo will start, and there's no EMF support now, and I don't know why I'd add it. What are your desired functional outcomes?

Grahame

[Updated on: Sat, 26 June 2010 05:57]

Report message to a moderator

Re: Proposal feedback, interested party [message #543173 is a reply to message #542796] Mon, 28 June 2010 15:17 Go to previous messageGo to next message
Werner Keil is currently offline Werner KeilFriend
Messages: 1087
Registered: July 2009
Senior Member
Grahame,

Thanks for the input. Packages in the existing UCUM project like "model"
suggest they support EMF already, which they don't.

Modeling Unit support probably more the likes of UnitsML than UCUM sounds
very interesting, not completely sure, if it applies to UCUM, but it may to
(a different part of) UOMo.

Werner
Re: Proposal feedback, interested party [message #543231 is a reply to message #542796] Mon, 28 June 2010 18:29 Go to previous messageGo to next message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Grahame Grieve wrote on Sat, 26 June 2010 01:54
hi Miles
How would EMF be useful? I maintain the existing UCUM code from which UOMo will start, and there's no EMF support now, and I don't know why I'd add it. What are your desired functional outcomes?



Hi Grahame,

Support for Model level representations would provide a common representational scheme not tied to a specific implementation, i.e. Java. To me the idea of common representation just cries out for such a non target specific level of support. And since Modeling is such a strong component of Eclipse, I think it would be useful for all projects to just consider how they might relate to the modeling approaches. As Werner says, such support would be like a kind of BlahML, except with an EMF representation you have much stronger semantics and can include validation, editing and even code generation to the mix.

So to answer your question directly, I'd like to incorporate a standard approach to units and measures within my own meta-model so that users of my tools can represent UOM in a way that is standardized and dockable with other approaches. The only way to accomplish this would be if there was common support at the model (not-API) level.

At the simplest level, once could provide wrappers around the existing UCUM (?) constructs so it is actually not as involved as it might sound.

hth,

Miles
Re: Proposal feedback, interested party [message #543286 is a reply to message #542392] Mon, 28 June 2010 23:57 Go to previous messageGo to next message
Grahame Grieve is currently offline Grahame GrieveFriend
Messages: 76
Registered: July 2009
Member
The UCUM code consists of a model for the UCUM essence file, a model for the syntax of a unit, and a set of code that provides services to parse strings to the syntax model, and to convert between them.

I think you're saying that there should be an EMF based model for the syntax because that's useful - though I don't see it myself. It's such a clunky way to do things - you need the services to make it useful.

But let's assume that we defined a EMF representation of the syntax of a unit. What services would you need provided with that?
Re: Proposal feedback, interested party [message #543291 is a reply to message #543286] Tue, 29 June 2010 00:18 Go to previous messageGo to next message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Grahame Grieve wrote on Mon, 28 June 2010 19:57
The UCUM code consists of a model for the UCUM essence file, a model for the syntax of a unit, and a set of code that provides services to parse strings to the syntax model, and to convert between them.


And convert between instances of units themselves, I would presume? IOTW, I could have something like Measure(Unit.Fahrenheit, 32.0) and say call ConvertUtil.toMeasure(Unit.Celsius) and get back Measure(Unit.Celius, 0.0)?

Quote:
I think you're saying that there should be an EMF based model for the syntax because that's useful - though I don't see it myself. It's such a clunky way to do things - you need the services to make it useful.


I don't understand what you mean by needing services -- it sort of sounds like you're saying "you need to make it useful to make it useful". Smile But if you're actually saying that the only thing that the UCUM model provides is string parsing then the model doesn't sound that useful.

In any case, I'm not sure that I agree that services are needed to make a representation useful. Especially for measures simply getting people to *specify* one in a consistent and transparent way is half he battle.

Quote:
But let's assume that we defined a EMF representation of the syntax of a unit. What services would you need provided with that?


Pretty simple, I think. In the above example, you'd simply want a representation of that such that in my meta-model framework, I could provide an XAttribute meta-class with a Unit attribute. Then a model developer could create an XAttribute instance "meanTemperature" specifying the Unit as the (enum?) "Celsius". Then, suppose someone wanted to dock that with a model using "Fahrenheit" as a unit. The Model representation would then be able to do a proper conversion.

does that make sense?
Re: Proposal feedback, interested party [message #543398 is a reply to message #543291] Tue, 29 June 2010 10:05 Go to previous messageGo to next message
Werner Keil is currently offline Werner KeilFriend
Messages: 1087
Registered: July 2009
Senior Member
The syntax is slightly different, but the idea is correct.

Measure being a core ICU4J class, we don't use it directly, as it is not as
type safe as the Units of Measure API allows.

The base type for measure amounts is called QuantityAmount in UOMo (could be
MeasureAmount, what the name emphasises is the Quantity interface being
used)
Re: Proposal feedback, interested party [message #543540 is a reply to message #543398] Tue, 29 June 2010 17:45 Go to previous messageGo to next message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Werner Keil wrote on Tue, 29 June 2010 06:05
The syntax is slightly different, but the idea is correct.

Measure being a core ICU4J class, we don't use it directly, as it is not as
type safe as the Units of Measure API allows.

The base type for measure amounts is called QuantityAmount in UOMo (could be
MeasureAmount, what the name emphasises is the Quantity interface being
used)


Yep, I just used the word "Measure" for the sake of example here..no connection with any existing APIs.
Re: Proposal feedback, interested party [message #543604 is a reply to message #542392] Wed, 30 June 2010 02:26 Go to previous messageGo to next message
John Conlon is currently offline John ConlonFriend
Messages: 35
Registered: July 2009
Member
I too am interested in this project.

Currently I am using the OSGi Measurement API in EMF metamodels using my own datatypes and my own conversion utilities that just wrap those in the Measurement API.

Better to do this with standard EMF datatypes and utilities so if in the future for example, I wish to add predictive simulation for the users of my application models and I use Miles' Agent Modeling Project (AMP) to provide this simulation of my problem domain the units of measurements will be the same.

Quote:
Pretty simple, I think. In the above example, you'd simply want a representation of that such that in my meta-model framework, I could provide an XAttribute meta-class with a Unit attribute. Then a model developer could create an XAttribute instance "meanTemperature" specifying the Unit as the (enum?) "Celsius". Then, suppose someone wanted to dock that with a model using "Fahrenheit" as a unit. The Model representation would then be able to do a proper conversion.


best regards,
John Conlon
Verticon, Inc.
Re: Proposal feedback, interested party [message #543819 is a reply to message #543291] Wed, 30 June 2010 16:30 Go to previous messageGo to next message
Grahame Grieve is currently offline Grahame GrieveFriend
Messages: 76
Registered: July 2009
Member
> does that make sense?

hmm maybe. We need a much longer exchange on this. Perhaps it's just because I haven't had the time to explore how EMF works that far. Can you contact me off the list (grahame at kestral.com.au) we'll bring it back here when we have convergence?
Re: Proposal feedback, interested party [message #543828 is a reply to message #543819] Wed, 30 June 2010 17:14 Go to previous messageGo to next message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Grahame Grieve wrote on Wed, 30 June 2010 12:30
> does that make sense?

hmm maybe. We need a much longer exchange on this. Perhaps it's just because I haven't had the time to explore how EMF works that far. Can you contact me off the list (grahame at kestral.com.au) we'll bring it back here when we have convergence?


Sounds great. The forum is a bit awkward for this kind of exchange. I'll also cc in the amp dev mailing list (see https://dev.eclipse.org/mailman/listinfo/amp-dev) so that anyone interested can follow there unless there is a UOMo list that works better.
Re: Proposal feedback, interested party [message #544093 is a reply to message #543828] Thu, 01 July 2010 14:31 Go to previous messageGo to next message
Werner Keil is currently offline Werner KeilFriend
Messages: 1087
Registered: July 2009
Senior Member
Could we use the AMP newsgroup for those discussion items?

If you CC "eclipse.uomo" those appear in both groups.

Werner
Re: Proposal feedback, interested party [message #549273 is a reply to message #543604] Mon, 26 July 2010 10:53 Go to previous message
Werner Keil is currently offline Werner KeilFriend
Messages: 1087
Registered: July 2009
Senior Member
John,

Thanks a lot for your interest.

I added you to the proposal document and project POM. As soon as EF got the
proposal updated you'll be on the list.
I outlined migration paths from OSGI Measurements already at Eclipse
Embedded Day or the Vienna DemoCamp.
The only issue I see in your drafted approach is using enum. While Unit is
an interface in the Units of Measure API, hence would be compatible with an
enum, the enum class has so far been found too immature and inflexible
(sorry Josh ;-) to be used. Even for simple things like Dimension there was
a quirk. Ask me for deteils if you're curious, and I'll dig up the reason
why it didn't work.

If XAttribute refers to OpenXML, then this sounds like a great idea. UnitsML
(http://unitsml.nist.gov/) is one of the standards already out there and a
goal of UOMo is interaction with other standards than UCUM that are widely
accepted, too.

Kind Regards,
Werner
Re: Proposal feedback, interested party [message #566548 is a reply to message #542392] Fri, 25 June 2010 14:46 Go to previous message
Werner Keil is currently offline Werner KeilFriend
Messages: 1087
Registered: July 2009
Senior Member
Miles,

Thanks a lot for your interest. I'll edit the proposal text and ask Anne to
update the live site.

An important part of UOMo is the implementation against a core Units of
Measure API, so unless EMF objects may use or extend the classes defined by
UOMo they could certainly implement the Core API in order to be compatible
with UOMo or other implementations.

Cheers,
Werner Keil
UOMo Project (Incubation) Lead
Re: Proposal feedback, interested party [message #566568 is a reply to message #542392] Sat, 26 June 2010 05:54 Go to previous message
Grahame Grieve is currently offline Grahame GrieveFriend
Messages: 76
Registered: July 2009
Member
hi Miles

How would EMF be useful? I maintain the existing UCUM code from which UOMo will start, and there's no UCUM support now, and I don't know why I'd add it. What are your desired functional outcomes?

Grahame
Re: Proposal feedback, interested party [message #566585 is a reply to message #566568] Mon, 28 June 2010 15:17 Go to previous message
Werner Keil is currently offline Werner KeilFriend
Messages: 1087
Registered: July 2009
Senior Member
Grahame,

Thanks for the input. Packages in the existing UCUM project like "model"
suggest they support EMF already, which they don't.

Modeling Unit support probably more the likes of UnitsML than UCUM sounds
very interesting, not completely sure, if it applies to UCUM, but it may to
(a different part of) UOMo.

Werner
Re: Proposal feedback, interested party [message #566605 is a reply to message #566568] Mon, 28 June 2010 18:29 Go to previous message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Grahame Grieve wrote on Sat, 26 June 2010 01:54
> hi Miles
> How would EMF be useful? I maintain the existing UCUM code from which UOMo will start, and there's no EMF support now, and I don't know why I'd add it. What are your desired functional outcomes?


Hi Grahame,

Support for Model level representations would provide a common representational scheme not tied to a specific implementation, i.e. Java. To me the idea of common representation just cries out for such a non target specific level of support. And since Modeling is such a strong component of Eclipse, I think it would be useful for all projects to just consider how they might relate to the modeling approaches. As Werner says, such support would be like a kind of BlahML, except with an EMF representation you have much stronger semantics and can include validation, editing and even code generation to the mix.

So to answer your question directly, I'd like to incorporate a standard approach to units and measures within my own meta-model so that users of my tools can represent UOM in a way that is standardized and dockable with other approaches. The only way to accomplish this would be if there was common support at the model (not-API) level.

At the simplest level, once could provide wrappers around the existing UCUM (?) constructs so it is actually not as involved as it might sound.

hth,

Miles
Re: Proposal feedback, interested party [message #566631 is a reply to message #542392] Mon, 28 June 2010 23:57 Go to previous message
Grahame Grieve is currently offline Grahame GrieveFriend
Messages: 76
Registered: July 2009
Member
The UCUM code consists of a model for the UCUM essence file, a model for the syntax of a unit, and a set of code that provides services to parse strings to the syntax model, and to convert between them.

I think you're saying that there should be an EMF based model for the syntax because that's useful - though I don't see it myself. It's such a clunky way to do things - you need the services to make it useful.

But let's assume that we defined a EMF representation of the syntax of a unit. What services would you need provided with that?
Re: Proposal feedback, interested party [message #566656 is a reply to message #543286] Tue, 29 June 2010 00:18 Go to previous message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Grahame Grieve wrote on Mon, 28 June 2010 19:57
> The UCUM code consists of a model for the UCUM essence file, a model for the syntax of a unit, and a set of code that provides services to parse strings to the syntax model, and to convert between them.


And convert between instances of units themselves, I would presume? IOTW, I could have something like Measure(Unit.Fahrenheit, 32.0) and say call ConvertUtil.toMeasure(Unit.Celsius) and get back Measure(Unit.Celius, 0.0)?

Quote:
> I think you're saying that there should be an EMF based model for the syntax because that's useful - though I don't see it myself. It's such a clunky way to do things - you need the services to make it useful.


I don't understand what you mean by needing services -- it sort of sounds like you're saying "you need to make it useful to make it useful". :) But if you're actually saying that the only thing that the UCUM model provides is string parsing then the model doesn't sound that useful.

In any case, I'm not sure that I agree that services are needed to make a representation useful. Especially for measures simply getting people to *specify* one in a consistent and transparent way is half he battle.

Quote:
> But let's assume that we defined a EMF representation of the syntax of a unit. What services would you need provided with that?


Pretty simple, I think. In the above example, you'd simply want a representation of that such that in my meta-model framework, I could provide an XAttribute meta-class with a Unit attribute. Then a model developer could create an XAttribute instance "meanTemperature" specifying the Unit as the (enum?) "Celsius". Then, suppose someone wanted to dock that with a model using "Fahrenheit" as a unit. The Model representation would then be able to do a proper conversion.

does that make sense?
Re: Proposal feedback, interested party [message #566674 is a reply to message #543291] Tue, 29 June 2010 10:05 Go to previous message
Werner Keil is currently offline Werner KeilFriend
Messages: 1087
Registered: July 2009
Senior Member
The syntax is slightly different, but the idea is correct.

Measure being a core ICU4J class, we don't use it directly, as it is not as
type safe as the Units of Measure API allows.

The base type for measure amounts is called QuantityAmount in UOMo (could be
MeasureAmount, what the name emphasises is the Quantity interface being
used)
Re: Proposal feedback, interested party [message #566689 is a reply to message #543398] Tue, 29 June 2010 17:45 Go to previous message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Werner Keil wrote on Tue, 29 June 2010 06:05
> The syntax is slightly different, but the idea is correct.
>
> Measure being a core ICU4J class, we don't use it directly, as it is not as
> type safe as the Units of Measure API allows.
>
> The base type for measure amounts is called QuantityAmount in UOMo (could be
> MeasureAmount, what the name emphasises is the Quantity interface being
> used)


Yep, I just used the word "Measure" for the sake of example here..no connection with any existing APIs.
Re: Proposal feedback, interested party [message #566706 is a reply to message #542392] Wed, 30 June 2010 02:26 Go to previous message
John Conlon is currently offline John ConlonFriend
Messages: 35
Registered: July 2009
Member
I too am interested in this project.

Currently I am using the OSGi Measurement API in EMF metamodels using my own datatypes and my own conversion utilities that just wrap those in the Measurement API.

Better to do this with standard EMF datatypes and utilities so if in the future for example, I wish to add predictive simulation for the users of my application models and I use Miles' Agent Modeling Project (AMP) to provide this simulation of my problem domain the units of measurements will be the same.

Quote:
> Pretty simple, I think. In the above example, you'd simply want a representation of that such that in my meta-model framework, I could provide an XAttribute meta-class with a Unit attribute. Then a model developer could create an XAttribute instance "meanTemperature" specifying the Unit as the (enum?) "Celsius". Then, suppose someone wanted to dock that with a model using "Fahrenheit" as a unit. The Model representation would then be able to do a proper conversion.


best regards,
John Conlon
Verticon, Inc.
Re: Proposal feedback, interested party [message #566721 is a reply to message #543291] Wed, 30 June 2010 16:30 Go to previous message
Grahame Grieve is currently offline Grahame GrieveFriend
Messages: 76
Registered: July 2009
Member
> does that make sense?

hmm maybe. We need a much longer exchange on this. Perhaps it's just because I haven't had the time to explore how EMF works that far. Can you contact me off the list (grahame at kestral.com.au) we'll bring it back here when we have convergence?
Re: Proposal feedback, interested party [message #566741 is a reply to message #543819] Wed, 30 June 2010 17:14 Go to previous message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Grahame Grieve wrote on Wed, 30 June 2010 12:30
> > does that make sense?
>
> hmm maybe. We need a much longer exchange on this. Perhaps it's just because I haven't had the time to explore how EMF works that far. Can you contact me off the list (grahame at kestral.com.au) we'll bring it back here when we have convergence?


Sounds great. The forum is a bit awkward for this kind of exchange. I'll also cc in the amp dev mailing list (see https://dev.eclipse.org/mailman/listinfo/amp-dev) so that anyone interested can follow there unless there is a UOMo list that works better.
Re: Proposal feedback, interested party [message #566760 is a reply to message #566741] Thu, 01 July 2010 14:31 Go to previous message
Werner Keil is currently offline Werner KeilFriend
Messages: 1087
Registered: July 2009
Senior Member
Could we use the AMP newsgroup for those discussion items?

If you CC "eclipse.uomo" those appear in both groups.

Werner
Re: Proposal feedback, interested party [message #570434 is a reply to message #566706] Mon, 26 July 2010 10:53 Go to previous message
Werner Keil is currently offline Werner KeilFriend
Messages: 1087
Registered: July 2009
Senior Member
John,

Thanks a lot for your interest.

I added you to the proposal document and project POM. As soon as EF got the
proposal updated you'll be on the list.
I outlined migration paths from OSGI Measurements already at Eclipse
Embedded Day or the Vienna DemoCamp.
The only issue I see in your drafted approach is using enum. While Unit is
an interface in the Units of Measure API, hence would be compatible with an
enum, the enum class has so far been found too immature and inflexible
(sorry Josh ;-) to be used. Even for simple things like Dimension there was
a quirk. Ask me for deteils if you're curious, and I'll dig up the reason
why it didn't work.

If XAttribute refers to OpenXML, then this sounds like a great idea. UnitsML
(http://unitsml.nist.gov/) is one of the standards already out there and a
goal of UOMo is interaction with other standards than UCUM that are widely
accepted, too.

Kind Regards,
Werner
Previous Topic:UOMo at Eclipse Summit Europe 2010
Next Topic:OUMo Financial
Goto Forum:
  


Current Time: Fri Apr 19 22:39:42 GMT 2024

Powered by FUDForum. Page generated in 0.04532 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top