[uf-discuss] Re: Currency + Unit of measurement (Was: Currency+Product)

Guillaume Lebleu gl at brixlogic.com
Mon Oct 2 17:17:18 PDT 2006


Please ignore my last post on the subject. As Andy M. pointed to me in 
another thread, I took an extreme interpretation of the process. Mea 
culpa. And sorry in advance for this long post.

On the subject of what is useful to do now with currency, I agree with 
you that limiting the proposal to just something like:

"2 barrels of oil for sale. Price: <span class="price"><abbr 
class="currency" title="USD">$</abbr>25</span> per barrel"

is pretty simple and would simplify the work of the developer of browser 
plugins that would perform some type of convenience currency conversion.

That said, it would provide no incremental value to the end-user, since 
the absence of a currency microformat has not blocked the development of 
these browser plugins.

This is why I argue that the simplest form of *useful* data should be a 
bit more than just disambiguating the currency.

On the subject of dealing with currencies first, then with combinations 
with other products,  I don't understand your point about "barrel being  
the product the currency references". In my example above, "2 barrels of 
oil" is the product, and "barrel" is a unit of "oil" as you said 
yourself at the beginning of your answer.

Maybe the example is confusing, but the following should be less:

"wage/hour" (see http://microformats.org/wiki/job-listing)
"Parking garage for rent: $215/mo" (see Examples in 

Outside of the microformats community, I can point to financial 
reporting ("USD/share" for earnings per share), or my original "$25/bll" 
example as fairly common examples.

I am sure you will agree that shares, barrel, mo, hour *are units, not 
products* and are an integral part of the price: If I wanted to compare 
two salaries: one in Euro/hour and one in Thousands of US dollar / year, 
converting the currency would not be enough to provide value to a user.

In conclusion, this is why I suggested that we try to come up with a 
single measurement proposal right away, with currency being a subset of it.

Perhaps what you meant was that we should have a separate "measure" 
proposal. I don't have a problem with that. If we agree measurement 
units are important in a price and that a currency unit is itself a 
measurement unit, then at the very least, we'd better make sure that the 
currency microformat will be viewed as a subset and component of the 
measurement unit microformat.




Scott Reynen wrote:
> On Sep 29, 2006, at 5:09 PM, Guillaume Lebleu wrote:
>> I don't think Lorenzo is talking of: *currency amount per 
>> item/product* as your title and example imply (that, I agree, is a 
>> non-starter)
>> but of *currency amount per unit of measurement* (which is widely 
>> used - see for instance: http://www.bloomberg.com/energy/, although 
>> not in the context of a house/product/job in which case the unit is 
>> obvious).
>> In "$25 per barrel" or in "25 ($/bbl)", I think you would agree that 
>> knowing that the barrel is the unit of measurement is very 
>> significant, and even though knowing that "$" means USD dollars, 
>> overlooking that it is a price per barrel would lead to a big mistake.
> I think "$" is a unit of measuring currency, and "barrel" is a unit of 
> measuring oil, which in this case is the product the currency 
> references.  Though used together here, these are two distinct 
> problems that deserve separate microformats, one for currency and 
> another for products (i.e. hListing).  Measurement of currency can be 
> useful without considering measurement of products of purchase.  We 
> should start with describing the simplest form of useful data.
> Peace,
> Scott
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
> --No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.407 / Virus Database: 268.12.11/460 - Release Date: 
> 10/1/2006

More information about the microformats-discuss mailing list