RE: [uf-discuss] Currency Quickpoll: Preliminary results
Thanks for considering my input. As for money vs. currency for some intangible reason I prefer currency, maybe because currency datatype always seemed more natural than money data type in programming, but I don't prefer it strongly enough to argue the point! :) P.S. I added my vote to your poll, but only selected three of eight thinking the rest shouldn't be included. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume Lebleu Sent: Friday, October 13, 2006 1:28 AM To: Microformats Discuss Subject: Re: [uf-discuss] Currency Quickpoll: Preliminary results Mike Schinkel wrote: This is a naïve question: Doesn't the ISO 4217 code *imply* a symbol? It appears so here: http://www.xe.com/symbols.htm Doesn't including this in the microformat create redundancy? Alternately, can't the symbols be extracted as not being alphanumeric characters? I tend to agree with you and see this as a bit redundant, but I felt I would reproduce the suggestion for the sake of not ignoring anyone's in the vote. I wouldn't have guessed that meaning; I thought your were talking worldwide, not document scope. :) So how would you mark up http://tonto.eia.doe.gov/dnav/pet/pet_pri_spt_s1_d.htm ? Can you show the actual HTML to help me better understand? (not for the entire file, just a snippet.) One solution is to use the include-pattern only; another solution is to use the th scope only (if the currency is present in the column header), or a combination of the two: amounts in span id=#u1 class=currencyUSD/span. ... tr th scope=colpricea href=#u1 class=include/a/th td24/td /tr If so, wouldn't that argue for combination with units (ex. $34 per gallon, $2 per miles) being out of scope and begging the need for a microformat that allows unit designation, i.e. hUnits? We came to the same conclusion. A separate measure effort was started: http://microformats.org/wiki/measure Anyway, I made a proposal here: http://microformats.org/wiki/currency-brainstorming#Mike_Schinkel with the idea of trying to minimize the burden placed on the author of the HTML, and only use lots of markup in the exceptional cases. You have some good points there. That said, I think that currency should not be the root class, money should be, since semantically (to me) $35 is not a currency, it is money, and currency is part of money. But I see the benefits of briefness. My last thought on the subject, is why are we using full names for currency and amount instead of cur and amt to minimize bloat when hCard uses names like fn? Good point too. I will try to document the different options presented over the last days. It does not seem that we will get a 100% on all feature implementations, so I guess it will be up for the community to decide through a vote, or limit the feature scope to what is 100% agreed, namely currency disambiguation. Thank you, Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] New Member on the List
Hello Mike, Welcome to the group. See ya On 10/12/06, Mike Schinkel [EMAIL PROTECTED] wrote: Hi all, I'm brand new to the list and would like to introduce myself. I saw Tantek give his talk at The Future of the Web Apps conference in San Fran last month, and I am sold on Microformats! (see: http://www.mikeschinkel.com/blog/MicroformatsHCard.aspx) This is great work and I'm so glad to see this initiative! Over the coming month I hope to contribute significantly, and I have some thoughts on some microformats I'd really like to see. However, I'm going to sit back and get a feel for the group and how things operate before I propose anything so as not to waste anybody's time. -Mike Schinkel President; Guides, Inc. http://www.guidesinc.com (404) 474-8948 (404) 276-1276 cell (404) 474-8949 fax skype: mike.schinkel [EMAIL PROTECTED] http://www.mikeschinkel.com/blog http://www.welldesignedurls.org/ http://www.linkedin.com/in/mikeschinkel -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Make Televisionhttp://maketelevision.com/ ___ Cars, Motorcycles, Trucks, and Racing... http://tirebiterz.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
Le 06-10-12 à 23:18, Scott Reynen a écrit : span class=moneyabbr class=amount title=0./abbrabbr class=currency title=USD¢/abbr/span This is the sort of absurdity that the credit card advertisers engage in. I'm not sure what this means. Do you not think 99¢ means fundamentally the same thing as 0.99USD? What you see is 99 and what you get is less than 1. That's only true if you consider the value outside the context of the currency, and I don't know why anyone would do that. 99 is a meaningless monetary value without a currency assigned. If the currency is going to be optional, I think it at least needs to be implied. Otherwise we just have a number with no idea what it means. And if there's an established currency, then why not use the unit already explicitly defined by that currency's ISO 4217 code? Why throw away the D in USD? http://en.wikipedia.org/wiki/ISO_4217 The first two letters of the code are the two letters of ISO 3166-1 alpha-2 country codes There are also issues in the way you divide numbers. In many countries, number are organized by sequence of 3 digits. For example, in Japan 10 yen = ju(10) yen 1000 yen = ichi(1) sen yen but1 yen = ichi(1) man yen (and not ju sen yen) 1 万 man 1000 千 sen wa-on kan-onmandarin 1 一 hito ichi yi 2 二 futa ni ar, liang * 3 三 mi san san 4 四 yonshi *si 5 五 itsutsugo wu 6 六 mu roku liu 7 七 nana shichi * qi 8 八 ya hachiba 9 九 kokonotsu kyuu jiu 10 十 toujyuu shi And this is actually used in daily life, in case people think its a corner case. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency Quickpoll: Preliminary results
Mike Schinkel wrote: Thanks for the clarification. Further questions (and forgive me if I missed any of this before I joined): Currency symbol identification This is a naïve question: Doesn't the ISO 4217 code *imply* a symbol? It appears so here: http://www.xe.com/symbols.htm Doesn't including this in the microformat create redundancy? It's not just about identifying which symbol represents the currency, but also which currency that symbol represents. Alternately, can't the symbols be extracted as not being alphanumeric characters? For a program to do so, it would have to be aware of every single alphanumeric character in Unicode. That does not just include [A-Za-z0-9]. It might be easier to do the reverse and know of every character that isn't a known currency symbol, but then even that list of symbols is missing some. e.g. * U+FE69 ﹩ (Small Dollar Sign) * U+FF04 ＄ (Fullwidth Dollar Sign) * U+FFE5 ￥ (Fullwidth Yen Sign) * etc. It's much easier for the author to explicitly state which character(s) represent the symbol, than implementing heuristics to guess. Broader Question: Isn't the idea behind Microformats to be as consise, cohesive, and single purposed as possible? If so, wouldn't that argue for combination with units (ex. $34 per gallon, $2 per miles) being out of scope and begging the need for a microformat that allows unit designation, i.e. hUnits? Yes. Tackling the problem of identifying specific units under the currency format is far too complicated when you consider the sheer number of units there are, including SI units, Imperial units and US customary units, used for various quantities including number of units, length, mass, time, volume, area, energy, etc. However, the format could make provisions for some form of quantity, even if it doesn't explicitly define what such quantities are. e.g. price per Litre: span class=money abbr class=currency unit title=AUD$/abbr1.23 span class=quantityL/span /span Or for each unit: span class=money abbr class=unit$/abbr4.95 span class=quantityeach/span /span That way, if and when a microformat for units of measurement is introduced, that could easily be expanded to the following. e.g. span class=quantity si-unitL/span My last thought on the subject, is why are we using full names for currency and amount instead of cur and amt to minimize bloat when hCard uses names like fn? One of the problems I have with hCard is that those abbreviated class names are difficult to comprehend and remember. e.g. It's easy to get confused about what 'fn' means, since it could easily stand for family name, though it doesn't. (I'm not exactly sure what it stands for, though I assume it means formatted name even though it's not explicitly stated as such in the vCard RFC) Abbreviations can be good in many cases, but you have to be careful not to introduce too much confusion or ambiguity for authors. -- Lachlan Hunt http://lachy.id.au/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: title attribute and abbreviated class names (Was: [uf-discuss] Currency Quickpoll: Preliminary results)
On Oct 12, 2006, at 10:34 PM, Mike Schinkel wrote: Anyway, I made a proposal here: http://microformats.org/wiki/currency-brainstorming#Mike_Schinkel with the idea of trying to minimize the burden placed on the author of the HTML, and only use lots of markup in the exceptional cases. I think your use of the title attribute in these examples contains two bad practices. The first is using title outside of abbr, which is effectively hiding data from humans, as this information is not human-readable in browsers, while abbr title is. The second is using title in abbr to surround data that is not meaningfully equivalent to the title. USD is a good abbr title for $ because they mean the same thing. USD is not a good abbr title for $12.57 because they do not mean the same thing. Imagine listening to that with a screen reader set to read titles instead of content for abbr tags. You'd hear Price: USD and have no idea what the price is, as opposed to a clear Price USD 12.57. Humans first, machines second. My last thought on the subject, is why are we using full names for currency and amount instead of cur and amt to minimize bloat when hCard uses names like fn? fn was taken directly from an existing vocabulary (vCard), so any change would make implementation more difficult for those familiar with that vocabulary. Without those constraints, we should use descriptive and human-readable class names to ease implementation and avoid name clashes. cur might mean current in another context, and this ambiguity is a problem for both publishers and parsers. It's a minor problem, but it's also a minor solution - typing four extra letters. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
On Oct 13, 2006, at 1:55 AM, Karl Dubost wrote: There are also issues in the way you divide numbers. In many countries, number are organized by sequence of 3 digits. For example, in Japan 10 yen = ju(10) yen 1000 yen = ichi(1) sen yen but1 yen = ichi(1) man yen (and not ju sen yen) 1 万 man 1000 千 sen And this is actually used in daily life, in case people think its a corner case. Good point. Can we get some examples of Japanese currency publishing in the wiki? I'd lean towards making this machine-readable without listing every unit for every currency, e.g.: abbr class=amount title=1000一千/abbrabbr class=currency title=JPY¥/abbr Otherwise, we face the task of defining currency units, and that's likely to be a huge headache for us and I think actually more work for publishers to track down the appropriate unit symbol. Consider also: The car costs $20k. I sold my old baseball cards for five benjamins. The war has cost $500 billion so far. These will require either special pre-defined units for k, benjamins, and billion or use of abbr to provide a machine- readable equivalent in a standard (dollar) unit. I think the latter is much simpler. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Use-check: rel=enclosure attribute
I have marked up the link to a PDF on: http://www.westmidlandbirdclub.com/ladywalk/maps.htm with the attribute rel=enlcosure Is that use correct? what are the advantages of doing so? Are there any tools in the wild, which will make use of that? I can see the use of a FireFox extension which lists all the attachments (Enclosures) on ap age. Does such a thing exist, yet? Perhaps 'Tails' might do so? -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Use-check: rel=enclosure attribute
Hello, On 10/13/06, Andy Mabbett [EMAIL PROTECTED] wrote: I have marked up the link to a PDF on: http://www.westmidlandbirdclub.com/ladywalk/maps.htm with the attribute rel=enlcosure Is that use correct? An enclosure basically marks what is being linked to as being part of the document. Thus, if you were to save the document, then you should save all the enclosures too. It's similar to an attachment you get with e-mails. So for your example, if you considered that PDF to be part of the HTML document... then it is correct. what are the advantages of doing so? Are there any tools in the wild, which will make use of that? Off the top of my head, both Fireant and Feedburner support rel-enclosure. I've seen (and even written) Greasemonkey userscripts that support it. And have written a webcrawler (and parser) that supports it. (There's probably more... that's just what comes to mind right now.) I can see the use of a FireFox extension which lists all the attachments (Enclosures) on ap age. Does such a thing exist, yet? Perhaps 'Tails' might do so? -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Make Televisionhttp://maketelevision.com/ ___ Cars, Motorcycles, Trucks, and Racing... http://tirebiterz.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] spreading the semantic web
A few people like the idea of a Spread the Semantic Web campaign, somewhat modeled on Spread Firefox. I would like to make the main focus on three projects, SIOC, SIMILIE, and MicroFormats, and any way to access the extant Semantic Web should be visible. Segala.com is interested, and will provide hosting. Along with OWL, RDF, etc. Also, site should run in Drupal with SIOC Exporter, and I would very much like to see SIOC and MicroFormats work togther. So the basic concept is get on the Semantic Web Today sort of thing. I am asking for help, in any way, for this campaign. All the Best, Alex ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
