From martin at weborganics.co.uk Mon Sep 1 02:01:20 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Sep 1 02:01:32 2008 Subject: [uf-new] Closing hAudio issues D1, D3 and D4 Message-ID: <48BBAF60.3050907@weborganics.co.uk> Hello all I will be closing issues D1, D3, and D4 today the solutions are outlined below. ------------------------------------------------------------------------------------------------------------------------------------------------------ D1: 2008-01-10 Contributor[1] *Resolved Issue* The hAudio Contributor Specification is to be changed to: * The element is identified by the class name |contributor|. * hAudio /MAY/ include one or more contributors. * The contributor's name SHOULD also be marked up as a valid hCard Microformat. * The |role| attribute /SHOULD/ be used to specify the contributor's responsibility related to the audio recording if hCard is utilized. * The contributor's name MAY be specified in plain-text without being enclosed in a hCard Microformat. REMOVED: * If multiple contributors are specified, without |role| specifications, it /MAY/ be assumed that the first role mentioned is the primary artist or creator. as highlighted By Manu Sporny http://microformats.org/discuss/mail/microformats-new/2008-August/001725.html ------------------------------------------------------------------------------------------------------------------------------------------------------ D3: 2008-01-10 *Resolved Issue* Position [3] The position is used to describe the position of the hAudio item in a list. Examples of hAudio lists can include album track listings, music top 10 lists, playlists, and podcast chapters. * The element is identified by the class name |position|. * hAudio /MAY/ include one |position| element. * The contents of the element /MUST/ be a number or other sequential identifier. * The sequential identifier /MAY/ be specified out-of-sequence As highlighted By Manu Sporny http://microformats.org/discuss/mail/microformats-new/2008-August/001708.html Andy Mabbett Expressed concerns that the Complete album example on the wiki http://microformats.org/wiki/haudio#Complete_Album_Example should be marked up as an ordered list this is unnecessary as "position" is nothing to do with the order of a track item in a list. @todo a tutorial on the importance of semantic ordered lists and hAudio is to be added to the hAudio Authoring Page http://microformats.org/wiki/haudio-authoring ------------------------------------------------------------------------------------------------------------------------------------------------------ D4: 2008-01-10 *Resolved Issue* rel-enclosure does not allow for links to streaming files [3] This can potentially be solved by recognition of downloadable/streamable MIME types. For performance reasons it is undesirable for parsers to be required to make HTTP requests for each file to determine its MIME type, so authors should be encouraged to include the MIME type in the type attribute. The hAudio Enclosure Specification is to be changed to: Full Download (Enclosure) A Full Download URI specifies from where the full version of an audio recording may be retrieved. The URI MUST point to a direct link to a file retrieval process (FTP, HTTP, BitTorrent URI, etc). * The element is identified by a URI fitting the rel-design-pattern, the rel content being enclosure. * hAudio MAY include one or more enclosure URIs. * The type of the file SHOULD be specified by using the type specifier for a URI. as suggested by Tantek http://microformats.org/discuss/mail/microformats-new/2008-August/001731.html and also by Toby http://microformats.org/wiki/haudio-brainstorming#Download_links @todo tutorial on the importance of a type specifier is to be added to the hAudio Authoring Page http://microformats.org/wiki/haudio-authoring ---------------------------------------------------------------------------------------------------------------------------------------------------- Best Wishes Martin McEvoy From martin at weborganics.co.uk Mon Sep 1 05:28:15 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Sep 1 05:28:46 2008 Subject: [uf-new] hAudio issue D2 "title" Message-ID: <48BBDFDF.4030904@weborganics.co.uk> Hello all I have left this issue until last because this is the longest and probably the most contentious issue of them all issue D2 hAudio Title[1] originally marked as Overloading "fn" The current discussion around hAudio Title[2] is at the moment that It can't be used because its already defined in hcard[3] to mean "Job Title"[4] [1] http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_Overloading_.22fn.22. [2] http://microformats.org/wiki/haudio#Title [3] http://microformats.org/wiki/hcard [3] http://www.w3.org/2002/12/cal/rfc2426#sec3.5.1 There are currently three possible resolutions: ------------------------------------------------------------------------------------------------------------------------- Resolution 1: Use "NAME" [...] Name http://en.wikipedia.org/wiki/Name "A name is a label for a human or animal, thing, place, product (as in a brand name) and even an idea or concept, normally used to distinguish one from another. Names can identify a class or category of things, or a single thing, either uniquely, or within a given context." [...] A Proposal was made in an email on March 5th 2008 by Myself. http://microformats.org/discuss/mail/microformats-new/2008-March/001555.html ------------------------------------------------------------------------------------------------------------------------- Resoulution 2: Use "HTITLE" [...] "hTitle can then be reused in any microformat that needs a "title" property. hTitle has been given a root class name as it is intended to be used in conjunction with any other root class microformat and mirrors the association semantics expressed by hfeed => hentry in hAtom" [...] A Proposal was made in an email on Aug 13th 2008 by Myself. http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html ------------------------------------------------------------------------------------------------------------------------- Resoulution 3: Use "AUDIO-TITLE" As tentatively proposed by Manu Spony in an email on Wed Aug 13th 2008 http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html ------------------------------------------------------------------------------------------------------------------------- If anyone would like to support any of the above resolutions please add a +1(plus one) to the resolution along with any comments you would like to add similarly you can add your disapproval and reasons why with a -1(minus one). Of course If you have another resolution please reply to this email with your proposal. Best Wishes Martin McEvoy From msporny at digitalbazaar.com Mon Sep 1 06:21:44 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Sep 1 06:21:52 2008 Subject: [uf-new] Closing hAudio issues D1, D3 and D4 In-Reply-To: <48BBAF60.3050907@weborganics.co.uk> References: <48BBAF60.3050907@weborganics.co.uk> Message-ID: <48BBEC68.3030804@digitalbazaar.com> Martin McEvoy wrote: > I will be closing issues D1, D3, and D4 today the solutions are > outlined below. +1 to all of your proposed solutions, Martin. Great work on closing these last remaining issues! :) -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.0 Website Launches http://blog.digitalbazaar.com/2008/07/03/bitmunk-3-website-launches From tantek at cs.stanford.edu Mon Sep 1 06:22:41 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Mon Sep 1 06:23:12 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <48BBDFDF.4030904@weborganics.co.uk> References: <48BBDFDF.4030904@weborganics.co.uk> Message-ID: <1268386725-1220275384-cardhu_decombobulator_blackberry.rim.net-622897905-@bxe118.bisx.prod.on.blackberry> Martin, The first option you provide illustrates the fundamental problem with this issue, which is that the meaning we are trying to express is the name of the track / hAudio item. Even the iTunes UI refers to the "Name" (select a track in iTunes, Get Info, click the Info tab, note the first field). For microformats, we already have a property for the meaning of "name", and that's "fn". It specifically means "formatted name" but that simply reflects the fact that it means the name as published (as it is shown) rather than some abstract structural name, and "as published" is precisely what we want in microformats since we are marking up visible content *published* on the web. "fn" is already used to mean name in hCard (from vCard), and for the names of hReview items and hListing items. Per the naming principle of not introducing two properties for the same meaning (see wiki/naming-principles ), we should have simply reused "fn" for this long ago. In addition, from a process perspective, please use the wiki not email for brainstorming and opinions on proposals. Tracking this in email over time is nearly impossible. Please place the options on wiki/audio-brainstorming along with nested list items for individuals to offer their +/-1 (or 0) opinion with username and any comments explaining their opinion. Thanks, Tantek -----Original Message----- From: Martin McEvoy Date: Mon, 01 Sep 2008 13:28:15 To: For discussion of new microformats. Subject: [uf-new] hAudio issue D2 "title" Hello all I have left this issue until last because this is the longest and probably the most contentious issue of them all issue D2 hAudio Title[1] originally marked as Overloading "fn" The current discussion around hAudio Title[2] is at the moment that It can't be used because its already defined in hcard[3] to mean "Job Title"[4] [1] http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_Overloading_.22fn.22. [2] http://microformats.org/wiki/haudio#Title [3] http://microformats.org/wiki/hcard [3] http://www.w3.org/2002/12/cal/rfc2426#sec3.5.1 There are currently three possible resolutions: ------------------------------------------------------------------------------------------------------------------------- Resolution 1: Use "NAME" [...] Name http://en.wikipedia.org/wiki/Name "A name is a label for a human or animal, thing, place, product (as in a brand name) and even an idea or concept, normally used to distinguish one from another. Names can identify a class or category of things, or a single thing, either uniquely, or within a given context." [...] A Proposal was made in an email on March 5th 2008 by Myself. http://microformats.org/discuss/mail/microformats-new/2008-March/001555.html ------------------------------------------------------------------------------------------------------------------------- Resoulution 2: Use "HTITLE" [...] "hTitle can then be reused in any microformat that needs a "title" property. hTitle has been given a root class name as it is intended to be used in conjunction with any other root class microformat and mirrors the association semantics expressed by hfeed => hentry in hAtom" [...] A Proposal was made in an email on Aug 13th 2008 by Myself. http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html ------------------------------------------------------------------------------------------------------------------------- Resoulution 3: Use "AUDIO-TITLE" As tentatively proposed by Manu Spony in an email on Wed Aug 13th 2008 http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html ------------------------------------------------------------------------------------------------------------------------- If anyone would like to support any of the above resolutions please add a +1(plus one) to the resolution along with any comments you would like to add similarly you can add your disapproval and reasons why with a -1(minus one). Of course If you have another resolution please reply to this email with your proposal. Best Wishes Martin McEvoy _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Mon Sep 1 06:31:33 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Sep 1 06:31:40 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <48BBDFDF.4030904@weborganics.co.uk> References: <48BBDFDF.4030904@weborganics.co.uk> Message-ID: <48BBEEB5.3040401@digitalbazaar.com> Martin McEvoy wrote: > ------------------------------------------------------------------------------------------------------------------------- > Resoulution 2: > > Use "HTITLE" > > [...] > "hTitle can then be reused in any microformat that needs a "title" > property. hTitle has been given a root class name as it is intended to > be used in conjunction with any other root class microformat and mirrors > the association semantics expressed by hfeed => hentry in hAtom" > [...] > > A Proposal was made in an email on Aug 13th 2008 by Myself. > http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html > ------------------------------------------------------------------------------------------------------------------------- +1 to your "htitle" proposal, Martin. I believe it is superior to all of the other proposals related to solving this problem, for the following reasons: - It can be re-used across all Microformats requiring a property to mark up future title information (hVideo, hBook, etc.). - It doesn't use a pseudo-namespace, like "audio-title" does. -- manu From martin at weborganics.co.uk Mon Sep 1 12:31:53 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Sep 1 12:32:05 2008 Subject: [uf-new] Closing hAudio issues D1, D3 and D4 In-Reply-To: <48BBEC68.3030804@digitalbazaar.com> References: <48BBAF60.3050907@weborganics.co.uk> <48BBEC68.3030804@digitalbazaar.com> Message-ID: <48BC4329.7050002@weborganics.co.uk> Manu Sporny wrote: > Martin McEvoy wrote: > >> I will be closing issues D1, D3, and D4 today the solutions are >> outlined below. >> > > +1 to all of your proposed solutions, Martin. Great work on closing > these last remaining issues! :) > Thank you Manu, I didnt do it on my own just nudged you all a little ;-) Best wishes Martin McEvoy > -- manu > > From martin at weborganics.co.uk Mon Sep 1 13:00:33 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Sep 1 13:00:45 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <1268386725-1220275384-cardhu_decombobulator_blackberry.rim.net-622897905-@bxe118.bisx.prod.on.blackberry> References: <48BBDFDF.4030904@weborganics.co.uk> <1268386725-1220275384-cardhu_decombobulator_blackberry.rim.net-622897905-@bxe118.bisx.prod.on.blackberry> Message-ID: <48BC49E1.6080100@weborganics.co.uk> Hello Tantek Tantek Celik wrote: > Martin, > > The first option you provide illustrates the fundamental problem with this issue, which is that the meaning we are trying to express is the name of the track / hAudio item. Even the iTunes UI refers to the "Name" (select a track in iTunes, Get Info, click the Info tab, note the first field). > > For microformats, we already have a property for the meaning of "name", and that's "fn". It specifically means "formatted name" but that simply reflects the fact that it means the name as published (as it is shown) rather than some abstract structural name, and "as published" is precisely what we want in microformats since we are marking up visible content *published* on the web. > > "fn" is already used to mean name in hCard (from vCard), and for the names of hReview items and hListing items. > Per the naming principle of not introducing two properties for the same meaning (see wiki/naming-principles ), we should have simply reused "fn" for this long ago. > "fn" was changed to "title" because it was over used in haudio, haudio title => fn haudio contributor = fn item title = fn and what If the author of the audio came first? very messy and uninspired I will accept however that haudio Items should use "fn" because thats how Item is used in all other Microformats
blah
"n" simply wont do either "The name of the unit" what does that mean? it seems deliberately vague to me what is a unit? is it defined in microformats?, sorry Tantek I'm just thinking out loud :-) > > In addition, from a process perspective, please use the wiki not email for brainstorming and opinions on proposals. Tracking this in email over time is nearly impossible. > > Please place the options on wiki/audio-brainstorming along with nested list items for individuals to offer their +/-1 (or 0) opinion with username and any comments explaining their opinion. > Done see, http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_Overloading_.22fn.22 Please add your support for any of the resolutions on the page above, or add your own resolution. > Thanks, > > Tantek > > Best wishes Martin McEvoy > -----Original Message----- > From: Martin McEvoy > > Date: Mon, 01 Sep 2008 13:28:15 > To: For discussion of new microformats. > Subject: [uf-new] hAudio issue D2 "title" > > > Hello all > > I have left this issue until last because this is the longest and > probably the most contentious issue of them all issue D2 hAudio Title[1] > originally marked as Overloading "fn" > > The current discussion around hAudio Title[2] is at the moment that It > can't be used because its already defined in hcard[3] to mean "Job > Title"[4] > > [1] > http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_Overloading_.22fn.22. > [2] http://microformats.org/wiki/haudio#Title > [3] http://microformats.org/wiki/hcard > [3] http://www.w3.org/2002/12/cal/rfc2426#sec3.5.1 > > There are currently three possible resolutions: > ------------------------------------------------------------------------------------------------------------------------- > Resolution 1: > > Use "NAME" > > [...] > Name http://en.wikipedia.org/wiki/Name > "A name is a label for a human or animal, thing, place, product (as in a > brand name) and even an idea or concept, normally used to distinguish > one from another. Names can identify a class or category of things, or a > single thing, either uniquely, or within a given context." > [...] > > A Proposal was made in an email on March 5th 2008 by Myself. > http://microformats.org/discuss/mail/microformats-new/2008-March/001555.html > > ------------------------------------------------------------------------------------------------------------------------- > Resoulution 2: > > Use "HTITLE" > > [...] > "hTitle can then be reused in any microformat that needs a "title" > property. hTitle has been given a root class name as it is intended to > be used in conjunction with any other root class microformat and mirrors > the association semantics expressed by hfeed => hentry in hAtom" > [...] > > A Proposal was made in an email on Aug 13th 2008 by Myself. > http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html > > ------------------------------------------------------------------------------------------------------------------------- > Resoulution 3: > > Use "AUDIO-TITLE" > > As tentatively proposed by Manu Spony in an email on Wed Aug 13th 2008 > http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html > > ------------------------------------------------------------------------------------------------------------------------- > > If anyone would like to support any of the above resolutions please add > a +1(plus one) to the resolution along with any comments you would like > to add similarly you can add your disapproval and reasons why with a > -1(minus one). Of course If you have another resolution please reply to > this email with your proposal. > > > Best Wishes > > Martin McEvoy > > > > > > > > _______________________________________________ > 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 Mon Sep 1 13:04:02 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Sep 1 13:04:13 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <48BC49E1.6080100@weborganics.co.uk> References: <48BBDFDF.4030904@weborganics.co.uk> <1268386725-1220275384-cardhu_decombobulator_blackberry.rim.net-622897905-@bxe118.bisx.prod.on.blackberry> <48BC49E1.6080100@weborganics.co.uk> Message-ID: <48BC4AB2.9040400@weborganics.co.uk> Martin McEvoy wrote: > Hello Tantek > > Tantek Celik wrote: >> Martin, >> >> The first option you provide illustrates the fundamental problem with >> this issue, which is that the meaning we are trying to express is the >> name of the track / hAudio item. Even the iTunes UI refers to the >> "Name" (select a track in iTunes, Get Info, click the Info tab, note >> the first field). >> >> For microformats, we already have a property for the meaning of >> "name", and that's "fn". It specifically means "formatted name" but >> that simply reflects the fact that it means the name as published (as >> it is shown) rather than some abstract structural name, and "as >> published" is precisely what we want in microformats since we are >> marking up visible content *published* on the web. >> >> "fn" is already used to mean name in hCard (from vCard), and for the >> names of hReview items and hListing items. >> Per the naming principle of not introducing two properties for the >> same meaning (see wiki/naming-principles ), we should have simply >> reused "fn" for this long ago. >> > "fn" was changed to "title" because it was over used in haudio, > > haudio title => fn > haudio contributor = fn > item title = fn > > and what If the author of the audio came first? very messy and uninspired > > I will accept however that haudio Items should use "fn" because thats > how Item is used in all other Microformats > >
> blah >
> > "n" simply wont do either "The name of the unit" what does that mean? > it seems deliberately vague to me what is a unit? is it defined in > microformats?, sorry Tantek I'm just thinking out loud :-) >> >> In addition, from a process perspective, please use the wiki not >> email for brainstorming and opinions on proposals. Tracking this in >> email over time is nearly impossible. >> >> Please place the options on wiki/audio-brainstorming along with >> nested list items for individuals to offer their +/-1 (or 0) opinion >> with username and any comments explaining their opinion. >> > > Done see, > http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_Overloading_.22fn.22 > oops! sorry changed to http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_hAudio_Title_was_Overloading_.22fn.22. Thanks Martin McEvoy > > Please add your support for any of the resolutions on the page above, > or add your own resolution. >> Thanks, >> >> Tantek >> >> > Best wishes > > Martin McEvoy >> -----Original Message----- >> From: Martin McEvoy >> >> Date: Mon, 01 Sep 2008 13:28:15 To: For discussion of new >> microformats. >> Subject: [uf-new] hAudio issue D2 "title" >> >> >> Hello all >> >> I have left this issue until last because this is the longest and >> probably the most contentious issue of them all issue D2 hAudio >> Title[1] originally marked as Overloading "fn" >> >> The current discussion around hAudio Title[2] is at the moment that >> It can't be used because its already defined in hcard[3] to mean "Job >> Title"[4] >> >> [1] >> http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_Overloading_.22fn.22. >> >> [2] http://microformats.org/wiki/haudio#Title >> [3] http://microformats.org/wiki/hcard >> [3] http://www.w3.org/2002/12/cal/rfc2426#sec3.5.1 >> >> There are currently three possible resolutions: >> ------------------------------------------------------------------------------------------------------------------------- >> >> Resolution 1: >> >> Use "NAME" >> >> [...] >> Name http://en.wikipedia.org/wiki/Name >> "A name is a label for a human or animal, thing, place, product (as in a >> brand name) and even an idea or concept, normally used to distinguish >> one from another. Names can identify a class or category of things, or a >> single thing, either uniquely, or within a given context." >> [...] >> >> A Proposal was made in an email on March 5th 2008 by Myself. >> http://microformats.org/discuss/mail/microformats-new/2008-March/001555.html >> >> >> ------------------------------------------------------------------------------------------------------------------------- >> >> Resoulution 2: >> >> Use "HTITLE" >> >> [...] >> "hTitle can then be reused in any microformat that needs a "title" >> property. hTitle has been given a root class name as it is intended to >> be used in conjunction with any other root class microformat and mirrors >> the association semantics expressed by hfeed => hentry in hAtom" >> [...] >> >> A Proposal was made in an email on Aug 13th 2008 by Myself. >> http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html >> >> >> ------------------------------------------------------------------------------------------------------------------------- >> >> Resoulution 3: >> >> Use "AUDIO-TITLE" >> >> As tentatively proposed by Manu Spony in an email on Wed Aug 13th 2008 >> http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html >> >> >> ------------------------------------------------------------------------------------------------------------------------- >> >> >> If anyone would like to support any of the above resolutions please >> add a +1(plus one) to the resolution along with any comments you >> would like to add similarly you can add your disapproval and reasons >> why with a -1(minus one). Of course If you have another resolution >> please reply to this email with your proposal. >> >> >> Best Wishes >> >> Martin McEvoy >> >> >> >> >> >> >> >> _______________________________________________ >> 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 Mon Sep 1 13:05:32 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Sep 1 13:05:43 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <48BBEEB5.3040401@digitalbazaar.com> References: <48BBDFDF.4030904@weborganics.co.uk> <48BBEEB5.3040401@digitalbazaar.com> Message-ID: <48BC4B0C.3090900@weborganics.co.uk> Manu Sporny wrote: > Martin McEvoy wrote: > >> ------------------------------------------------------------------------------------------------------------------------- >> Resoulution 2: >> >> Use "HTITLE" >> >> [...] >> "hTitle can then be reused in any microformat that needs a "title" >> property. hTitle has been given a root class name as it is intended to >> be used in conjunction with any other root class microformat and mirrors >> the association semantics expressed by hfeed => hentry in hAtom" >> [...] >> >> A Proposal was made in an email on Aug 13th 2008 by Myself. >> http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html >> ------------------------------------------------------------------------------------------------------------------------- >> > > +1 to your "htitle" proposal, Martin. I believe it is superior to all of > the other proposals related to solving this problem, for the following > reasons: > > - It can be re-used across all Microformats requiring a property to > mark up future title information (hVideo, hBook, etc.). > - It doesn't use a pseudo-namespace, like "audio-title" does. > Thank you Manu please add your support to http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_hAudio_Title_was_Overloading_.22fn.22. Best wishes Martin McEvoy > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From scott at makedatamakesense.com Mon Sep 1 14:41:57 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Mon Sep 1 14:42:06 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <48BC49E1.6080100@weborganics.co.uk> References: <48BBDFDF.4030904@weborganics.co.uk> <1268386725-1220275384-cardhu_decombobulator_blackberry.rim.net-622897905-@bxe118.bisx.prod.on.blackberry> <48BC49E1.6080100@weborganics.co.uk> Message-ID: On [Sep 1], at [ Sep 1] 2:00 , Martin McEvoy wrote: > "fn" was changed to "title" because it was over used in haudio, > > haudio title => fn > haudio contributor = fn > item title = fn > > and what If the author of the audio came first? This shouldn't be an issue. Every hAudio parser must understand contributors and items, so there's no room for confusion here. However, there *is* room for confusion when embedding hAudio in every other microformat using fn, as those parsers have no awareness of hAudio. And this is the problem mfo [1] seeks to solve. [1] http://microformats.org/wiki/mfo-examples -- Scott Reynen MakeDataMakeSense.com From martin at weborganics.co.uk Mon Sep 1 15:34:09 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Sep 1 15:34:21 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: References: <48BBDFDF.4030904@weborganics.co.uk> <1268386725-1220275384-cardhu_decombobulator_blackberry.rim.net-622897905-@bxe118.bisx.prod.on.blackberry> <48BC49E1.6080100@weborganics.co.uk> Message-ID: <48BC6DE1.9090208@weborganics.co.uk> Hello Scott Scott Reynen wrote: > On [Sep 1], at [ Sep 1] 2:00 , Martin McEvoy wrote: > >> "fn" was changed to "title" because it was over used in haudio, >> >> haudio title => fn >> haudio contributor = fn >> item title = fn >> >> and what If the author of the audio came first? > > > This shouldn't be an issue. Every hAudio parser must understand > contributors and items, so there's no room for confusion here. > However, there *is* room for confusion when embedding hAudio in every > other microformat using fn, as those parsers have no awareness of > hAudio. And this is the problem mfo [1] seeks to solve. But doesn't Not yet, mfo is just a concept an has not really been contributed to since early 2007 so yes it would cause problems if you decided to embed a haudio inside a hcard because hcard has no understanding of haudio I would say on a whole that existing microformats class names (particularaly the older ones) cant really be used reliably in New Microformats. because the older one's are only aware of their own context. Best wishes Martin McEvoy > > [1] http://microformats.org/wiki/mfo-examples > > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From tantek at cs.stanford.edu Mon Sep 1 16:34:05 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Mon Sep 1 16:34:36 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <48BC6DE1.9090208@weborganics.co.uk> References: <48BBDFDF.4030904@weborganics.co.uk> <1268386725-1220275384-cardhu_decombobulator_blackberry.rim.net-622897905-@bxe118.bisx.prod.on.blackberry> <48BC49E1.6080100@weborganics.co.uk><48BC6DE1.9090208@weborganics.co.uk> Message-ID: <1350129280-1220312068-cardhu_decombobulator_blackberry.rim.net-394139173-@bxe118.bisx.prod.on.blackberry> Martin, I agree with you that this is a larger issue impacting existing and new microformats, however, trying to come up with new names for the same meaning is not the answer, and will quickly fall apart. We likely need to come up with scoping rules for all microformats like (just thinking out loud here, please do not implement) - some options: 1. any class name starting with an "h" should be treated as a root microformat which introduces a new scope 2. introduce a root microformat classname like "hroot" or "hitem" which introduces a new scope and require its use in addition to any new microformat root class name (eg class="hitem haudio") this is essentially the mfo solution but with a friendlier generic root name. Feel free to brainstorm additional friendly generic root names. 3. same as 2 except don't introduce any other root microformat-specific class names, and use some other mechanism to specify what type/kind of microformat the item is. E.g. all new microformats would start with class="hitem" and then we come up with another way of "typing" them. 4 ... ? Additional suggestions? I'm on my BB enroute in the airport and would prefer to add this to the wiki (will do once I reach my destination, or feel free to do so - perhaps on a new page since it is a cross-microformat issue e.g. /wiki/root-brainstorming ) but I felt this issue was important enough to share a few of these thoughts immediately. Again these are just thoughts and not intended for implementation (at this point). Thanks, Tantek -----Original Message----- From: Martin McEvoy Date: Mon, 01 Sep 2008 23:34:09 To: For discussion of new microformats. Subject: Re: [uf-new] hAudio issue D2 "title" Hello Scott Scott Reynen wrote: > On [Sep 1], at [ Sep 1] 2:00 , Martin McEvoy wrote: > >> "fn" was changed to "title" because it was over used in haudio, >> >> haudio title => fn >> haudio contributor = fn >> item title = fn >> >> and what If the author of the audio came first? > > > This shouldn't be an issue. Every hAudio parser must understand > contributors and items, so there's no room for confusion here. > However, there *is* room for confusion when embedding hAudio in every > other microformat using fn, as those parsers have no awareness of > hAudio. And this is the problem mfo [1] seeks to solve. But doesn't Not yet, mfo is just a concept an has not really been contributed to since early 2007 so yes it would cause problems if you decided to embed a haudio inside a hcard because hcard has no understanding of haudio I would say on a whole that existing microformats class names (particularaly the older ones) cant really be used reliably in New Microformats. because the older one's are only aware of their own context. Best wishes Martin McEvoy > > [1] http://microformats.org/wiki/mfo-examples > > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > 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 davidjanes at blogmatrix.com Mon Sep 1 17:21:15 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Sep 1 17:21:18 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <1350129280-1220312068-cardhu_decombobulator_blackberry.rim.net-394139173-@bxe118.bisx.prod.on.blackberry> References: <48BBDFDF.4030904@weborganics.co.uk> <1268386725-1220275384-cardhu_decombobulator_blackberry.rim.net-622897905-@bxe118.bisx.prod.on.blackberry> <48BC49E1.6080100@weborganics.co.uk> <48BC6DE1.9090208@weborganics.co.uk> <1350129280-1220312068-cardhu_decombobulator_blackberry.rim.net-394139173-@bxe118.bisx.prod.on.blackberry> Message-ID: <21e523c20809011721i3736df6dn8fa17ae609591585@mail.gmail.com> On Mon, Sep 1, 2008 at 7:34 PM, Tantek Celik wrote: > Martin, > > I agree with you that this is a larger issue impacting existing and new microformats, however, trying to come up with new names for the same meaning is not the answer, and will quickly fall apart. > > We likely need to come up with scoping rules for all microformats like (just thinking out loud here, please do not implement) - some options: > > 1. any class name starting with an "h" should be treated as a root microformat which introduces a new scope > 2. introduce a root microformat classname like "hroot" or "hitem" which introduces a new scope and require its use in addition to any new microformat root class name (eg class="hitem haudio") this is essentially the mfo solution but with a friendlier generic root name. Feel free to brainstorm additional friendly generic root names. > 3. same as 2 except don't introduce any other root microformat-specific class names, and use some other mechanism to specify what type/kind of microformat the item is. E.g. all new microformats would start with class="hitem" and then we come up with another way of "typing" them. > 4 ... ? Additional suggestions? > The idea I've been kicking around in my head is to use "hitem" in tandem for "top level" microformats, and then allowing "item" ... if needed ... for scoping subparts within if needed. I'll add something to the Wiki tomorrow [1] as it's bedtime for new schoolkids. Regards, etc... [1] http://microformats.org/wiki/item -- David Janes Mercenary Programmer From msporny at digitalbazaar.com Mon Sep 1 17:39:56 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Sep 1 17:40:04 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <1350129280-1220312068-cardhu_decombobulator_blackberry.rim.net-394139173-@bxe118.bisx.prod.on.blackberry> References: <48BBDFDF.4030904@weborganics.co.uk> <1268386725-1220275384-cardhu_decombobulator_blackberry.rim.net-622897905-@bxe118.bisx.prod.on.blackberry> <48BC49E1.6080100@weborganics.co.uk><48BC6DE1.9090208@weborganics.co.uk> <1350129280-1220312068-cardhu_decombobulator_blackberry.rim.net-394139173-@bxe118.bisx.prod.on.blackberry> Message-ID: <48BC8B5C.5060501@digitalbazaar.com> Tantek Celik wrote: > I agree with you that this is a larger issue impacting existing > and new microformats, however, trying to come up with new names > for the same meaning is not the answer, and will quickly fall apart. *sigh* - and we were so close to getting hAudio to the draft stage... I sense another 3 month discussion coming down the pipe, prolonging the agonizing wait for hAudio to be finalized. Hopefully, I'm wrong. > 1. any class name starting with an "h" should be treated as a > root microformat which introduces a new scope So, now we're looking into ditching Microformats mostly scope-less design? I'm fine with that, but why now - I pointed this issue out a year ago and there seemed to be push-back on adding more scope to Microformats parsing algorithm: http://microformats.org/discuss/mail/microformats-new/2007-June/000582.html I'll certainly support any effort to add more parsing scope to uFs... we should have done this a year ago. > 2. introduce a root microformat classname like "hroot" or "hitem" which > introduces a new scope and require its use in addition to any new > microformat root class name (eg class="hitem haudio") this is essentially > the mfo solution but with a friendlier generic root name. Feel free to > brainstorm additional friendly generic root names. I believe that this approach would confuse the same people that find namespaces scary - they won't understand why they need to provide "hroot" beside their "haudio". If we're going to do scoping, we should: 1. Depend on the structure of the HTML document to provide that scope - web developers understand that elements can go inside other elements... it's an easy concept to grok. 2. Re-use a solution that already exists instead of rolling our own for this community, if possible. > 3. same as 2 except don't introduce any other root microformat-specific > class names, and use some other mechanism to specify what type/kind > of microformat the item is. E.g. all new microformats would start > with class="hitem" and then we come up with another way of "typing" them. We could re-use RDFa's @typeof attribute - it does exactly that and is defined in HTML4.01, XHTML1.1 and XHTML2. We're working on extending RDFa to support just this very use case - it would be a perfect fit. > 4 ... ? Additional suggestions? I suggest that we re-use RDFa's scoping rules since they have already solved this problem for us. This dove-tails into my suggestion late last week of working with the RDFa community to solve some of these long-standing problems since both communities have much to gain from working together: http://microformats.org/discuss/mail/microformats-discuss/2008-August/012432.html I'll post more when we have a more solid proposal together, but what we have so far would solve the scoping issue for Microformats - opening the possibility of re-using FN for hAudio. Here's how the markup would look in practice: ...
Martin Luther King, Jr.
I Have a Dream, a speech by
This would generate this Microformat object (JSON-ish encoding): (haudio) { contributor(hcard) : { fn : "Martin Luther King, Jr." }, fn : "I Have a Dream", type : "speech" } We have the parsing rules for this if anybody is interested - it definitely works, and we'd be happy to undertake a standardization push for this via the W3C if this community was interested in doing so... -- manu From derrick at pallas.us Mon Sep 1 17:44:24 2008 From: derrick at pallas.us (Derrick Lyndon Pallas) Date: Mon Sep 1 17:45:20 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <1350129280-1220312068-cardhu_decombobulator_blackberry.rim.net-394139173-@bxe118.bisx.prod.on.blackberry> References: <48BBDFDF.4030904@weborganics.co.uk> <1268386725-1220275384-cardhu_decombobulator_blackberry.rim.net-622897905-@bxe118.bisx.prod.on.blackberry> <48BC49E1.6080100@weborganics.co.uk><48BC6DE1.9090208@weborganics.co.uk> <1350129280-1220312068-cardhu_decombobulator_blackberry.rim.net-394139173-@bxe118.bisx.prod.on.blackberry> Message-ID: It is my duty to point out that this issue comes up every six months. In the past, it has always been tabled for a variety of reasons. Maybe this will be the last time I exercise this office. As someone who consumes ufs, my +1 is for a top-level, generic scoping class of a single name used in conjunction with other classes for non- scoping semantics. ~Derrick ? iPhone On Sep 1, 2008, at 5:34 PM, "Tantek Celik" wrote: > Martin, > > I agree with you that this is a larger issue impacting existing and > new microformats, however, trying to come up with new names for the > same meaning is not the answer, and will quickly fall apart. > > We likely need to come up with scoping rules for all microformats > like (just thinking out loud here, please do not implement) - some > options: > > 1. any class name starting with an "h" should be treated as a root > microformat which introduces a new scope > 2. introduce a root microformat classname like "hroot" or "hitem" > which introduces a new scope and require its use in addition to any > new microformat root class name (eg class="hitem haudio") this is > essentially the mfo solution but with a friendlier generic root > name. Feel free to brainstorm additional friendly generic root names. > 3. same as 2 except don't introduce any other root microformat- > specific class names, and use some other mechanism to specify what > type/kind of microformat the item is. E.g. all new microformats > would start with class="hitem" and then we come up with another way > of "typing" them. > 4 ... ? Additional suggestions? > > I'm on my BB enroute in the airport and would prefer to add this to > the wiki (will do once I reach my destination, or feel free to do so > - perhaps on a new page since it is a cross-microformat issue e.g. / > wiki/root-brainstorming ) but I felt this issue was important enough > to share a few of these thoughts immediately. Again these are just > thoughts and not intended for implementation (at this point). > > Thanks, > > Tantek > > -----Original Message----- > From: Martin McEvoy > > Date: Mon, 01 Sep 2008 23:34:09 > To: For discussion of new microformats. > > Subject: Re: [uf-new] hAudio issue D2 "title" > > > Hello Scott > > Scott Reynen wrote: >> On [Sep 1], at [ Sep 1] 2:00 , Martin McEvoy wrote: >> >>> "fn" was changed to "title" because it was over used in haudio, >>> >>> haudio title => fn >>> haudio contributor = fn >>> item title = fn >>> >>> and what If the author of the audio came first? >> >> >> This shouldn't be an issue. Every hAudio parser must understand >> contributors and items, so there's no room for confusion here. >> However, there *is* room for confusion when embedding hAudio in every >> other microformat using fn, as those parsers have no awareness of >> hAudio. And this is the problem mfo [1] seeks to solve. > But doesn't Not yet, mfo is just a concept an has not really been > contributed to since early 2007 > > so yes it would cause problems if you decided to embed a haudio > inside a > hcard because hcard has no understanding of haudio > > I would say on a whole that existing microformats class names > (particularaly the older ones) cant really be used reliably in New > Microformats. because the older one's are only aware of their own > context. > > > Best wishes > > Martin McEvoy >> >> [1] http://microformats.org/wiki/mfo-examples >> >> -- >> Scott Reynen >> MakeDataMakeSense.com >> >> >> _______________________________________________ >> 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 Mon Sep 1 18:16:54 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Sep 1 18:17:04 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <1350129280-1220312068-cardhu_decombobulator_blackberry.rim.net-394139173-@bxe118.bisx.prod.on.blackberry> References: <48BBDFDF.4030904@weborganics.co.uk> <1268386725-1220275384-cardhu_decombobulator_blackberry.rim.net-622897905-@bxe118.bisx.prod.on.blackberry> <48BC49E1.6080100@weborganics.co.uk><48BC6DE1.9090208@weborganics.co.uk> <1350129280-1220312068-cardhu_decombobulator_blackberry.rim.net-394139173-@bxe118.bisx.prod.on.blackberry> Message-ID: <48BC9406.2060509@weborganics.co.uk> Hello again Tantek Tantek Celik wrote: > Martin, > > I agree with you that this is a larger issue impacting existing and new microformats, however, trying to come up with new names for the same meaning is not the answer, and will quickly fall apart. > Agreed.... > We likely need to come up with scoping rules for all microformats like (just thinking out loud here, please do not implement) - some options: > > 1. any class name starting with an "h" should be treated as a root microformat which introduces a new scope > This was exactly my thinking when I proposed "htitle" [http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html] it does introduce scope, but its nothing new in Microformats hAtom was the first to introduces scope in this way with the hfeed and hentry classes, > 2. introduce a root microformat classname like "hroot" or "hitem" which introduces a new scope and require its use in addition to any new microformat root class name (eg class="hitem haudio") this is essentially the mfo solution but with a friendlier generic root name. Feel free to brainstorm additional friendly generic root names. > I like hItem or class="item" its the nearest thing in Microformats to an opaque element as I have mentioned before its works like a semantic
its easily expandable to things like item-title and item-author again creating more scope both the above points are very much worth perusing in my view. > 3. same as 2 except don't introduce any other root microformat-specific class names, and use some other mechanism to specify what type/kind of microformat the item is. E.g. all new microformats would start with class="hitem" and then we come up with another way of "typing" them. > 4 ... ? Additional suggestions? > I'm on my BB enroute in the airport and would prefer to add this to the wiki (will do once I reach my destination, or feel free to do so - perhaps on a new page since it is a cross-microformat issue e.g. /wiki/root-brainstorming ) but I felt this issue was important enough to share a few of these thoughts immediately. Again these are just thoughts and not intended for implementation (at this point). > Thank you very much for your input, you kind of confirmed a few things for me, have a good flight. Best wishes Martin McEvoy > Thanks, > > Tantek > > -----Original Message----- > From: Martin McEvoy > > Date: Mon, 01 Sep 2008 23:34:09 > To: For discussion of new microformats. > Subject: Re: [uf-new] hAudio issue D2 "title" > > > Hello Scott > > Scott Reynen wrote: > >> On [Sep 1], at [ Sep 1] 2:00 , Martin McEvoy wrote: >> >> >>> "fn" was changed to "title" because it was over used in haudio, >>> >>> haudio title => fn >>> haudio contributor = fn >>> item title = fn >>> >>> and what If the author of the audio came first? >>> >> This shouldn't be an issue. Every hAudio parser must understand >> contributors and items, so there's no room for confusion here. >> However, there *is* room for confusion when embedding hAudio in every >> other microformat using fn, as those parsers have no awareness of >> hAudio. And this is the problem mfo [1] seeks to solve. >> > But doesn't Not yet, mfo is just a concept an has not really been > contributed to since early 2007 > > so yes it would cause problems if you decided to embed a haudio inside a > hcard because hcard has no understanding of haudio > > I would say on a whole that existing microformats class names > (particularaly the older ones) cant really be used reliably in New > Microformats. because the older one's are only aware of their own context. > > > Best wishes > > Martin McEvoy > >> [1] http://microformats.org/wiki/mfo-examples >> >> -- >> Scott Reynen >> MakeDataMakeSense.com >> >> >> _______________________________________________ >> 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 mail at tobyinkster.co.uk Tue Sep 2 01:37:42 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Tue Sep 2 01:38:13 2008 Subject: [uf-new] hAudio issue D2 "title" Message-ID: <2859BA2B-E6D3-4376-A998-76001A315D07@tobyinkster.co.uk> Tantek wrote: > 1. any class name starting with an "h" should be treated as a root > microformat which introduces a new scope Classes that begin with an 'h' like 'header'?

