Joe:
I bear a lot of responsibility for this. The original posts that lead to this tell some of the story:
http://ontolog.cim3.net/forum/ontology-summit/2009-05/msg00007.html
“This might be a great place to perform some ontology work which would demonstrate a huge benefit to society. The WCO has major issues mapping to and from various languages for UoM. For example, in Japan, you use a completely different counting system for anything that is flat. Even thinks in North America have vastly different units of measure. Mapping each of these ontology concepts to terms in various languages would be a huge issue. Think about these units of measure:
A dozen eggs
A “loaf” of bread, but also has weight
Apples are not sold each in most places but by aggregate weight
Liquids are sold by volume
Long things are often sold in lengths
Flat things are often sold in square feet or meters
Firewood is sold by volume (chords), processed timber is sold by units, square feet, length and other measures. They all come from trees.
...”
Here is a use case. I am in Canada, I import cosmetic brushes from Korea. When I fill out the customs form here for a shipment of 5,000 brushes, I have to declare them in “dozens”. There are many different concepts that the WCO uses including:
Count – the actual value domain for quantity
UnitsOfMeasure – the units that qualify the Count
Precision – the precision value for the Count.
In the case of the brushes, the precision is to the 1/4 (25% of 12 means that I can be within 3 brushes of my stated objective). I therefore indicate on the customs form that I am importing 416 and one half dozen brushes (even though the precise value is 416.66666666~ dozen).
At the other side, the Korean shipping company fills out export documents using a different system for quantifying the number of brushes. They count by individual units, in boxes of 100. Their form shows Count: 50, Units of Measure: Box 100, precision: each.
The discrepancies vary from country to country and by products etc, however the high level concepts such as length, mass, count, volume etc are primitives used by each system. Establishing an ontology of UoM that each system could map to could allow easier translations between domain specific values for quantity, hence improving the ability for trade facilitation.
I hope this helps.
Duane
On 9/24/09 9:18 AM, "Joe Collins" <joseph.collins@xxxxxxxxxxxx> wrote:
I must admit that I find many of these ontology discussions hard to follow.
They are too abstract for me.
Let me suggest that we need a set of agreed upon use cases.
How will any UoM knowledge structure be used?
I believe that use cases will help define and allow some agreement on requirements.
What kinds of knowledge do we expect to express?
Let me suggest these (open-ended) categories:
1) At a minimum people want to express physical quantities in databases, as
inputs to and outputs from applications that use this data.
2) Support for units conversion.
3) I have oriented my work towards enabling quantity _expression_ and mathematical
formula _expression_. This requires some form of mathematical semantics.
...
N) Reasoning within natural language expressions?
Regards,
Joe C.
Joel Bender wrote:
> Or am I a nominal pragmatist?
>
> In the "What is Mass?" thread there are references to tropes, which was
> a completely new term that I didn't understand until I followed a few
> discussions in the ontolog-forum. Then Matthew West wrote "My lump of
> cheese is a member of the 1.3Kg equivalence class" and it causes me a
> bit of concern.
>
> Neither the use of the term 'trope' nor mapping of a thing like a lump
> cheese into an 'equivalence class' is going to fly very far with
> software engineers, programmers, or architects.
>
> When this standard gets published, I expect that these people will begin
> with the notion (or could eventually be convinced) that properties of an
> object, fields of a structure, and columns of a database table could be
> improved by annotating them with a unit of measure. Having a
> consistent label for the annotation and a consistent way of applying it
> is a good thing, they'll keep reading.
>
> Up front there will probably be some clause that says "how the unit of
> measure is associated with the value is a local matter", so don't expect
> this standard to propose a new kind of property for an object, a new
> type of database column. That leaves "presentation" or "exchange" issues.
>
> So how do I, as a architect, tell my programmers to present the fact
> that my lump of cheese is 1.3Kg rather than 1.3 (un-annotated)? As a
> character string in a comma-delimited text file?
>
> ...,"1.3 Kg",...
>
> How do I do it in XML?
>
> <weight uom:unit="Kg">1.3</weight>
>
> RDF?
>
> :myCheeseLump :weight
> [ rdf:value "1.3"^^xsd:decimal; uom:unit uom-si:Kg ] .
>
> I know that while my database calls it 'weight', it should probably be
> called 'mass', but is that really important? Can I still call it
> 'weight' and take advantage of the standard?
>
> I'm exchanging data with a partner, and while my stuff is in Kg, his
> database uses lbs. How does this standard help me know if Kg can be
> converted to lbs, and how can that be accomplished?
>
> On to the next layer of abstraction.
>
> My database has many tables and many columns, does this standard provide
> a way to say column Y of table X is always Kg?
>
> What if its a count? My transaction database has a QTY column which is
> a count of widgets. Is a 'widget' a proper unit of measure? Can I
> _expression_ "widgets per day" as something I have measured?
>
> Now I would like to improve the way my programmers use values. In some
> cases the programmers have added two values together and they are not
> the same unit, does the standard provide a way of knowing if two
> annotated values can be added? In some cases, like widgets, it is
> required that the values be integers, 1.5 widgets doesn't make sense.
> How can I say that the value is restricted to be an integer?
>
> More generally, how is this standard going move from "trope" to being
> the stimulus motivating systems architects to change their systems
> ...dare I say... tropism?
>
> :-)
>
>
> Joel
> p.s.- while I can't join immediately, I'm looking forward to today's
> conference call
>
--
_______________________________
Joseph B. Collins, Ph.D.
Code 5583, Adv. Info. Tech.
Naval Research Laboratory
Washington, DC 20375
(202) 404-7041
(202) 767-1122 (fax)
B34, R221C
_______________________________
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/uom-ontology-std/
Subscribe: mailto:uom-ontology-std-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/uom-ontology-std/
Shared Files: http://ontolog.cim3.net/file/work/UoM/
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?UoM_Ontology_Standard
--
Come to Adobe MAX 2009 and sign up for the LiveCycle Bundle - http://max.adobe.com/sessions/livecycle/?sdid=EUQZE
Twitter: duancechaos
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/uom-ontology-std/
Subscribe: mailto:uom-ontology-std-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/uom-ontology-std/
Shared Files: http://ontolog.cim3.net/file/work/UoM/
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?UoM_Ontology_Standard (01)
|