Re: [uf-discuss] origin of class attribute approach in microformats ?
Thank you Karl for this short, proselytism-free answer. Guillaume Karl Dubost wrote: Guillaume, Le 22 juil. 06 à 08:35, Guillaume Lebleu a écrit : why the approach has evolved to become the following class attribute-approach: [...] instead of the following mixed-namespace approach: [...] Both approaches work fine in a browser (firefox at least), and both approaches could be generated from the same XML. But having an XML background I see that the second approach has the following advantages: It depends on the Web community you are talking to and then the type of applications and tools. In the paradigm of Web authors and Web designers, the Web community has a better understanding of class names because they are used to it. In some other Web communities, it will be the opposite, people will have a better grip on XML namespaces, and schemas. So it's really a question of community of practices. The more important is to find bridges when it's possible. The rest turns always in religious debates, which are pointless. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] 'currency' microformat straw-man proposal.
Looks like there are many others: There are various common abbreviations to distinguish the Canadian dollar from others: while the ISO http://en.wikipedia.org/wiki/International_Organization_for_Standardization currency code http://en.wikipedia.org/wiki/ISO_4217 *CAD* (a three-character code without monetary symbols http://en.wikipedia.org/wiki/Currency_sign) is common, no single system is universally accepted. *C$* is recommended by the Canadian government (e.g., per /The Canadian Style/ guide) and is used by the International Monetary Fund http://en.wikipedia.org/wiki/International_Monetary_Fund, while /Editing Canadian English/ indicates *Can$* and *CDN$*; both guides note the ISO scheme/code. The abbreviation *CA$* is also used, e.g., in some software packages. http://en.wikipedia.org/wiki/Canadian_dollar Guillaume Andy Mabbett wrote: In message [EMAIL PROTECTED], Charles Iliya Krempeaux [EMAIL PROTECTED] writes What I'm arguing is that... we should throw an iso4127 class name in there too so that other currency codes (besides ISO 4127) could be used too without (potentially) breaking this or other Semantic HTML systems (that either exist now or will exist in the future) for marking up currency. What currency code uses CDN for Canadian dollars - or we going to have people inventing their own currency codes, too? Well... I use CDN. (I'm Canadian BTW.) Until I read the ISO 4127 spec, I don't think I've noticed CAD being used. But I've seen CDN all over the place. Even at the currency exchage stores (that I've been to) I believe they use CDN. It's a defacto standard. (Just because ISO doesn't give CDN its blessing and tells people to use CAD doesn't mean people will.) I'm not disputing that it's used; you've said ...other currency codes (besides ISO 4127) could be used...; and I'm asking what currency code uses CDN. Seems you can't name one. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] 'currency' microformat straw-man proposal.
A little detail. Shoulnd't it be: abbr class=currency title=Canadian dollarC$/abbr ? CAD being itself an abbreviation. BTW, I think in this context currency as a class name makes sense. I proposed earlier having a currencyamount class name that would contain a value (expressed as text or numerical) and and optionally a currency (optional b/c if we imagine a table of 1000s or rows containing currency amounts, we may not want to have the currency symbol/code next to each entry, but only in the th). span class=currencyamount100abbr class=currency title=Euroeuro;/abbr/span. Guillaume Andy Mabbett wrote: In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes Looks like there are many others: There are various common abbreviations to distinguish the Canadian dollar from others: while the ISO http://en.wikipedia.org/wiki/Interna tional_Organization_for_Standardization currency code http://en.wikip edia.org/wiki/ISO_4217 *CAD* (a three-character code without monetary symbols http://en.wikipedia.org/wiki/Currency_sign) is common, no single system is universally accepted. *C$* is recommended by the Canadian government (e.g., per /The Canadian Style/ guide) and is used by the International Monetary Fund http://en.wikipedia.org/wiki/Intern ational_Monetary_Fund, while /Editing Canadian English/ indicates *Can$* and *CDN$*; both guides note the ISO scheme/code. The abbreviation *CA$* is also used, e.g., in some software packages. Any of which can be marked up thus: abbr class=currency title-CADC$/abbr [1] since any of them is a symbol representing CAD. [1] or whatever class we eventually decide on. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] question about currency amounts in tables
Should the currency amount mF proposal include support for representation of currency-qualified values in a table format? If so, take a look at: http://investor.google.com/fin_data.html As you can see, it would not make sense to have the currency repeated for each piece of data. Instead, it should be provided once at the table level, and then a td may override the default value. What do you think? Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Introductory message, again
Andy, My take on the introductory message: http://microformats.org/wiki/what-are-microformats#Guillaume_Lebleu Guillaume Andy Mabbett wrote: I have just had an e-mail from a friend, to whom I'd recommended uFs: Just had a quick look at http://microformats.org but they only say what it's FOR not what it IS - unless you dig deeper than I did. Please see : http://microformats.org/wiki/what-are-microformats#Andy_Mabbett for my proosed alternative wording. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Dated currency examples?
A correction to one of my code samples: span class=pricespan class=currencyamountabbr class=unitcurrency title=USD$/abbr25/span a abbr class=unit title=barrelbarrel/abbr/span. Guillaume Guillaume Lebleu wrote: Sorry if I'm only getting up-to-speed on this debate. I agree that attaching explicitly date/time information directly to a currency value is relatively rare, and when necessary that it is usually inferred from the context. For instance, we talk of the date of the price of a barrel of oil, in which case the date/time is attached to the price component of a product, the currency value being only one expression of the price. See Andy's example: http://news.bbc.co.uk/2/hi/business/1096916.stm On the other hand, I think attaching date/time information to *currency rates* is very common (See Andy's example: http://en.wikipedia.org/wiki/1922_in_Germany#Inflation_and_Repercussions). Moreover, even though a currency rate is the price of a product, it is particular enough that it deserves its own class. Taking one of Andy's examples that deals with currency rates, and reusing both the abbr/date pattern used in hCalendar and some he IFX/OFX semantics, I think we could get away with: span class=currencyrateOn abbr class=datetime title=1998-03-12T08:30:00-05:00August 1/abbr, the abbr class=currency title=USDUS Dollar/abbr still stood at span class=currencyamount643 abbr class=unitcurrency title=DEMMarks/abbr/span to the Dollar./span i.e.: * currencyrate o currency o currencyamount + unitcurrency Another attempt with the oil barrel example: span class=pricespan class=currencyamountabbr class=unitcurrency title=USD$/abbr25/span a abbr class=unit title=barrelbarrel/barrel/span. i.e.: * price o currencyamount + unitcurrency o unit Of course, this is just brainstorming, as I am just getting started with microformats. Guillaume Scott Reynen wrote: In the currency-brainstorming [1] page, I see a few straw man proposals with dated currency. But I don't see anything in currency-examples [2] with dated currency. I think I understand the general idea, that currencies change value over time, but in what currently published HTML would such date markup be used? I'm sure there are examples of dated currency published on the web, but I suspect they are far under 20% of the currency values published. I'm interested in seeing this microformat completed and adopted and I'd hate to see unnecessary complexity prevent that from happening. [1] http://microformats.org/wiki/currency-brainstorming [2] http://microformats.org/wiki/currency-examples Peace, Scott ___ microformats-discuss mailing list microformats-discuss@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.9/457 - Release Date: 9/26/2006 ___ 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] Dated currency examples?
Lorenzo, With this approach, how would you represent the following price: $25 per barrel? Guillaume Lorenzo De Tomasi wrote: What about the following proposal? p class=price abbr class=unit money title=euro€/abbr span class=value10,5/span /p that can also be used for othe measures like: p class=lenght abbr class=unit title=meterm/abbr span class=value10,5/span /p Thanks for your opinion :-) On 9/27/06, Scott Reynen [EMAIL PROTECTED] wrote: On Sep 27, 2006, at 2:21 PM, Guillaume Lebleu wrote: span class=pricespan class=currencyamountabbr class=unitcurrency title=USD$/abbr25/span a abbr class=unit title=barrelbarrel/abbr/span. As suggested in the currency Related microformats section, I think a simpler money microformat (without unit) could be combined with hListing [1] to cover something like this, e.g.: span class=hlisting span class=price money abbr class=currency title=USD$/abbrspan class=value25/ span /span a span class=item fnbarrel/span /span [1] http://microformats.org/wiki/hlisting Peace, Scott ___ 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
[uf-discuss] Re: Currency + Unit of measurement (Was: Currency+Product)
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 Lorenzo is furthermore suggesting that a currency is just another unit. I agree conceptually that it is, but in practice, standard bodies (that I know of) have traditionally separated currency amounts from other measures. For instance, I took a look at the UNECE recommended codes for units of measurement (reused by some industry standards), available at: http://www.unece.org/cefact/codesfortrade/codes_index.htm. http://www.unece.org/cefact/recommendations/rec20/rec20.zip. They indeed have the barrel (US) as a well-known unit, but as I mentioned UNECE does not include currencies in their list of units of measurement. Which leads me to my updated code examples. span class=priceabbr class=currency title=USD$/abbvspan class=value25/span span class=unit title=BLLper barrel/span/span span class=pricespan class=value25/span abbr class=currency title=USD$/abbvabbr class=unit title=BLL/bbl/abbr/span/span span class=priceOn abbr class=datetime title=1998-03-12T08:30:00-05:00August 1/abbr, the US Dollar still stood at span class=value643 abbr class=currency title=DEMMarks/abbr/span to the span class=unit currency title=USDDollar/span./span The following rules should be used: * If value is not present, then value = 1. * unit is optional By the way, I haven't found any measurement microformat on the wiki, so maybe we could do the currency+measurement at the same time. Let me know what you think. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Currency + Unit of measurement (Was: Currency+Product)
One little correction in the text below. The following rules should be used: * unit is optional * if unit is present, then value is optional, and if value not present, then it is assumed to be 1. Guillaume 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 Lorenzo is furthermore suggesting that a currency is just another unit. I agree conceptually that it is, but in practice, standard bodies (that I know of) have traditionally separated currency amounts from other measures. For instance, I took a look at the UNECE recommended codes for units of measurement (reused by some industry standards), available at: http://www.unece.org/cefact/codesfortrade/codes_index.htm. http://www.unece.org/cefact/recommendations/rec20/rec20.zip. They indeed have the barrel (US) as a well-known unit, but as I mentioned UNECE does not include currencies in their list of units of measurement. Which leads me to my updated code examples. span class=priceabbr class=currency title=USD$/abbvspan class=value25/span span class=unit title=BLLper barrel/span/span span class=pricespan class=value25/span abbr class=currency title=USD$/abbvabbr class=unit title=BLL/bbl/abbr/span/span span class=priceOn abbr class=datetime title=1998-03-12T08:30:00-05:00August 1/abbr, the US Dollar still stood at span class=value643 abbr class=currency title=DEMMarks/abbr/span to the span class=unit currency title=USDDollar/span./span The following rules should be used: * If value is not present, then value = 1. * unit is optional By the way, I haven't found any measurement microformat on the wiki, so maybe we could do the currency+measurement at the same time. Let me know what you think. 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] Re: Currency + Unit of measurement (Was: Currency+Product)
Scott, My feeling is that if we must start with the simplest form of useful data and pave the cow paths, then price in hListing is good enough for me, and there is no need to pave that currency path for now, or even discuss it, at least not on this discussion list: * Google says that the price classname is the 40th most popular class name on the Web: http://code.google.com/webstats/2005-12/classes.html. You can't beat that. * There seems to be very few cows on the currency path today: after hours of research, the only example I've found on the Web that disambiguates the $ with a span or abbr and adhoc class name is the MacAfee example: http://microformats.org/wiki/currency-examples#McAfee.C2.A0.28http:.2F.2Fus.mcafee.com.2Froot.2Fpackage.asp.3Fpkgid.3D100.29.None of the top online vendors (Dell, Amazon, Walmart, Staples, etc.) care about disambiguating currencies in price. * Focusing on disambiguating only the currency can only be useful to me for conversion, and Greasemonkey scripts and other browser plugins for currency conversion seem to work ok most of the time, using other clues to disambiguate, for instance the domain name .ca to disambiguate the $ sign. Once we found more real examples, we can resume discussions here on this subject. Let me know what you think. Guillaume 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@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] Marking Up Personal Profiles
I have had a really hard time finding currency examples on the Web using something else/more than the price class name to qualify currency amounts (I wish there was a search engine for HTML source code). Actually, I haven't found any (only one is documented on the http://microformats.org/wiki/currency-examples page). Have you seen any in the context of personal profiles? If so, they should be added to the page. http://microformats.org/wiki/currency-examples. If not, and if we follow the microformat process, then price is probably enough. Thank you Guillaume Andy Mabbett wrote: In message [EMAIL PROTECTED], Lachlan Hunt [EMAIL PROTECTED] writes There are formats being discussed for marking up currency. Here: http://microformats.org/wiki/currency ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] existing currency formats: XBRL
I took a look at the semantics used by XBRL for currency amounts (a standard for corporate financial reporting pushed among others by the SEC). I have made an adaptation of them in semantic XHTML: http://microformats.org/wiki/currency-formats#XBRL (without incorporating existing thoughts on currency, just for the sake documenting just XBRL). What's nice about these semantics is that: * In XBRL, a currency is just another simple unit of measure. * In XBRL, a unit of measure can be simple or complex. A simple unit of measure if for instance feet or Dollars while a complex unit of measure is Euros per share. * Units of measurement can be specified anywhere in the XBRL document and assigned a unique identifier, then referred to from numerical facts. Here are two examples from the page. The globally defined currency relies on an empty anchor. I don't know if anyone has an opinion about using anchors this way. Locally defined currency: span class=price100 span class=unitGBP/span/span Globally defined currency: span id=u1 class=unitGBP/span ... span class=price100a href=#u1 rel=unit//span If we incorporate some of the patterns that seem to emerge from the brainstorming page, we could have: Locally defined currency: span class=price100 span class=unit currency title=GBP#163;/span/span Globally defined currency: Amounts in span id=u1 class=unit currency title=GBP#163;/span ... table tr td.../td td100a href=#u1 rel=unit//td /tr /table Let me know what you think. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Currency + Unit of measurement (Was: Currency+Product)
Scott, 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=priceabbr class=currency title=USD$/abbr25/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 http://microformats.org/wiki/hlisting) 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. Peace, Guillaume 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@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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Currency + Unit of measurement (Was: Currency+Product)
Here are some additional examples from the Web of currency mixed with measures, some of which differ from the $__ per barrel pattern and a suggested new conceptualization that seems to work with them. http://microformats.org/wiki/currency-examples#Real-World_Examples Here is another suggested conceptualization that seems to match what's on the Web: $ is not a unit, $ is a currency. Dollar Cent are the units of the USD currency. Just like length is not a unit, but meter and foot are. Currency measures have a default unit (for USD, it's the dollar), that is sometimes omitted in the representation of currency amounts. *Example 1* So $25 per barrel is really $25 dollar per barrel, but a computer can figure this out from: span class=priceabbr class=currency title=USD$/abbrspan class=value25/span span class=unitdividerper/span span class=unit title=BLLbarrel/span/span/span BLL is the UNECE code for barrel. See http://microformats.org/wiki/measure-formats#UNECE *Example 2* 25 (USD per barrel) is really 25 $ dollar per barrel, $ is the currency, dollar per barrel is the unit but a computer can figure this out from: span class=price25 (abbr class=currency title=USDUSD/abbr span class=unitdividerper/span span class=unit title=BLLbarrel/span)/span *Example 3* Similarly in $150K per year the currency is $ but the unit is thousands of dollars per year, but the computer can figure it out from: span class=salaryabbr class=currency title=USD$/abbr150abbr class=unitmultiple title=1000K/abbr span class=unitdividerper/span span class=unit title=ANNyear/span/span/span ANN is the UNECE code for year. See http://microformats.org/wiki/measure-formats#UNECE Let me know what you think. I'll put this on the wiki later. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Currency + Unit of measurement (Was: Currency+Product)
Scott Reynen wrote: I think this is a good example of the benefits of modularization. I think all of these various measurements would be more useful if they were more widely published, and I think the best way to get them widely published is to keep them as separate microformats addressing specific problems. We'll end up missing the most important information related to currency if we attempt an ocean-boiling currency-and-everything-related microformat. There are still 2 separate sections for measure and currency, and I intend to keep it this way. But it was useful to look at both right away to see how they could be used as modules. For example, two of the above examples have no markup indicating the value of the price. It doesn't do much good to know you're talking about barrels of oil and US dollars if I don't know what the value is. I assume this was just an oversight, but it's the kind of oversight we can avoid by keeping currency focused on currency and relegating everything else to more specific microformats (e.g. history, measurement, hListing). $50 is $50 whether I'm spending it on a barrel of oil or receiving it for an hour of work. This was an oversight as I was focusing on the aspects at hand. It should have read: span class=pricespan class=value25/span (abbr class=currency title=USDUSD/abbr span class=unitdividerper/span span class=unit title=BLLbarrel/span)/span Although in some simple contexts, I don't think value is required. span class=price25abbr class=currency title=USDUSD/abbr/span What do you think? Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Currency + Unit of measurement (Was: Currency+Product)
Colin wrote: This proposal is shaping up nicely. Could you think of other client uses for just the measurement format? Already described in this thread were some excellent uses for measurement + currency (e.g. searching job listings). Thanks Colin. For just the measurement format, of course automatic localization based on a browser preference, but I imagine you already thought about this one. Also, I'm curious to know your thoughts on how this would tie in to the proposed historical uF. Would the entire currency+measure get wrapped in a history? That doesn't seem entirely necessary: the size of a barrel of oil doesn't change (right?). Only the $ currency fluctuates. In my adaptation of XBRL currency semantics to uF, I have explored the use of empty anchors as references to global definitions of units instead of redundant local definitions, but I haven't got any feedback from the community on this yet. See http://microformats.org/wiki/currency-formats#XBRL This is not just relevant for the history uF but also for any tabular representation (ex. financial statements) where you don't want to repeat the unit/currency in each cell. See http://microformats.org/wiki/currency-examples#Use_of_currency_amounts_in_tables Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Currency + Unit of measurement (Was: Currency+Product)
Colin wrote: This proposal is shaping up nicely. Could you think of other client uses for just the measurement format? Already described in this thread were some excellent uses for measurement + currency (e.g. searching job listings). Thanks Colin. For just the measurement format, of course automatic localization based on a browser preference, but I imagine you already thought about this one. Also, I'm curious to know your thoughts on how this would tie in to the proposed historical uF. Would the entire currency+measure get wrapped in a history? That doesn't seem entirely necessary: the size of a barrel of oil doesn't change (right?). Only the $ currency fluctuates. In my adaptation of XBRL currency semantics to uF, I have explored the use of empty anchors as references to global definitions of units instead of redundant local definitions, but I haven't got any feedback from the community on this yet. See http://microformats.org/wiki/currency-formats#XBRL This is not just relevant for the history uF but also for any tabular representation (ex. financial statements) where you don't want to repeat the unit/currency in each cell. See http://microformats.org/wiki/currency-examples#Use_of_currency_amounts_in_tables Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Handling hCalendar event updates on clients
Ryan King wrote: I think it's good practice, not just for hCalendar, but for all web content to create permalinks which are independent of things like pagination. If you can do that, then pagination shouldn't be a problem. Maybe I'm missing something, but instead of a new UID element with a namespace-like value, couldn't we use the id attribute of the element of class vevent? The added advantage I see is that it is RESTful and I can refer to an event as a URL, for instance: http://microformats.org/wiki/hcalendar-examples#someid Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] First version of Currency proposal
Please find it at: http://microformats.org/wiki/currency-proposal Thank you in advance for your feedback. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
King Chung Huang wrote: Is currency unit intended to be one whole name or two names? My intention is to have 2 class names, one for the currency (ex. U.S. currency), and one for the unit within that currency (ex. Dollar, Cent). unit is optional, b/c most currencies have a default unit (Dollar in the case of the U.S. currency). I have added more details to the proposal on this. See: http://microformats.org/wiki/currency-proposal Hope this helps. Thank you for your feedback, Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
Scott Reynen wrote: Specifically, I don't think it makes sense to have the first abbr tag with no title, and the second abbr with no content. It looks like you're trying to communicate three different pieces of information when only two are really being published. Thank you for the feedback. Let me first clear up what I am trying to communicate here. My rationale is that in 99 cents, the two pieces of information published are the amount and the unit of currency (See http://en.wikipedia.org/wiki/Cent_(currency)), not the amount and the currency. Without context, the currency piece of information in 99 cents could be U.S. currency, Australian currency, Canadian currency or Euro currency. This is what I am trying to reflect. See also: http://www.austlii.edu.au/au/legis/cth/consol_act/ca1965120/s8.html that clearly shows the distinction between the currency and the denomination. The reason why there is no title attribute in abbr class=unit¢/abbr in my example is b/c I don't want to get ahead of myself and leave this up to the measure proposal, but it should be abbr class=unit title=[some standard/agreed upon code for cent] Can we just treat everything as the default unit Not sure what you mean in the context of the 99c example. The default unit for the US currency is the Dollar, not the Cent, but in the context of the 99c context, we need to ensure that Dollar is not picked as the unit, but Cent instead is. and adjust the machine-readable values accordingly? E.g.: span class=moneyabbr class=amount title=0./abbrabbr class=currency title=USD¢/abbr/span So using this notation would require the parser to interpret the ¢ as the cent unit of the USD currency without this information being disambiguated using a microformat. It would certainly work, assuming you can deal with the different way of representing the Cent information, but isn't our goal here to make interpretation easier, and not require to have to deal with all these tiny differences? Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
Scott Reynen wrote: What I'm suggesting is that everything be treated as dollars in USD and everything be treated as Yen in JPY. Isn't that how most applications and people deal with money anyway? I think this will indeed work in most cases. There are some examples on the Web that make use of cents, and my design philosophy with this proposal was to make simple things simple to microformat, and complex things possible to microformat, without requiring publishers to change some of their practices: - http://www.99only.com/ - http://www.smh.com.au/articles/2004/07/01/1088488063161.html?from=storylhs But we certainly could, if this is the consensus of this community, to enforce that all microformatted money amounts be expressed in the default unit of each currency. What I have seen in other standardization processes, is the documentation of the different options explored with benefits/drawbacks for each, to allow easy side-by-side comparison by the community. I think this will be my next step. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Currency microformat most important features quickpoll
Hello, I thought that to expand feedback on the Currency proposal, a simple poll would be nice, so here it is: http://www.vizu.com/poll-vote.html?n=15067 Note: choices are randomly ordered. Looking forward to your participation. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
Scott Reynen wrote: So which of these tasks should we aim to make simple? I'd say the latter, because it's far more common (well over 80%, I think). I think we agree here. $99 is more common than 99c, so the former should be simpler to microformat than the latter. Where it seems we differ in opinion is that the latter should still be possible to microformat. To paraphrase you, what is simpler? to give a solution, although a bit less simple, to the minority of people who uses 99c, or to ask them to change the way they do things and use $0.99? I believe in the former. I think you'll agree that the following is pretty simple: span class=moneyabbr class=currency title=USD$/abbrspan class=amount99/span/span And most people in this community seems to be in agreement with this. See currency-brainstorming Now, what do we offer to people who use amounts in U.S. cents on their Web site. Nothing or something? If the community agrees it is a rarity, then we may want to just offer nothing (hopefull the poll I sent will provide useful feedback to this question). Users will come up with something themselves if the community was wrong. I have seen at least one web page where the cents part of the price was marking up (even when represented like $39.99) to display the .99 as superscript - I'll try to find this again and document it in examples. If we want to offer something, then for 70 US cents as in http://www.smh.com.au/articles/2004/07/01/1088488063161.html?from=storylhs, we could have: span class=moneyspan class=amount70/span abbr class=currency title=USDUS/abbr abbr class=unit title=centcents/abbr/span This is slightly more complex, but after all, people using this are relatively few. Now, what about 70 cents. I suggested using an empty abbreviation that was not well received, but an include link to a hidden global definition would work as well: abbr id=#u1 class=hidden currency title=USD$/abbr span class=moneyspan class=amount70/span abbr class=unit title=centcents/abbr a href=#u1 class=include/a/span That's a bit more complex, but at least there is something for the minority to follow. And my experience with standards is that if there is something that the community defined, and it works for a user's particular problem, then the user tends to go with it. My 2 cents, Guillaume Peace, Scott ___ microformats-discuss mailing list microformats-discuss@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.13.1/466 - Release Date: 10/7/2006 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Currency Quickpoll: Preliminary results
I thought I'd share these results with you. Voters were asked to select up to 4 features in a list of 8. We only had a handful of votes so far, so please cast yours at: http://www.vizu.com/poll-vote.html?n=15067 Features deemed most important: 1. (100%) Currency used identification (ex. US dollars versus Canadian dollars) 2. (83.3%) Currency unit/denomination used identification (ex. dollar versus cent, pound versus shilling) 3. (50%) * Amount identification from other part of the text * Support for combination with units (ex. $34 per gallon, $2 per miles) 4. (33.3%) Global currency definition (ex. all amounts in table are in US dollars) 5. (16.7%) Currency symbol identification from other part of the text (ex. $ is the dollar sign) 6. (0%) * Dated money amounts (ex. Five 1929 US dollars) * Support for non-numerical representation (ex. 10 dollars 99 cents, five pounds 23 pence) Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
Scott Reynen wrote: span class=moneyabbr class=amount title=0./abbrabbr class=currency title=USD¢/abbr/span My bad. I had missed the title=0.99 part earlier. This will work for all currency amounts of recent times, as all currencies are now officially or de facto decimalized (UK was one of the last ones in 1971, see http://en.wikipedia.org/wiki/Decimalization), and indeed saves us from talking about units for now. Thank you, Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] new standard for product information
Ted Drake wrote: I would thin this standard could be adopted quickly via microformats. What are the thoughts? I think microformats would probably help adoption with the less sophisticated (smaller) retailers quickly, but would not satisfy all the business needs of more sophisticated manufacturers. More: Microformats can help for product content that is on the manufacturer's Web pages. But not all of the product content is on their Web pages, especially for sophisticated manufacturers. One example is pricing rules, which can be very complex. See the ARTS data model http://www.nrf-arts.org/xml_dictionary_5/XMLDictionary-NonMembers.html. Moreover, having worked on manufactuer/e-retailer collaboration software in the 90s, my experience is that some, if not most manufacturers are worried about how they differentiate on the electronic shelf (i.e. the comparison shopping site), how their brand is represented, and as a result are actually reluctant to making their Web site content easily scraped, taking the risk that their content end up in places they don't want to end up. So, they typically resort to integration mechanism or other concepts (retailer-manager store-in-store) they can control and authorize for select e-retailers they work closely with. Guillaume ___ 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: * Currency symbol identification from other part of the text This means that in $25 dollars, we would mark up $ as the currency symbol. See http://microformats.org/wiki/currency-brainstorming#Andy_Mabbett under symbol bullet for an explanation of this. * Global currency definition This means that a currency can be defined once in the document (just like you define once a global variable in a program) and then refer to when needed, instead of locally defined every time. See for instance: http://tonto.eia.doe.gov/dnav/pet/pet_pri_spt_s1_d.htm where there is a global legend Products in Cents per Gallon, and then the numbers have no currency symbol. * Amount identification from other part of the text This means that in $25 dollars or twenty five USD dollars, we would mark up 25 and twenty-five as amount so that it can easily be extracted from the rest of the string. With a numerical value it may not be necessary, with a textual representation, it may be necessary. So, depending on the scope of the proposal (do we want to support textual, another feature choice in the poll), this may be a related important feature or not. Hope this helps. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency Quickpoll: Preliminary results
In my previous table example, you should read: tr th scope=colpricea href=#u1 class=include/a/th /tr tr td24/td /tr Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] currency quickpoll results and suggested next step
See below the results for What do you think are the [4] most important features [out of 8] for the currency proposal? Thank you to all who have participated. My recommended next step is to edit the current proposal so that it focuses only on the 3 top features below, with the goal to get a first version, lean yet functional, officially approved as soon as possible, and push back the other features to a subsequent version. Let me know what you think. Guillaume --- Unanimity (100%): * Identification of currency used (ex. US dollars versus Canadian dollars) Majority (50% and more): * Currency unit/denomination used identification (ex. dollar versus cent, pound versus shilling) - 62.5% * Amount identification from other part of the text - 62.5% Divided (50%): * Global currency definition (ex. all amounts in table are in US dollars) * Support for combination with units (ex. $34 per gallon, $2 per miles) Minority (50% and less) * Currency symbol identification from other part of the text (ex. $ is the dollar sign) - 12.5% None (0%) * Dated money amounts (ex. Five 1929 US dollars) * Support for non-numerical representation (ex. 10 dollars 99 cents, five pounds 23 pence) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] currency quickpoll results and suggested next step
Mike Schinkel wrote: My opinion is this sounds like a great idea! Will you be doing the edit on the current proposal? yes, I intend to do before the end of this week. I am surprised however at the number of people who felt Currency unit/denomination used identification was important and it seems like an edge case to me. I'm hoping that this become an optional aspect as opposed to always required, and the same with amount, actually. I think that you can change your vote (assuming your re-vote from the same machine and cookies are one and haven't been erased). Let me know. Otherwise, I think the simplest is that I remove your vote from the final results. Also, will the current spec worry about the other concerns so as not to eliminate the possibility of including them later, or by asking am I just removing the benefit of focusing on the top 3 by asking? I suggest the current spec focuses on the top 3. The future will be moved to a 2.0 page. Any concern that some aspects of the 1.0 spec are not be forward-compatible with 2.0 is relevant for 1.0. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] currency quickpoll results and suggested next step
Joe Andrieu wrote: This may be a fact of test bias. The test asked for four answers, so I selected four answers, and #4 for me was Currency unit/denomination used. I didn't really have my heart in it, so to speak. Sorry for this. You're welcome to change your vote, if you want to. See earlier post. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] include-pattern support for data outside of the current page? [Was: Visible Data...a Microformat requirement?]
The thread around invisble microformats reminded me of this example from the visible Web. Maybe relevant to this discussion, if not relevant to the include-pattern. An index page (http://www.eia.doe.gov/emeu/international/oilprice.html) contains currency information that applies to all pages it indexes. For instance, in this data page (http://quotes.ino.com/exchanges/?r=NYMEX_CL), there is no unit/currency defined, and we only know the numbers are U.S. Dollars per barrel b/c it was defined in the separate page we came from. Should my data page contains an include-pattern link to the currency definition from the other page? Is it good for the interpretation of the data on one page to rely on data on another page? anyone has an opinion? I'm asking since I haven't seen on the include-pattern page any clear direction on this. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: [hcite] indentifier
Ryan Cannon wrote: I'm not sure we want to get into the morass of defining values for TYPE, but if an identifier is for a specific resource, we should allow a way to tell which resource it's from. I have been thinking of identifiers in the context of another standard. I think this could be a separate recommendation from the hCite, which could be reused in other contexts. The conclusion of my analysis are: Every identifier is a collection of predicates of the subjects that together uniquely identify the entity (ex. book title, book author, and book edition year and type - if that works). Using lexical identifiers 'shortcuts' to these collection of predicates can be useful. I call these lexical identifiers issued identifiers and sometimes, some of these predicates happen to be issued identifiers themselves. An issued identifier is issued by another entity. This other entity may have also been issued an identifier (typically a domain name). At the end, all these identifiers can be tracked back to a single root identifier issuer. In addition, an issued identifiers may be permanent, or may expire. My 2 cents Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
hPrivacy [Re: [uf-discuss] Numbers of Microformats in the Wild?]
Does this OpenID+hCard deals with selective privacy? i.e. showing certain information to only some class of people? I have tried to solve this problem on my own with something I call hPrivacy. I know this is more semantic HTML than Microformats, but I think this may be relevant to this list. hPrivacy is about using hprivacy-friends, hprivacy-pro, etc. class attributes in the HTML to annotate what I want specific groups to see about my identity. A proxy or Web server module is used to filter the content based on the visitor's group. It's very early and not finished (visitors cannot authenticate or provide secrets that prove they belong to a particular group, in a way akin to Danah Boyd's SecureId http://smg.media.mit.edu/people/danah/thesis/thesis/secureid.html), but I have implemented the proxy that filters the HTML content based on the group. Here is what the public sees: http://lebleu.org/index.php Here is what my friends see: http://lebleu.org/index.php?group=family (of course this URL is just for the prototype) Here is what my pro contacts see: http://lebleu.org/index.php?group=pro (of course this URL is just for the prototype) In the source HTML of these pages, you won't see any hprivacy- attributes as they are removed to not provide any clue as to which group a visitor does not belong to. Here is the actual HTML with the hprivacy attributes: http://lebleu.org/hcard.html (should be in a private folder retrieved by the Web server module/proxy) where you can see all the annotations. Let me know what you think. Since this is not a microformat really, as it is not on the Web, if some people find it useful and would like to discuss it or help me with the implementation, I was thinking to move this to a separate Web site hprivacy.org. Guillaume Kevin Marks wrote: On Apr 12, 2007, at 8:06 AM, Kevin Lawver wrote: I'm presenting on microformats at Web 2.0 Expo (well, hopefully, if they can move me back to my original time) next week, and would love to have more examples of folks using microformats as APIs. I ungraciously stole an idea I saw on the list of grabbing the URL used as an OpenID and looking for an hcard on it to build a demo for my talk, but, I'd love more examples to point to. I made an openid+hCard example at http://kevinmarks.com Also, anyone have the digits that Tantek likes to use about the number of pieces of microformatted content out there in the wild? I don't have the latest... ___ microformats-discuss mailing list [EMAIL PROTECTED] http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list [EMAIL PROTECTED] http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCards and Companies
Duncan Cragg wrote: - I would like to drop in a field for the ticker code: NASDAQ:MSFT, etc; also the SEDOL and ISIN codes. I would think that stock tickers / security identifiers deserve a microformat of their own before we can think of aggregating it into other ones. I have a bit of background in this area and I would be happy to contribute some work on this (gathering examples from the Web, practices from FIX and OFX, etc.), if others are willing to participate. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCards and Companies
Scott Reynen wrote: See: http://microformats.org/wiki/stock-symbol-examples Sorry I missed this one. I did vaguely remember that something had been done, but couldn't find it on http://microformats.org/wiki/exploratory-discussions What category should it be referenced in? Current ? Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] ufXtract - new microformats parser
Glenn Jones wrote: It has been built from the ground up to take configuration objects which allow the parsing of different microformats or POSH patterns. Great job Glenn, I was wondering what the configuration objects look like. Do you use a grammar for each uf expressed? Thank you, Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] ufXtract - new microformats parser
Thanks Glenn, I wonder what you and others think about the following idea. Since one of your output mechanism is XML, I thought an idea might be to use XML schema (with possibly uf-specific appinfo annotations/documentation where relevant) to declare each microformat, instead of serialized C# collection in a bespoke syntax or a new microschema syntax (see separate thread). Granted, not everything can be expressed in the XSD (just like not everything can be expressed in serialized C# collections), but a lot can, and it might be valuable to developers who want to do microformat processing via classes generated from the XSD, instead of via DOM/XPath. What do people think? what am I missing? Thanks, Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Tentative proposal: Sub-microformats to streamline common microformat patterns for simple data
Andy Mabbett wrote: Because they're the most appropriate semantics; I don't agree with that, but I'm not going to argue about it. and because people are already using the long-hand version of hCard to do so. vCard is an electronic business cards standard; hCard is not merely an electronic business cards standard, but already has wider uses. Ok, I didn't know that. I'm really just raising a warning. I can think of at least one discussion here (http://microformats.org/discuss/mail/microformats-discuss/2007-November/010974.html) that was arguing how one of the wider uses of hCard, particular for microformatting narrative content might not be actually a publisher's best practice. In addition, my experience in other communities is that favoring reuse over semantic precision can result in very difficult machine processing (due to disambiguation requirements), which may defeat the point of microformats: reusing the same tag/classname seems good at first, but then people realize that a particular tag/classname's meaning depends on the context, i.e. what other tags/classnames are present, and the processing complexity increases. While microformats are for humans, I see microformats as a way to reduce the costs of machine reading. If the meaning of a tag/classname is highly context-sensitive, then you may end up building the same $1M code that you would have to build if there was no microformat. Are you suggesting that we use different class-names to mark up the same data? That's directly in contravention of the microformat principles; and would put more weight back onto the shoulders of publishers. No. I don't think that's necessary. I just think that the John Smith in your example ...as John Smith said in... is different data than in My contact information: br/John Smith br/Cell: (415) I would tag the John Smith in your example as an entity name, a formatted name, a person's name, a reference to an entity, but not as something that is also use for electronic business card. Otherwise, I have to look at the context to understand what I'm really supposed to do with this information. For instance, a software like tail will have to disambiguate between vcards that are merely a person name (and are not very valuable in my opinion to export to an address book) and vcards, which actually carry contact information. In other words, my opinion is that a vcard implies a named entity, but a named entity does not imply a vcard. In other words, I would be perfectly happy to simply microformat ...as John Smith said in... as ... as span class=fn nJohn Smith/span said in I don't see the value of prefixing fn and n by vcard. I'm probably missing something though, if so, let me know. Who says that that information is one the page in question? I assume you mean on the page in question. I'm not saying it is. I'm saying that if it is not there, then the John Smith in ... as John Smith said in... is not a contact card, but if there is such contact information for this person somewhere else on the page, or on a different page, then an href ... as a class=fn n href=http://johnsmith.com/home#JohnshCard;John Smith/a said in... is what would make sense to me. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard to represent simple entities
Andy Mabbett wrote:
The hCard spec says that:
hCard is a simple, open, distributed format for representing
people, companies, organizations, and places, using a 1:1
representation of vCard (RFC2426) properties and values
note that's NOT:
hCard is a 1:1 representation of [a] vCard...
For clarity, the former can be distilled to:
hCard is for representing people, companies, organizations, and
places
I know, but I still think there is a sweet spot for hCard (portable
friends list, distributed address book with personal electronic cards,
anything use case that involves exchange of contact info of some sort),
and still think that microformatting narrative content with hCard where
there is no contact info and where people, organizations, and places'
names are only used as references/identifiers is outside of that sweet
spot. If there is no such sweet spot, then why excluding ships? they do
have a name, location and contact info.
Another argument is that: if we microformat all people's names with
hCard, then, if I want to style my actual electronic card from mere
people's names/references/identifiers mentioned in my blog posts, I will
have to wrap the hCard used for electronic cards into an element with a
new classname to communicate precise meaning. So, IMO, I do lose
semantic meaning by widening the use of hCard beyond its sweet spot.
But I won't argue with the spec. So, case closed AFAIC.
That the classes fn and/or n might already be used, with different
(or no) semantic meaning, to style the page in question?
Sorry if this is not really the point of the discussion, but what I'm
reading here is that classname fn may have different meaning if used
outside of an element of class vcard.
Saying this is to me equivalent to saying the vcard classname syntax
is syntactic sugar for the concept of a namespace (as is vcard-fn). My
understanding was that the concept of namespace, not just its xml
syntax, was an antipattern in microformats. Am I mistaken?
Re: styling, I believe I can use (at least in Firefox):
.hcard .fn { ... }
to specifically style the element of class fn found in an element of
class hcard, and:
.fn { ... }
to specifically style elements of class fn, which do not appear within
an element of class hcard.
Guillaume
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: natural language hCards (was Re: [uf-discuss] web programmers vs web designers and microformats)
Tantek Çelik wrote: Ah ok, this is what Jeremy Keith refers to as natural language hCards, wherein you simply markup inline references to people accordingly. I believe Wikipedia calls these inline hCards, which sounds to me like a good name. http://en.wikipedia.org/wiki/Template:Hcard-bday Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RDFa Basics video (8 minutes)
Manu Sporny wrote: Constructive feedback would be great, as I'll probably be doing the advanced RDFa tutorial in a month or so, and will need to know what worked and what didn't in the RDFa Basics video. I'm relatively new to RDFa and this is a great introduction. I'm probably going to say things you've already heard, so please bear with me. For someone like me who has learnt to value the accessibility of standards, the brutally honest takeaway of your introduction is that RDFa does what microformats do and probably more (otherwise why would it exist?), but not clear what exactly and plus it requires XHTML 2.0 and complex syntax. So, when comparing uf and RDFa, adopting RDFa seems a huge leap of faith and a lot of work considering it requires XHTML 2.0 and your introduction does not mention any application supporting RDFa... So, if the goal of this video is to evangelize RDFa to a large audience, I think it would be great to explain why (ex. why id, class and a/href/rel haven't been leveraged more to represent RDF triples) and also explain how an implementation can best leverage the backward-compatibility/evolutionary benefits of microformats with the RDFa more formalist and consistency with other w3 standards. Last, if you believe like me that applications drive standards, not the reverse, then I think what will ultimately get people excited is to have a demonstration of how this content can be leveraged by an application once published and gathered in a RDF store. In an ideal world, putting a aside resource constraints issues, if I had to evangelize RDFa, I would start with the application, for instance showing content in a browser, then showing how it's possible to type queries against this content in a browser plugin. Then only I would show the implementation, and at the end possibly, adoption numbers such as how many people have downloaded the plugin so far. My 2 cents. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: url and tel
Andy Mabbett wrote: When did you last see a listing of, say, Pizza restaurants that labelled each telephone number as work? When did you last see a listing of, say, Pizza restaurants that included the managers' home numbers? In that same vein, we could ask: when did you last see a phone number not being a work number when both a person's formatted name and organization name were present? So, to avoid the meta discussion and go back to Kat's specific problem (she wants to specify a phone as work but without the content containing work or any of its abbreviations), maybe something that would work would be to have an implied 'work' tel type when a fn and an org that are both present and a tel type is not present. I believe we could have an implied 'voice' type in this case as well. Sorry in advance if this idea has already been proposed/discussed. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: url and tel
Tantek Çelik wrote: On 1/7/08 5:19 PM, Guillaume Lebleu [EMAIL PROTECTED] wrote: voice in fact is already default value of the type sub-property for tel: http://microformats.org/wiki/hcard#adr_tel_email_types Thanks for the pointer. Sorry I missed that. Perhaps you could document your brainstorm for implied 'work' tel type when fn and org are present (and the same? is this for organization hCards only?) on the hCard brainstorming page? Just did at http://microformats.org/wiki/hcard-brainstorming#Implied_work_tel Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Hcard - marking up sms short codes
Philip Tellis wrote: On 08/01/2008, Jim O'Donnell [EMAIL PROTECTED] wrote: I don't understand this. Why can't type=cell be dialled for voice calls? I think the problem is that they can, but SMS short numbers can't. so should there be a way to distinguish voice enabled numbers from SMS only numbers and data only numbers? SMS support is currently implied from 'cell' TEL TYPE in implementation I know of (ex. Window Mobile / Apple iPhone). Right now, we just currently can't have a non 'cell' phone number described as supporting SMS, which is the case of short codes. Adding a TEL TYPE value 'sms' seems to be a viable possible option. It is just another service available @ the phone number, just like voice, fax, etc. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: url and tel
Andy Mabbett wrote: In that same vein, we could ask: when did you last see a phone number not being a work number when both a person's formatted name and organization name were present? Today - and nearly every time I look at a contact page about someone who does voluntary work. Andy, Can you point to an example that will help me understand your point? TIA, Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: url and tel
Andy Mabbett wrote: In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes In that same vein, we could ask: when did you last see a phone number not being a work number when both a person's formatted name and organization name were present? Today - and nearly every time I look at a contact page about someone who does voluntary work. Can you point to an example that will help me understand your point? http://www.westmidlandbirdclub.com/records/recorders.htm Ok. But I still don't understand why you say that in the case of voluntary work, a single tel with an unspecified type cannot be assumed to be of type 'work' if an org is present. The vCard RFC recommends the use of work to indicate a telephone number associated with a place of work. The case above seems to qualify: voluntary work... is work and the place of work is WMBC and the phone number provided is clearly associated with WMBC. So it seems to me legitimate to assume that the tel provided are of type 'work' even though it is not explicitly stated in the content. I still don't get your point. Can you elaborate? TIA, Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Hcard - marking up sms short codes
Andy Mabbett wrote: While I'm aware that we're discussing possible changes to vcard, rather than ways of using the current hCard, I think this is a case where looking at what people actually publish (and allow for in forms) on the web; and what address-book apps allow for, would be useful (even is a revision to vCard, or changing user behaviour, ultimately causes changes in the latter) Andy, I started to document the address book/PIM practices in http://microformats.org/wiki/vcard-suggestions#TEL_Type_Definition Not sure if that's the best place to do so in the wiki though. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Hcard - marking up sms short codes
Philip Tellis wrote: Would you, for example, put down, preferred from 0900-1700IST, except on weekends and between the 5th and 15th of May, unless you're signed up with plan foo on provider bar as meta info for the number? Here is a real-life example of a similar case (opening hours bound to specific phone numbers, not to the org they are associated with): http://www.theaa.com/aboutaa/contact.html How would you see this content marked up? as different hCard with different FN of the same (included) ORG? or as one hCard? You can easily find other instances by searching for Contact us 9AM or call me after 7PM Anyway, I think people do publish this type of information, and we should look into how to best address this requirement. Whether they do it to maximize customer satisfaction (office hours) or to minimize communications costs is not our problem. That said, I can't resist to quote the following from one of Danah Boyd's posts, which I thought about right away when I read your example: I'm fascinated by how U.S. teens build intricate models of which friends are available via mobile and which aren't. Teens know who is on what plan, who can be called after 7PM, who can be called after 9PM, who can receive texts, who is over their texting for the month, etc. It's part of their mental model of their social network and knowing this is a core exchange of friendship. http://www.zephoria.org/thoughts/archives/mobile/ I don't know any social networking app where people can share this type of information (ex. remaining text message for the months, unlimited WE hours, etc.) but if you know, let me know. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Possible alternative methods for include
Andy Mabbett wrote: A brainstorm of possible alternative methods of using include in microformats, avoiding the use of the problematic OBJECT or empty-link variants: foo id=birminghamid class=localityBirmingham/foo then: foo class=adr birminghamid[...]/foo What about: span class=adr id=myaddressmy addressspan a href=#myaddress rev=propertyOf class=localityBirmingham/a ? The idea is that: span class=adr span class=locality.../span /span is in my view a convenient short cut for: span class=adr id=#myadress.../span a href=#myaddr rev=propertyOf class=locality.../a The shortcut notation is convenient when properties are grouped together in the HTML tree (usually the case), while the subject/predicate/object works in any case. In other words, in the first case, you can view the parent/child relationship (span of class adr is the parent element of span of class=locality) as overloaded semantically: it means both part of (in HTML) and property of (in microformats). Don't mean to start a debate on properties vs relationships... Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Possible alternative methods for include
Andy Mabbett wrote: In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes Andy Mabbett wrote: A brainstorm of possible alternative methods of using include in microformats, avoiding the use of the problematic OBJECT or empty-link variants: What about: span class=adr id=myaddressmy addressspan a href=#myaddress rev=propertyOf class=localityBirmingham/a ? That seems to presume, wrongly, a 1:1 relationship between the included data and the microformat. Consider: span class=adr id=myaddressmy addressspan span class=adr id=mysecondaddressmy second addressspan a href=# rev=propertyOf class=localityBirmingham/a Sorry for the late response. In this case, I would group the two adr in a container and have the href point to that container. For instance: divOur company has offices at two addresses in a href=#adrlist1 rev=propertyOfspan class=localitySan Francisco/span/a: ul id=adrlist1 li id=adr1 class=adrspan class=street-address665 3rd Street/span, and /lili id=adr2 class=adrspan class=street-address123 Folsom/span/li/ul./div adr1 and adr2 inherit the property attached to their parent ul. It also requires publishers to make a within-page link, where none existed previously. I am not sure what you mean. I don't see why this is such a problem when we require them to markup content anyhow. Furthermore, rev is deprecated for use in microformats. Ok, sorry I had missed point 2.10 in the rel page. I won't push the above idea further in this case, but since there is not much content in there that justifies the decision, I'd appreciate any pointer anyone has about how rev came to be deprecated in microformats. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Calais: a POSH project?
Bob Jonkman wrote: Via Techdirt [1] I found an interesting project called OpenCalais [2]. It seems designed to take arbitrary text documents and spit out semantic RDF. There's absolutely no mention of microformats on the OpenCalais web site, but I can see incorporating microformat markup into the output. And, of course, any effort at making the Web more POSH is A Good Thing. Bob, thanks for the link, given the RDF output, I would imagine RDFa or eRDF would be more straightforward for them to add than microformats. The site seems sparse on working code or examples, and I haven't even tried to download the developer package (needs a developer key -- not so Open, IMHO) I gave it a quick try. Seems to me very specific to financial/business news, but the roadmap says the 3rd party extensibility to other domains will be available later this year. More: http://lebleu.org/blog/2008/02/02/kicking-the-tires-with-opencalais/ Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes If you really want to make the distinction between a publisher, a drummer, a singer, a technician, and someone else, you can always use an hCard and utilize the role property That presumes that the roles are exposed in the page; they may be if or, say a producer, but often using the verb (produced by...), and frequently are not, We don't need to say that Beethoven is a composer, when saying Beethoven's fifth. That's clear to a human (well, mist humans of any western education!) from context; but not to a machine. Before anyone cries hidden metadata, how often to we explicitly say that Mabbett is my family name?, or that 21 High street is a street address? I agree with others that these are edge cases for microformats. I don't think you are correct when you say that only a human can infer Beethoven--(composerOf)--fifth, from Beethoven's fifth. As far as I've seen in other more lucrative domains than music, a well-trained semantic software extractor working off sufficient content, plain old grammatically-correct english and music metadata would do that job with less sweat than an editor will take to write the content and mark it up in hAudio or something else (not to say to come up with the markup that works in these edge cases in the first place). Grammatically-correct english IS semantic markup, in a way. I think microformats' sweet spot is easing semantic extraction in cases where the level of structure is high, and the plain english context is low. The back of an album that lists tracks is such a case, its entry in Gracenote, a list of friends, electronic business cards, etc. are good examples as well. A plain english critics' review of an album on the other hand with lots of context, but little structure is a case that is economically much better handled using semantic analysis than with $1M markup. I'm not saying that microformats should not try to make formats that work with plain old English or natural language (I've been trying myself), I'm just saying that we may consider the fact that the ROI will most likely be low and other technologies will compete better there, so we might just focus our time on where we have the biggest chance of straightforward adoption, then only look at solving the plain english cases, instead of trying to solve everything at once. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
focus of microformats (was: Re: [uf-discuss] haudio contributor)
Andy Mabbett wrote: Everything is an edge case, depending on which point you're looking from. I'm conceding that I'm looking at these natural language examples from a particular perspective, the economic one, to decide what is an edge case or not, and that I'm just assuming that this economic perspective is the most important perspective to have when deciding where to focus the discussions. In particular, I'm looking at the following costs: - costs for the community to define a microformat that support these natural language, unstructured cases (this encompasses the include discussion). - costs for a human editor to understand the microformat and implement it. - costs for a software developer to implement a microformat parser. From what I have seen, these costs are high for the natural language examples in general, whether it's for hCard or hAudio. For other examples (structured content) these costs are low. The value is the same in both cases. Note that because these costs relate to unstructured content, they only apply to compound microformats which by nature imply structure, not elementary microformats. For instance, a microformat for a person's name (fn) is relatively easy to define, use and implement. Same thing for a money amount. A microformat for a person's complete contact information that works in all cases, not just the seminal blog's about box, has in comparison much higher costs of definition, use and implementation. A microformat for a resume, to the extent that a resume is highly structured is possible to define, use and implement. In comparison, a bio with the same content would most likely not be as easy. how many of us have access to a well-trained semantic software extractor, and what music metadata is widely used? It's not because I don't have something that others don't have it, and that I should ignore the fact that they have it in my decisions. Obviously, semantic extraction from the Web is of utmost importance for a lot of organizations, some with lots of resources, some with less, but all operating under the same economic rule: how can we lower the costs of understanding what people put on the Web with no/minimum costs/change of habits on their end. We all compete, and hopefully not a single one will win but some will be more successful for some classes of problems than others. Knowing what class of problems microformats are most likely to compete on is to me very important for the maximizing the returns on our time spent here. By your argument, we wouldn't need microformats at all. No. As I mentioned already, the costs listed above are the smallest in the case of structured content with little context. Guillaume Lebleu. T(W): 415 408 5856 has less context and more structure than My name is Guillaume Lebleu. My phone number at the office is 408-5856. My area code is 415.. The first example is a charm to microformat, the second one is less so. A semantic extractor will most likely do a poor job in first example and will do a better job at understanding the second example. As a result, it is my opinion that if microformats were officially focusing on structured content publishing (most known as blogging/social networking), we would have less discussions and probably more microformats. If that's where you want to concentrate your use of microformats, that's fine, but that's not how I see them, and I see nothing in any of the specs or other defining documentation which restricts them in that way. There are no written rules as of today, and in theory we don't need such. But I've seen a lot of discussions and time spent on cases that don't make economic sense. The it's on the Web, so it's relevant for microformats was excellent to avoid the known pitfalls of standard organzation (what if?) but also opened the can of worms in my opinion. It should in my opinion be: it's elementary pieces of data or structured content on the Web, so it's relevant for microformats, or something similar. I think that's an opinion - a restrictive one at that - not shared by everyone here, certainly not by me, and not supported by past experience of developing and using microformats. Restriction is the negative name of focus. Focus is key to success. I've yet to see someone successful at boiling the ocean. But I indeed don't know to what extent this opinion, or similar, is shared in this community. I only know you disagree with it. I'd be glad to see it put for a vote. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Apple Data Detectors
Thom Shannon wrote: Not sure if anyone's mentioned this before but the new version of Apples Mail has functionality similar to what microformats is trying to enable (hCard and hCal) You can mouse over data in an email like addresses, phone numbers and dates, then add them to your address book/calendar. http://www.apple.com/business/videotips/?movie=maildatadetectors A few things spring to mind: a) Does it use microformats if they're present? - I just tested it, it put the postcode in the state field so I guess not b) Wouldn't it be nice to get hold of their pattern matching code! c) Interesting how they've done the interface, not too far from some mock-ups I saw for FF3, what can we learn from it? Thom, you probably have found http://www.miramontes.com/writing/add-cacm/index.php, which describes ADD as it was introduced in 1998. The side column only mentions that the current implementation looks Livedoc/ADD-like. It was an interesting read to me. What I have been thinking more and more and what this tells me again is that the same way we talk of POSH and microformats, we could talk of plain text or plain old english formats, essentially standardizing how people write dates, addresses, etc on the Web or on their emails. Asking people to write Tuesday, February 5, 2008 in this order, with the commas, etc. is very likely even simpler for normal people than writing abbr class=foo title=2008-05-02Tuesday, February 5, 2008/abbr. Knowing that receivers will be able to do more with this just by writing it this way, like not forgetting your event, is a big value when comparing it to the additional costs. Even english writers can do this, not just Web developers. Of course, the issue is that this is currently an Apple-only plain-text microformats and implementing may be a bit more work than parsing a microformat (only guessing here). So cheap publishing costs, but possibly more expensive/not as widely available consumption mechanism. I wonder if this technology could not be used in a reverse way: detect formats as I'm typing (names, addresses, phone numbers, etc.) in plain english and convert them in microformats (cheap publishing costs, cheap consumption costs). The way I see it is that it would provide some code-autocompletion-like feature that makes a little calendar or contact list show up as I'm writing. For instance, if I start to type Thanks Tho, Tho is recognized as being likely a person (following Thanks + I have two people in my contacts matching Tho), and I'm prompted to confirm whether I'm talking about Thom or Thomas. I select Thom and behind the seen the right microformat is added to my content for the convenience of those that will consume my content. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: In message [EMAIL PROTECTED], Robert O'Rourke [EMAIL PROTECTED] writes And are groups/bands considered to be an organisation? Yes: foo class=fn orgPink Floyd/foo not least because the alternative: foo class=fnPink Floyd/foo would be optimised (sic) to have a given name of Pink and a family name of Floyd. I don't disagree that groups/bands should be considered organisations. That said, I don't think the reason offered here is a strong one. The issue described is directly related to FN's (over?)reuse beyond its original vCard scope of person names, to cover any name. [Not only has this led to the fn/title debate, but it seems some implementors are confused between following the vCard semantics (FN only for person names) or the hCard ones (FN for any name). See. http://cinematreasures.org/theater/365/, which uses an empty FN, resulting in their vCard not being detected by Operator, only the address] Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes not least because the alternative: foo class=fnPink Floyd/foo would be optimised (sic) to have a given name of Pink and a family name of Floyd. I don't disagree that groups/bands should be considered organisations. That said, I don't think the reason offered here is a strong one. Neither do I; that's why I said not least. Sorry if I misinterpreted: I'm not a native english speaker. Doesn't not least because [reason] means that [reason] is not the least reason, i.e. a strong one? Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Using hCard to publish a member list
Walter Logeman wrote: Is there some way to get sliced and diced views of that list? An easy way for me to publish several lists or to have a list generator of some sort for viewers? Walt, not sure if the following will address all your requirements, but it is a start: I would use an HTML table with one hCard in each row. Then, I would use http://www.kryogenix.org/code/browser/sorttable/ to make each column sorttable. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Apple Data Detectors
Toby A Inkster wrote: Guillaume Lebleu wrote: What I have been thinking more and more and what this tells me again is that the same way we talk of POSH and microformats, we could talk of plain text or plain old english formats, essentially standardizing how people write dates, addresses, etc on the Web or on their emails. Asking people to write Tuesday, February 5, 2008 in this order, with the commas, etc. is very likely even simpler for normal people than writing abbr class=foo title=2008-05-02Tuesday, February 5, 2008/abbr. One problem with that is that it will find matches on people who aren't even intending to use your plain-old-english format. They may happen to be including Tuesday, February 5, 2008 on their pages with a different intended meaning. 2008 could refer to eight minutes past eight PM in military time -- unlikely, but possible. And as you move away from dates, phone numbers and postcodes which have relatively parseable formats, towards locations, people's names and job titles and so on, the likelihood of false matches increases. The use of explicit tags to mark up information do make microformats slightly harder to use, yes. But the key is that they also make microformats much easier to explicitly not use. Toby, I understand the challenge of disambiguation and the value microformats bring in terms of easier parser implementation and more reliable information consumption experience. The challenge for average people writing microformats can't be underestimated though. I strongly believe that the time where disambiguation costs are the lowest are at publishing time, but this is also the time where you are focused on the english content, not the microformats. This is why in the second part of the post you cited, I suggested the use of Apple Data Detectors' like functionality, not to detect objects in plain old english (POE) in published content, but to detect objects in POE at the time they are written and ask for the user for disambiguation at the same time, in a way that the underlying microformat markup is generated, but without the user having to know the syntax. I'm thinking of this particularly in the context of writing a blog post: writing 1 hCards just to say My friend Joe is way too much for normal people. On the other end, if, as I type this, I get an intellisense-like list of my contacts that I can select from, then I can just select Joe from the list and have the microformat markup added for me (just like Wordpress adds a lot of markup that isn't in the visual editor or like Wiki converts simplified markup into HTML markup). Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Apple Data Detectors
Toby, Here is an implementation of what I described in my previous post by Yahoo. http://shortcuts.yahoo.com/ They offer a Wordpress plugin that detects objects from plain old english patterns as you write your blog post, then asks you for disambiguation and whether you want to link to it (to their content obviously). I've not reviewed it yet, so don't know if they use uf. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Editor integration (was: NLP was Apple Data Detectors)
Brian Suda wrote: The ideal solution would be for somesort of plugin in the CMS so you can simply highlight areas and push a button and it will add the microformatted information Do you or anyone know of any microformats integration work with TinyMCE or any insight into why it hasn't happened yet? Seems like there has been some talk about this on this list back in 2006. http://microformats.org/discuss/mail/microformats-discuss/2006-March/003298.html TIA, Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats and privacy
Thom Shannon wrote: What is the response to the privacy argument? As a carefree technophile I'm happy publishing personal info on the web. But when you're trying to convince a major social network to add semantics that makes their users personal information easier to harvest and possibly abuse. Is there any answer? Thom, Last year, I brought up the idea of something I named hprivacy and presented a very primitive hprivacy html proxy filter prototype with three groups: pro, family, friends and public. See http://microformats.org/discuss/mail/microformats-discuss/2007-April/009264.html This is a tiny prototype that is not integrated with a tagged social graph, so for now, I simulate the filtering by passing the group in the URL. But you'll get the idea. Some links have moved: http://lebleu.org/projects/hprivacy/index.php (what the public sees) http://lebleu.org/projects/hprivacy/index.php?group=family (what a family member would see) http://lebleu.org/projects/hprivacy/index.php?group=friends http://lebleu.org/projects/hprivacy/index.php?group=pro See the markup: http://lebleu.org/projects/hprivacy/hcard.html (obviously, in real implementation, this would be pulled from a non-public folder) There didn't seem to be much interest on this list. Maybe because it's not so much about data formats and/or because it's about marking up content that is not public to anyone (microformats seems to have a bias toward public content). Let me know what you think. Also, someone helped me design a cool logo: http://hprivacy.org Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
Belov, Charles wrote: I feel it is unreasonable to ask a non-technical person to produce ISO-format dates/times, so microformats do not produce an acceptable solution at this time for marking up meeting announcements. I agree that only an editor extension would make writing ISO-format date/time practical by humans, which I never felt was compliant with designed for humans first, machine second. What about the idea of a plain old English microformat (POEM?) based on well-known practices in various languages [1], in the tradition of paving the cows path: these practices are pretty-well established IMO and used by authors in the newspapers, magazines, etc. For instance, in English: span class=dstart lang=en-usOctober 5, 2004/span span class=dstart lang=en-us10/5/2004/span span class=dstart lang=fr5 Octobre 2004/span span class=dstart lang=fr5/10/2004/span The locale could be specified locally (lang=en-us) or inherited from the HTML document or a containing div. Granted it would make the parsing more complex, but it would comply with designed for humans first, machine second. Also, additional class would be required to distinguish the date part from the time part in something like: span class=dstart lang=en-usspan class=dateOctober 5, 2004span at span class=time6PM/span/span Just an idea, Guillaume [1] http://www.ego4u.com/en/cram-up/vocabulary/date/written ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
Toby A Inkster wrote: Guillaume Lebleu wrote: span class=dstart lang=en-usOctober 5, 2004/span Cognition already supports this as a last ditch attempt at parsing dates - Thank you for the attempt. but I wouldn't recommend it get adopted widely. It's too unreliable; Why is this that requiring that English content writers (I mean only those don't want to use the abbr pattern) to write dates and times in accordance to the existing precise rules of English grammar and publishing style guides (ex. AP stylebook) they know about (or used to know about) is less reliable than asking them to write them twice, one in the format they like and a second time in an ISO format most of them likely don't know about in an relatively arcane syntax? I think it really depends on where our priorities are as a community. If most hCalendar items are destined to be software-generated (including via, say, a TinyMCE plugin) or are added by specialized staff, after the content is authored, I agree with you. On the other hand, if we want actual content authors to be able to add this mark-up, then I think plain old English microformats may be more reliable, and actually more used in the first place, than dark data or RDFa. too much work to deal with internationalisation; I don't think we need to support all locales at once. I don't know in how many written languages BBC publishes in, but it might be that supporting en-uk and en-us might be enough for a start. Also, one can imagine that Microformats tools could focus on the most common written languages and then expose hooks for others to implement support for other locales. too much work full-stop in languages that don't provide a handy library that takes care of most of the work. True, but again, what are our priorities? making programmers' life easier or making content authors and content readers' life easier? Anyway, there are other problems. Just trying to think outside of the class. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
Belov, Charles wrote: I'd suggest modifying that to not require the computer to parse the date. Something like: span class=dstartm lang=en-usOctober/span span class=dstartd5/span, span class=dstarty2004/span +1: DRY-, POSH- and humans first-compatible IMO. Maybe the following may be POSHer and backward-compatible with the existing dstart class name convention? span class=dtstart lang=en-usspan class=monthOctober/span span class=day5/span, span class=year2004/span/span Just a thought. G ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Human and machine readable data format
Glenn Jones wrote: As the exchange between Ben and Jeremy has shown what is human readable is up for debate. Having spent far too much time looking at the ISO date formats they are all readable to me, but I know that's not the case for everyone else. We need to expand the discussion and ask those involved in the accessibility area what is an acceptable human readable format. The format 2008-01-25 is a compromise and as such we need to ask the other party is it's an acceptable middle ground. For example would the BBC accept 2008-01-25 in the title of a abbr. Since the BBC's request was specifically related to screen readers, we may want to distinguish machine-readable, human-readable and human-hearable. I think there is less debate re: what is human-hearable than there is debate re: what is human-readable IMO, 2008-01-25 is indeed more human-readable than 2008-01-25T12:00:11, but it is still less human-hearable than the plain old English January 25th, 2008, which is human-readable and machine-readable as long as it is written following precisely English US conventions and the locale can be deduced from a lang attribute (either global to the HTML document or local to the date). Moreover, January 25th, 2008 is indeed an expansion form of say 1/25 so, the following is correct HTML: abbr title=January 25th, 2008 class=dstart lang=en-us1/25/abbr Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Plain Old English/French/..., human-readable/hearable alternative to ISO date
FYI. I've summarized/combined some of the ideas suggested by Glenn Jones, myself and others here [1]. I will elaborate on some of the details (ex. time) later. Guillaume [1] http://microformats.org/wiki/datetime-design-pattern#Plain_Old_English_alternative_to_ISO_date ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hoard.it
Jim O'Donnell wrote: The recent discussion here about dates has made me wonder if such a web service woud be useful for microformats parsers. What do others think? It seems to me that this type of date extraction might present risks if used by uf parsers to extract date/time from published content (and lead to the people showing up on the wrong date error mentioned in earlier posts). On the other hand, it might be great at the time content is authored, to convert ambiguous natural language dates into unambiguous microformats, as a way to reduce the pain of micro-formatting content (especially it can detect dates in plain text rather than parsing something it knows is a date). Authors could confirm the generated microformats before publishing in a way similar to how Yahoo! shortcuts Wordpress plugin works [1] Guillaume [1] http://lebleu.org/blog/2008/02/09/trying-out-yahoo-shortcuts/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