Blah blah blah

Joe Bloggs

...
I can't imagine that constructions like this aren't common. 'header'/'heading' seems to be one of the most commonly used HTML classes around and 'help' is far from uncommon too. For that matter... classes that being with an 'h' like 'vcard', or 'vcalendar', or 'vevent', or 'xfolkentry', or 'adr', or 'geo'? A common pattern for root class names, with a low rate of false positives (e.g. /^uf[A-Z]/) would be ideal, but that ship has sailed. We don't have it, and it's not going to happen in the future. > 2. introduce a root microformat classname like "hroot" or "hitem" > which introduces a new scope and require its use in addition to any > new microformat root class name (eg class="hitem haudio") this is > essentially the mfo solution but with a friendlier generic root > name. Feel free to brainstorm additional friendly generic root names. This is certainly the most workable solution. In Cognition I support this with class="mfo", but if consensus forms around some other class name (e.g. hroot), then of course it's pretty easy to support that instead/as well. (Though I have to say that hitem is awful ? it looks like "hit 'em" ? an unnecessarily violent class name.) I have published an algorithm for parsing microformats (which deals with most general cases, but not a few special cases) and put it in the public domain: http://microformats.org/wiki/parsing-brainstorming Including support for "hroot" would be as simple as adding it to this list: http://microformats.org/wiki/parsing- brainstorming#Compound_microformat_root_classes > 3. same as 2 except don't introduce any other root microformat- > specific class names, and use some other mechanism to specify what > type/kind of microformat the item is. E.g. all new microformats > would start with class="hitem" and then we come up with another way > of "typing" them. I like this less. -- Toby A Inkster From martin at weborganics.co.uk Tue Sep 2 05:08:12 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Tue Sep 2 05:08:23 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <2859BA2B-E6D3-4376-A998-76001A315D07@tobyinkster.co.uk> References: <2859BA2B-E6D3-4376-A998-76001A315D07@tobyinkster.co.uk> Message-ID: <48BD2CAC.1010702@weborganics.co.uk> Hello Toby Toby A Inkster wrote: > Tantek wrote: > >> 1. any class name starting with an "h" should be treated as a root >> microformat which introduces a new scope > > Classes that begin with an 'h' like 'header'? I dont think Tantek means "all" in general I think he means Microformats only > >
>
>

