From swarmers at gmail.com Sun Feb 1 20:42:56 2009 From: swarmers at gmail.com (JMesserly) Date: Sun Feb 1 20:43:02 2009 Subject: [uf-new] Exposing place names whose property type (street-adr, locality...) is unknown Message-ID: <96a8315f0902012042w21300966xe46d84a3dc561c5b@mail.gmail.com> I am posting this to the microformats-new list because it may include a scenario not anticipated by the current spec. If not please forward to the appropriate list. Problem: on Wikipedia and on Commons (the image repository for all wikipedias of all languages), we have historical images that we can provide some semantic adr information on. For example, consider the following painting by Monet: http://commons.wikimedia.org/wiki/File:Claude_Monet_-_The_Highway_Bridge_under_repair.jpg. We don't have a street address, but we know it is in the Paris suburb of Argenteuil. As I understand from the hcard docs on microformats, the canonical thing is to indicate Paris as the locality and not pass Argenteuil. That eliminates precision, because now (via Operator click) Google takes me to Paris central, not the Argenteuil neighborhood. The workaround of making Argenteuil a street address might work except that is that there is no way of knowing that "Paris" is a city, and presumably ineligible from being placed in any property other than locality. The only knowledge we might have is a placename hierarchy: that Argentuil is part of Paris , and Paris is part of France (up to 7 layers of meronym nesting). Placename values are anything that Google/Yahoo/Mapquest might recognize: a landmark like arc de triomphe, a structure like empire state building, or a street. In all cases, we don't know the property type of these names (that one is a street-address, another a locality or whatever) I have come up with many variant solutions, but they boil down to two separate approaches: Solution 1: Use Locality. In an earlier version of this, the Template would emit Argenteuil, Paris in the locality value. This diverges from adr guidance, but there is some basis for this use since X520 is permissive in its definition of locality: "The Locality Name attribute type specifies a locality. When used as a component of a directory name, it identifies a geographical area or locality in which the named object is physically located or with which it is associated in some other important way." Solution 2: declare Adr type=mapsearch: This approach is divergent from current adr guidance on microformats.org. Oftentimes, Commons can provide a geographic set hierarchy (meronymy). For example, we may know the picture is of a plaza in a neighborhood, of a borough, of a city, of a state. We can provide this containment hierarchy, knowing that the square is part of neighborhood and so on, but the problem is, we don't know these placenames are regions, cities, counties, informal landmarks or none of the former. Rather than jam them all into locality delimited by commas, another approach keeps them cleanly distinct in an array. However this diverges severely from current spec to do this. As of the date of this writing, the current running version places each element in a street-address since it allows multiple declarations, and because map applications like google, and yahoo interpret the sequence as a containment hierarchy (example see vcard emitted for fn= Argenteuil). The rationale is that addresses used by Postal workers are not the only legitimate way of locating places. Just as people nowadays more often tell people how to find things via google searches rather than URLs, it is possible to give addresses via map search expressions. EG: meet me next year on St. Patrick's day at Bailie's Bar? in Christchurch,New Zealand. Either google maps or Yahoo will find that just fine with that metadata, but only with certainty if the semantics of the containment hierarchy is expressed somehow. It is implicit with commas in locality. It is less subject to ambiguities if it is permissible to encode them as search terms by overloading the street-address field with these values, and declare an adr type like mapsearch. That's your bailiwick- I don't really have a preference, the current implementation has no special status- it is just the last one I wrote up. My goal is to provide Commons users the microformats based feature of interoperability with Google/Yahoo/Mapquest and would like to be a good citizen and do this in the supported way if possible. The only thing I'd have a hard time with is that if contributors will be required to explicitly encode place types (because as a practical matter they won't do it), or if the map searches are less precise than they could be because there is a prohibition on transferring additional location information that commons has on an image. There is no urgency to this inquiry, and I am not requesting changes to your specifications. I would however appreciate some guidance, however informal/provisional, and I totally understand if your consensus is that the guidance be given with the caveat that your advice could change in the future. The template can easily be alterred to emit in either of these forms and possibly others depending on your community's recommendations. Regards, John JMesserly From mail at tobyinkster.co.uk Sun Feb 1 22:24:38 2009 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Feb 1 22:32:51 2009 Subject: [uf-new] Exposing place names whose property type (street-adr, locality...) is unknown Message-ID: <9E72649E-4528-40A0-8666-A67BB8CFD90C@tobyinkster.co.uk> JMesserly wrote: > The workaround of making Argenteuil a street address > might work except that is that there is no way of knowing that "Paris" > is a city, and presumably ineligible from being placed in any property > other than locality.
Argenteuil, Paris France
-- Toby A Inkster From swarmers at gmail.com Mon Feb 2 10:23:08 2009 From: swarmers at gmail.com (JMesserly) Date: Mon Feb 2 10:23:13 2009 Subject: [uf-new] Re: Exposing place names whose property type (street-adr, locality...) is unknown In-Reply-To: <96a8315f0902012042w21300966xe46d84a3dc561c5b@mail.gmail.com> References: <96a8315f0902012042w21300966xe46d84a3dc561c5b@mail.gmail.com> Message-ID: <96a8315f0902021023i7b36c9aaob869f8e375ae3c27@mail.gmail.com> Toby A Inkster wrote: >> The workaround of making Argenteuil a street address >> might work except that is that there is no way of knowing that "Paris" >> is a city, and presumably ineligible from being placed in any property >> other than locality. >
> Argenteuil, > Paris > France >
Then in the case of Bailie's Bar?, is it permissible to use the generality of locality in this way? eg:
Bailie's Bar, Christchurch New Zealand
Red alert? case two:
Teal street, Honolulu
(real case- see http://commons.wikimedia.org/wiki/File:Pearl_harbor_attack_Japanese_recon_photo_of_battleship_row_80G30552.jpg) It gets worse. In some cases there are real addresses with street numbers. From brian.suda at gmail.com Mon Feb 2 10:59:01 2009 From: brian.suda at gmail.com (Brian Suda) Date: Mon Feb 2 11:06:33 2009 Subject: [uf-new] Re: Exposing place names whose property type (street-adr, locality...) is unknown In-Reply-To: <96a8315f0902021023i7b36c9aaob869f8e375ae3c27@mail.gmail.com> References: <96a8315f0902012042w21300966xe46d84a3dc561c5b@mail.gmail.com> <96a8315f0902021023i7b36c9aaob869f8e375ae3c27@mail.gmail.com> Message-ID: <21e770780902021059h4720b57dm723ced9aa48dbaa8@mail.gmail.com> On 2/2/09, JMesserly wrote: > Then in the case of Bailie's Bar?, is it permissible to use the > generality of locality in this way? eg: >
> Bailie's Bar, > Christchurch > New Zealand >
--- i would use extended-address for something like "Bailie's Bar" it is not the street-address, and it is not the locality, but it is useful. Infact, i probably would work in ORG and FN if this were an hCard. > Red alert? case two: >
> Teal street, > Honolulu >
> (real case- see > http://commons.wikimedia.org/wiki/File:Pearl_harbor_attack_Japanese_recon_photo_of_battleship_row_80G30552.jpg) --- I am not sure what "Teal street" is, is it a street name without an address? If so, then you should use street-address, if it is not (it is some colloquial name), then you should probably use extended-address. > It gets worse. In some cases there are real addresses with street numbers. --- If they are real addresses, with real street numbers, what is wrong with 'street-address'? If you have the precision to the street and house number, then what is the dissonance with the ADR structure? -brian -- brian suda http://suda.co.uk From swarmers at gmail.com Mon Feb 2 12:29:04 2009 From: swarmers at gmail.com (JMesserly) Date: Mon Feb 2 12:29:08 2009 Subject: [uf-new] Re: Exposing place names whose property type (street-adr, locality...) is unknown In-Reply-To: <96a8315f0902021023i7b36c9aaob869f8e375ae3c27@mail.gmail.com> References: <96a8315f0902012042w21300966xe46d84a3dc561c5b@mail.gmail.com> <96a8315f0902021023i7b36c9aaob869f8e375ae3c27@mail.gmail.com> Message-ID: <96a8315f0902021229j312a0af5j573055920559dbe7@mail.gmail.com> Brian, thank you for your advice. You suggested: >--- i would use extended-address for something like "Bailie's Bar" it >is not the street-address, and it is not the locality, but it is >useful. Infact, i probably would work in ORG and FN if this were an >hCard. Of course I wouldn't have posted the inquiry to this list if I had the type of this information. But the user has not declared it- Wikipedia authors may eventually get around to such things, but in large numbers of cases, there is no location information explicitly declared. In cases where it is, they declare Location as one long string, and they move on. My plan is to do Bot runs to examine these location values and provisionally declare the types, for later correction by subsequent editing by contributors. In those cases, it will be trivial mapping to the relevant hcard/hcalendar fields. My question concerns the unknown types, and what I hear people saying is that it would be ok to expose them in the locality field with the understanding that we try to motivate contributors to refine the data with explicitly typed address information. >> Red alert? case two: >>
>> Teal street, >> Honolulu >>
>> (real case- see >> http://commons.wikimedia.org/wiki/File:Pearl_harbor_attack_Japanese_recon_photo_of_battleship_row_80G30552.jpg) >--- I am not sure what "Teal street" is, is it a street name without >an address? If so, then you should use street-address, if it is not >(it is some colloquial name), then you should probably use >extended-address. It's a street name, visible in the Pearl harbor bombing run photo that the link points to. No street number available. Using the provisional implementation mentioned above, after the author coded it, the template would expose "Teal St." in the locality property. In a subsequent Bot pass, Teal St. would be identified with a type that would allow the template to expose it in a street-address property (assuming that is the correct type for a street name without a street number). >> It gets worse. In some cases there are real addresses with street numbers. >--- If they are real addresses, with real street numbers, what is >wrong with 'street-address'? If you have the precision to the street >and house number, then what is the dissonance with the ADR structure? Wikipedia and Commons are not a structured databases, and although we can make templates that require such declarations, the contributors are volunteers and generally shun bothering with formal declarations. So we don't know the types of these strings. A bot can guess at them, but in some cases it will be impossible to figure out. For example, on page http://commons.wikimedia.org/wiki/File:Bundesarchiv_Bild_183-11500-0030,_Berlin-Treptow,_sowjetisches_Ehrenmal.jpg the template exposes Sowjetisches Ehrenmal as a string. If you use Operator to click Google maps, you will find that it correctly associates this feature as most relevant to "Treptower park". No way will a bot ever figure whether these are neighborhoods, squares, or landmarks. For instances where the bot can't make a good guess, is it ok to leave this ambiguous information in the locality property until such time as a contributor declares its type? If so, then I can code it up that way and run some bot passes so we can do a volume test of a couple hundred (later thousands) of pages in this form. Naturally, such processing can be reversed so we can back out if your community wants to modify this guidance. Thanks for everyone's time considering this matter. John JMesserly From mail at tobyinkster.co.uk Mon Feb 2 14:17:12 2009 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Mon Feb 2 14:17:21 2009 Subject: [uf-new] Re: Exposing place names whose property type (street-adr, locality...) is unknown Message-ID: <2262B12A-53E5-4935-838E-BCF8AA858F51@tobyinkster.co.uk> JMesserly wrote: > Of course I wouldn't have posted the inquiry to this list if I had the > type of this information. If you don't know what level address parts are - street-address, locality, region, etc - then you can't (properly) use adr. Use hCard's "label" field instead - that's precisely what it's for - unstructured address data. -- Toby A Inkster From brian.suda at gmail.com Mon Feb 2 13:36:39 2009 From: brian.suda at gmail.com (Brian Suda) Date: Mon Feb 2 14:30:00 2009 Subject: [uf-new] Re: Exposing place names whose property type (street-adr, locality...) is unknown In-Reply-To: <96a8315f0902021229j312a0af5j573055920559dbe7@mail.gmail.com> References: <96a8315f0902012042w21300966xe46d84a3dc561c5b@mail.gmail.com> <96a8315f0902021023i7b36c9aaob869f8e375ae3c27@mail.gmail.com> <96a8315f0902021229j312a0af5j573055920559dbe7@mail.gmail.com> Message-ID: <21e770780902021336k8d891dfp4434d6f9f39d4efc@mail.gmail.com> On 2/2/09, JMesserly wrote: > It's a street name, visible in the Pearl harbor bombing run photo that > the link points to. [...] In a > subsequent Bot pass, Teal St. would be identified with a type that > would allow the template to expose it in a street-address property > (assuming that is the correct type for a street name without a street > number). --- ah, OK, sorry, i completely missed that this is a Bot guessing at structured data. > Wikipedia and Commons are not a structured databases, and although we > can make templates that require such declarations, the contributors > are volunteers and generally shun bothering with formal declarations. > So we don't know the types of these strings. A bot can guess at them, > but in some cases it will be impossible to figure out. > ... > If so, then I can code it up that way and run some bot passes so we > can do a volume test of a couple hundred (later thousands) of pages in > this form. Naturally, such processing can be reversed so we can back > out if your community wants to modify this guidance. --- this is another kettle of fish then. I guess there is two houses of thought on this. 1) If they user didn't explicitly state the structure then you shouldn't mess with it. Is it better to have some false positives and more data, or less data, but have it be more correct? In this case, the bot shouldn't add anything. 2) The other idea is that if it looks like a duck, quacks like a duck, then it's a duck. Would attempt to make anything that looks like an ADR into an ADR. You are attempting #2 and trying to minimize any false-positives. OK, i think we're on the same page now. There is a LABEL property in vCard for a "label" representing an address. This is unstructured, and therefore probably not much use when it gets fed to external applications like Operator to a Map. The vCard RFC says: The structured type value corresponds, in sequence, to the post office box; the extended address; the street address; the locality (e.g., city); the region (e.g., state or province); the postal code; the country name. It gives an example of what "locality" could mean (e.g. city) but doesn't discount what it can't be. The same for 'street-address' it is not explicit about that it MUST have a number or if just the street-name would suffice. The only other sort of "catch-all" is 'extended-address'. I personally would probably use 'extended-address', but that would be just personal preference. (partly because an importing app like Outlook might not accept multiple locality "cities" and drop one, whereas the chance of extended-address colliding with others is very low) The important part would be to get the data into the customer's address book, then they can easily copy-paste-CrUD as needed. i hope this helps, -brian -- brian suda http://suda.co.uk From kevinmarks at gmail.com Mon Feb 2 14:32:45 2009 From: kevinmarks at gmail.com (Kevin Marks) Date: Mon Feb 2 14:32:50 2009 Subject: [uf-new] Re: Exposing place names whose property type (street-adr, locality...) is unknown In-Reply-To: <96a8315f0902021229j312a0af5j573055920559dbe7@mail.gmail.com> References: <96a8315f0902012042w21300966xe46d84a3dc561c5b@mail.gmail.com> <96a8315f0902021023i7b36c9aaob869f8e375ae3c27@mail.gmail.com> <96a8315f0902021229j312a0af5j573055920559dbe7@mail.gmail.com> Message-ID: <73766b160902021432w38b1c3e4sa90b3e74373458a4@mail.gmail.com> The other way to do this is to use the "label" property of hcard, which is an unstructured address. if you wrap the vaguer information in a "label", that can be fed into a geocoder that accepts fuzzier information. On Mon, Feb 2, 2009 at 12:29 PM, JMesserly wrote: > > Brian, thank you for your advice. You suggested: > >--- i would use extended-address for something like "Bailie's Bar" it > >is not the street-address, and it is not the locality, but it is > >useful. Infact, i probably would work in ORG and FN if this were an > >hCard. > > > >> Red alert? case two: > >>
> >> Teal street, > >> Honolulu > >>
How about
Teal street, Honolulu
You could use a structured geocoder to feed the raw information into, and output that for possible human correction; for example Google's geocoder: http://maps.google.com/maps/geo?q=teal%20street,%20honolulu&output=json will give you back: { "name": "teal street, honolulu", "Status": { "code": 200, "request": "geocode" }, "Placemark": [ { "id": "p1", "address": "Teal St, HI 96860, USA", "AddressDetails": {"Country": {"CountryNameCode": "US","CountryName": "USA","AdministrativeArea": {"AdministrativeAreaName": "HI","Thoroughfare":{"ThoroughfareName": "Teal St"},"PostalCode": {"PostalCodeNumber": "96860"}}},"Accuracy": 6}, "ExtendedData": { "LatLonBox": { "north": 21.3685381, "south": 21.3622429, "east": -157.9489099, "west": -157.9552051 } }, "Point": { "coordinates": [ -157.9520480, 21.3654570, 0 ] } } ] } which you could expand back to an hcard From scott at makedatamakesense.com Mon Feb 2 15:03:45 2009 From: scott at makedatamakesense.com (Scott Reynen) Date: Mon Feb 2 15:03:51 2009 Subject: [uf-new] Re: Exposing place names whose property type (street-adr, locality...) is unknown In-Reply-To: <2262B12A-53E5-4935-838E-BCF8AA858F51@tobyinkster.co.uk> References: <2262B12A-53E5-4935-838E-BCF8AA858F51@tobyinkster.co.uk> Message-ID: On [Feb 2], at [ Feb 2] 3:17 , Toby A Inkster wrote: > JMesserly wrote: > >> Of course I wouldn't have posted the inquiry to this list if I had >> the >> type of this information. > > If you don't know what level address parts are - street-address, > locality, region, etc - then you can't (properly) use adr According to the wiki [1], adr has no required fields. By my reading, John knows the content is an address; he just doesn't know what exactly the individual parts of the address are. So he can properly use adr by labeling the content with class="adr" and avoiding further (likely wrong) detail. That won't be useable in all adr tools, but it will still work in some. [1] http://microformats.org/wiki/adr-cheatsheet -- Scott Reynen MakeDataMakeSense.com From swarmers at gmail.com Mon Feb 2 15:55:42 2009 From: swarmers at gmail.com (JMesserly) Date: Mon Feb 2 15:55:45 2009 Subject: [uf-new] Re: Exposing place names whose property type (street-adr, locality...) is unknown In-Reply-To: <73766b160902021432w38b1c3e4sa90b3e74373458a4@mail.gmail.com> References: <96a8315f0902012042w21300966xe46d84a3dc561c5b@mail.gmail.com> <96a8315f0902021023i7b36c9aaob869f8e375ae3c27@mail.gmail.com> <96a8315f0902021229j312a0af5j573055920559dbe7@mail.gmail.com> <73766b160902021432w38b1c3e4sa90b3e74373458a4@mail.gmail.com> Message-ID: <96a8315f0902021555u259e1006k98f8022462026328@mail.gmail.com> Kevin suggested: > How about > >
> >
> Teal street, > Honolulu >
> >
> If this is kosher, then Operator gives me Maps just fine. Your microformats site was clear about unstructured data- I understood about label. As Brian noted, the problem is that nothing will use it if I do it this way. (Also if you notice on the example pages, I am generating hcalendars, but we can punt on that until some history app, or mr. peabody wayback machine applications show up.) The template code cannot do much- I don't even have string functions, but a python Bot can make much more reasonable guesses at type. For all of you familiar with wikipedia, the danger of generating some false positives is mitigated by the fact that editors constantly refine these articles fiddling with such minutiae. Editors will notice that a province of some obscure African country was labeled as as a locality rather than a region and correct it. If there is a blessing on Kevin's scheme, I will proceed with his approach. I will muck about with extended addresses to try and make that fly, but otherwise I will use locality. -John From kavi at google.com Wed Feb 11 14:26:00 2009 From: kavi at google.com (Kavi Goel) Date: Wed Feb 11 14:26:09 2009 Subject: [uf-new] re: Microformats support for aggregate reviews In-Reply-To: <199b56630901221602v114791f7je2a3e779dc8d7759@mail.gmail.com> References: <4B362894-1372-4A38-9FDC-667079487BCE@tobyinkster.co.uk> <199b56630901221602v114791f7je2a3e779dc8d7759@mail.gmail.com> Message-ID: <199b56630902111426o59e08dfapf659dbea6668fb9@mail.gmail.com> Hi all, Here is a quick update on conversations around microformats aggregate reviews support. I've updated the aggregate-review-brainstorming wiki page based on our IRC conversation a few weeks ago: http://microformats.org/wiki/aggregate-review-brainstorming The short summary of the proposal that emerged from the discussion over IRC is as follows: - define a new microformat that contains two elements. 1) number of reviews, and 2) an embedded hReview - fields in the embedded hReview (i.e. rating, summary, item type) would refer to aggregate information. For example, the rating is the average rating across all reviews. Why this proposal? - the new microformat would contain only one element (at least in an initial version) to keep things simple according to the 80% rule - creating a new microformat rather than extending hReview provides flexibility to potentially add more aggregate-only fields in the future without cluttering hReview. If this approach seems like a good one, Jay Myers and/or I will also add a few examples of how this markup could look for some sites. One issue we ran into when trying to apply this to Best Buy and Amazon pages -- on many pages, the entire page is about a product, whereas only a section of the page is about the reviews. On the other hand, for sites like Yelp, the entire page is about the reviews, and only a section of the page is about the product spec. So it probably makes sense to allow embedded reviews in hProduct's as well as embedded hProduct's in hReview's depending on the hierarchy that naturally exists on the page. Kavi On Thu, Jan 22, 2009 at 4:02 PM, Kavi Goel wrote: > > In order to move this discussion about aggregate reviews along, I'd > like to have a discussion over IRC. As a heads-up, I'll plan on > discussing alternatives around 2PM Pacific time tomorrow. For folks in > different timezones who will be out enjoying the nightlife, sleeping > or otherwise away from a computer, please feel encouraged to post > ideas via this email discussion or on the brainstorming wiki here: > http://microformats.org/wiki/aggregate-review-brainstorming > > Thanks, > Kavi > > On Wed, Jan 14, 2009 at 12:48 AM, Toby A Inkster wrote: > > > > Jamie Rumbelow wrote: > > > >> See, comments like that lead me on to think that we need some form of > >> pagination system for microformats - pagination is much more popular among > >> sites these days and a rel="paginate" might come in handy. > > > > HTML already has perfectly good rel="next"/"prev" for that. > > > > http://www.w3.org/TR/REC-html40/types.html#type-links > > > > -- > > Toby A Inkster > > > > > > > > > > > > _______________________________________________ > > microformats-new mailing list > > microformats-new@microformats.org > > http://microformats.org/mailman/listinfo/microformats-new From Jay.Myers at bestbuy.com Fri Feb 13 08:26:35 2009 From: Jay.Myers at bestbuy.com (Myers, Jay) Date: Fri Feb 13 08:27:11 2009 Subject: [uf-new] re: Microformats support for aggregate reviews In-Reply-To: <199b56630902111426o59e08dfapf659dbea6668fb9@mail.gmail.com> References: <4B362894-1372-4A38-9FDC-667079487BCE@tobyinkster.co.uk><199b56630901221602v114791f7je2a3e779dc8d7759@mail.gmail.com> <199b56630902111426o59e08dfapf659dbea6668fb9@mail.gmail.com> Message-ID: <0A55472BC29958468426825844F9F22E0659882E@dsp63mail.na.bestbuy.com> Good morning Kavi, I am putting together an example this morning to post on the wiki. A couple of issues that I ran into with the "postcard" example we talked about earlier this week: -- hReview has a required item attribute. I decided to put an href around the stars that points to a product detail page url. It might not be the most solid workaround, but we can certainly work on that either through the format itself, or altering the html to include the name of the product. -- in many examples there is a total number of reviews. I have added the class "num" to identify this. Completely up for debate on the naming... I should be able to create more examples from other sites next week... Thanks, Jay Jay Myers Lead Web Development Engineer Online Solutions, BestBuy.com jay.myers@bestbuy.com (w) 612-291-4007 (c) 612-296-5836 (twitter) @jaymyers (skype) jaymmyers -----Original Message----- From: microformats-new-bounces@microformats.org [mailto:microformats-new-bounces@microformats.org] On Behalf Of Kavi Goel Sent: Wednesday, February 11, 2009 4:26 PM To: For discussion of new microformats. Subject: Re: [uf-new] re: Microformats support for aggregate reviews Hi all, Here is a quick update on conversations around microformats aggregate reviews support. I've updated the aggregate-review-brainstorming wiki page based on our IRC conversation a few weeks ago: http://microformats.org/wiki/aggregate-review-brainstorming The short summary of the proposal that emerged from the discussion over IRC is as follows: - define a new microformat that contains two elements. 1) number of reviews, and 2) an embedded hReview - fields in the embedded hReview (i.e. rating, summary, item type) would refer to aggregate information. For example, the rating is the average rating across all reviews. Why this proposal? - the new microformat would contain only one element (at least in an initial version) to keep things simple according to the 80% rule - creating a new microformat rather than extending hReview provides flexibility to potentially add more aggregate-only fields in the future without cluttering hReview. If this approach seems like a good one, Jay Myers and/or I will also add a few examples of how this markup could look for some sites. One issue we ran into when trying to apply this to Best Buy and Amazon pages -- on many pages, the entire page is about a product, whereas only a section of the page is about the reviews. On the other hand, for sites like Yelp, the entire page is about the reviews, and only a section of the page is about the product spec. So it probably makes sense to allow embedded reviews in hProduct's as well as embedded hProduct's in hReview's depending on the hierarchy that naturally exists on the page. Kavi On Thu, Jan 22, 2009 at 4:02 PM, Kavi Goel wrote: > > In order to move this discussion about aggregate reviews along, I'd > like to have a discussion over IRC. As a heads-up, I'll plan on > discussing alternatives around 2PM Pacific time tomorrow. For folks in > different timezones who will be out enjoying the nightlife, sleeping > or otherwise away from a computer, please feel encouraged to post > ideas via this email discussion or on the brainstorming wiki here: > http://microformats.org/wiki/aggregate-review-brainstorming > > Thanks, > Kavi > > On Wed, Jan 14, 2009 at 12:48 AM, Toby A Inkster wrote: > > > > Jamie Rumbelow wrote: > > > >> See, comments like that lead me on to think that we need some form of > >> pagination system for microformats - pagination is much more popular among > >> sites these days and a rel="paginate" might come in handy. > > > > HTML already has perfectly good rel="next"/"prev" for that. > > > > http://www.w3.org/TR/REC-html40/types.html#type-links > > > > -- > > Toby A Inkster > > > > > > > > > > > > _______________________________________________ > > microformats-new mailing list > > microformats-new@microformats.org > > http://microformats.org/mailman/listinfo/microformats-new _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Tue Feb 17 21:44:05 2009 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Feb 17 21:44:11 2009 Subject: [uf-new] Issue HP2 - FN vs. N use in hProduct Message-ID: <499BA025.3040000@digitalbazaar.com> http://microformats.org/wiki/hproduct-issues#HP2_-_FN_should_be_used_instead_of_N_for_product_title Why does hProduct use N instead of FN for the title of a product? I thought that the term that this community has settled on, after an excruciating amount of debate, was FN? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 From msporny at digitalbazaar.com Tue Feb 17 22:28:53 2009 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Feb 17 23:01:54 2009 Subject: [uf-new] Issue HP7 - Abundance of vocabulary terms in hProduct Message-ID: <499BAAA5.4040501@digitalbazaar.com> http://microformats.org/wiki/hproduct-issues#HP7_-_Lots_of_vocabulary_terms.2C_does_the_data_really_back_this_up.3F There are currently 15 vocabulary terms in hProduct, but some of the terms don't seem to be backed up in the hProduct analysis[1]. For example, MODEL shows up in 15% of the examples, but made it into the vocabulary. However, DIMENSIONS shows up in 51% of the examples, COLOR in 31% of the examples, but neither made it into the vocabulary. Why did that happen? Also - do we really think that VERSION is a good idea? Where on the page are we going to use this? Are we suggesting that page authors should version each of the hProduct instances? Does anybody actually use this in practice? -- manu [1]http://microformats.org/wiki/hproduct-examples#Analysis_of_Product.2FCommerce_Sites -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 From msporny at digitalbazaar.com Tue Feb 17 22:12:54 2009 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Feb 17 23:01:55 2009 Subject: [uf-new] Issue HP6 - P-V seems like a catch-all for hProduct Message-ID: <499BA6E6.6070304@digitalbazaar.com> http://microformats.org/wiki/hproduct-issues#HP6_-_P-V_seems_like_a_catch-all_for_hProduct hProduct currently allows the author to use the P-V pattern for anything that doesn't fit neatly into hProduct. While it is true that this is a nice way to expand hProduct and see where future versions of hProduct might need to be expanded, there is a danger that over-use of the P-V pattern will result in weird issues between future Microformats. For example, if hProduct lists a number of P-Vs and another Microformat starts using P-V heavily, there will be clashes between the overlapping Microformats. These clashes will result in the wrong P-Vs being assigned to the wrong object. It also seems a bit sloppy - using P-V may be a clear sign that the problem being solved isn't small enough, or that you're attempting to boil the oceans in a clever way. Anybody else have some thoughts about the use or abuse of P-V in Microformats? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 From msporny at digitalbazaar.com Tue Feb 17 22:03:12 2009 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Feb 17 23:01:56 2009 Subject: [uf-new] Issue HP5 - SHIPPING term in hProduct is vague Message-ID: <499BA4A0.2020003@digitalbazaar.com> http://microformats.org/wiki/hproduct-issues#HP5_-_The_format_for_the_contents_of_SHIPPING_are_vague The definition of shipping is: > shipping:: the class name shipping MAY define the method, timeframe, > and cost associated with shipping the product. MUST be > singular. I realize that this is all important information, but why mash method, timeframe AND cost into one attribute? It would be nice if an application could use each of those pieces of information out without having to resort to some sort of natural language processing. For example, why don't we have: shipping-method, shipping-timeframe, and shipping-price? or something like this:
$ 3.95
UPS Ground, expect 4-6 days for delivery.
-- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 From msporny at digitalbazaar.com Tue Feb 17 21:55:57 2009 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Feb 17 23:01:56 2009 Subject: [uf-new] Issue HP4 - Multiple formats for PRICE in hProduct Message-ID: <499BA2ED.9060000@digitalbazaar.com> http://microformats.org/wiki/hproduct-issues#HP4_-_Are_all_of_the_formats_for_PRICE_in_hProduct_allowed The hProduct specification lists the following formats as allowable for PRICE: > price. optional. floating point number. can be further refined by type > (msrp, regular, sale, clearance), can use currency format. So, we can do the following in PRICE: Floating point number: ---------------------- 3.40 Currency format: ---------------- ? 4.99 Further refined by type: ------------------------ $3.40 MSRP Are all of these good ideas as an extension to PRICE? We don't allow the type to be refined in other uFs do we? Is the price specified as a regular floating point number useful without a currency? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 From msporny at digitalbazaar.com Tue Feb 17 21:45:54 2009 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Feb 17 23:01:57 2009 Subject: [uf-new] Issue HP3 - BUY vs. PAYMENT in hProduct Message-ID: <499BA092.5060605@digitalbazaar.com> http://microformats.org/wiki/hproduct-issues#HP3_-_BUY_duplicates_functionality_of_PAYMENT_from_hAudio hProduct seems to create a new term called BUY instead of re-using PAYMENT. What's the reasoning behind creating the new term vs. using the one that has already been invented? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 From davidjanes at blogmatrix.com Wed Feb 18 01:19:28 2009 From: davidjanes at blogmatrix.com (David Janes) Date: Wed Feb 18 01:19:31 2009 Subject: [uf-new] Issue HP6 - P-V seems like a catch-all for hProduct In-Reply-To: <499BA6E6.6070304@digitalbazaar.com> References: <499BA6E6.6070304@digitalbazaar.com> Message-ID: <21e523c20902180119xbf288adp3d970028c439a8a3@mail.gmail.com> On Wed, Feb 18, 2009 at 1:12 AM, Manu Sporny wrote: > http://microformats.org/wiki/hproduct-issues#HP6_-_P-V_seems_like_a_catch-all_for_hProduct > > > hProduct currently allows the author to use the P-V pattern for anything > that doesn't fit neatly into hProduct. While it is true that this is a > nice way to expand hProduct and see where future versions of hProduct > might need to be expanded, there is a danger that over-use of the P-V > pattern will result in weird issues between future Microformats. > > For example, if hProduct lists a number of P-Vs and another Microformat > starts using P-V heavily, there will be clashes between the overlapping > Microformats. These clashes will result in the wrong P-Vs being assigned > to the wrong object. > > It also seems a bit sloppy - using P-V may be a clear sign that the > problem being solved isn't small enough, or that you're attempting to > boil the oceans in a clever way. Anybody else have some thoughts about > the use or abuse of P-V in Microformats? I got hung up on this one too, wrote a post, deleted it. Thoughts: 1) my thinking is that the "semanticness" doesn't go down to the P and V, that we know that products have lists of property and values but at this level we _attach no meaning to the terms_ beyond the fact that they are there. And later on, if we decide (e.g.) that "Number of Wheels"/"4" has standardizable meaning, we can define "number-of-wheels" and add that as class value. 2) is this just not a DL? we are fine with that... 3) why not use a DL? I note alternatively that hAtom allows both H# and entry-title. Regards, etc... -- David Janes Mercenary Programmer http://code.davidjanes.com From paullee at google.com Wed Feb 18 15:00:24 2009 From: paullee at google.com (=?EUC-KR?B?UGF1bCBMZWUgKMDMseK89ik=?=) Date: Wed Feb 18 15:00:35 2009 Subject: [uf-new] Issue HP6 - P-V seems like a catch-all for hProduct In-Reply-To: <21e523c20902180119xbf288adp3d970028c439a8a3@mail.gmail.com> References: <499BA6E6.6070304@digitalbazaar.com> <21e523c20902180119xbf288adp3d970028c439a8a3@mail.gmail.com> Message-ID: IIUC, part of the reason why hproduct has been under discussion for quite awhile is b/c of the debate between p-v vs. more defined attributes. p-v is quite helpful b/c the attributes users care about change over time. Take cameras, for instance. Did anyone care about megapixels 10 years ago? etc. On Wed, Feb 18, 2009 at 1:19 AM, David Janes wrote: > On Wed, Feb 18, 2009 at 1:12 AM, Manu Sporny wrote: >> http://microformats.org/wiki/hproduct-issues#HP6_-_P-V_seems_like_a_catch-all_for_hProduct >> >> >> hProduct currently allows the author to use the P-V pattern for anything >> that doesn't fit neatly into hProduct. While it is true that this is a >> nice way to expand hProduct and see where future versions of hProduct >> might need to be expanded, there is a danger that over-use of the P-V >> pattern will result in weird issues between future Microformats. >> >> For example, if hProduct lists a number of P-Vs and another Microformat >> starts using P-V heavily, there will be clashes between the overlapping >> Microformats. These clashes will result in the wrong P-Vs being assigned >> to the wrong object. >> >> It also seems a bit sloppy - using P-V may be a clear sign that the >> problem being solved isn't small enough, or that you're attempting to >> boil the oceans in a clever way. Anybody else have some thoughts about >> the use or abuse of P-V in Microformats? > > I got hung up on this one too, wrote a post, deleted it. Thoughts: > > 1) my thinking is that the "semanticness" doesn't go down to the P and > V, that we know that products have lists of property and values but at > this level we _attach no meaning to the terms_ beyond the fact that > they are there. And later on, if we decide (e.g.) that "Number of > Wheels"/"4" has standardizable meaning, we can define > "number-of-wheels" and add that as class value. > 2) is this just not a DL? we are fine with that... > 3) why not use a DL? I note alternatively that hAtom allows both H# > and entry-title. > > Regards, etc... > > -- > David Janes > Mercenary Programmer > http://code.davidjanes.com > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -- Paul Lee Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 +1 (650) 214-6612 From paullee at google.com Wed Feb 18 14:52:33 2009 From: paullee at google.com (=?EUC-KR?B?UGF1bCBMZWUgKMDMseK89ik=?=) Date: Wed Feb 18 15:22:55 2009 Subject: [uf-new] Issue HP7 - Abundance of vocabulary terms in hProduct In-Reply-To: <499BAAA5.4040501@digitalbazaar.com> References: <499BAAA5.4040501@digitalbazaar.com> Message-ID: The examples aren't necessarily an accurate reflection of how frequently attributes/data is used by retailers. In practice, model/mpn is used much more frequently than dimensions, both for retailer websites as well as retailer submissions to search and shopping engines. Defer to those with more experience/other data on version. On Tue, Feb 17, 2009 at 10:28 PM, Manu Sporny wrote: > http://microformats.org/wiki/hproduct-issues#HP7_-_Lots_of_vocabulary_terms.2C_does_the_data_really_back_this_up.3F > > There are currently 15 vocabulary terms in hProduct, but some of the > terms don't seem to be backed up in the hProduct analysis[1]. > > For example, MODEL shows up in 15% of the examples, but made it into the > vocabulary. However, DIMENSIONS shows up in 51% of the examples, COLOR > in 31% of the examples, but neither made it into the vocabulary. Why did > that happen? > > Also - do we really think that VERSION is a good idea? Where on the page > are we going to use this? Are we suggesting that page authors should > version each of the hProduct instances? Does anybody actually use this > in practice? > > -- manu > > [1]http://microformats.org/wiki/hproduct-examples#Analysis_of_Product.2FCommerce_Sites > > -- > Manu Sporny > President/CEO - Digital Bazaar, Inc. > blog: Scaling Past 100,000 Concurrent Web Service Requests > http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -- Paul Lee Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 +1 (650) 214-6612 From paullee at google.com Wed Feb 18 14:42:21 2009 From: paullee at google.com (=?EUC-KR?B?UGF1bCBMZWUgKMDMseK89ik=?=) Date: Wed Feb 18 15:44:15 2009 Subject: [uf-new] Issue HP3 - BUY vs. PAYMENT in hProduct In-Reply-To: <499BA092.5060605@digitalbazaar.com> References: <499BA092.5060605@digitalbazaar.com> Message-ID: >From the payment page: RelPayment is a microformat for making exchanges of support (be it financial or otherwise) possible. By adding rel="payment" to a hyperlink a page indicates that the destination of that hyperlink provides a way to show or give support for the current page. For example to give financial support to the owner of the current page. One of the goals with this microformat is to give content aggregators such as RSS readers a way to extract these support links and give them special attention (such as displaying a standard button along with the content). First, this seems like a simple exercise for blogs, etc.; but the transaction process for shopping sites is typically considerably more complex. Usually, the actual payment URI is toward the end of the cart checkout process, the entry to which "buy" is intended to direct to the beginning of. Second, there is the potential for confusion when using payment, since "payment" in the shopping space often refers to payment methods, e.g., credit card, check, etc. On Tue, Feb 17, 2009 at 9:45 PM, Manu Sporny wrote: > > http://microformats.org/wiki/hproduct-issues#HP3_-_BUY_duplicates_functionality_of_PAYMENT_from_hAudio > > hProduct seems to create a new term called BUY instead of re-using > PAYMENT. What's the reasoning behind creating the new term vs. using the > one that has already been invented? > > -- manu > > -- > Manu Sporny > President/CEO - Digital Bazaar, Inc. > blog: Scaling Past 100,000 Concurrent Web Service Requests > http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new -- Paul Lee Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 +1 (650) 214-6612 From tantek at cs.stanford.edu Wed Feb 18 15:45:38 2009 From: tantek at cs.stanford.edu (Tantek Celik) Date: Wed Feb 18 15:45:43 2009 Subject: [uf-new] hProduct issues HP1-HP7 Message-ID: <529453680-1235000739-cardhu_decombobulator_blackberry.rim.net-1152297912-@bxe1184.bisx.prod.on.blackberry> Thanks Manu for documenting some hProduct issues on the wiki. I have added my comments to each one. http://microformats.org/wiki/hproduct-issues In short I agree that all of the issues raised so far are issues and went further on some of them. Please follow-up on the wiki and also one email announcing a batch of new issues is sufficient. Let's try to keep emails to a minimum for notification only, and capture discussion/iteration on the wiki. Thanks, Tantek From othar at othar.com Wed Feb 18 16:10:18 2009 From: othar at othar.com (Othar Hansson) Date: Wed Feb 18 16:10:22 2009 Subject: [uf-new] re: Microformats support for aggregate reviews In-Reply-To: <0A55472BC29958468426825844F9F22E0659882E@dsp63mail.na.bestbuy.com> References: <4B362894-1372-4A38-9FDC-667079487BCE@tobyinkster.co.uk> <199b56630901221602v114791f7je2a3e779dc8d7759@mail.gmail.com> <199b56630902111426o59e08dfapf659dbea6668fb9@mail.gmail.com> <0A55472BC29958468426825844F9F22E0659882E@dsp63mail.na.bestbuy.com> Message-ID: <6934bc6b0902181610k60c7b55er117dde2a35027f53@mail.gmail.com> Adding a new microformat for aggregate reviews seems like the wrong direction to me, because we're adding one that will have strictly fewer users than hReview itself. Will we do the same for aggregates of everything? products, listings, events, etc. could all reasonably have aggregates to describe "what's on a page". Why don't we just define a trivial microformat "aggregate", which contains one value "count", and can wrap any other microformat? The fields of the wrapped microformat get a new meaning: any given field is meant to be an aggregate of all the other data associated with the page. E.g., a hypothetical price field should contain a price range. A rating field should contain an aggregrate rating. etc. --Othar On Fri, Feb 13, 2009 at 8:26 AM, Myers, Jay wrote: > > Good morning Kavi, > > I am putting together an example this morning to post on the wiki. A > couple of issues that I ran into with the "postcard" example we talked > about earlier this week: > > -- hReview has a required item attribute. I decided to put an href > around the stars that points to a product detail page url. It might not > be the most solid workaround, but we can certainly work on that either > through the format itself, or altering the html to include the name of > the product. > -- in many examples there is a total number of reviews. I have added the > class "num" to identify this. Completely up for debate on the naming... > > I should be able to create more examples from other sites next week... > > Thanks, > > Jay > > > Jay Myers > Lead Web Development Engineer > Online Solutions, BestBuy.com > jay.myers@bestbuy.com > (w) 612-291-4007 > (c) 612-296-5836 > (twitter) @jaymyers > (skype) jaymmyers > -----Original Message----- > From: microformats-new-bounces@microformats.org > [mailto:microformats-new-bounces@microformats.org] On Behalf Of Kavi > Goel > Sent: Wednesday, February 11, 2009 4:26 PM > To: For discussion of new microformats. > Subject: Re: [uf-new] re: Microformats support for aggregate reviews > > Hi all, > > Here is a quick update on conversations around microformats aggregate > reviews support. I've updated the aggregate-review-brainstorming wiki > page based on our IRC conversation a few weeks ago: > http://microformats.org/wiki/aggregate-review-brainstorming > > The short summary of the proposal that emerged from the discussion > over IRC is as follows: > - define a new microformat that contains two elements. 1) number of > reviews, and 2) an embedded hReview > - fields in the embedded hReview (i.e. rating, summary, item type) > would refer to aggregate information. For example, the rating is the > average rating across all reviews. > > Why this proposal? > - the new microformat would contain only one element (at least in an > initial version) to keep things simple according to the 80% rule > - creating a new microformat rather than extending hReview provides > flexibility to potentially add more aggregate-only fields in the > future without cluttering hReview. > > If this approach seems like a good one, Jay Myers and/or I will also > add a few examples of how this markup could look for some sites. > > One issue we ran into when trying to apply this to Best Buy and Amazon > pages -- on many pages, the entire page is about a product, whereas > only a section of the page is about the reviews. On the other hand, > for sites like Yelp, the entire page is about the reviews, and only a > section of the page is about the product spec. So it probably makes > sense to allow embedded reviews in hProduct's as well as embedded > hProduct's in hReview's depending on the hierarchy that naturally > exists on the page. > > Kavi > > > On Thu, Jan 22, 2009 at 4:02 PM, Kavi Goel wrote: > > > > In order to move this discussion about aggregate reviews along, I'd > > like to have a discussion over IRC. As a heads-up, I'll plan on > > discussing alternatives around 2PM Pacific time tomorrow. For folks in > > different timezones who will be out enjoying the nightlife, sleeping > > or otherwise away from a computer, please feel encouraged to post > > ideas via this email discussion or on the brainstorming wiki here: > > http://microformats.org/wiki/aggregate-review-brainstorming > > > > Thanks, > > Kavi > > > > On Wed, Jan 14, 2009 at 12:48 AM, Toby A Inkster > wrote: > > > > > > Jamie Rumbelow wrote: > > > > > >> See, comments like that lead me on to think that we need some form > of > > >> pagination system for microformats - pagination is much more > popular among > > >> sites these days and a rel="paginate" might come in handy. > > > > > > HTML already has perfectly good rel="next"/"prev" for that. > > > > > > http://www.w3.org/TR/REC-html40/types.html#type-links > > > > > > -- > > > Toby A Inkster > > > > > > > > > > > > > > > > > > _______________________________________________ > > > microformats-new mailing list > > > microformats-new@microformats.org > > > http://microformats.org/mailman/listinfo/microformats-new > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From martin at weborganics.co.uk Wed Feb 18 16:32:35 2009 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Feb 18 16:32:58 2009 Subject: [uf-new] hProduct issues HP1-HP7 In-Reply-To: <529453680-1235000739-cardhu_decombobulator_blackberry.rim.net-1152297912-@bxe1184.bisx.prod.on.blackberry> References: <529453680-1235000739-cardhu_decombobulator_blackberry.rim.net-1152297912-@bxe1184.bisx.prod.on.blackberry> Message-ID: <499CA8A3.4010902@weborganics.co.uk> + 1 from me on all issues HP1-HP7 To be honest one of the issues highlighted by Manu, the "p-v" property I don't quite understand ... what does it "mean" ? the lack of examples and data concerns me too sorry. Thanks Tantek Celik wrote: > Thanks Manu for documenting some hProduct issues on the wiki. > > I have added my comments to each one. > > http://microformats.org/wiki/hproduct-issues > > In short I agree that all of the issues raised so far are issues and went further on some of them. > > Please follow-up on the wiki and also one email announcing a batch of new issues is sufficient. Let's try to keep emails to a minimum for notification only, and capture discussion/iteration on the wiki. > > Thanks, > > Tantek > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -- Martin McEvoy http://weborganics.co.uk/ "You may find it hard to swallow the notion that anything as large and apparently inanimate as the Earth is alive." Dr. James Lovelock, The Ages of Gaia From martin at weborganics.co.uk Wed Feb 18 17:42:17 2009 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Feb 18 17:42:37 2009 Subject: [uf-new] hProduct issues HP1-HP7 In-Reply-To: <499CA8A3.4010902@weborganics.co.uk> References: <529453680-1235000739-cardhu_decombobulator_blackberry.rim.net-1152297912-@bxe1184.bisx.prod.on.blackberry> <499CA8A3.4010902@weborganics.co.uk> Message-ID: <499CB8F9.5080502@weborganics.co.uk> Great start on a product microformat Paul, Martin McEvoy wrote: > + 1 from me on all issues HP1-HP7 > > To be honest one of the issues highlighted by Manu, the "p-v" > property I don't quite understand ... what does it "mean" ? the lack > of examples and data concerns me too sorry. OK I do understand "p-v" "property" - "value" what I don't understand is how I am supposed to use it?.....
by Tenacious D
why doesn't this work?
by Released: November 14, 2006 huh? see: http://microformats.org/wiki/datetime-design-pattern November 14, 2006 looks better? see http://microformats.org/wiki/hproduct#Examples_in_Production for example Also the example is a bit complex how about some minimal markup first? it might help us all get a grip of the basics first. I think a product microformat is a good idea but you have to think a little more micro, which is simple, minimal and only covers the most commonly used properties occurring 80% or more of the time based on solid examples that illustrate your problem precisely. Once you have worked out what that is ask yourself has any of this been done before? no! that doesn't mean with just microformats Manu is the key developer of haudio and ended up finding that what he wanted to do would be much more practical in RDFa it sounds a bit off putting but look elsewhere FIRST ...still not happy then we can talk about a microformat. have a look at http://microformats.org/wiki/principles and http://microformats.org/wiki/process understand them (I'm not saying you don't) they offer some really good guidance on what to do next. Best wishes. -- Martin McEvoy http://weborganics.co.uk/ "You may find it hard to swallow the notion that anything as large and apparently inanimate as the Earth is alive." Dr. James Lovelock, The Ages of Gaia From msporny at digitalbazaar.com Sun Feb 22 18:12:34 2009 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Feb 22 18:12:42 2009 Subject: [uf-new] Issue HP3 - BUY vs. PAYMENT in hProduct In-Reply-To: References: <499BA092.5060605@digitalbazaar.com> Message-ID: <49A20612.6070204@digitalbazaar.com> Paul Lee (???) wrote: >>From the payment page: > > RelPayment is a microformat for making exchanges of support (be it > financial or otherwise) possible. By adding rel="payment" to a > hyperlink a page indicates that the destination of that hyperlink > provides a way to show or give support for the current page. For > example to give financial support to the owner of the current page. > > One of the goals with this microformat is to give content aggregators > such as RSS readers a way to extract these support links and give them > special attention (such as displaying a standard button along with the > content). > > > First, this seems like a simple exercise for blogs, etc.; but the > transaction process for shopping sites is typically considerably more > complex. Usually, the actual payment URI is toward the end of the > cart checkout process, the entry to which "buy" is intended to direct > to the beginning of. Hrm, I tend to disagree with your reading of payment. We use "payment" in the same way that you intend to use it in hAudio - to point to a URL that starts the purchase process. > Second, there is the potential for confusion when using payment, since > "payment" in the shopping space often refers to payment methods, e.g., > credit card, check, etc. I think "payment-method" refers to the various payment methods, not "payment". The argument for "buy" is a difficult one to make because there already exists something for the purpose that you describe in Microformats - "payment". hAudio defines payment like so: http://microformats.org/wiki/haudio#Purchase_.28Payment.29 specifically, "The URI MUST point to the beginning of a purchase process for the hAudio." I don't see why you can't re-use that term instead of minting a new one. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 From msporny at digitalbazaar.com Sun Feb 22 18:24:26 2009 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Feb 22 18:24:31 2009 Subject: [uf-new] Issue HP7 - Abundance of vocabulary terms in hProduct In-Reply-To: References: <499BAAA5.4040501@digitalbazaar.com> Message-ID: <49A208DA.1020402@digitalbazaar.com> Paul Lee (???) wrote: > The examples aren't necessarily an accurate reflection of how > frequently attributes/data is used by retailers. In practice, > model/mpn is used much more frequently than dimensions, both for > retailer websites as well as retailer submissions to search and > shopping engines. I would expect many people on this list would have an issue if I made the following statement: "The hAudio examples aren't necessarily an accurate reflection of how frequently the ISRC is used by retailers. In practice, ISRC is used quite frequently and should be in the vocabulary." The reason uFers should have an issue with this statement is because I'm asserting something that isn't backed up by the examples that have been gathered for hAudio - there is no hard data behind it. In the Microformats community, if you can't show hard usage data for a vocabulary term, it should not be a part of the vocabulary. If you don't have enough data to prove that model/mpn is used more than 15% of the time, you are going to have a very hard time convincing this group that it belongs in a vocabulary. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 From msporny at digitalbazaar.com Sun Feb 22 18:35:13 2009 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Feb 22 18:35:21 2009 Subject: [uf-new] Issue HP6 - P-V seems like a catch-all for hProduct In-Reply-To: References: <499BA6E6.6070304@digitalbazaar.com> <21e523c20902180119xbf288adp3d970028c439a8a3@mail.gmail.com> Message-ID: <49A20B61.602@digitalbazaar.com> Paul Lee (???) wrote: > IIUC, part of the reason why hproduct has been under discussion for > quite awhile is b/c of the debate between p-v vs. more defined > attributes. p-v is quite helpful b/c the attributes users care about > change over time. Take cameras, for instance. Did anyone care about > megapixels 10 years ago? etc. Don't try to future-proof your vocabulary - if there isn't enough data to back up a vocabulary term, it doesn't belong in a Microformat. One of the principles that this whole community is built around is proving that vocabulary term usage in-the-wild has reached a critical mass and thus needs to be standardized. The nice thing about vocabulary development is that it is a continuous process... if you miss an important vocabulary term now, you can always put it in later. It's much more costly to remove vocabulary terms from a vocabulary if they are not used. For example, if "printable" becomes a reality for a large range of plastic products (due to the proliferation of high-quality, low-cost 3D printers), then the term can be added to the product vocabulary when that happens. Not before. I understand your argument for p-v, however, if every Microformat used it we would start to have a high number of collisions when interleaving Microformats on a page. There are two arguments against using p-v: 1. It is an attempt to future-proof a vocabulary that isn't based on any hard data. 2. It increases the likely-hood of vocabulary term collisions. To put it another way - if we are going to allow 'p-v', hAudio will have support for it immediately... and then people will have a nasty time interleaving hAudio+hProduct. If you'd like an example of this issue, I'd be happy to give one. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 From msporny at digitalbazaar.com Sun Feb 22 18:50:38 2009 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Feb 22 18:50:51 2009 Subject: One issue per thread (was: Re: [uf-new] hProduct issues HP1-HP7) In-Reply-To: <529453680-1235000739-cardhu_decombobulator_blackberry.rim.net-1152297912-@bxe1184.bisx.prod.on.blackberry> References: <529453680-1235000739-cardhu_decombobulator_blackberry.rim.net-1152297912-@bxe1184.bisx.prod.on.blackberry> Message-ID: <49A20EFE.3050503@digitalbazaar.com> Tantek Celik wrote: > Please follow-up on the wiki and also one email announcing a batch > of new issues is sufficient. Let's try to keep emails to a minimum > for notification only, and capture discussion/iteration on the wiki. The reason I put each of these in a separate e-mail is to separate issues out into manage-able threads of discussion. I do admit that it's a personal preference, but threaded discussion seems to be a fairly accepted method of working through spec issues. I realize that your preference is to edit the wiki and not respond via e-mail, but it's not clear to me how this is a better method of refining these specs, especially when we're just discussing things. I see that the mailing list rules have been updated as a result of my posts: http://microformats.org/wiki/mailing-lists#Avoid_sending_one_message_per_issue_raised Could you please explain why it's better to discourage per-issue threads on the mailing list and instead direct people to the wiki? Why are we discouraging one form of recorded communication over another? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. twitter: http://twitter.com/manusporny From kavi at google.com Tue Feb 24 17:39:28 2009 From: kavi at google.com (Kavi Goel) Date: Tue Feb 24 17:39:35 2009 Subject: [uf-new] re: Microformats support for aggregate reviews In-Reply-To: <6934bc6b0902181610k60c7b55er117dde2a35027f53@mail.gmail.com> References: <4B362894-1372-4A38-9FDC-667079487BCE@tobyinkster.co.uk> <199b56630901221602v114791f7je2a3e779dc8d7759@mail.gmail.com> <199b56630902111426o59e08dfapf659dbea6668fb9@mail.gmail.com> <0A55472BC29958468426825844F9F22E0659882E@dsp63mail.na.bestbuy.com> <6934bc6b0902181610k60c7b55er117dde2a35027f53@mail.gmail.com> Message-ID: <199b56630902241739t412d627m1c13a01169454c1a@mail.gmail.com> This approach makes sense to me. What do other folks think? On Wed, Feb 18, 2009 at 4:10 PM, Othar Hansson wrote: > > Adding a new microformat for aggregate reviews seems like the wrong > direction to me, because we're adding one that will have strictly > fewer users than hReview itself. > > Will we do the same for aggregates of everything? ?products, listings, > events, etc. could all reasonably have aggregates to describe "what's > on a page". > > Why don't we just define a trivial microformat "aggregate", which > contains one value "count", and can wrap any other microformat? ?The > fields of the wrapped microformat get a new meaning: any given field > is meant to be an aggregate of all the other data associated with the > page. ?E.g., a hypothetical price field should contain a price range. > A rating field should contain an aggregrate rating. ?etc. > > --Othar > > > > On Fri, Feb 13, 2009 at 8:26 AM, Myers, Jay wrote: > > > > Good morning Kavi, > > > > I am putting together an example this morning to post on the wiki. A > > couple of issues that I ran into with the "postcard" example we talked > > about earlier this week: > > > > -- hReview has a required item attribute. I decided to put an href > > around the stars that points to a product detail page url. It might not > > be the most solid workaround, but we can certainly work on that either > > through the format itself, or altering the html to include the name of > > the product. > > -- in many examples there is a total number of reviews. I have added the > > class "num" to identify this. Completely up for debate on the naming... > > > > I should be able to create more examples from other sites next week... > > > > Thanks, > > > > Jay > > > > > > Jay Myers > > Lead Web Development Engineer > > Online Solutions, BestBuy.com > > jay.myers@bestbuy.com > > (w) 612-291-4007 > > (c) 612-296-5836 > > (twitter) @jaymyers > > (skype) jaymmyers > > -----Original Message----- > > From: microformats-new-bounces@microformats.org > > [mailto:microformats-new-bounces@microformats.org] On Behalf Of Kavi > > Goel > > Sent: Wednesday, February 11, 2009 4:26 PM > > To: For discussion of new microformats. > > Subject: Re: [uf-new] re: Microformats support for aggregate reviews > > > > Hi all, > > > > Here is a quick update on conversations around microformats aggregate > > reviews support. I've updated the aggregate-review-brainstorming wiki > > page based on our IRC conversation a few weeks ago: > > http://microformats.org/wiki/aggregate-review-brainstorming > > > > The short summary of the proposal that emerged from the discussion > > over IRC is as follows: > > - define a new microformat that contains two elements. 1) number of > > reviews, and 2) an embedded hReview > > - fields in the embedded hReview (i.e. rating, summary, item type) > > would refer to aggregate information. For example, the rating is the > > average rating across all reviews. > > > > Why this proposal? > > - the new microformat would contain only one element (at least in an > > initial version) to keep things simple according to the 80% rule > > - creating a new microformat rather than extending hReview provides > > flexibility to potentially add more aggregate-only fields in the > > future without cluttering hReview. > > > > If this approach seems like a good one, Jay Myers and/or I will also > > add a few examples of how this markup could look for some sites. > > > > One issue we ran into when trying to apply this to Best Buy and Amazon > > pages -- on many pages, the entire page is about a product, whereas > > only a section of the page is about the reviews. On the other hand, > > for sites like Yelp, the entire page is about the reviews, and only a > > section of the page is about the product spec. So it probably makes > > sense to allow embedded reviews in hProduct's as well as embedded > > hProduct's in hReview's depending on the hierarchy that naturally > > exists on the page. > > > > Kavi > > > > > > On Thu, Jan 22, 2009 at 4:02 PM, Kavi Goel wrote: > > > > > > In order to move this discussion about aggregate reviews along, I'd > > > like to have a discussion over IRC. As a heads-up, I'll plan on > > > discussing alternatives around 2PM Pacific time tomorrow. For folks in > > > different timezones who will be out enjoying the nightlife, sleeping > > > or otherwise away from a computer, please feel encouraged to post > > > ideas via this email discussion or on the brainstorming wiki here: > > > http://microformats.org/wiki/aggregate-review-brainstorming > > > > > > Thanks, > > > Kavi > > > > > > On Wed, Jan 14, 2009 at 12:48 AM, Toby A Inkster > > wrote: > > > > > > > > Jamie Rumbelow wrote: > > > > > > > >> See, comments like that lead me on to think that we need some form > > of > > > >> pagination system for microformats - pagination is much more > > popular among > > > >> sites these days and a rel="paginate" might come in handy. > > > > > > > > HTML already has perfectly good rel="next"/"prev" for that. > > > > > > > > http://www.w3.org/TR/REC-html40/types.html#type-links > > > > > > > > -- > > > > Toby A Inkster > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > microformats-new mailing list > > > > microformats-new@microformats.org > > > > http://microformats.org/mailman/listinfo/microformats-new > > _______________________________________________ > > microformats-new mailing list > > microformats-new@microformats.org > > http://microformats.org/mailman/listinfo/microformats-new > > > > _______________________________________________ > > microformats-new mailing list > > microformats-new@microformats.org > > http://microformats.org/mailman/listinfo/microformats-new > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From meitarm at gmail.com Tue Feb 24 23:07:23 2009 From: meitarm at gmail.com (Mr. Meitar Moscovitz) Date: Tue Feb 24 23:07:42 2009 Subject: [uf-new] re: Microformats support for aggregate reviews In-Reply-To: <199b56630902241739t412d627m1c13a01169454c1a@mail.gmail.com> References: <4B362894-1372-4A38-9FDC-667079487BCE@tobyinkster.co.uk> <199b56630901221602v114791f7je2a3e779dc8d7759@mail.gmail.com> <199b56630902111426o59e08dfapf659dbea6668fb9@mail.gmail.com> <0A55472BC29958468426825844F9F22E0659882E@dsp63mail.na.bestbuy.com> <6934bc6b0902181610k60c7b55er117dde2a35027f53@mail.gmail.com> <199b56630902241739t412d627m1c13a01169454c1a@mail.gmail.com> Message-ID: <23A59DDE-BA64-4D42-898C-94A5B542BDC7@gmail.com> On Feb 25, 2009, at 12:39 PM, Kavi Goel wrote: > This approach makes sense to me. What do other folks think? +1. This feels simpler to me, and also somehow feels like it's actually solving for the case when I *only* want aggregates themselves. -Meitar Moscovitz Personal: http://maymay.net Professional: http://MeitarMoscovitz.com > On Wed, Feb 18, 2009 at 4:10 PM, Othar Hansson > wrote: >> >> Adding a new microformat for aggregate reviews seems like the wrong >> direction to me, because we're adding one that will have strictly >> fewer users than hReview itself. >> >> Will we do the same for aggregates of everything? products, >> listings, >> events, etc. could all reasonably have aggregates to describe "what's >> on a page". >> >> Why don't we just define a trivial microformat "aggregate", which >> contains one value "count", and can wrap any other microformat? The >> fields of the wrapped microformat get a new meaning: any given field >> is meant to be an aggregate of all the other data associated with the >> page. E.g., a hypothetical price field should contain a price range. >> A rating field should contain an aggregrate rating. etc. >> >> --Othar From mail at tobyinkster.co.uk Wed Feb 25 11:06:32 2009 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Feb 25 11:25:43 2009 Subject: [uf-new] re: Microformats support for aggregate reviews Message-ID: Othar Hansson wrote: > Why don't we just define a trivial microformat "aggregate", which > contains one value "count", and can wrap any other microformat? The > fields of the wrapped microformat get a new meaning: any given field > is meant to be an aggregate of all the other data associated with the > page. E.g., a hypothetical price field should contain a price range. > A rating field should contain an aggregrate rating. But how are things to be aggregated? In some cases (like hReview's "rating"), the aggregate might be the numerical mean of the individuals. For other fields, the median, the mode or the range might be more suitable. For yet others, perhaps it would be desirable to see the sum of the individuals. For example, say you're creating an aggregate hCalendar event. Using an average dtstart and dtend is probably not very useful, but taking the earliest dtstart and latest dtend might be. -- Toby A Inkster From othar at othar.com Wed Feb 25 12:06:48 2009 From: othar at othar.com (Othar Hansson) Date: Wed Feb 25 12:06:50 2009 Subject: [uf-new] re: Microformats support for aggregate reviews In-Reply-To: References: Message-ID: <6934bc6b0902251206v1f794d2as804a05510089ccf9@mail.gmail.com> Details of the aggregation are field-dependent and also up to the page owner. You're right that the natural aggregate of a date or a price is the range. --Othar On Wed, Feb 25, 2009 at 11:06 AM, Toby A Inkster wrote: > Othar Hansson wrote: > >> Why don't we just define a trivial microformat "aggregate", which >> contains one value "count", and can wrap any other microformat? ?The >> fields of the wrapped microformat get a new meaning: any given field >> is meant to be an aggregate of all the other data associated with the >> page. ?E.g., a hypothetical price field should contain a price range. >> A rating field should contain an aggregrate rating. > > But how are things to be aggregated? In some cases (like hReview's > "rating"), the aggregate might be the numerical mean of the individuals. For > other fields, the median, the mode or the range might be more suitable. For > yet others, perhaps it would be desirable to see the sum of the individuals. > > For example, say you're creating an aggregate hCalendar event. Using an > average dtstart and dtend is probably not very useful, but taking the > earliest dtstart and latest dtend might be. > > -- > Toby A Inkster > > > > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From tantek at cs.stanford.edu Fri Feb 27 18:48:20 2009 From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=) Date: Fri Feb 27 18:48:22 2009 Subject: One issue per thread (was: Re: [uf-new] hProduct issues HP1-HP7) In-Reply-To: <49A20EFE.3050503@digitalbazaar.com> References: <529453680-1235000739-cardhu_decombobulator_blackberry.rim.net-1152297912-@bxe1184.bisx.prod.on.blackberry> <49A20EFE.3050503@digitalbazaar.com> Message-ID: <60cb038a0902271848t548bcb77h6a2a26f0da9fe6fa@mail.gmail.com> On Sun, Feb 22, 2009 at 6:50 PM, Manu Sporny wrote: > Could you please explain why it's better to discourage per-issue threads > on the mailing list and instead direct people to the wiki? Why are we > discouraging one form of recorded communication over another? I have written up a page that explains some of the reasons behind the microformats community's preference for using the wiki instead of email: http://microformats.org/wiki/wiki-better-than-email On Sun, Feb 22, 2009 at 6:50 PM, Manu Sporny wrote: > Tantek Celik wrote: >> Please follow-up on the wiki and also one email announcing a batch >> of new issues is sufficient. Let's try to keep emails to a minimum >> for notification only, and capture discussion/iteration on the wiki. > > The reason I put each of these in a separate e-mail is to separate > issues out into manage-able threads of discussion. I do admit that it's > a personal preference, but threaded discussion seems to be a fairly > accepted method of working through spec issues. Email-centric threaded discussion is fairly accepted method in many other standards communities/organizations (W3C, IETF). Per http://microformats.org/wiki/wiki-better-than-email#tradition , this has been different in the microformats community from the start of microformats, and deliberately so. Thanks, Tantek From msporny at digitalbazaar.com Fri Feb 27 19:33:05 2009 From: msporny at digitalbazaar.com (Manu Sporny) Date: Fri Feb 27 19:33:10 2009 Subject: [uf-new] Re: One issue per thread In-Reply-To: <60cb038a0902271848t548bcb77h6a2a26f0da9fe6fa@mail.gmail.com> References: <529453680-1235000739-cardhu_decombobulator_blackberry.rim.net-1152297912-@bxe1184.bisx.prod.on.blackberry> <49A20EFE.3050503@digitalbazaar.com> <60cb038a0902271848t548bcb77h6a2a26f0da9fe6fa@mail.gmail.com> Message-ID: <49A8B071.6090900@digitalbazaar.com> Tantek ?elik wrote: > On Sun, Feb 22, 2009 at 6:50 PM, Manu Sporny wrote: >> Could you please explain why it's better to discourage per-issue threads >> on the mailing list and instead direct people to the wiki? Why are we >> discouraging one form of recorded communication over another? > > I have written up a page that explains some of the reasons behind the > microformats community's preference for using the wiki instead of > email: > > http://microformats.org/wiki/wiki-better-than-email I've noted various issues on the page. Most notably that the community shouldn't be forcing a particular workflow on community members. Some of us can't be distracted by IRC at all times and the people we need to talk to aren't always on IRC anyway. There's much more on the wiki page that I've commented on, so I'll leave it at that, I guess. > On Sun, Feb 22, 2009 at 6:50 PM, Manu Sporny wrote: >> Tantek Celik wrote: >>> Please follow-up on the wiki and also one email announcing a batch >>> of new issues is sufficient. Let's try to keep emails to a minimum >>> for notification only, and capture discussion/iteration on the wiki. >> The reason I put each of these in a separate e-mail is to separate >> issues out into manage-able threads of discussion. I do admit that it's >> a personal preference, but threaded discussion seems to be a fairly >> accepted method of working through spec issues. > > Email-centric threaded discussion is fairly accepted method in many > other standards communities/organizations (W3C, IETF). Per > http://microformats.org/wiki/wiki-better-than-email#tradition , this > has been different in the microformats community from the start of > microformats, and deliberately so. Tradition, in and of itself, is not a valid reason for doing something a certain way. I don't think it should be listed as a "reason" - distill out the reasoning that makes the tradition an acceptable practice, please. More on this on the wiki page. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 From davidjanes at blogmatrix.com Sat Feb 28 03:55:56 2009 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Feb 28 03:56:00 2009 Subject: [uf-new] Re: One issue per thread In-Reply-To: <49A8B071.6090900@digitalbazaar.com> References: <529453680-1235000739-cardhu_decombobulator_blackberry.rim.net-1152297912-@bxe1184.bisx.prod.on.blackberry> <49A20EFE.3050503@digitalbazaar.com> <60cb038a0902271848t548bcb77h6a2a26f0da9fe6fa@mail.gmail.com> <49A8B071.6090900@digitalbazaar.com> Message-ID: <21e523c20902280355k5ec2215cwd256c0e4c6ee7732@mail.gmail.com> On Fri, Feb 27, 2009 at 10:33 PM, Manu Sporny wrote: > Tantek ?elik wrote: >> On Sun, Feb 22, 2009 at 6:50 PM, Manu Sporny wrote: >>> Could you please explain why it's better to discourage per-issue threads >>> on the mailing list and instead direct people to the wiki? Why are we >>> discouraging one form of recorded communication over another? >> >> I have written up a page that explains some of the reasons behind the >> microformats community's preference for using the wiki instead of >> email: >> >> http://microformats.org/wiki/wiki-better-than-email > > I've noted various issues on the page. Most notably that the community > shouldn't be forcing a particular workflow on community members. Some of > us can't be distracted by IRC at all times and the people we need to > talk to aren't always on IRC anyway. > > There's much more on the wiki page that I've commented on, so I'll leave > it at that, I guess. > >> On Sun, Feb 22, 2009 at 6:50 PM, Manu Sporny wrote: >>> Tantek Celik wrote: >>>> Please follow-up on the wiki and also one email announcing a batch >>>> of new issues is sufficient. Let's try to keep emails to a minimum >>>> for notification only, and capture discussion/iteration on the wiki. >>> The reason I put each of these in a separate e-mail is to separate >>> issues out into manage-able threads of discussion. I do admit that it's >>> a personal preference, but threaded discussion seems to be a fairly >>> accepted method of working through spec issues. >> >> Email-centric threaded discussion is fairly accepted method in many >> other standards communities/organizations (W3C, IETF). Per >> http://microformats.org/wiki/wiki-better-than-email#tradition , this >> has been different in the microformats community from the start of >> microformats, and deliberately so. > > Tradition, in and of itself, is not a valid reason for doing something a > certain way. I don't think it should be listed as a "reason" - distill > out the reasoning that makes the tradition an acceptable practice, > please. More on this on the wiki page. > > -- manu I'm with Manu with on this one. Tantek and Kevin Marks could also just walk down the corridor and thrash through ideas back in 2005 and can probably do the same by meeting at the food court for lunch or whatever in 2009. For many of us e-mail is a natural way of discussing ideas, working through issues and so forth; not adding '* +1 my comment my name' to Wiki pages that will be seen by 6 or whatever people over its lifetime. Regards, etc... -- David Janes Mercenary Programmer http://code.davidjanes.com From Jay.Myers at bestbuy.com Sat Feb 28 06:14:32 2009 From: Jay.Myers at bestbuy.com (Myers, Jay) Date: Sat Feb 28 06:15:24 2009 Subject: [uf-new] Re: One issue per thread Message-ID: <57c601c999ae$d896d6f3$a2475ea8@na.bestbuy.com> Would it be a reasonable request for a new discussion list for people who would like to address issues in this way, with the condition that they summarize discussions on the wiki? - Jay -----Original Message----- From: David Janes Sent: Saturday, February 28, 2009 5:56 AM To: For discussion of new microformats. Subject: Re: [uf-new] Re: One issue per thread On Fri, Feb 27, 2009 at 10:33 PM, Manu Sporny wrote: > Tantek ?elik wrote: >> On Sun, Feb 22, 2009 at 6:50 PM, Manu Sporny wrote: >>> Could you please explain why it's better to discourage per-issue threads >>> on the mailing list and instead direct people to the wiki? Why are we >>> discouraging one form of recorded communication over another? >> >> I have written up a page that explains some of the reasons behind the >> microformats community's preference for using the wiki instead of >> email: >> >> http://microformats.org/wiki/wiki-better-than-email > > I've noted various issues on the page. Most notably that the community > shouldn't be forcing a particular workflow on community members. Some of > us can't be distracted by IRC at all times and the people we need to > talk to aren't always on IRC anyway. > > There's much more on the wiki page that I've commented on, so I'll leave > it at that, I guess. > >> On Sun, Feb 22, 2009 at 6:50 PM, Manu Sporny wrote: >>> Tantek Celik wrote: >>>> Please follow-up on the wiki and also one email announcing a batch >>>> of new issues is sufficient. Let's try to keep emails to a minimum >>>> for notification only, and capture discussion/iteration on the wiki. >>> The reason I put each of these in a separate e-mail is to separate >>> issues out into manage-able threads of discussion. I do admit that it's >>> a personal preference, but threaded discussion seems to be a fairly >>> accepted method of working through spec issues. >> >> Email-centric threaded discussion is fairly accepted method in many >> other standards communities/organizations (W3C, IETF). Per >> http://microformats.org/wiki/wiki-better-than-email#tradition , this >> has been different in the microformats community from the start of >> microformats, and deliberately so. > > Tradition, in and of itself, is not a valid reason for doing something a > certain way. I don't think it should be listed as a "reason" - distill > out the reasoning that makes the tradition an acceptable practice, > please. More on this on the wiki page. > > -- manu I'm with Manu with on this one. Tantek and Kevin Marks could also just walk down the corridor and thrash through ideas back in 2005 and can probably do the same by meeting at the food court for lunch or whatever in 2009. For many of us e-mail is a natural way of discussing ideas, working through issues and so forth; not adding '* +1 my comment my name' to Wiki pages that will be seen by 6 or whatever people over its lifetime. Regards, etc... -- David Janes Mercenary Programmer http://code.davidjanes.com _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Sat Feb 28 07:49:52 2009 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sat Feb 28 07:50:03 2009 Subject: [uf-new] Re: One issue per thread In-Reply-To: <57c601c999ae$d896d6f3$a2475ea8@na.bestbuy.com> References: <57c601c999ae$d896d6f3$a2475ea8@na.bestbuy.com> Message-ID: <49A95D20.4030401@digitalbazaar.com> Myers, Jay wrote: > Would it be a reasonable request for a new discussion list for > people who would like to address issues in this way, with the > condition that they summarize discussions on the wiki? I thought that was what this mailing list was for? At least, that's how we were operating during hAudio development. Here's another idea (that would take months to implement), just thinking out loud: Problem: We are not capturing all of the conversations surrounding each Microformats spec in a way that: - Can be automatically associated with a specification on the wiki. - Can be searched quickly for answers. - Works with different workflows (IRC+wiki) and (e-mail+wiki) What would be really great is a mechanism where we could do sub-subscriptions, so that you could create a set of filters for "things I am not interested in". So, you would subscribe to microformats-new and then provide filters for things that you are not interested in (hCard, hAudio, etc.) It would give us finer-grain control over what we're exposed to as mailing list participants. Tying this into IRC so that we could choose to get a daily log of IRC conversations related to each topic area would be great as well. That way, we get daily/weekly updates from IRC that have a good subscriber-specific signal-to-noise ratio. Perhaps if somebody could hack together an IRC-like mechanism (using HTML5's canvas feature) and tie it into the microformats.org wiki to provide a synchronous communication mechanism with logging support. The logs for all hAudio channels (IRC and mailing list) would be tied to the hAudio wiki page. People could filter out each sub-topic as they pleased and these discussions would be a part of the living documentation for the spec. All conversations are auto-sorted into their respective logging area on the wiki. The only problem with this approach is that it would take a very long time to develop/implement. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 From scott at makedatamakesense.com Sat Feb 28 09:47:29 2009 From: scott at makedatamakesense.com (Scott Reynen) Date: Sat Feb 28 09:47:40 2009 Subject: [uf-new] Re: One issue per thread In-Reply-To: <21e523c20902280355k5ec2215cwd256c0e4c6ee7732@mail.gmail.com> References: <529453680-1235000739-cardhu_decombobulator_blackberry.rim.net-1152297912-@bxe1184.bisx.prod.on.blackberry> <49A20EFE.3050503@digitalbazaar.com> <60cb038a0902271848t548bcb77h6a2a26f0da9fe6fa@mail.gmail.com> <49A8B071.6090900@digitalbazaar.com> <21e523c20902280355k5ec2215cwd256c0e4c6ee7732@mail.gmail.com> Message-ID: On [Feb 28], at [ Feb 28] 4:55 , David Janes wrote: > For many of us e-mail is a natural way of discussing > ideas, working through issues and so forth For what it's worth, I've always considered email a tool for discussion and the wiki a tool for documentation. But I don't think that's worth much. It seems to me this discussion boils down to "I like email" vs. "I don't", and all of the arguments about what's best for this community are just dressing for personal bias. We're not going to find what works best for this community until we actually start looking for it, which is hard to do when we're working toward pre-determined conclusions. -- Scott Reynen MakeDataMakeSense.com From lists at ben-ward.co.uk Sat Feb 28 16:11:00 2009 From: lists at ben-ward.co.uk (Ben Ward) Date: Sat Feb 28 16:11:08 2009 Subject: [uf-new] Re: One issue per thread In-Reply-To: <49A95D20.4030401@digitalbazaar.com> References: <57c601c999ae$d896d6f3$a2475ea8@na.bestbuy.com> <49A95D20.4030401@digitalbazaar.com> Message-ID: <5DBDF01A-D610-4495-932C-C4D7FBC64DCC@ben-ward.co.uk> I am a very pro-wiki person; not just in microformats.org, but everywhere else, too. Also, moving this discussion to microformats-discuss, since this is not discussing the creation of new microformats. On 28 Feb 2009, at 07:49, Manu Sporny wrote: > The only problem with this approach is that it would take a very long > time to develop/implement. I think I would class that problem as ?fatal? to an otherwise beautiful vision of interoperating technologies. Nice try though ;-) On 28 Feb 2009, at 09:47, Scott Reynen wrote: > For what it's worth, I've always considered email a tool for > discussion and the wiki a tool for documentation. But I don't think > that's worth much. I somewhat agree, in that regardless of how the content is compromised, the content of the wiki *must* function as a piece of documentation. It's all the documentation we have, of specs, brainstorms, and so forth. Certainly within this community it is regarded as ?truth? ? ?wiki or it didn't happen?. As such, no matter where discussion takes place, the knowledge from it *must* go on the wiki, or it will be lost. If anything has dragged this community down in the past, it's not being able to accurately refer to past events. Using the wiki thoroughly is what prevents that. The importance of using it as part of spec and related developments here cannot be played down. I think it's well suited to editorially driven content, which is the primary output of microformats.org. * The problem with the lists is that if an issue discussed is not documented on the wiki, you raise an ever increasing barrier to entry for someone else to join that discussion, particularly as time passes and the thread is buried under subsequent unrelated discussions. * Conversely, the problem with the wiki is that a piece of documentation can be spoiled by interjections of disagreement in every other paragraph. I find value in lists for humanising discussion too. Writing this email I'm able to be a little more verbose with mannerisms and language that, hopefully, means everyone appreciates me as a human being rather than a Robot Overlord Admin Robot (additional robot for benefit of awesome ?ROAR? abbreviation). I think that's important to everyone here being able to work together, and the depersonalised nature of documentation on the wiki is the opposite; highly-optimised issues are vital for documentation, but bad for interacting in a friendly manner with the people that contributed. (Issue documented: http://is.gd/laIn) The result is a certain amount of duplicity to having lists. As I say, I have no issue just ignoring list content that should go on the wiki. But, somewhere it shifts a burden: Either to individuals who must ensure their point of view is documented twice, or onto specification editors to pull every discussion together. The latter editorial burdon is not going to be acceptable in most cases; expecting a spec editor to create permanent wiki documentation of every discussion is an unreasonable waste of their time. I'm not anti-email. But I support the idea that everyone contributing must ensure their knowledge is documented. I don't have a clear idea on precisely where the line between different sorts of discussion sits to reduce duplication. B