Blah blah blah

>

> Joe Bloggs >

>
>
...
>
> > I can't imagine that constructions like this aren't common. > 'header'/'heading' seems to be one of the most commonly used HTML > classes around and 'help' is far from uncommon too. > > I do understand what you are saying however :-) I have those two links bookmarked, that are a good source of information when picking class names for things that's partly why I was Insisting that class=title should be used in haudio because its more popular than help in both of your examples, that cant be though its already used. > > For that matter... classes that being with an 'h' like 'vcard', or > 'vcalendar', or 'vevent', or 'xfolkentry', or 'adr', or 'geo'? > > A common pattern for root class names, with a low rate of false > positives (e.g. /^uf[A-Z]/) would be ideal, but that ship has sailed. > We don't have it, and it's not going to happen in the future. You know you have just kicked a thought, I think I Preffer the prefix "X" like "xfolkentry" and would map thus ^x[A-Z] this would cause the lowest rate of false positives because its not commonly used at the beginning of words in the English language. So how about I change this proposal to "XTITLE", I like it! microformats would scope very nicely in this way > >> 2. introduce a root microformat classname like "hroot" or "hitem" >> which introduces a new scope and require its use in addition to any >> new microformat root class name (eg class="hitem haudio") this is >> essentially the mfo solution but with a friendlier generic root name. >> Feel free to brainstorm additional friendly generic root names. > Using the thought above hItem would be xItem, nice! > This is certainly the most workable solution. In Cognition I support > this with class="mfo", but if consensus forms around some other class > name (e.g. hroot), then of course it's pretty easy to support that > instead/as well. (Though I have to say that hitem is awful ? it looks > like "hit 'em" ? an unnecessarily violent class name.) (lol) > > I have published an algorithm for parsing microformats (which deals > with most general cases, but not a few special cases) and put it in > the public domain: Thank you Toby... Best Wishes Martin McEvoy > > http://microformats.org/wiki/parsing-brainstorming > > Including support for "hroot" would be as simple as adding it to this > list: > > http://microformats.org/wiki/parsing-brainstorming#Compound_microformat_root_classes > > >> 3. same as 2 except don't introduce any other root >> microformat-specific class names, and use some other mechanism to >> specify what type/kind of microformat the item is. E.g. all new >> microformats would start with class="hitem" and then we come up with >> another way of "typing" them. > > I like this less. > From scott at makedatamakesense.com Tue Sep 2 06:20:56 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Tue Sep 2 06:21:04 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <48BC8B5C.5060501@digitalbazaar.com> References: <48BBDFDF.4030904@weborganics.co.uk> <1268386725-1220275384-cardhu_decombobulator_blackberry.rim.net-622897905-@bxe118.bisx.prod.on.blackberry> <48BC49E1.6080100@weborganics.co.uk><48BC6DE1.9090208@weborganics.co.uk> <1350129280-1220312068-cardhu_decombobulator_blackberry.rim.net-394139173-@bxe118.bisx.prod.on.blackberry> <48BC8B5C.5060501@digitalbazaar.com> Message-ID: <1B8F193C-B2B7-4DD1-A054-8AE63E467C48@makedatamakesense.com> On [Sep 1], at [ Sep 1] 6:39 , Manu Sporny wrote: > *sigh* - and we were so close to getting hAudio to the draft > stage... I > sense another 3 month discussion coming down the pipe, prolonging the > agonizing wait for hAudio to be finalized. Hopefully, I'm wrong I don't think this discussion necessarily needs to prolong finishing the initial version of hAudio. If we're agreed that we need a general mechanism for publishers to indicate relevant context of the assertions they're publishing, we should be able to move forward with hAudio while treating potential embedding issues as out-of-scope for hAudio. Calling it "out-of-scope" doesn't actually solve the problem, of course, but our evidence-based process means assuming it will be solved outside hAudio may be the best way to ensure it actually is. -- Scott Reynen MakeDataMakeSense.com From scott at makedatamakesense.com Tue Sep 2 05:31:01 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Tue Sep 2 06:30:40 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <2859BA2B-E6D3-4376-A998-76001A315D07@tobyinkster.co.uk> References: <2859BA2B-E6D3-4376-A998-76001A315D07@tobyinkster.co.uk> Message-ID: On [Sep 2], at [ Sep 2] 2:37 , Toby A Inkster wrote: > In Cognition I support this with class="mfo", but if consensus forms > around some other class name (e.g. hroot), then of course it's > pretty easy to support that instead/as well. As this discussion seems to be gradually recreating the MFO proposal, I'd encourage everyone to build from the work already done there: http://microformats.org/wiki/mfo-examples -- Scott Reynen MakeDataMakeSense.com From msporny at digitalbazaar.com Tue Sep 2 08:21:22 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Sep 2 08:21:27 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: References: <2859BA2B-E6D3-4376-A998-76001A315D07@tobyinkster.co.uk> Message-ID: <48BD59F2.8040503@digitalbazaar.com> Scott Reynen wrote: > As this discussion seems to be gradually recreating the MFO proposal, > I'd encourage everyone to build from the work already done there: > > http://microformats.org/wiki/mfo-examples Scott is correct - hitem, hroot, hwhatever are just the same mechanism used to address the problem that mfo does. You can call it "opacity" or "scoping", but the problem it solves is the same: How do you prevent a Microformat class from attaching to a particular Microformat object? -- manu From msporny at digitalbazaar.com Tue Sep 2 08:29:28 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Sep 2 08:29:34 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <1B8F193C-B2B7-4DD1-A054-8AE63E467C48@makedatamakesense.com> References: <48BBDFDF.4030904@weborganics.co.uk> <1268386725-1220275384-cardhu_decombobulator_blackberry.rim.net-622897905-@bxe118.bisx.prod.on.blackberry> <48BC49E1.6080100@weborganics.co.uk><48BC6DE1.9090208@weborganics.co.uk> <1350129280-1220312068-cardhu_decombobulator_blackberry.rim.net-394139173-@bxe118.bisx.prod.on.blackberry> <48BC8B5C.5060501@digitalbazaar.com> <1B8F193C-B2B7-4DD1-A054-8AE63E467C48@makedatamakesense.com> Message-ID: <48BD5BD8.6020008@digitalbazaar.com> Scott Reynen wrote: > I don't think this discussion necessarily needs to prolong finishing the > initial version of hAudio. If we're agreed that we need a general > mechanism for publishers to indicate relevant context of the assertions > they're publishing, we should be able to move forward with hAudio while > treating potential embedding issues as out-of-scope for hAudio. Calling > it "out-of-scope" doesn't actually solve the problem, of course, but our > evidence-based process means assuming it will be solved outside hAudio > may be the best way to ensure it actually is. Perhaps, and this would be the easiest way forward. However, if we move hAudio forward without fixing this issue, there will be less desire to fix the 'mfo' issue. The same thing that has happened every time this has happened will happen again: People won't have a desire to work on mfo because it's not blocking progress on anything. -- manu From davidjanes at blogmatrix.com Tue Sep 2 10:52:24 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Tue Sep 2 10:52:28 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <48BD59F2.8040503@digitalbazaar.com> References: <2859BA2B-E6D3-4376-A998-76001A315D07@tobyinkster.co.uk> <48BD59F2.8040503@digitalbazaar.com> Message-ID: <21e523c20809021052s7ce36644pe5774826c0645aa7@mail.gmail.com> On Tue, Sep 2, 2008 at 11:21 AM, Manu Sporny wrote: > Scott Reynen wrote: >> As this discussion seems to be gradually recreating the MFO proposal, >> I'd encourage everyone to build from the work already done there: >> >> http://microformats.org/wiki/mfo-examples > > Scott is correct - hitem, hroot, hwhatever are just the same mechanism > used to address the problem that mfo does. > > You can call it "opacity" or "scoping", but the problem it solves is the > same: hItem/item was intended to do more than that -- it was to bring in a number of commonly used class names (e.g. "fn") so we don't have these year long discussions about how to do things that really the answer is already known. Regards, etc... -- David Janes Mercenary Programmer From scott at makedatamakesense.com Tue Sep 2 12:39:43 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Tue Sep 2 12:39:47 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <21e523c20809021052s7ce36644pe5774826c0645aa7@mail.gmail.com> References: <2859BA2B-E6D3-4376-A998-76001A315D07@tobyinkster.co.uk> <48BD59F2.8040503@digitalbazaar.com> <21e523c20809021052s7ce36644pe5774826c0645aa7@mail.gmail.com> Message-ID: On [Sep 2], at [ Sep 2] 11:52 , David Janes wrote: > hItem/item was intended to do more than that -- it was to bring in a > number of commonly used class names (e.g. "fn") so we don't have these > year long discussions about how to do things that really the answer is > already known. I completely misunderstood the intent of this proposal as being specific to physical objects and commerce. Now that I understand this proposal better, I prefer it to MFO, as it puts the emphasis on the content being published (where it belongs) rather than on parsing rules. I'll retract my earlier suggestion to build on the MFO work and instead suggest building on the item work: http://microformats.org/wiki/items-brainstorming Further, I propose merging the two, as they're basically the same proposal from two different angles. -- Scott Reynen MakeDataMakeSense.com From martin at weborganics.co.uk Wed Sep 3 14:29:59 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Sep 3 14:30:11 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <48BD2CAC.1010702@weborganics.co.uk> References: <2859BA2B-E6D3-4376-A998-76001A315D07@tobyinkster.co.uk> <48BD2CAC.1010702@weborganics.co.uk> Message-ID: <48BF01D7.9080407@weborganics.co.uk> Hello all Just a ping to say I have added resolution 4 to this issue: Resoulution 4: Change |"title"| back to |"fn"| . and lets put this whole "title" issue on the side for another time and say "out of scope for this version of haudio" http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_hAudio_Title_was_Overloading_.22fn.22. Please add your support to the wiki with a +1 or -1 Best Wishes Martin McEvoy From msporny at digitalbazaar.com Wed Sep 3 15:02:34 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Sep 3 15:02:38 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <48BF01D7.9080407@weborganics.co.uk> References: <2859BA2B-E6D3-4376-A998-76001A315D07@tobyinkster.co.uk> <48BD2CAC.1010702@weborganics.co.uk> <48BF01D7.9080407@weborganics.co.uk> Message-ID: <48BF097A.1020804@digitalbazaar.com> Martin McEvoy wrote: > Resoulution 4: Change |"title"| back to |"fn"| . > > http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_hAudio_Title_was_Overloading_.22fn.22. > > Please add your support to the wiki with a +1 or -1 +1 for changing hAudio "TITLE" back to "FN". This assumes that we're going to deal with the mfo/hItem/scoping issue - which I hope we do soon. Just want to make it clear that I'm voting for this not because I believe it is the best solution, but because I believe that we've exhausted the options that do/don't work for those on this list and are having to compromise on this issue in order to get hAudio to Draft stage. -- manu From martin at weborganics.co.uk Wed Sep 3 15:37:22 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Sep 3 15:37:34 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <48BF097A.1020804@digitalbazaar.com> References: <2859BA2B-E6D3-4376-A998-76001A315D07@tobyinkster.co.uk> <48BD2CAC.1010702@weborganics.co.uk> <48BF01D7.9080407@weborganics.co.uk> <48BF097A.1020804@digitalbazaar.com> Message-ID: <48BF11A2.3090306@weborganics.co.uk> Manu Sporny wrote: > Martin McEvoy wrote: > >> Resoulution 4: Change |"title"| back to |"fn"| . >> >> http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_hAudio_Title_was_Overloading_.22fn.22. >> >> Please add your support to the wiki with a +1 or -1 >> > > +1 for changing hAudio "TITLE" back to "FN". > > This assumes that we're going to deal with the mfo/hItem/scoping issue - > which I hope we do soon. > > Just want to make it clear that I'm voting for this not because I > believe it is the best solution, but because I believe that we've > exhausted the options that do/don't work for those on this list and are > having to compromise on this issue in order to get hAudio to Draft stage. > Well said Manu, I placed this option on the Issues wiki because really everyone wasn't given a full range of options, I thought you should ;-) I have also supported using "fn" (as a second choice) because really this issue is the only thing holding up this round of issues. I dont like "fn" because: 1. Audio titles contain a song name and and artist. 2. Audio titles contain a song name and date (podcasts). 3. Audio titles contain just a song name. using "fn" is stretching the semantics of fn a bit far I think audio titles are a bit more than just a name and they don't have any format or tokenized data as such. that being said I can live with it. Best Wishes Martin McEvoy > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From tantek at cs.stanford.edu Thu Sep 4 04:03:32 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Thu Sep 4 04:04:37 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <48BF11A2.3090306@weborganics.co.uk> References: <2859BA2B-E6D3-4376-A998-76001A315D07@tobyinkster.co.uk> <48BD2CAC.1010702@weborganics.co.uk> <48BF01D7.9080407@weborganics.co.uk><48BF097A.1020804@digitalbazaar.com><48BF11A2.3090306@weborganics.co.uk> Message-ID: <2059875758-1220526269-cardhu_decombobulator_blackberry.rim.net-1881743165-@bxe118.bisx.prod.on.blackberry> Martin, I want to make sure the concerns you raise about hAudio's re-use of fn are not lost: "I dont like "fn" because: ..." Please be sure to include your 1,2,3 points in your comments on the issue in the wiki. Thanks, Tantek -----Original Message----- From: Martin McEvoy Date: Wed, 03 Sep 2008 23:37:22 To: For discussion of new microformats. Subject: Re: [uf-new] hAudio issue D2 "title" Manu Sporny wrote: > Martin McEvoy wrote: > >> Resoulution 4: Change |"title"| back to |"fn"| . >> >> http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_hAudio_Title_was_Overloading_.22fn.22. >> >> Please add your support to the wiki with a +1 or -1 >> > > +1 for changing hAudio "TITLE" back to "FN". > > This assumes that we're going to deal with the mfo/hItem/scoping issue - > which I hope we do soon. > > Just want to make it clear that I'm voting for this not because I > believe it is the best solution, but because I believe that we've > exhausted the options that do/don't work for those on this list and are > having to compromise on this issue in order to get hAudio to Draft stage. > Well said Manu, I placed this option on the Issues wiki because really everyone wasn't given a full range of options, I thought you should ;-) I have also supported using "fn" (as a second choice) because really this issue is the only thing holding up this round of issues. I dont like "fn" because: 1. Audio titles contain a song name and and artist. 2. Audio titles contain a song name and date (podcasts). 3. Audio titles contain just a song name. using "fn" is stretching the semantics of fn a bit far I think audio titles are a bit more than just a name and they don't have any format or tokenized data as such. that being said I can live with it. Best Wishes Martin McEvoy > -- manu > > _______________________________________________ > 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 Thu Sep 4 04:40:53 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Sep 4 04:41:05 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <2059875758-1220526269-cardhu_decombobulator_blackberry.rim.net-1881743165-@bxe118.bisx.prod.on.blackberry> References: <2859BA2B-E6D3-4376-A998-76001A315D07@tobyinkster.co.uk> <48BD2CAC.1010702@weborganics.co.uk> <48BF01D7.9080407@weborganics.co.uk><48BF097A.1020804@digitalbazaar.com><48BF11A2.3090306@weborganics.co.uk> <2059875758-1220526269-cardhu_decombobulator_blackberry.rim.net-1881743165-@bxe118.bisx.prod.on.blackberry> Message-ID: <48BFC945.1080903@weborganics.co.uk> Tantek Celik wrote: > Martin, > > I want to make sure the concerns you raise about hAudio's re-use of fn are not lost: "I dont like "fn" because: ..." > > Please be sure to include your 1,2,3 points in your comments on the issue in the wiki. > > Done! See: http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_hAudio_Title_was_Overloading_.22fn.22. Best wishes Martin McEvoy > Thanks, > > Tantek > > -----Original Message----- > From: Martin McEvoy > > Date: Wed, 03 Sep 2008 23:37:22 > To: For discussion of new microformats. > Subject: Re: [uf-new] hAudio issue D2 "title" > > > Manu Sporny wrote: > >> Martin McEvoy wrote: >> >> >>> Resoulution 4: Change |"title"| back to |"fn"| . >>> >>> http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_hAudio_Title_was_Overloading_.22fn.22. >>> >>> Please add your support to the wiki with a +1 or -1 >>> >>> >> +1 for changing hAudio "TITLE" back to "FN". >> >> This assumes that we're going to deal with the mfo/hItem/scoping issue - >> which I hope we do soon. >> >> Just want to make it clear that I'm voting for this not because I >> believe it is the best solution, but because I believe that we've >> exhausted the options that do/don't work for those on this list and are >> having to compromise on this issue in order to get hAudio to Draft stage. >> >> > Well said Manu, > > I placed this option on the Issues wiki because really everyone wasn't > given a full range of options, I thought you should ;-) > > I have also supported using "fn" (as a second choice) because really > this issue is the only thing holding up this round of issues. > > I dont like "fn" because: > > 1. Audio titles contain a song name and and artist. > 2. Audio titles contain a song name and date (podcasts). > 3. Audio titles contain just a song name. > > using "fn" is stretching the semantics of fn a bit far I think audio > titles are a bit more than just a name and they don't have any format or > tokenized data as such. > > that being said I can live with it. > > Best Wishes > > Martin McEvoy > > > >> -- manu >> >> _______________________________________________ >> 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 csarven at gmail.com Thu Sep 4 07:48:28 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Thu Sep 4 07:48:32 2008 Subject: [uf-new] hAudio issue D2 "title" In-Reply-To: <48BBDFDF.4030904@weborganics.co.uk> References: <48BBDFDF.4030904@weborganics.co.uk> Message-ID: On Mon, Sep 1, 2008 at 8:28 AM, Martin McEvoy wrote: > Resoulution 2: > > Use "HTITLE" > > [...] > "hTitle can then be reused in any microformat that needs a "title" > property. hTitle has been given a root class name as it is intended to > be used in conjunction with any other root class microformat and mirrors > the association semantics expressed by hfeed => hentry in hAtom" > [...] > > A Proposal was made in an email on Aug 13th 2008 by Myself. > http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html If we don't want to undo the definition of TITLE across all microformats, then we should respect the same reasoning for FN. "Stretching" or "undoing" names aside, I find "title" to be more accurate and will probably be grasped easier then "fn". Yet, the definition of TITLE is more stretched then FN. Not an easy call. Hence, I believe this will leave us with htitle or something-else because it has potential to solve certain problems and stretch some of the limitations that we are facing. Manu made a fair summary here: http://microformats.org/discuss/mail/microformats-new/2008-September/001759.html Choice: 1) +1 for htitle 2) +1 for title 3) +1 for fn Sarven Capadisli http://www.csarven.ca From paullee at google.com Sun Sep 7 18:26:24 2008 From: paullee at google.com (=?EUC-KR?B?UGF1bCBMZWUgKMDMseK89ik=?=) Date: Sun Sep 7 18:26:31 2008 Subject: [uf-new] hProduct: Shipping Message-ID: Shipping is set as messaging - what about where shipping is actually a flat shipping rate? Should we try to capture that here, elsewhere, or ignore since it is so complicated? -- Paul Lee Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 +1 (650) 214-6612 From paullee at google.com Sun Sep 7 18:26:46 2008 From: paullee at google.com (=?EUC-KR?B?UGF1bCBMZWUgKMDMseK89ik=?=) Date: Sun Sep 7 18:26:56 2008 Subject: [uf-new] hProduct: Suggested changes to proposed fields Message-ID: Based on work on examples and brainstorming, what about the following suggestions? - bump sku, upc, isbn to top level, also optional (agreement with Jay Myers on sku) - drop uid (since this seems to replicate sku, per the examples page) - add condition, mpn to top level, also optional Paul -- Paul Lee Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 +1 (650) 214-6612 From Jay.Myers at bestbuy.com Mon Sep 8 12:23:46 2008 From: Jay.Myers at bestbuy.com (Myers, Jay) Date: Mon Sep 8 12:23:51 2008 Subject: [uf-new] hProduct: Shipping In-Reply-To: References: Message-ID: <0A55472BC29958468426825844F9F22E065984F2@dsp63mail.na.bestbuy.com> Would it make sense to contain both: shipping messaging | price that follows currency format? Jay Myers Lead Web Development Engineer Online Solutions, BestBuy.com jay.myers@bestbuy.com (w) 612-291-4007 (twitter) @jaymyers -----Original Message----- From: microformats-new-bounces@microformats.org [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul Lee (???) Sent: Sunday, September 07, 2008 8:26 PM To: microformats-new@microformats.org Subject: [uf-new] hProduct: Shipping Shipping is set as messaging - what about where shipping is actually a flat shipping rate? Should we try to capture that here, elsewhere, or ignore since it is so complicated? -- Paul Lee Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 +1 (650) 214-6612 _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From Jay.Myers at bestbuy.com Mon Sep 8 12:59:53 2008 From: Jay.Myers at bestbuy.com (Myers, Jay) Date: Mon Sep 8 12:59:58 2008 Subject: [uf-new] hProduct progress -- category discussion In-Reply-To: References: Message-ID: <0A55472BC29958468426825844F9F22E065984F6@dsp63mail.na.bestbuy.com> Hi Paul, Catching up on my hProduct work here... I wanted to address the topic of subcategories. I think that many subcategory-specific values may be addressed in the p-v section of the hProduct microformat. I agree that there are many universal product attributes that can be addressed using the base hProduct spec, and it would be worth it to continue foundational work. Speaking of category, the current foundation hProduct brainstorm schema doesn't include any mention of product category. I could envision adding category and subcategory nodes (ala category "breadcrumbs") to help identify product cats and subcats. Thoughts? Thanks, Jay Jay Myers Lead Web Development Engineer Online Solutions, BestBuy.com jay.myers@bestbuy.com (w) 612-291-4007 (twitter) @jaymyers -----Original Message----- From: microformats-new-bounces@microformats.org [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul Lee (???) Sent: Thursday, August 21, 2008 12:20 AM To: microformats-new@microformats.org Subject: [uf-new] hProduct progress (reply) Hi Jay, Just had two points to chime in on: 1. Reading over the page, sounds still a bit early to call it hProduct. =) 2. That said, I agree with you that there's a case for a separate format. The hListing proposal page makes it clear that it simply wasn't designed to address retail products, for instance: "We are focusing on providing "just enough" structure to enable matching, not to consummate transactions. This is distinct from the majority of formats described on the wiki under listing-examples, which are specific enough to completely describe products for retail sale according to the idiosyncratic semantics of particular merchants and shopping engines. Instead of encoding retail-oriented fields such as UPCs, SKUs, and manufacturer part numbers, this proposal acknowledges that many listings are for "inventories of one" that may not have such precise abstractions." A product microformat could help fill the gap for information like condition, brand, MPN, and unique product identifiers (UPC/EAN, ISBN). 3. Of course, that leads to the question: What about all the product subcategories? My sense from reading archives is that that might be part of the reason why discussion on product has died out - it's a pretty behemoth task to design for tens of highly diverse categories, with their own subcategories, many of which are still evolving. I think, however, there's a lot of value in focusing on the common ground across all products, and the value that that can add in and of itself, as well as as a foundation for future work on subcategories. Paul Google Product Search [uf-new] hProduct progress Jay Myers jmyers at visi.com Wed Aug 6 14:59:06 PDT 2008 All, There is work being done on new standards and reviving the hProduct microformat. During the course of this effort, people have pointed to hListing as a more viable, mature format for displaying product data. We proponents of hProduct feel that a separate hProduct uF would be more granular, and provide more specifics around the products, which often are more complex and have important attributes that are outside of the scope of hListing and others. Please see the updated brainstorming and draft proposal wiki pages for more information on the updated schema. Nonetheless, there are still correlations between hListing and hProduct that can't be ignored. It has been suggested that hProduct be used in conjuction with hListing to enhance the semantics of that format, where hProduct would live under .item. This I agree with, but I would still propose it also be used separately. I would appreciate any thoughts or ideas you might have around the revival effort of hProduct. Thanks, Jay _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From tantek at cs.stanford.edu Mon Sep 8 14:23:04 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Mon Sep 8 14:24:14 2008 Subject: [uf-new] hProduct progress -- category discussion In-Reply-To: <0A55472BC29958468426825844F9F22E065984F6@dsp63mail.na.bestbuy.com> References: <0A55472BC29958468426825844F9F22E065984F6@dsp63mail.na.bestbuy.com> Message-ID: <190612150-1220909047-cardhu_decombobulator_blackberry.rim.net-1688246717-@bxe118.bisx.prod.on.blackberry> Categories/subcategories - just use rel-tags as hReview does. Tantek -----Original Message----- From: "Myers, Jay" Date: Mon, 8 Sep 2008 14:59:53 To: For discussion of new microformats. Subject: RE: [uf-new] hProduct progress -- category discussion Hi Paul, Catching up on my hProduct work here... I wanted to address the topic of subcategories. I think that many subcategory-specific values may be addressed in the p-v section of the hProduct microformat. I agree that there are many universal product attributes that can be addressed using the base hProduct spec, and it would be worth it to continue foundational work. Speaking of category, the current foundation hProduct brainstorm schema doesn't include any mention of product category. I could envision adding category and subcategory nodes (ala category "breadcrumbs") to help identify product cats and subcats. Thoughts? Thanks, Jay Jay Myers Lead Web Development Engineer Online Solutions, BestBuy.com jay.myers@bestbuy.com (w) 612-291-4007 (twitter) @jaymyers -----Original Message----- From: microformats-new-bounces@microformats.org [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul Lee (???) Sent: Thursday, August 21, 2008 12:20 AM To: microformats-new@microformats.org Subject: [uf-new] hProduct progress (reply) Hi Jay, Just had two points to chime in on: 1. Reading over the page, sounds still a bit early to call it hProduct. =) 2. That said, I agree with you that there's a case for a separate format. The hListing proposal page makes it clear that it simply wasn't designed to address retail products, for instance: "We are focusing on providing "just enough" structure to enable matching, not to consummate transactions. This is distinct from the majority of formats described on the wiki under listing-examples, which are specific enough to completely describe products for retail sale according to the idiosyncratic semantics of particular merchants and shopping engines. Instead of encoding retail-oriented fields such as UPCs, SKUs, and manufacturer part numbers, this proposal acknowledges that many listings are for "inventories of one" that may not have such precise abstractions." A product microformat could help fill the gap for information like condition, brand, MPN, and unique product identifiers (UPC/EAN, ISBN). 3. Of course, that leads to the question: What about all the product subcategories? My sense from reading archives is that that might be part of the reason why discussion on product has died out - it's a pretty behemoth task to design for tens of highly diverse categories, with their own subcategories, many of which are still evolving. I think, however, there's a lot of value in focusing on the common ground across all products, and the value that that can add in and of itself, as well as as a foundation for future work on subcategories. Paul Google Product Search [uf-new] hProduct progress Jay Myers jmyers at visi.com Wed Aug 6 14:59:06 PDT 2008 All, There is work being done on new standards and reviving the hProduct microformat. During the course of this effort, people have pointed to hListing as a more viable, mature format for displaying product data. We proponents of hProduct feel that a separate hProduct uF would be more granular, and provide more specifics around the products, which often are more complex and have important attributes that are outside of the scope of hListing and others. Please see the updated brainstorming and draft proposal wiki pages for more information on the updated schema. Nonetheless, there are still correlations between hListing and hProduct that can't be ignored. It has been suggested that hProduct be used in conjuction with hListing to enhance the semantics of that format, where hProduct would live under .item. This I agree with, but I would still propose it also be used separately. I would appreciate any thoughts or ideas you might have around the revival effort of hProduct. Thanks, Jay _______________________________________________ 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 paullee at google.com Tue Sep 9 03:14:54 2008 From: paullee at google.com (=?EUC-KR?B?UGF1bCBMZWUgKMDMseK89ik=?=) Date: Tue Sep 9 03:15:06 2008 Subject: [uf-new] hProduct: Shipping In-Reply-To: <0A55472BC29958468426825844F9F22E065984F2@dsp63mail.na.bestbuy.com> References: <0A55472BC29958468426825844F9F22E065984F2@dsp63mail.na.bestbuy.com> Message-ID: Just looked at the currency wiki pages but didn't see the analogue - can you send a link? Otherwise, conceptually, i think this makes sense. Question, though: There are some other shipping components that might be useful, e.g., carrier (if applicable), service (if applicable), type (if not carrier/service, e.g., Ground). On Mon, Sep 8, 2008 at 12:23 PM, Myers, Jay wrote: > > Would it make sense to contain both: shipping messaging | price that > follows currency format? > > > Jay Myers > Lead Web Development Engineer > Online Solutions, BestBuy.com > jay.myers@bestbuy.com > (w) 612-291-4007 > (twitter) @jaymyers > > -----Original Message----- > From: microformats-new-bounces@microformats.org > [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul Lee > (???) > Sent: Sunday, September 07, 2008 8:26 PM > To: microformats-new@microformats.org > Subject: [uf-new] hProduct: Shipping > > Shipping is set as messaging - what about where shipping is actually a > flat shipping rate? Should we try to capture that here, elsewhere, or > ignore since it is so complicated? > > -- > Paul Lee > Google, Inc. > 1600 Amphitheatre Parkway > Mountain View, CA 94043 > +1 (650) 214-6612 > _______________________________________________ > 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 -- Paul Lee Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 +1 (650) 214-6612 From Jay.Myers at bestbuy.com Tue Sep 9 09:30:34 2008 From: Jay.Myers at bestbuy.com (Myers, Jay) Date: Tue Sep 9 09:30:39 2008 Subject: [uf-new] hProduct: Shipping In-Reply-To: References: <0A55472BC29958468426825844F9F22E065984F2@dsp63mail.na.bestbuy.com> Message-ID: <0A55472BC29958468426825844F9F22E065984FE@dsp63mail.na.bestbuy.com> This is the way I have been marking up currency in shipping blocks in some recent hProduct demo work:

Usually leaves our warehouse in 1 business day. Estimated shipping cost: $19.99.

There definitely are other shipping components that could be used here. My thought is that we might be over-complicating things by trying to include all of them in an hProduct spec. Additionally, on a majority of e-commerce/ manufacturer sites these components show up further down the chain (i.e., when you end up in cart/checkout pages), and aren't necessarily product-specific -- a fixed carrier/service/type/ typically applies to most products, per the fulfillment model of the business. J -----Original Message----- From: microformats-new-bounces@microformats.org [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul Lee (???) Sent: Tuesday, September 09, 2008 5:15 AM To: For discussion of new microformats. Subject: Re: [uf-new] hProduct: Shipping Just looked at the currency wiki pages but didn't see the analogue - can you send a link? Otherwise, conceptually, i think this makes sense. Question, though: There are some other shipping components that might be useful, e.g., carrier (if applicable), service (if applicable), type (if not carrier/service, e.g., Ground). On Mon, Sep 8, 2008 at 12:23 PM, Myers, Jay wrote: > > Would it make sense to contain both: shipping messaging | price that > follows currency format? > > > Jay Myers > Lead Web Development Engineer > Online Solutions, BestBuy.com > jay.myers@bestbuy.com > (w) 612-291-4007 > (twitter) @jaymyers > > -----Original Message----- > From: microformats-new-bounces@microformats.org > [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul Lee > (???) > Sent: Sunday, September 07, 2008 8:26 PM > To: microformats-new@microformats.org > Subject: [uf-new] hProduct: Shipping > > Shipping is set as messaging - what about where shipping is actually a > flat shipping rate? Should we try to capture that here, elsewhere, or > ignore since it is so complicated? > > -- > Paul Lee > Google, Inc. > 1600 Amphitheatre Parkway > Mountain View, CA 94043 > +1 (650) 214-6612 > _______________________________________________ > 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 -- Paul Lee Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 +1 (650) 214-6612 _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From paullee at google.com Tue Sep 9 12:30:29 2008 From: paullee at google.com (=?EUC-KR?B?UGF1bCBMZWUgKMDMseK89ik=?=) Date: Tue Sep 9 12:30:39 2008 Subject: [uf-new] hProduct: Shipping In-Reply-To: <0A55472BC29958468426825844F9F22E065984FE@dsp63mail.na.bestbuy.com> References: <0A55472BC29958468426825844F9F22E065984F2@dsp63mail.na.bestbuy.com> <0A55472BC29958468426825844F9F22E065984FE@dsp63mail.na.bestbuy.com> Message-ID: Agree that this info is typically available further downstream. Should we even try to tackle this in the hProduct proposal? On Tue, Sep 9, 2008 at 9:30 AM, Myers, Jay wrote: > This is the way I have been marking up currency in shipping blocks in > some recent hProduct demo work: > >

Usually leaves our warehouse in 1 business day. > Estimated shipping cost: class="currency">$19.99. >

> > There definitely are other shipping components that could be used here. > My thought is that we might be over-complicating things by trying to > include all of them in an hProduct spec. Additionally, on a majority of > e-commerce/ manufacturer sites these components show up further down the > chain (i.e., when you end up in cart/checkout pages), and aren't > necessarily product-specific -- a fixed carrier/service/type/ typically > applies to most products, per the fulfillment model of the business. > > J > > > > > -----Original Message----- > From: microformats-new-bounces@microformats.org > [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul Lee > (???) > Sent: Tuesday, September 09, 2008 5:15 AM > To: For discussion of new microformats. > Subject: Re: [uf-new] hProduct: Shipping > > Just looked at the currency wiki pages but didn't see the analogue - > can you send a link? Otherwise, conceptually, i think this makes > sense. Question, though: There are some other shipping components > that might be useful, e.g., carrier (if applicable), service (if > applicable), type (if not carrier/service, e.g., Ground). > > On Mon, Sep 8, 2008 at 12:23 PM, Myers, Jay > wrote: >> >> Would it make sense to contain both: shipping messaging | price that >> follows currency format? >> >> >> Jay Myers >> Lead Web Development Engineer >> Online Solutions, BestBuy.com >> jay.myers@bestbuy.com >> (w) 612-291-4007 >> (twitter) @jaymyers >> >> -----Original Message----- >> From: microformats-new-bounces@microformats.org >> [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul > Lee >> (???) >> Sent: Sunday, September 07, 2008 8:26 PM >> To: microformats-new@microformats.org >> Subject: [uf-new] hProduct: Shipping >> >> Shipping is set as messaging - what about where shipping is actually a >> flat shipping rate? Should we try to capture that here, elsewhere, or >> ignore since it is so complicated? >> >> -- >> Paul Lee >> Google, Inc. >> 1600 Amphitheatre Parkway >> Mountain View, CA 94043 >> +1 (650) 214-6612 >> _______________________________________________ >> 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 > > > > -- > Paul Lee > Google, Inc. > 1600 Amphitheatre Parkway > Mountain View, CA 94043 > +1 (650) 214-6612 > _______________________________________________ > 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 > -- Paul Lee Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 +1 (650) 214-6612 From jthale at gmail.com Tue Sep 9 13:25:27 2008 From: jthale at gmail.com (Jason Hale) Date: Tue Sep 9 13:32:46 2008 Subject: [uf-new] hProduct: Shipping In-Reply-To: References: <0A55472BC29958468426825844F9F22E065984F2@dsp63mail.na.bestbuy.com> <0A55472BC29958468426825844F9F22E065984FE@dsp63mail.na.bestbuy.com> Message-ID: I also agree that shipping information doesn't belong to a product, it belongs to that transaction and shouldn't be tackled within hproduct. This would also go along with taxes or any other sales fees associated with a transaction, they should not be apart of hproduct. - Jason On Tue, Sep 9, 2008 at 1:30 PM, Paul Lee (???) wrote: > > Agree that this info is typically available further downstream. > Should we even try to tackle this in the hProduct proposal? > > On Tue, Sep 9, 2008 at 9:30 AM, Myers, Jay wrote: > > This is the way I have been marking up currency in shipping blocks in > > some recent hProduct demo work: > > > >

Usually leaves our warehouse in 1 business day. > > Estimated shipping cost: > class="currency">$19.99. > >

> > > > There definitely are other shipping components that could be used here. > > My thought is that we might be over-complicating things by trying to > > include all of them in an hProduct spec. Additionally, on a majority of > > e-commerce/ manufacturer sites these components show up further down the > > chain (i.e., when you end up in cart/checkout pages), and aren't > > necessarily product-specific -- a fixed carrier/service/type/ typically > > applies to most products, per the fulfillment model of the business. > > > > J > > > > > > > > > > -----Original Message----- > > From: microformats-new-bounces@microformats.org > > [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul Lee > > (???) > > Sent: Tuesday, September 09, 2008 5:15 AM > > To: For discussion of new microformats. > > Subject: Re: [uf-new] hProduct: Shipping > > > > Just looked at the currency wiki pages but didn't see the analogue - > > can you send a link? Otherwise, conceptually, i think this makes > > sense. Question, though: There are some other shipping components > > that might be useful, e.g., carrier (if applicable), service (if > > applicable), type (if not carrier/service, e.g., Ground). > > > > On Mon, Sep 8, 2008 at 12:23 PM, Myers, Jay > > wrote: > >> > >> Would it make sense to contain both: shipping messaging | price that > >> follows currency format? > >> > >> > >> Jay Myers > >> Lead Web Development Engineer > >> Online Solutions, BestBuy.com > >> jay.myers@bestbuy.com > >> (w) 612-291-4007 > >> (twitter) @jaymyers > >> > >> -----Original Message----- > >> From: microformats-new-bounces@microformats.org > >> [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul > > Lee > >> (???) > >> Sent: Sunday, September 07, 2008 8:26 PM > >> To: microformats-new@microformats.org > >> Subject: [uf-new] hProduct: Shipping > >> > >> Shipping is set as messaging - what about where shipping is actually a > >> flat shipping rate? Should we try to capture that here, elsewhere, or > >> ignore since it is so complicated? > >> > >> -- > >> Paul Lee > >> Google, Inc. > >> 1600 Amphitheatre Parkway > >> Mountain View, CA 94043 > >> +1 (650) 214-6612 > >> _______________________________________________ > >> 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 > > > > > > > > -- > > Paul Lee > > Google, Inc. > > 1600 Amphitheatre Parkway > > Mountain View, CA 94043 > > +1 (650) 214-6612 > > _______________________________________________ > > 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 > > > > > > -- > Paul Lee > Google, Inc. > 1600 Amphitheatre Parkway > Mountain View, CA 94043 > +1 (650) 214-6612 > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From paullee at google.com Wed Sep 10 14:36:04 2008 From: paullee at google.com (=?EUC-KR?B?UGF1bCBMZWUgKMDMseK89ik=?=) Date: Wed Sep 10 14:36:13 2008 Subject: [uf-new] hProduct: Shipping In-Reply-To: References: <0A55472BC29958468426825844F9F22E065984F2@dsp63mail.na.bestbuy.com> <0A55472BC29958468426825844F9F22E065984FE@dsp63mail.na.bestbuy.com> Message-ID: I'm fine with that - Jay? 2008/9/9 Jason Hale > > I also agree that shipping information doesn't belong to a product, it > belongs to that transaction and shouldn't be tackled within hproduct. > This would also go along with taxes or any other sales fees associated > with a transaction, they should not be apart of hproduct. > > - Jason > > On Tue, Sep 9, 2008 at 1:30 PM, Paul Lee (???) wrote: > > > > Agree that this info is typically available further downstream. > > Should we even try to tackle this in the hProduct proposal? > > > > On Tue, Sep 9, 2008 at 9:30 AM, Myers, Jay wrote: > > > This is the way I have been marking up currency in shipping blocks in > > > some recent hProduct demo work: > > > > > >

Usually leaves our warehouse in 1 business day. > > > Estimated shipping cost: > > class="currency">$19.99. > > >

> > > > > > There definitely are other shipping components that could be used here. > > > My thought is that we might be over-complicating things by trying to > > > include all of them in an hProduct spec. Additionally, on a majority of > > > e-commerce/ manufacturer sites these components show up further down the > > > chain (i.e., when you end up in cart/checkout pages), and aren't > > > necessarily product-specific -- a fixed carrier/service/type/ typically > > > applies to most products, per the fulfillment model of the business. > > > > > > J > > > > > > > > > > > > > > > -----Original Message----- > > > From: microformats-new-bounces@microformats.org > > > [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul Lee > > > (???) > > > Sent: Tuesday, September 09, 2008 5:15 AM > > > To: For discussion of new microformats. > > > Subject: Re: [uf-new] hProduct: Shipping > > > > > > Just looked at the currency wiki pages but didn't see the analogue - > > > can you send a link? Otherwise, conceptually, i think this makes > > > sense. Question, though: There are some other shipping components > > > that might be useful, e.g., carrier (if applicable), service (if > > > applicable), type (if not carrier/service, e.g., Ground). > > > > > > On Mon, Sep 8, 2008 at 12:23 PM, Myers, Jay > > > wrote: > > >> > > >> Would it make sense to contain both: shipping messaging | price that > > >> follows currency format? > > >> > > >> > > >> Jay Myers > > >> Lead Web Development Engineer > > >> Online Solutions, BestBuy.com > > >> jay.myers@bestbuy.com > > >> (w) 612-291-4007 > > >> (twitter) @jaymyers > > >> > > >> -----Original Message----- > > >> From: microformats-new-bounces@microformats.org > > >> [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul > > > Lee > > >> (???) > > >> Sent: Sunday, September 07, 2008 8:26 PM > > >> To: microformats-new@microformats.org > > >> Subject: [uf-new] hProduct: Shipping > > >> > > >> Shipping is set as messaging - what about where shipping is actually a > > >> flat shipping rate? Should we try to capture that here, elsewhere, or > > >> ignore since it is so complicated? > > >> > > >> -- > > >> Paul Lee > > >> Google, Inc. > > >> 1600 Amphitheatre Parkway > > >> Mountain View, CA 94043 > > >> +1 (650) 214-6612 > > >> _______________________________________________ > > >> 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 > > > > > > > > > > > > -- > > > Paul Lee > > > Google, Inc. > > > 1600 Amphitheatre Parkway > > > Mountain View, CA 94043 > > > +1 (650) 214-6612 > > > _______________________________________________ > > > 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 > > > > > > > > > > > -- > > Paul Lee > > Google, Inc. > > 1600 Amphitheatre Parkway > > Mountain View, CA 94043 > > +1 (650) 214-6612 > > _______________________________________________ > > 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 -- Paul Lee Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 +1 (650) 214-6612 From Jay.Myers at bestbuy.com Wed Sep 10 15:14:58 2008 From: Jay.Myers at bestbuy.com (Myers, Jay) Date: Wed Sep 10 15:15:02 2008 Subject: [uf-new] hProduct: Shipping In-Reply-To: References: <0A55472BC29958468426825844F9F22E065984F2@dsp63mail.na.bestbuy.com><0A55472BC29958468426825844F9F22E065984FE@dsp63mail.na.bestbuy.com> Message-ID: <0A55472BC29958468426825844F9F22E0659850F@dsp63mail.na.bestbuy.com> Sounds good to me... thanks for the input, Jason! -----Original Message----- From: microformats-new-bounces@microformats.org [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul Lee (???) Sent: Wednesday, September 10, 2008 4:36 PM To: For discussion of new microformats. Subject: Re: [uf-new] hProduct: Shipping I'm fine with that - Jay? 2008/9/9 Jason Hale > > I also agree that shipping information doesn't belong to a product, it > belongs to that transaction and shouldn't be tackled within hproduct. > This would also go along with taxes or any other sales fees associated > with a transaction, they should not be apart of hproduct. > > - Jason > > On Tue, Sep 9, 2008 at 1:30 PM, Paul Lee (???) wrote: > > > > Agree that this info is typically available further downstream. > > Should we even try to tackle this in the hProduct proposal? > > > > On Tue, Sep 9, 2008 at 9:30 AM, Myers, Jay wrote: > > > This is the way I have been marking up currency in shipping blocks in > > > some recent hProduct demo work: > > > > > >

Usually leaves our warehouse in 1 business day. > > > Estimated shipping cost: > > class="currency">$19.99. > > >

> > > > > > There definitely are other shipping components that could be used here. > > > My thought is that we might be over-complicating things by trying to > > > include all of them in an hProduct spec. Additionally, on a majority of > > > e-commerce/ manufacturer sites these components show up further down the > > > chain (i.e., when you end up in cart/checkout pages), and aren't > > > necessarily product-specific -- a fixed carrier/service/type/ typically > > > applies to most products, per the fulfillment model of the business. > > > > > > J > > > > > > > > > > > > > > > -----Original Message----- > > > From: microformats-new-bounces@microformats.org > > > [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul Lee > > > (???) > > > Sent: Tuesday, September 09, 2008 5:15 AM > > > To: For discussion of new microformats. > > > Subject: Re: [uf-new] hProduct: Shipping > > > > > > Just looked at the currency wiki pages but didn't see the analogue - > > > can you send a link? Otherwise, conceptually, i think this makes > > > sense. Question, though: There are some other shipping components > > > that might be useful, e.g., carrier (if applicable), service (if > > > applicable), type (if not carrier/service, e.g., Ground). > > > > > > On Mon, Sep 8, 2008 at 12:23 PM, Myers, Jay > > > wrote: > > >> > > >> Would it make sense to contain both: shipping messaging | price that > > >> follows currency format? > > >> > > >> > > >> Jay Myers > > >> Lead Web Development Engineer > > >> Online Solutions, BestBuy.com > > >> jay.myers@bestbuy.com > > >> (w) 612-291-4007 > > >> (twitter) @jaymyers > > >> > > >> -----Original Message----- > > >> From: microformats-new-bounces@microformats.org > > >> [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul > > > Lee > > >> (???) > > >> Sent: Sunday, September 07, 2008 8:26 PM > > >> To: microformats-new@microformats.org > > >> Subject: [uf-new] hProduct: Shipping > > >> > > >> Shipping is set as messaging - what about where shipping is actually a > > >> flat shipping rate? Should we try to capture that here, elsewhere, or > > >> ignore since it is so complicated? > > >> > > >> -- > > >> Paul Lee > > >> Google, Inc. > > >> 1600 Amphitheatre Parkway > > >> Mountain View, CA 94043 > > >> +1 (650) 214-6612 > > >> _______________________________________________ > > >> 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 > > > > > > > > > > > > -- > > > Paul Lee > > > Google, Inc. > > > 1600 Amphitheatre Parkway > > > Mountain View, CA 94043 > > > +1 (650) 214-6612 > > > _______________________________________________ > > > 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 > > > > > > > > > > > -- > > Paul Lee > > Google, Inc. > > 1600 Amphitheatre Parkway > > Mountain View, CA 94043 > > +1 (650) 214-6612 > > _______________________________________________ > > 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 -- Paul Lee Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 +1 (650) 214-6612 _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From lists at ben-ward.co.uk Wed Sep 10 14:44:43 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Wed Sep 10 15:20:54 2008 Subject: [uf-new] hProduct: Shipping In-Reply-To: References: <0A55472BC29958468426825844F9F22E065984F2@dsp63mail.na.bestbuy.com> <0A55472BC29958468426825844F9F22E065984FE@dsp63mail.na.bestbuy.com> Message-ID: <2CBD4E84-498F-4D0D-94F2-8815C818AB77@ben-ward.co.uk> On 10 Sep 2008, at 14:36, Paul Lee (???) wrote: > I'm fine with that - Jay? > > 2008/9/9 Jason Hale >> >> I also agree that shipping information doesn't belong to a product, >> it >> belongs to that transaction and shouldn't be tackled within hproduct. >> This would also go along with taxes or any other sales fees >> associated >> with a transaction, they should not be apart of hproduct. It makes more sense to me that taxes, shipping information and so forth would be part of a product listing, and thus hListing. Price of a product would, presumably, be the ?recommended retail price?? B From martin at weborganics.co.uk Thu Sep 11 02:53:09 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Sep 11 02:53:16 2008 Subject: [uf-new] [hAudio issue] D2: hAudio Title was Overloading "fn" Message-ID: <48C8EA85.3090104@weborganics.co.uk> Hello All I would like to propose that hAudio Issue D2:hAudio Title was Overloading "fn"[1] should be now marked as resolved. Resolution: Change |"title"| back to |"fn" this resolution has more support than any of the other Proposed resolutions both on the mailing list and on the wiki page. ||David Janes commented this is "the right thing to do" and I believe it is. The purpose of the haudio format is to first re-use any existing microformats, "title" IS being used incorrectly, this can potentially "break" existing formats such as hCard.| [1] http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_hAudio_Title_was_Overloading_.22fn.22. Thanks Martin McEvoy||| ||| From msporny at digitalbazaar.com Thu Sep 11 06:05:29 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Sep 11 06:05:39 2008 Subject: [uf-new] Re: [hAudio issue] D2: hAudio Title was Overloading "fn" In-Reply-To: <48C8EA85.3090104@weborganics.co.uk> References: <48C8EA85.3090104@weborganics.co.uk> Message-ID: <48C91799.5040508@digitalbazaar.com> Martin McEvoy wrote: > I would like to propose that hAudio Issue D2:hAudio Title was > Overloading "fn"[1] should be now marked as resolved. +1 to marking it as resolved. -- manu From martin at weborganics.co.uk Thu Sep 11 12:54:54 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Sep 11 12:55:08 2008 Subject: [uf-new] hAudio issue D5: 2008-01-10 there is no way of linking to an interim page In-Reply-To: <48AC2A5F.5020008@digitalbazaar.com> References: <48AC1EF2.1010409@weborganics.co.uk> <48AC2A5F.5020008@digitalbazaar.com> Message-ID: <48C9778E.5080106@weborganics.co.uk> Hello Manu Sorry I took so long to respond.. Manu Sporny wrote: > Martin McEvoy wrote: > >> [...] >>
> href="/music/album/-/Lost%20Angel/Psychosomatic/?id=7961">Psychosomatic
> >> [...] >> >> The above is a link to another page where audio may be listened to or >> downloaded. >> > > -1 to class="url" > > rel="bookmark" would be a more POSH way of marking up that relationship: > -1 to @rel="bookmark" > http://www.w3.org/TR/REC-html40/types.html#type-links > All links, url's are not clickable/hyperlinkable, also publishers of haudio may not have the option to add a @rel link type some applications such as Wiki's disable link types in favour of adding "nofollow" to all outgoing url's (this is only done for SEO purposes, it saves a site from losing Page Rank/P.R)... > rel="help" is also an option - we should re-use pre-existing HTML > LinkTypes where appropriate. > !! ... > However, I believe that there is also a problem with examples. Most of > the hAudio examples deal with the final location of the hAudio data and > rarely point elsewhere. We'd need more examples before adding this to > hAudio (per the Microformats process). > Manu, Take another look at all the example's[1] (I have that's what took me so long to respond) nearly all the examples have arbitrary links, not Author Links, not Payment Links or Enclosure Links just links that maybe link to other recordings by an artist, or a link where more information can be found about a recording, even links to where a said artist may be performing at some time in the future, these kind of links are directly associated with a particular or recording. > I'm not arguing that it's not useful, just arguing that we don't have > enough examples to support adding that feature to hAudio right now. > There are more than you would expect here are just a few for you to look at: http://microformats.org/blog/2005/09/30/web-essentials-audio/ (the audio is not on the page it is on Odeo) http://darwin-online.org.uk/audio_darwin.html (the titles of each section are on different pages) http://www.scottandrew.com/music/ (there are links where Lyrics can be found) http://magnatune.com/podcasts/details/magnatune_middle-eastern_podcast_2006_12_14 (all the links are links to pages where the audio may be found and listened to) ....I will leave you to go through the rest. [1] http://microformats.org/wiki/audio-info-examples Best Wishes Martin McEvoy > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From msporny at digitalbazaar.com Mon Sep 15 16:55:10 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Sep 15 16:55:16 2008 Subject: [uf-new] hAudio/Audio RDF clarification (possible admin moderation request) Message-ID: <48CEF5DE.1050804@digitalbazaar.com> Attached is a personal e-mail that I received today regarding my intentions towards hAudio and Audio RDF. I will be responding publicly to what I perceive as an attack on my efforts surrounding hAudio, Audio RDF, Microformats and RDFa. I am hesitant to make this a public issue as I don't want to waste anybody's time, but also do not want any sort of mis-information to be spread or assumptions made about my intentions with regard to hAudio, Audio RDF, the Microformats community or RDFa. This is a way of documenting this issue publicly, so that there is no question with regard to insinuations of non-transparency. I feel that I must respond to these allegations, even though I deem them to have no merit, to prevent people from getting the wrong impression. This conversation started on the RDFa mailing list: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Sep/0037.html Attached is a private e-mail I received a little over an three hours ago from Martin McEvoy. I'm surprised as it is out of character for him to be this aggressive, but I certainly don't want this to get out of hand. I'll publicly respond to his comments, as he has asked me to do, in case anybody else has been under the same mistaken set of impressions. -- manu ------------------------------------------------------------------------------ Subject: Re: RDFa and Microformats From: Martin McEvoy Date: Mon, 15 Sep 2008 22:19:47 +0100 To: Manu Sporny This is off list Manu Martin McEvoy wrote: > Manu Sporny wrote: >> Martin McEvoy wrote: >> >>> Talking of "hacks" why is this NOT a "hack" : >>> http://wiki.digitalbazaar.com/en/HAudio_RDFa? it looks like a direct rip >>> from the Microformats wiki, >>> >> >> That's because it started out as a direct rip from the Microformats wiki >> > it still is >> - the fact that it is so close to hAudio was deliberate. The intention >> was to create a cross-community vocabulary that would work for people >> jumping between RDFa and Microformats. > what people? hAudio is not yet even a draft proposal, and all these Publisher were Jumping around between vocabularies, that's interesting show me where? >> The outcome of that research was >> this: >> > By the W3C, the Microformats Community...? >> http://purl.org/media/audio >> >> The Audio RDF Vocabulary above has a clean/direct mapping to/from >> Microformats hAudio. >> Yo may be wandering about all the retaliation about "audio rdfa" Manu when you Microformats New mailing list with hAudio RDFa you received little support for your endeavour, in fact it was explicitly stated that: > --- this is one of the things that microformats wants to prevent... > http://microformats.org/discuss/mail/microformats-new/2007-July/000716.html basically because it causes a "drift" in semantics. you received no feedback from the list because we didn't want you to do it. you read Brian's email right? it was an incidental concern. It goes a little further than that, basically Manu You ripped the hAudio Microformat against the wishes of the Microformats Community and thus seriously damaged the haudio process in fact you almost killed it dead. if I could have stopped you I would. lets get hAudio out the door first eh! I request that you refrain from Editing the hAudio wiki further until I can be sure you are not serving your own needs. I cant believe you became an invited expert over your efforts. how did you deserve that. I will be adding Myself as Editor on the Version 1.0 format, because I don't have some other agenda other than completing haudio. Manu If you Ignore this email like you seem to conveniently do, I will post this email to the list because I think you will be ignoring me and I really would like some answers this time publicly or privately . Best Wishes Martin McEvoy From msporny at digitalbazaar.com Mon Sep 15 17:36:40 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Sep 15 17:36:45 2008 Subject: [uf-new] hAudio/Audio RDF clarification (possible admin moderation request) In-Reply-To: <48CEF5DE.1050804@digitalbazaar.com> References: <48CEF5DE.1050804@digitalbazaar.com> Message-ID: <48CEFF98.8060908@digitalbazaar.com> > Martin McEvoy wrote: > Yo may be wandering about all the retaliation about "audio rdfa" Manu > when you Microformats New mailing list with hAudio RDFa you received > little support for your endeavour, in fact it was explicitly stated > that: > >> --- this is one of the things that microformats wants to prevent... > >http://microformats.org/discuss/mail/microformats-new/2007-July/000716.html > > basically because it causes a "drift" in semantics. you received no > feedback from the list because we didn't want you to do it. you read > Brian's email right? it was an incidental concern. The reason the hAudio RDFa effort was started was because a number of us were concerned about what would happen if folks from this community wanted to do hAudio markup using RDFa, or vice versa. We wanted there to be nearly parallel ways of marking up semantics about audio in both RDFa and Microformats. We wanted there to be a clear mapping between the two. That is of secondary importance, however. I'm disturbed by what you are implying - that research projects must get the approval of this community before proceeding. I don't think that anybody in this community believes that is the best way to proceed - it would lead to a chilling effect on semantics research if one had to get approval from the Microformats community before using the basic work that all of us have done here. Do you think that scientists should be required to get approval before doing research on web semantics? That seems to be what you are implying with the statements you have made above. > It goes a little further than that, basically Manu You ripped the > hAudio Microformat against the wishes of the Microformats Community I certainly take issue with this - it sounds as if you're accusing me of plagiarism or something equally evil. We have gone out of our way to let everyone know that hAudio RDFa and Audio RDF was based[1][2][3] upon work done on the Microformats community (check the diff-logs and date/time stamps in the wiki - we have stated this from the beginning). In addition, it is clearly stated in the patents/copyright section of each vocabulary document that Digital Bazaar has authored[4][5][6][7]: """ This document and all ideas and patentable material outlined in the document are hereby placed into the public domain. It is our intent that all future additions, modifications and contributions will be placed into the public domain as well. We have released our copyright and control of this vocabulary for the good of the community and the betterment of the world in the name of open standards. We kindly ask that proper credit is given when using the vocabulary. A line like the following is sufficient: The Media/Audio/Video/Commerce RDF Vocabulary is an initiative lead by Digital Bazaar, Inc. and collaborated on by a number of people from the Web at large, the World Wide Web Consortium, the RDFa community and the Microformats community. """ We have released every vocabulary that we have into the public domain. Microformats has done the same with hAudio. I fail to see how one community is ripping the other one off? The whole purpose we have placed things into the public domain is to ensure that the work we do here and at Digital Bazaar can be re-used in other places without fear of copyright restrictions. > and > thus seriously damaged the haudio process in fact you almost killed it > dead. if I could have stopped you I would. lets get hAudio out the > door first eh! Getting hAudio to Draft and beyond has always been a high priority and will continue to be one. hAudio and Audio RDF are pragmatic approaches to the problem of audio identification. My hope is that they will be used by the general public to discover new artists via semantic web techniques. I don't believe that we should bet on one approach or one technology. I vehemently reject the notion that I am acting against its best interests or against the best interests of the 60,000+ artists whose music we distribute. In addition - my entire family is composed of artists (sculptors, painters, architects, writers, musicians, etc.). I grew up watching many artists languish in obscurity while those with better means (money) could market their creations with relative ease. I view the web, and web semantics as a great equalizer of cultural control. I have a deep personal commitment to improve the lives of artists and creators of all walks of life - I founded Digital Bazaar to stand behind that goal and it is what I have dedicated a very large part of my life to achieving. Not only for myself, but for the hundreds of thousands of people that want to make a living creating and bettering our global culture. Why would I want to stop that? It goes against everything that we're trying to achieve. > I request that you refrain from Editing the hAudio wiki further until > I can be sure you are not serving your own needs. Elaborate on what personal needs that I am serving. If you are going to accuse me of doing something nefarious, be specific. I have no problem addressing any of your concerns in a public forum. I have nothing to hide and feel that I have been overly transparent, logical and open about what we're trying to achieve. > I cant believe you became an invited expert over your efforts. how did > you deserve that. You would have to ask the members of the RDFa in XHTML Task Force on why they accepted me as an Invited Expert. I'm sure they would vouch for all of the hard work that I have done for that community. Just like there are people in this community that can vouch for the countless hours and hard work that I have volunteered, along with the other fine contributors - including yourself, in getting hAudio to the point that it is at now. > I will be adding Myself as Editor on the Version 1.0 format, because > I don't have some other agenda other than completing haudio. Had you approached this in a non-combative manner, I would have not taken issue with what you are proposing. However, to say that I have done something wrong and, I presume, to forcibly remove me from the specification would need the intervention of a group of people other than either of us. If you would like to proceed down this road, please state exactly what you think I have done wrong and make your request to the admins in this forum and not through private e-mail. Your approach is offensive to say the least. Even with that realization, I still think that your heart is in the right place and if you want to do some minor edits to hAudio in order to get it to Draft, I'm certainly not going to stand in your way. In fact, I would encourage it - just as I have been over the past several weeks[8][9][10]. > Manu If you Ignore this email like you seem to conveniently do, I will > post this email to the list because I think you will be ignoring me > and I really would like some answers this time publicly or privately. There is a very large chasm between the concept of "ignoring" and "not having enough time to respond". My e-mail load hovers around 100-150 e-mails that I must read a day - on average, I respond to about 30-40 e-mails a day and work 13-15 hour days (that's actual hours worked, not counting breakfast, lunch and dinner). I don't have time to get to every e-mail I want to respond to and quite often miss important e-mails. There are several others on this list in the same situation - we do our best, but can't always make everyone happy. Just to be clear - accusing me of mis-conduct and then threatening to make the information public is a terrible way to get a response. It will backfire each and every time you attempt to do it. I regret that you have taken this most reprehensible approach to do whatever it is that you are trying to do. If you goal is to out me as some sort of double-crossing semantics standards spy, you are going to fail. I have better things to do with my time than get wrapped up in some sort of petty standards fight - I care about helping artists make a decent living, everything else is a logical byproduct of that mission. -- manu [1]http://wiki.digitalbazaar.com/en/HAudio_RDFa#hAudio_RDFa_Draft_Specification [2]http://wiki.digitalbazaar.com/en/HAudio_RDFa#hAudio_RDFa_Specification [3]http://wiki.digitalbazaar.com/en/HAudio_RDFa#Patents [4]http://purl.org/media/ [5]http://purl.org/media/audio [6]http://purl.org/media/video [7]http://purl.org/commerce/ [8]http://microformats.org/discuss/mail/microformats-new/2008-August/001709.html [9]http://microformats.org/discuss/mail/microformats-new/2008-August/001693.html [10]http://microformats.org/discuss/mail/microformats-new/2008-August/001708.html From martin at weborganics.co.uk Mon Sep 15 17:50:29 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Sep 15 17:50:42 2008 Subject: [uf-new] hAudio/Audio RDF clarification (possible admin moderation request) In-Reply-To: <48CEF5DE.1050804@digitalbazaar.com> References: <48CEF5DE.1050804@digitalbazaar.com> Message-ID: <48CF02D5.9050208@weborganics.co.uk> Manu Sporny wrote: I also sent this one too: > Martin McEvoy wrote: >> I will be adding Myself as Editor on the Version 1.0 format, because >> I don't have some other agenda other than completing haudio. > In fact forget that its not very diplomatic, I will Invite Tantek, or > Brian to edit the 1.0 version of hAudio they are the two admin's that > have had the most input in haudio, haudio may gain a little of its > credibility in this way, and I think that it is the best. > > I will be emailing the admin's airing your total disregard of > microformat's principles, and of the damage you are causing the > Microformats Community, in particular hAudio > http://microformats.org/wiki/haudio and currency > http://microformats.org/wiki/currency to which you had no hand in > authoring. > > I will CC you the email in the next few days. > > > Kind Regards > > Martin McEvoy > Attached is a personal e-mail that I received today regarding my > intentions towards hAudio and Audio RDF. I will be responding publicly > to what I perceive as an attack on my efforts surrounding hAudio, Audio > RDF, Microformats and RDFa. > > I am hesitant to make this a public issue as I don't want to waste > anybody's time, but also do not want any sort of mis-information to be > spread or assumptions made about my intentions with regard to hAudio, > Audio RDF, the Microformats community or RDFa. This is a way of > documenting this issue publicly, so that there is no question with > regard to insinuations of non-transparency. I feel that I must respond > to these allegations, even though I deem them to have no merit, to > prevent people from getting the wrong impression. > > This conversation started on the RDFa mailing list: > > http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Sep/0037.html > > Attached is a private e-mail I received a little over an three hours ago > from Martin McEvoy. I'm surprised as it is out of character for him to > be this aggressive, but I certainly don't want this to get out of hand. > I'll publicly respond to his comments, as he has asked me to do, in case > anybody else has been under the same mistaken set of impressions. > > -- manu > > ------------------------------------------------------------------------------ > > Subject: Re: RDFa and Microformats > From: Martin McEvoy > Date: Mon, 15 Sep 2008 22:19:47 +0100 > To: Manu Sporny > > This is off list Manu > > Martin McEvoy wrote: > >> Manu Sporny wrote: >> >>> Martin McEvoy wrote: >>> >>> >>>> Talking of "hacks" why is this NOT a "hack" : >>>> http://wiki.digitalbazaar.com/en/HAudio_RDFa? it looks like a direct rip >>>> from the Microformats wiki, >>>> >>>> >>> That's because it started out as a direct rip from the Microformats wiki >>> >>> >> it still is >> >>> - the fact that it is so close to hAudio was deliberate. The intention >>> was to create a cross-community vocabulary that would work for people >>> jumping between RDFa and Microformats. >>> >> what people? hAudio is not yet even a draft proposal, and all these >> > Publisher were Jumping around between vocabularies, that's interesting > show me where? > >>> The outcome of that research was >>> this: >>> >>> >> By the W3C, the Microformats Community...? >> >>> http://purl.org/media/audio >>> >>> The Audio RDF Vocabulary above has a clean/direct mapping to/from >>> Microformats hAudio. >>> >>> > > Yo may be wandering about all the retaliation about "audio rdfa" Manu > when you Microformats New mailing list with hAudio RDFa you received > little support for your endeavour, in fact it was explicitly stated that: > > >> --- this is one of the things that microformats wants to prevent... >> >> > http://microformats.org/discuss/mail/microformats-new/2007-July/000716.html > > basically because it causes a "drift" in semantics. you received no > feedback from the list because we didn't want you to do it. you read > Brian's email right? it was an incidental concern. > > It goes a little further than that, basically Manu You ripped the > hAudio Microformat against the wishes of the Microformats Community and > thus seriously damaged the haudio process in fact you almost killed it > dead. if I could have stopped you I would. lets get hAudio out the door > first eh! > > I request that you refrain from Editing the hAudio wiki further until I > can be sure you are not serving your own needs. > > I cant believe you became an invited expert over your efforts. how did > you deserve that. > > I will be adding Myself as Editor on the Version 1.0 format, because I > don't have some other agenda other than completing haudio. > > Manu If you Ignore this email like you seem to conveniently do, I will > post this email to the list because I think you will be ignoring me and > I really would like some answers this time publicly or privately . > > Best Wishes > > Martin McEvoy > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From lists at ben-ward.co.uk Mon Sep 15 18:25:40 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Mon Sep 15 18:25:45 2008 Subject: [uf-new] hAudio/Audio RDF clarification (possible admin moderation request) In-Reply-To: <48CF02D5.9050208@weborganics.co.uk> References: <48CEF5DE.1050804@digitalbazaar.com> <48CF02D5.9050208@weborganics.co.uk> Message-ID: On 15 Sep 2008, at 17:50, Martin McEvoy wrote: >> Martin McEvoy wrote: >>> I will be adding Myself as Editor on the Version 1.0 format, >>> because I don't have some other agenda other than completing haudio. >> In fact forget that its not very diplomatic, I will Invite Tantek, >> or Brian to edit the 1.0 version of hAudio they are the two admin's >> that have had the most input in haudio, haudio may gain a little of >> its credibility in this way, and I think that it is the best. >> >> I will be emailing the admin's airing your total disregard of >> microformat's principles, and of the damage you are causing the >> Microformats Community, in particular hAudio http://microformats.org/wiki/haudio >> and currency http://microformats.org/wiki/currency to which you >> had no hand in authoring. Obviously the admins are open to email from anyone about any issue, but I for one would prefer that as much of this complaint is resolved in public, please. And, of course, the personal issues are more complex and it's up to individual judgement if you think it's more appropriate to take something offlist. I'm just emphasising that as much as can be resolved openly in this community and through process adherence should be, please. Additionally, my feeling is that I'm not involved enough in hAudio to comment on specifics, so what follows is quite general. That said, a few things regarding the process/development side of this seem quite clear to me. I want to know if the alleged process violations can be handled within the development process itself, rather than being an admin issue. Please consider these points: ? All issues with hAudio, be they problems to solve, capabilities to add, incompatibilities with the Process or anything else should be tracked as issues on the microformats wiki. (http://microformats.org/wiki/haudio-issues ). For a format to advance, issues need to be resolved. If issues are not resolved, the format can't be moved to its next stage (be that draft or spec) ? If an issue is ?resolved? in a way that is incompatible with the process (regardless of who resolves the issue), that issue cannot be resolved without addressing that breach of the process. Addressing that could be: Changing the issue resolution or changing the Process if the process were to be found to be broken. Either way, issues against formats cannot be resolved whilst in unaddressed violation of the process. These two points *should* prevent any individual ever pushing through a format in a manner which is incompatible with the process. If issue resolutions are insufficient, the issue must be reopened. Martin, if enforcing the process in the manner I describe here is insufficient to avoid/revert the issues you've raised, I'd be very grateful for elaboration or example of where these two checks have been avoided. Where the above is sufficient, anyone involved in hAudio development should be able to reopen issues that haven't been adequately addressed. Again I emphasise that I'm not endorsing any side of this personal argument at this point, and I'm speaking generally for that purpose. What I am trying to do is jump in quickly to apply the Process to the development problems raised, and avoid the personal aspects of this complaint being tangled with hAudio process issues. Thanks all, Ben From msporny at digitalbazaar.com Mon Sep 15 20:36:55 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Sep 15 20:37:00 2008 Subject: [uf-new] hAudio/Audio RDF clarification (possible admin moderation request) In-Reply-To: References: <48CEF5DE.1050804@digitalbazaar.com> <48CF02D5.9050208@weborganics.co.uk> Message-ID: <48CF29D7.4040209@digitalbazaar.com> Ben Ward wrote: > Obviously the admins are open to email from anyone about any issue, but > I for one would prefer that as much of this complaint is resolved in > public, please. I would prefer that this complaint is resolved publicly as well. > I want to know if the alleged process violations > can be handled within the development process itself It would be helpful if Martin could list the process violations that he believes have been made. -- manu From paullee at google.com Mon Sep 15 22:10:40 2008 From: paullee at google.com (=?EUC-KR?B?UGF1bCBMZWUgKMDMseK89ik=?=) Date: Mon Sep 15 22:11:04 2008 Subject: [uf-new] hProduct progress -- category discussion In-Reply-To: <190612150-1220909047-cardhu_decombobulator_blackberry.rim.net-1688246717-@bxe118.bisx.prod.on.blackberry> References: <0A55472BC29958468426825844F9F22E065984F6@dsp63mail.na.bestbuy.com> <190612150-1220909047-cardhu_decombobulator_blackberry.rim.net-1688246717-@bxe118.bisx.prod.on.blackberry> Message-ID: Tantek, is there any way to convey hierarchy with rel-tags? We've done both in Google Base/Product Search, going with hierarchical labels that include breadcrumbs, as well as with tags. I think we'd need something that supports both; most actually seem to use hierarchical labels/ontologies. On Mon, Sep 8, 2008 at 2:23 PM, Tantek Celik wrote: > > Categories/subcategories - just use rel-tags as hReview does. > > Tantek > -----Original Message----- > From: "Myers, Jay" > > Date: Mon, 8 Sep 2008 14:59:53 > To: For discussion of new microformats. > Subject: RE: [uf-new] hProduct progress -- category discussion > > > Hi Paul, > > Catching up on my hProduct work here... > > I wanted to address the topic of subcategories. I think that many > subcategory-specific values may be addressed in the p-v section of the > hProduct microformat. I agree that there are many universal product > attributes that can be addressed using the base hProduct spec, and it > would be worth it to continue foundational work. > > Speaking of category, the current foundation hProduct brainstorm schema > doesn't include any mention of product category. I could envision adding > category and subcategory nodes (ala category "breadcrumbs") to help > identify product cats and subcats. > > Thoughts? > > > Thanks, > > Jay > > > Jay Myers > Lead Web Development Engineer > Online Solutions, BestBuy.com > jay.myers@bestbuy.com > (w) 612-291-4007 > (twitter) @jaymyers > > -----Original Message----- > From: microformats-new-bounces@microformats.org > [mailto:microformats-new-bounces@microformats.org] On Behalf Of Paul Lee > (???) > Sent: Thursday, August 21, 2008 12:20 AM > To: microformats-new@microformats.org > Subject: [uf-new] hProduct progress (reply) > > Hi Jay, > > Just had two points to chime in on: > > 1. Reading over the page, sounds still a bit early to call it hProduct. > =) > > 2. That said, I agree with you that there's a case for a separate > format. The hListing proposal page makes it clear that it simply > wasn't designed to address retail products, for instance: > > "We are focusing on providing "just enough" structure to enable > matching, not to consummate transactions. This is distinct from the > majority of formats described on the wiki under listing-examples, > which are specific enough to completely describe products for retail > sale according to the idiosyncratic semantics of particular merchants > and shopping engines. Instead of encoding retail-oriented fields such > as UPCs, SKUs, and manufacturer part numbers, this proposal > acknowledges that many listings are for "inventories of one" that may > not have such precise abstractions." > > A product microformat could help fill the gap for information like > condition, brand, MPN, and unique product identifiers (UPC/EAN, ISBN). > > 3. Of course, that leads to the question: What about all the product > subcategories? My sense from reading archives is that that might be > part of the reason why discussion on product has died out - it's a > pretty behemoth task to design for tens of highly diverse categories, > with their own subcategories, many of which are still evolving. I > think, however, there's a lot of value in focusing on the common > ground across all products, and the value that that can add in and of > itself, as well as as a foundation for future work on subcategories. > > Paul > Google Product Search > > > [uf-new] hProduct progress > > Jay Myers jmyers at visi.com > Wed Aug 6 14:59:06 PDT 2008 > > All, > > There is work being done on new standards and reviving the > hProduct microformat. During the course of this effort, > people have pointed to hListing as a more viable, mature > > format for displaying product data. We proponents of > hProduct feel that a separate hProduct uF would be more > granular, and provide more specifics around the products, > which often are more complex and have important attributes > > that are outside of the scope of hListing and others. > Please see the updated brainstorming and draft proposal > wiki pages for more information on the updated schema. > > Nonetheless, there are still correlations between hListing > > and hProduct that can't be ignored. It has been suggested > that hProduct be used in conjuction with hListing to > enhance the semantics of that format, where hProduct would > live under .item. This I agree with, but I would still > > propose it also be used separately. > > I would appreciate any thoughts or ideas you might have > around the revival effort of hProduct. > > Thanks, > > Jay > _______________________________________________ > 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 -- Paul Lee Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 +1 (650) 214-6612 From paullee at google.com Mon Sep 15 22:38:05 2008 From: paullee at google.com (=?EUC-KR?B?UGF1bCBMZWUgKMDMseK89ik=?=) Date: Mon Sep 15 22:38:13 2008 Subject: [uf-new] hProduct: Model vs. MPN Message-ID: Hey Jay and others, A few other questions: - Do we still need Model if we have MPN? I suppose it's valuable for vehicles, but I expect those would need to be covered by a separate format. What do you think? - Do we need Savings if we have the ability to denote that the price is a sale price in Price? - I was thinking about internationalization, and wondering if we want to specify EAN and possibly even JAN, along with UPC and ISBN? - Finally, we have availability, how about quantity? I realize not all merchants will list this, but some might ... what do you think? Paul -- Paul Lee Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 +1 (650) 214-6612 From mail at tobyinkster.co.uk Tue Sep 16 09:39:24 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Tue Sep 16 09:39:58 2008 Subject: [uf-new] figure microformat Message-ID: <2AA51D1C-EB7C-4833-98BA-1581BACEF3EF@tobyinkster.co.uk> Dear all, Sarven Capadisli and I have, for the last 6 months or so, been working on a "figure" microformat for marking up images, charts and diagrams as part of a document. After a lot of brainstorming by many people on the microformats wiki, and off-site, what we've arrived at is a "port" of the HTML 5 figure construct to earlier versions of (X)HTML. The HTML 5 figure construct looks like this:
...
This is translated into a microformat as:

...

We've also defined various optimisations - for example, in the code above, the 'class="image"' could be removed. Lastly, we've defined some ways to use some existing microformats (rel-tag, hCard and hCalendar) inside figure to mark up what the image depicts, the credits, and some tags. We'd appreciate your feedback on the draft specification so far - either on this mailing list, or on the issues page. http://microformats.org/wiki/figure http://microformats.org/wiki/figure-issues -- Toby A Inkster From martin at weborganics.co.uk Tue Sep 16 15:01:47 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Tue Sep 16 15:02:04 2008 Subject: [uf-new] hAudio/Audio RDF clarification (possible admin moderation request) In-Reply-To: <48CEFF98.8060908@digitalbazaar.com> References: <48CEF5DE.1050804@digitalbazaar.com> <48CEFF98.8060908@digitalbazaar.com> Message-ID: <48D02CCB.2070108@weborganics.co.uk> Hello Manu... I really do not have to answer any of your remarks in this email, because you have only told half truths and not really answered any of my questions. I gave you reasonable notice of my intentions I spoke plainly to you Manu I always do... Manu Sporny wrote: >> Martin McEvoy wrote: >> Yo may be wandering about all the retaliation about "audio rdfa" Manu >> when you Microformats New mailing list with hAudio RDFa you received >> little support for your endeavour, in fact it was explicitly stated >> that: >> >> >>> --- this is one of the things that microformats wants to prevent... >>> >> http://microformats.org/discuss/mail/microformats-new/2007-July/000716.html >> >> basically because it causes a "drift" in semantics. you received no >> feedback from the list because we didn't want you to do it. you read >> Brian's email right? it was an incidental concern. >> > > The reason the hAudio RDFa effort was started was because a number of us > were concerned about what would happen if folks from this community > wanted to do hAudio markup using RDFa, Who exactly is "Us" The Microformats Community, The w3c, or Digital Bizzare?... And as I have said previously you were advised not to peruse hAudio-RDFa, because it will cause a "drift" in semantics, haudio will no longer be about the hAudio Microformat, it Will also be about the RDF vocabulary, a Fairly important fact you overlooked hAudio is not about RDF, or the "The Semantic Web" as a whole its about real life Publishing Patterns in HTML and the "meaning" contained therein. > or vice versa. We wanted there to > be nearly parallel ways of marking up semantics about audio in both RDFa > and Microformats. We wanted there to be a clear mapping between the two. > "We" is Digital Bizzare then? right! > That is of secondary importance, however. I'm disturbed by what you are > implying - that research projects must get the approval of this > community before proceeding. I don't think that anybody in this > community believes that is the best way to proceed - it would lead to a > chilling effect on semantics research if one had to get approval from > the Microformats community before using the basic work that all of us > have done here. > It would have been nice If you would have at least talked to this community first before you embarked on your endeavour, sorry you did didn't you and as I believe Nobody was really up for the idea, What is the POINT in duplicating it? and confusing people? Principle: KISS http://en.wikipedia.org/wiki/KISS_principle > Do you think that scientists should be required to get approval before > doing research on web semantics? That seems to be what you are implying > with the statements you have made above. > ?..no and no. > >> It goes a little further than that, basically Manu You ripped the >> hAudio Microformat against the wishes of the Microformats Community >> > > I certainly take issue with this - it sounds as if you're accusing me of > plagiarism or something equally evil. You know I have never actually said anything like that to you have I?. I will explain again, to see if you understand this time.... How did you rip off this community? (principally hAudio there are others) "You ripped off the hAudio Microformat against the wishes of the Microformats Community" Here was your first foray into the question about hAudio and RDFa http://microformats.org/discuss/mail/microformats-new/2007-July/000592.html Nobody Answered your noble call to the community, I did off list, I was interested (personaly) because I had just started exploring how hAudio matches up to other Audio formats, Chiefly RSS2, Music Ontology(I have an active interest in this..) XSPF(This too..) and a generic RDF vocabulary(for GRDDL, hey this too..) I was interested in how this would "pan out" in RDFa(would you believe this too..) There is a Reason for all this of course. If hAudio can be Matched up Semantically n=>n with an Existing Standard, do you not think It should? it would kind of make it "easier on the cognitive load" .... > We have gone out of our way to let > everyone know that hAudio RDFa and Audio RDF was based[1][2][3] upon > work done on the Microformats community (check the diff-logs and > date/time stamps in the wiki - we have stated this from the beginning). > In addition, it is clearly stated in the patents/copyright section of > each vocabulary document that Digital Bazaar has authored[4][5][6][7]: > That's kind of you...... > """ > This document and all ideas and patentable material outlined in the > document are hereby placed into the public domain. It is our intent that > all future additions, modifications and contributions will be placed > into the public domain as well. > > We have released our copyright and control of this vocabulary for the > good of the community and the betterment of the world in the name of > open standards. > Noble! > We kindly ask that proper credit is given when using the vocabulary. A > line like the following is sufficient: > > The Media/Audio/Video/Commerce RDF Vocabulary is an initiative lead by > Digital Bazaar, Inc. and collaborated on by a number of people from the > Web at large, the World Wide Web Consortium, the RDFa community and the > Microformats community Hold up a minute... you are Joking? are you? "The Media/Audio/Video/Commerce RDF Vocabulary is an initiative lead by Digital Bazaar, Inc" the Audio: http://microformats.org/wiki/haudio The Media: http://wiki.digitalbazaar.com/en/HMedia_Microformat(what is this?) Video: http://digitalbazaar.com/media/video (which I presume is a subset of hAudio, my name is on the bottom it must be) and Commerce: http://digitalbazaar.com/commerce .... Is? currency I hope http://microformats.org/wiki/currency or not Because Neither You, Or I, or many of the others are somehow involved in this "collaborative work"? > . > """ > > We have released every vocabulary that we have into the public domain. > Microformats has done the same with hAudio. I should hope so.... > I fail to see how one > community is ripping the other one off? The whole purpose we have placed > things into the public domain is to ensure that the work we do here and > at Digital Bazaar can be re-used in other places without fear of > copyright restrictions. > > There Are restrictions Manu! None of which either I or possibly others of This community could possibly ever "ethically" condone... "We kindly ask that proper credit is given when using the vocabulary. A line like the following is sufficient: The Commerce/Audio/Video RDF Vocabulary is an initiative lead by Digital Bazaar, Inc. and collaborated on by a number of people from the Web at large, the World Wide Web Consortium, the RDFa community and the Microformats community." >> and >> thus seriously damaged the haudio process in fact you almost killed it >> dead. if I could have stopped you I would. lets get hAudio out the >> door first eh! >> > > Getting hAudio to Draft and beyond has always been a high priority and > will continue to be one. hAudio and Audio RDF are pragmatic approaches > to the problem of audio identification. My hope is that they will be > used by the general public to discover new artists via semantic web > techniques. I don't believe that we should bet on one approach or one > technology. > Pretty speech, are you running for President? > I vehemently reject the notion that I am acting against its best > interests or against the best interests of the 60,000+ artists whose > music we distribute. In addition - my entire family is composed of > artists (sculptors, painters, architects, writers, musicians, etc.). I > grew up watching many artists languish in obscurity while those with > better means (money) could market their creations with relative ease. I > view the web, and web semantics as a great equalizer of cultural control. > > I have a deep personal commitment to improve the lives of artists and > creators of all walks of life - I founded Digital Bazaar to stand behind > that goal and it is what I have dedicated a very large part of my life > to achieving. Not only for myself, but for the hundreds of thousands of > people that want to make a living creating and bettering our global culture. > .... do you want me to cry? > Why would I want to stop that? It goes against everything that we're > trying to achieve. > Your cause is Just! and noble!, sorry Manu but please Keep up the Question is.... "hAudio/Audio RDF clarification" ... > >> I request that you refrain from Editing the hAudio wiki further until >> I can be sure you are not serving your own needs. >> > > .... > Elaborate on what personal needs that I am serving. If you are going to > accuse me of doing something nefarious, be specific "Infamous by way of being extremely wicked."? > . I have no problem > addressing any of your concerns in a public forum. I have nothing to > hide and feel that I have been overly transparent, logical and open > about what we're trying to achieve. > So you Say... This is NOT a Microformat: http://wiki.digitalbazaar.com/en/HMedia_Microformat The Microformats Community did NOT collaborate With Digital Bizzare, the W3C or The RDFa Community on any Of this: http://digitalbazaar.com/media http://digitalbazaar.com/media/audio http://digitalbazaar.com/media/video http://digitalbazaar.com/commerce are you Seriously Saying Me "Martin McEvoy" had in any way "collaborated" with you in ANY of these formats? I thought that the hAudio RDFa n=>n mapping was Interesting that was all. More Importantly the Discussion, to which I had no real part of, never existed... its just part of the constant sensationalism >> I cant believe you became an invited expert over your efforts. how did >> you deserve that. >> > > You would have to ask the members of the RDFa in XHTML Task Force on why > they accepted me as an Invited Expert. I'm sure they would vouch for all > of the hard work that I have done for that community. > Manu I'm sure you have worked your little fingers to the bone trying to gain credibility for the things you have done, how about gaining some credibility in the Microformats Community first, does that somehow matter? > Just like there are people in this community that can vouch for the > countless hours and hard work that I have volunteered, along with the > other fine contributors - including yourself, in getting hAudio to the > point that it is at now. > > >> I will be adding Myself as Editor on the Version 1.0 format, because >> I don't have some other agenda other than completing haudio. >> > > Had you approached this in a non-combative manner, I would have not > taken issue with what you are proposing. However, to say that I have > done something wrong I do, don't you see that? > and, I presume, to forcibly remove me from the > specification would need the intervention of a group of people other > than either of us. If you would like to proceed down this road, please > state exactly what you think I have done wrong and make your request to > the admins in this forum and not through private e-mail. > Manu these were Personal issues with how I felt on the hAudio Process was going, and what a negative effects Audio RDF are having. We could have done this reasonably as a personal issue, if this could not be resolved then I intended on taking my issues to one of the admin's of this list because of how personally I felt about your actions, I do not feel I am wrong in my actions.] How about remove your self Manu? by appointing a New Editor, Maybe someone would like to nominate themselves? > Your approach is offensive to say the least. so was yours.... > Even with that realization, > I still think that your heart is in the right place and if you want to > do some minor edits to hAudio in order to get it to Draft, I'm certainly > not going to stand in your way. In fact, I would encourage it - just as > I have been over the past several weeks[8][9][10]. > Thanks! >> Manu If you Ignore this email like you seem to conveniently do, I will >> post this email to the list because I think you will be ignoring me >> and I really would like some answers this time publicly or privately. >> > > There is a very large chasm between the concept of "ignoring" and "not > having enough time to respond". My e-mail load hovers around 100-150 > e-mails that I must read a day - on average, I respond to about 30-40 > e-mails a day and work 13-15 hour days (that's actual hours worked, not > counting breakfast, lunch and dinner). I don't have time to get to every > e-mail I want to respond to and quite often miss important e-mails. > There are several others on this list in the same situation - we do our > best, but can't always make everyone happy. > Yes you have to prioritize your work load. > Just to be clear - accusing me of mis-conduct and then threatening to > make the information public is a terrible way to get a response. It will > backfire each and every time you attempt to do it. > > I regret that you have taken this most reprehensible approach to do > whatever it is that you are trying to do. If you goal is to out me as > some sort of double-crossing semantics standards spy, I again Didn't say that... I really wish you would not distort my words? > you are going to fail. Sigh! at what Defending something I have spent A Year and Half Developing. something I actually care about, never mind my personal credibility, In case you havnt guessed I dont really care about My Personal credibility Manu, You should Know that... I do Care about all the effects I have on My Community... > I have better things to do with my time than get wrapped up in > some sort of petty standards fight - I care about helping artists make a > decent living, everything else is a logical byproduct of that mission. > ... good Manu at least you have some Morals and Regard for your your peers... Best Wishes Martin McEvoy. > -- manu > > [1]http://wiki.digitalbazaar.com/en/HAudio_RDFa#hAudio_RDFa_Draft_Specification > [2]http://wiki.digitalbazaar.com/en/HAudio_RDFa#hAudio_RDFa_Specification > [3]http://wiki.digitalbazaar.com/en/HAudio_RDFa#Patents > [4]http://purl.org/media/ > [5]http://purl.org/media/audio > [6]http://purl.org/media/video > [7]http://purl.org/commerce/ > [8]http://microformats.org/discuss/mail/microformats-new/2008-August/001709.html > [9]http://microformats.org/discuss/mail/microformats-new/2008-August/001693.html > [10]http://microformats.org/discuss/mail/microformats-new/2008-August/001708.html > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From ckstjohn at gmail.com Tue Sep 16 16:53:34 2008 From: ckstjohn at gmail.com (Christopher St John) Date: Tue Sep 16 16:53:38 2008 Subject: [uf-new] hAudio/Audio RDF clarification (possible admin moderation request) In-Reply-To: <48D02CCB.2070108@weborganics.co.uk> References: <48CEF5DE.1050804@digitalbazaar.com> <48CEFF98.8060908@digitalbazaar.com> <48D02CCB.2070108@weborganics.co.uk> Message-ID: <8ba906450809161653q74baef89yb1f57233449ec7a6@mail.gmail.com> On Tue, Sep 16, 2008 at 5:01 PM, Martin McEvoy wrote: > ... > And as I have said previously you were advised not to peruse hAudio-RDFa, > ... > This thread is getting really weird. It's also gotten completely off topic. None of this has anything to do with new microformats. Personally, I'd like to see the alleged process violations documented and discussed (preferably not on microformats-new) or, even better, for the thread to end. But hey, that's just me. -cks -- Christopher St. John http://artofsystems.blogspot.com From bhawkeslewis at googlemail.com Fri Sep 19 02:31:18 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Fri Sep 19 02:31:26 2008 Subject: [uf-new] figure microformat In-Reply-To: <2AA51D1C-EB7C-4833-98BA-1581BACEF3EF@tobyinkster.co.uk> References: <2AA51D1C-EB7C-4833-98BA-1581BACEF3EF@tobyinkster.co.uk> Message-ID: <48D37166.2040202@googlemail.com> Toby A Inkster wrote: > After a lot of brainstorming by many people on the microformats wiki, > and off-site, what we've arrived at is a "port" of the HTML 5 figure > construct to earlier versions of (X)HTML. The HTML 5 figure construct > looks like this: > >
> > ... >
> > This is translated into a microformat as: > >
> >

...

>
> > We've also defined various optimisations - for example, in the code > above, the 'class="image"' could be removed. I think the notion that this is in any sense a port of the HTML5 figure construct is problematic, since "figure" in HTML5 maps to a wider set than supporting images: "The figure element represents some flow content, optionally with a caption, which can be moved away from the main flow of the document without affecting the document's meaning. "The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix." http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded0.html#the-figure If you're going to try and port this feature, I suggest allowing figure to have the same scope as the original. -- Benjamin Hawkes-Lewis From Jay.Myers at bestbuy.com Fri Sep 19 13:53:51 2008 From: Jay.Myers at bestbuy.com (Myers, Jay) Date: Fri Sep 19 13:53:55 2008 Subject: [uf-new] hProduct: more around product category Message-ID: <0A55472BC29958468426825844F9F22E0659857C@dsp63mail.na.bestbuy.com> I've added a straight "category" to the schema, in addition to rel-tag, to cover those instances where using rel-tag isn't possible. An example would be when a publisher adds a category but cannot make it a clickable link (thank you for the tip on this, Andy Mabbett). I would think there could be multiple category nodes in the markup to represent and replicate the hierarchical labels that most publishers employ to categorize their products, similar to unordered/ ordered HTML "breadcrumb" markup used on many sites. Any comments or suggestions would be appreciated! J Jay Myers Lead Web Development Engineer Online Solutions, BestBuy.com @jaymyers From paullee at google.com Sun Sep 21 17:58:46 2008 From: paullee at google.com (=?EUC-KR?B?UGF1bCBMZWUgKMDMseK89ik=?=) Date: Sun Sep 21 17:58:53 2008 Subject: [uf-new] hProduct: more around product category In-Reply-To: <0A55472BC29958468426825844F9F22E0659857C@dsp63mail.na.bestbuy.com> References: <0A55472BC29958468426825844F9F22E0659857C@dsp63mail.na.bestbuy.com> Message-ID: Thanks, Jay. I think this makes sense and allows hierarchical labels. Paul On Fri, Sep 19, 2008 at 1:53 PM, Myers, Jay wrote: > > I've added a straight "category" to the schema, in addition to rel-tag, > to cover those instances where using rel-tag isn't possible. An example > would be when a publisher adds a category but cannot make it a clickable > link (thank you for the tip on this, Andy Mabbett). > > I would think there could be multiple category nodes in the markup to > represent and replicate the hierarchical labels that most publishers > employ to categorize their products, similar to unordered/ ordered HTML > "breadcrumb" markup used on many sites. > > Any comments or suggestions would be appreciated! > > J > > Jay Myers > Lead Web Development Engineer > Online Solutions, BestBuy.com > @jaymyers > > > > > _______________________________________________ > 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 mail at tobyinkster.co.uk Sun Sep 21 22:23:46 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Sep 21 22:24:24 2008 Subject: [uf-new] hProduct: more around product category Message-ID: <22717836-FF4A-4D3A-BDB8-CACD84C0E22F@tobyinkster.co.uk> Paul Lee wrote: > Thanks, Jay. I think this makes sense and allows hierarchical labels.

Percoidei: Remoras: Echeneis

Parsed as: category : ["Percoidei: Remoras: Echenei", "Percoidei: Remoras", "Percoidei"] which gives you an implicit hierarchy. -- Toby A Inkster From paullee at google.com Sun Sep 21 22:31:32 2008 From: paullee at google.com (=?EUC-KR?B?UGF1bCBMZWUgKMDMseK89ik=?=) Date: Sun Sep 21 22:31:40 2008 Subject: [uf-new] hProduct: more around product category In-Reply-To: <22717836-FF4A-4D3A-BDB8-CACD84C0E22F@tobyinkster.co.uk> References: <22717836-FF4A-4D3A-BDB8-CACD84C0E22F@tobyinkster.co.uk> Message-ID: Or simply with category : ["Percoidei: Remoras: Echenei"], most folks should be able to auto-detect the breadcrumbs. On Sun, Sep 21, 2008 at 10:23 PM, Toby A Inkster wrote: > Paul Lee wrote: > >> Thanks, Jay. I think this makes sense and allows hierarchical labels. > >

class="category">Percoidei: Remoras: Echeneis

> > Parsed as: > > category : ["Percoidei: Remoras: Echenei", "Percoidei: Remoras", > "Percoidei"] > > which gives you an implicit hierarchy. > > -- > Toby A Inkster > > > > > > _______________________________________________ > 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 nicolas at nicolasleroy.fr Mon Sep 22 07:45:08 2008 From: nicolas at nicolasleroy.fr (Nicolas Leroy) Date: Mon Sep 22 07:45:12 2008 Subject: [uf-new] hProduct: Should "availability", "quantity" and "shipping" be part of hProduct or hListing? Message-ID: <8519cd450809220745j2f3ba56do9e5176eccf1a44e5@mail.gmail.com> Hi, As I'm new to this discussion around hProduct, let me (briefly) introduce myself :) I'm product manager at Kelkoo, an European price comparison site, part of the Yahoo! group. At Kelkoo, we have become strong advocates of the benefits of microformats (thanks to Ben Ward who contributes to this list). Indeed, since our '07 redesign, we now support the hListing microformat to describe all offers from merchants (+hReview, hCard). Clearly, as product manager, I would welcome a hProduct microformat to differenciate offers (product with a price / a deliverycost / an availability sent by a single merchant) and products. I had a look at the current status of the hListing microformats: http://microformats.org/wiki/product-brainstorming - and you guys did a really great job pushing this spec forwards. My first question on this list would be on the "availability", "quantity" and "shipping" elements. As described on the twiki: "The actual price/sale price/final price should be solely in the domain of hListing". I therefore think those elements ("availability", "quantity" and "shipping") should be part of hListing, not hProduct, as they are different for each merchant. What do u think? Nicolas -- >From Nicolas Leroy - http://www.nicolasleroy.fr