From msporny at digitalbazaar.com Wed Aug 1 20:54:34 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Aug 1 20:54:37 2007 Subject: [uf-new] hAudio issues page updated Message-ID: <46B1557A.1020805@digitalbazaar.com> The hAudio issues page has been updated with the following: * Redundant property issues * Graphic buttons and 'rel-sample', 'rel-enclosure', and 'rel-payment Please take a look at the page if you were involved in the discussions on hAudio. Make additions to the page if you have any outstanding issues that are not already on there: http://microformats.org/wiki/audio-info-issues We are going to make another pass at addressing the issues next week. -- manu From msporny at digitalbazaar.com Sun Aug 5 19:39:10 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Aug 5 19:39:13 2007 Subject: [uf-new] hAudio ISSUE #1: image-summary is redundant Message-ID: <46B689CE.7070804@digitalbazaar.com> The full issue description can be found on the audio-info-issues page: http://microformats.org/wiki/audio-info-issues#image-summary_Property hAudio ISSUE #1: image-summary - This is a small graphic image that summarizes the audio piece. There are several other formats that already use the PHOTO property, including hCard and hReview. This has potential to collapse and remove image-summary. Possible Solutions 1. Use PHOTO instead. I think we should go with Brian's suggestion and use PHOTO instead of image-summary. If you are involved in hAudio (or want to be), please give the list an "AGREE/+1" or disagree with a line of reasoning. -- manu From msporny at digitalbazaar.com Sun Aug 5 19:47:14 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Aug 5 19:47:16 2007 Subject: [uf-new] hAudio ISSUE #3: published-date is redundant Message-ID: <46B68BB2.105@digitalbazaar.com> Skipping haudio ISSUE #2 because we don't have halbum done yet. halbum might also use audio-title, or album-title. Use of FN or SUMMARY could conflict. We'll revisit hAudio ISSUE #2 when we have halbum in a more stable state. hAudio ISSUE #3: http://microformats.org/wiki/audio-info-issues#published-date_Property published-date is a duplicate of the PUBLISHED property found-in hAtom. This can be collapsed to a single property name or dtstart, from hCalendar. Possible Solutions 1. Use PUBLISHED instead 2. Use DTSTART instead 3. One of the two above, and make published an hCalendar event I suggest that we use PUBLISHED and not make it an hCalendar event to stay in line with how PUBLISHED is defined in hAtom. It should use the date-time-design-pattern.If you are involved in hAudio (or want to be), please give the list an "AGREE/+1" or disagree with a line of reasoning. -- manu From msporny at digitalbazaar.com Sun Aug 5 21:00:47 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Aug 5 21:00:51 2007 Subject: [uf-new] hAlbum Microformat brainstorming and proposal pages created Message-ID: <46B69CEF.40303@digitalbazaar.com> To get ready for the hAlbum Microformat discussion, separate brainstorming and proposal pages have been created. hAlbum was cleaved from hAudio several months ago because it was complicating issues. The decision was made to tackle audio collections at a later date, thus we dropped all discussion at that time. The plan is to revive discussion on hAlbum now that we've gone through an implementation cycle with hAudio. The new pages can be found here... they are rough, but should outline what we're planning on discussing. hAlbum borrows very heavily from hAudio: http://microformats.org/wiki/audio-album-brainstorming http://microformats.org/wiki/audio-album-proposal Once some of the hAudio issues have been addressed we can move on to hAlbum... the page is up if people want to make changes, or start commenting on the audio-album-issues page. -- manu From martin at weborganics.co.uk Mon Aug 6 03:44:39 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 6 03:43:13 2007 Subject: [uf-new] hAudio ISSUE #1: image-summary is redundant In-Reply-To: <46B689CE.7070804@digitalbazaar.com> References: <46B689CE.7070804@digitalbazaar.com> Message-ID: <1186397079.16632.19.camel@localhost.localdomain> On Sun, 2007-08-05 at 22:39 -0400, Manu Sporny wrote: > The full issue description can be found on the audio-info-issues page: > > http://microformats.org/wiki/audio-info-issues#image-summary_Property > > hAudio ISSUE #1: > > image-summary - This is a small graphic image that summarizes the audio > piece. There are several other formats that already use the PHOTO > property, including hCard and hReview. This has potential to collapse > and remove image-summary. > > Possible Solutions > > 1. Use PHOTO instead. > > I think we should go with Brian's suggestion and use PHOTO instead of > image-summary. If you are involved in hAudio (or want to be), please > give the list an "AGREE/+1" or disagree with a line of reasoning. > > -- manu Disagree Photo or Logo is not a correct description of what may be potentially a work of art eg, Sergeant Peppers lonely hearts club album image, by the Beatles which was created by Robert Fraser [1] and the Fallen Angels ' Fallen Angels '[2] album cover which is an original work of art, which is a 48" x 48" oil on board which has a selling price of around ?2000 created by KNOX Many album images are artistic impressions or summaries of the music its self eg, The Bat out of Hell album cover by Meat Loaf [3] I feel also that image-summary would fit in with both hImage and hVideo [1] http://en.wikipedia.org/wiki/Robert_Fraser [2] http://www.knox76.com/Latestadditions1.html [3] http://en.wikipedia.org/wiki/Image:Bat_out_of_Hell.jpg Thanks Martin > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2171 bytes Desc: not available Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070806/dbaa39c5/smime.bin From martin at weborganics.co.uk Mon Aug 6 03:47:06 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 6 03:45:36 2007 Subject: [uf-new] hAudio ISSUE #3: published-date is redundant In-Reply-To: <46B68BB2.105@digitalbazaar.com> References: <46B68BB2.105@digitalbazaar.com> Message-ID: <1186397226.16632.20.camel@localhost.localdomain> On Sun, 2007-08-05 at 22:47 -0400, Manu Sporny wrote: > Skipping haudio ISSUE #2 because we don't have halbum done yet. halbum > might also use audio-title, or album-title. Use of FN or SUMMARY could > conflict. We'll revisit hAudio ISSUE #2 when we have halbum in a more > stable state. > > hAudio ISSUE #3: > http://microformats.org/wiki/audio-info-issues#published-date_Property > > published-date is a duplicate of the PUBLISHED property found-in hAtom. > This can be collapsed to a single property name or dtstart, from hCalendar. > > Possible Solutions > > 1. Use PUBLISHED instead > 2. Use DTSTART instead > 3. One of the two above, and make published an hCalendar event > > I suggest that we use PUBLISHED and not make it an hCalendar event to > stay in line with how PUBLISHED is defined in hAtom. It should use the > date-time-design-pattern.If you are involved in hAudio (or want to be), > please give the list an "AGREE/+1" or disagree with a line of reasoning. > > -- manu AGREE/+1 > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2171 bytes Desc: not available Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070806/d6ff4092/smime.bin From martin at weborganics.co.uk Mon Aug 6 19:11:21 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 6 19:37:15 2007 Subject: [uf-new] hAudio ISSUE #1: image-summary is redundant In-Reply-To: <1186397079.16632.19.camel@localhost.localdomain> References: <46B689CE.7070804@digitalbazaar.com> <1186397079.16632.19.camel@localhost.localdomain> Message-ID: <1186452681.4603.4.camel@localhost.localdomain> On Mon, 2007-08-06 at 11:44 +0100, Martin McEvoy wrote: > On Sun, 2007-08-05 at 22:39 -0400, Manu Sporny wrote: > > The full issue description can be found on the audio-info-issues page: > > > > http://microformats.org/wiki/audio-info-issues#image-summary_Property > > > > hAudio ISSUE #1: > > > > image-summary - This is a small graphic image that summarizes the audio > > piece. There are several other formats that already use the PHOTO > > property, including hCard and hReview. This has potential to collapse > > and remove image-summary. > > > > Possible Solutions > > > > 1. Use PHOTO instead. > > > > I think we should go with Brian's suggestion and use PHOTO instead of > > image-summary. If you are involved in hAudio (or want to be), please > > give the list an "AGREE/+1" or disagree with a line of reasoning. > > > > -- manu > > Disagree > > Photo or Logo is not a correct description of what may be potentially a > work of art eg, Sergeant Peppers lonely hearts club album image, by the > Beatles which was created by Robert Fraser [1] oops reading my notes wrong sorry It wasnt created by Robert Fraser it was "Directed" by Robert Fraser. Sergeant Peppers lonely hearts club album image was created by Pop Artist Peter Blake http://en.wikipedia.org/wiki/Peter_Blake_%28artist%29 Thanks Martin > and the Fallen Angels ' Fallen Angels '[2] album cover which is an > original work of art, which is a 48" x 48" oil on board which has a > selling price of around ?2000 created by KNOX > > Many album images are artistic impressions or summaries of the music its > self eg, The Bat out of Hell album cover by Meat Loaf [3] > > I feel also that image-summary would fit in with both hImage and hVideo > > [1] http://en.wikipedia.org/wiki/Robert_Fraser > [2] http://www.knox76.com/Latestadditions1.html > [3] http://en.wikipedia.org/wiki/Image:Bat_out_of_Hell.jpg > > Thanks Martin > > > > > _______________________________________________ > > microformats-new mailing list > > microformats-new@microformats.org > > http://microformats.org/mailman/listinfo/microformats-new -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2171 bytes Desc: not available Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070807/2d0a047d/smime.bin From brian.suda at gmail.com Tue Aug 7 02:30:44 2007 From: brian.suda at gmail.com (Brian Suda) Date: Tue Aug 7 02:30:46 2007 Subject: [uf-new] hAudio ISSUE #3: published-date is redundant In-Reply-To: <46B68BB2.105@digitalbazaar.com> References: <46B68BB2.105@digitalbazaar.com> Message-ID: <21e770780708070230w79507b88ufd45e9ed86eb08a1@mail.gmail.com> On 8/6/07, Manu Sporny wrote: > Possible Solutions > > 1. Use PUBLISHED instead > 2. Use DTSTART instead > 3. One of the two above, and make published an hCalendar event > > I suggest that we use PUBLISHED and not make it an hCalendar event to > stay in line with how PUBLISHED is defined in hAtom. It should use the > date-time-design-pattern.If you are involved in hAudio (or want to be), > please give the list an "AGREE/+1" or disagree with a line of reasoning. If you look at the wiki page which lists our classes, http://microformats.org/wiki/classes you will see that we have several ways of specifying a date hCard uses REV, which is the REVISION date hCalendar uses LAST-MODIFIED, the time the calendar was last changes hAtom uses UPDATED and PUBLISHED I agree it should use the ISO date-time pattern every other date format is using. -- brian suda http://suda.co.uk From brian.suda at gmail.com Tue Aug 7 02:50:11 2007 From: brian.suda at gmail.com (Brian Suda) Date: Tue Aug 7 02:50:13 2007 Subject: [uf-new] hAudio ISSUE #1: image-summary is redundant In-Reply-To: <1186397079.16632.19.camel@localhost.localdomain> References: <46B689CE.7070804@digitalbazaar.com> <1186397079.16632.19.camel@localhost.localdomain> Message-ID: <21e770780708070250h5cd96f5epc993d4c890ed3646@mail.gmail.com> On 8/6/07, Martin McEvoy wrote: > On Sun, 2007-08-05 at 22:39 -0400, Manu Sporny wrote: > > The full issue description can be found on the audio-info-issues page: > > > > http://microformats.org/wiki/audio-info-issues#image-summary_Property > > > > hAudio ISSUE #1: > > > > image-summary - This is a small graphic image that summarizes the audio > > piece. There are several other formats that already use the PHOTO > > property, including hCard and hReview. This has potential to collapse > > and remove image-summary. > > > > Possible Solutions > > > > 1. Use PHOTO instead. > > > > I think we should go with Brian's suggestion and use PHOTO instead of > > image-summary. If you are involved in hAudio (or want to be), please > > give the list an "AGREE/+1" or disagree with a line of reasoning. > > > > -- manu > > Disagree > > Photo or Logo is not a correct description of what may be potentially a > work of art eg, --- i think this is splitting hairs, at the end of the day, this is a representation of the actual Art, Photo, Painting, etc. Applications are called "PhotoShop". "iPhoto", etc. even though they are not always indexing or editing JUST photos. Re-using PHOTO keeps us from inventing more and more terms. Also, the current spec says that this MUST use an , i would say this should be changed to SHOULD, not MUST. There could be cases were you might want to simply give the URL to the image or use an AREA or OBJECT element. Or possibly use other elements in RSS. We should avoid mandating how/where to encoding specific microformat properties. -brian -- brian suda http://suda.co.uk From brian.suda at gmail.com Tue Aug 7 03:10:15 2007 From: brian.suda at gmail.com (Brian Suda) Date: Tue Aug 7 03:10:18 2007 Subject: [uf-new] hAlbum Microformat brainstorming and proposal pages created In-Reply-To: <46B69CEF.40303@digitalbazaar.com> References: <46B69CEF.40303@digitalbazaar.com> Message-ID: <21e770780708070310k5bb653b2y9217bce57409b89e@mail.gmail.com> On 8/6/07, Manu Sporny wrote: > The new pages can be found here... they are rough, but should outline > what we're planning on discussing. hAlbum borrows very heavily from hAudio: --- with the exception of TRACKS an Album has all the identical properties of the audio proposal. > Once some of the hAudio issues have been addressed we can move on to > hAlbum... the page is up if people want to make changes, or start > commenting on the audio-album-issues page. --- i'm slightly confused at the point of Albums being something different? (Please add the following to the issues pages of your choice) What happens when you have 10 tracks all reporting to be from different CDs, different artists, different album art, all .99cents. Then thoses are inside an hAlbum which is $5.99 (not the same price summed - this is ok, buy as a whole album or buy individually, like iTunes) and you have different artwork at the album level and different artists? Wouldn?t it be easier to just NOT have hAlbum, and simply add something to hAudio called "collection" or something? then all TRACKS on a page with the same value for COLLECTION could suffice? that fails to get you an OVERALL price for an album, but then maybe in your hAudio, simply make the track name optional... so if there is NO track name, but a collection name, then all the attributes are about the collection? Then you can have a price/photo/description/ect at the collection level and you can have all the same things at the track level and associate it with a collection. Do we need a whole separate format to markup the exact same data twice? I think we should work more on the hAudio proposal, as there are still a few open issues. Then possibly instead of inventing a new format, can we simply iterate on hAudio to include information at the album/collection level. -brian -- brian suda http://suda.co.uk From martin at weborganics.co.uk Tue Aug 7 10:44:53 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Tue Aug 7 10:43:25 2007 Subject: [uf-new] hAudio ISSUE #1: image-summary is redundant In-Reply-To: <21e770780708070250h5cd96f5epc993d4c890ed3646@mail.gmail.com> References: <46B689CE.7070804@digitalbazaar.com> <1186397079.16632.19.camel@localhost.localdomain> <21e770780708070250h5cd96f5epc993d4c890ed3646@mail.gmail.com> Message-ID: <1186508693.10531.6.camel@localhost.localdomain> On Tue, 2007-08-07 at 09:50 +0000, Brian Suda wrote: > On 8/6/07, Martin McEvoy wrote: > > On Sun, 2007-08-05 at 22:39 -0400, Manu Sporny wrote: > > > The full issue description can be found on the audio-info-issues page: > > > > > > http://microformats.org/wiki/audio-info-issues#image-summary_Property > > > > > > hAudio ISSUE #1: > > > > > > image-summary - This is a small graphic image that summarizes the audio > > > piece. There are several other formats that already use the PHOTO > > > property, including hCard and hReview. This has potential to collapse > > > and remove image-summary. > > > > > > Possible Solutions > > > > > > 1. Use PHOTO instead. > > > > > > I think we should go with Brian's suggestion and use PHOTO instead of > > > image-summary. If you are involved in hAudio (or want to be), please > > > give the list an "AGREE/+1" or disagree with a line of reasoning. > > > > > > -- manu > > > > Disagree > > > > Photo or Logo is not a correct description of what may be potentially a > > work of art eg, > > --- i think this is splitting hairs, at the end of the day, this is a > representation of the actual Art, Photo, Painting, etc. Applications > are called "PhotoShop". "iPhoto", etc. even though they are not always > indexing or editing JUST photos. Re-using PHOTO keeps us from > inventing more and more terms. > > Also, the current spec says that this MUST use an , i would say > this should be changed to SHOULD, not MUST. There could be cases were > you might want to simply give the URL to the image or use an AREA or > OBJECT element. Or possibly use other elements in RSS. We should avoid > mandating how/where to encoding specific microformat properties. Do you think the use of PHOTO may interfere with the hCard that is already part of the hAudio proposal, Suppose I wanted to mark up my hAudio hcard's with Photos of the band members? isn't that breaking the don't repeat yourself rule? Thanks Martin > > -brian > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2171 bytes Desc: not available Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070807/2b9ceded/smime.bin From scott at makedatamakesense.com Tue Aug 7 11:22:13 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Tue Aug 7 11:22:22 2007 Subject: [uf-new] hAudio ISSUE #1: image-summary is redundant In-Reply-To: <1186508693.10531.6.camel@localhost.localdomain> References: <46B689CE.7070804@digitalbazaar.com> <1186397079.16632.19.camel@localhost.localdomain> <21e770780708070250h5cd96f5epc993d4c890ed3646@mail.gmail.com> <1186508693.10531.6.camel@localhost.localdomain> Message-ID: <84ED5BDD-1309-4B62-A3C2-7F16984325A8@makedatamakesense.com> On Aug 7, 2007, at 11:44 AM, Martin McEvoy wrote: > Do you think the use of PHOTO may interfere with the hCard that is > already part of the hAudio proposal, Suppose I wanted to mark up my > hAudio hcard's with Photos of the band members? isn't that breaking > the > don't repeat yourself rule? Not really. DRY refers to content, not structure. Unlike content, we should repeat structure as much as possible (for different content). That's what makes it standardized and useful. However, there is an issue with defining scope (i.e. how do we limit the scope of hCard photos to the hCard and not affect a surrounding hAudio?) that we keep running into whenever anyone suggests re-use of property names. There's an effort to solve that problem started here: http://microformats.org/wiki/mfo But that's moving slowly precisely because we keep avoiding the problem instead of addressing it. But it's a solvable problem. Parsers can figure out the difference between hCard photos and hAudio photos, even though they're not doing so yet. If it becomes a significant problem, it will be solved by clarifying parsing rules. If it doesn't become a significant problem, it's not worth worrying about. Either way, it needn't influence our choice of property names. -- Scott Reynen MakeDataMakeSense.com From brian.suda at gmail.com Tue Aug 7 12:31:19 2007 From: brian.suda at gmail.com (Brian Suda) Date: Tue Aug 7 12:31:22 2007 Subject: [uf-new] hAudio ISSUE #1: image-summary is redundant In-Reply-To: <84ED5BDD-1309-4B62-A3C2-7F16984325A8@makedatamakesense.com> References: <46B689CE.7070804@digitalbazaar.com> <1186397079.16632.19.camel@localhost.localdomain> <21e770780708070250h5cd96f5epc993d4c890ed3646@mail.gmail.com> <1186508693.10531.6.camel@localhost.localdomain> <84ED5BDD-1309-4B62-A3C2-7F16984325A8@makedatamakesense.com> Message-ID: <21e770780708071231o391733b8r26f83067da4e0912@mail.gmail.com> On 8/7/07, Scott Reynen wrote: > On Aug 7, 2007, at 11:44 AM, Martin McEvoy wrote: > > > Do you think the use of PHOTO may interfere with the hCard that is > > already part of the hAudio proposal, Suppose I wanted to mark up my > > hAudio hcard's with Photos of the band members? isn't that breaking > > the > > don't repeat yourself rule? --- like scott was saying, when developing the format, you can also define the parsing rules. If you look at hReview, it uses hCards and PHOTO. To disambinguate the two it is a matter of PHOTO inside an hCard and PHOTO not inside an hCard. This is already something that hReview deals with and that has been working pretty well so far. hReview is a good example, because it can use an hCard to be the thing reviewed, and an hCard for the reviewer. So you have multiple FNs, PHOTOs, all over the place and it manages to get sorted out just fine, it is just a matter of parsing rules. -brian -- brian suda http://suda.co.uk From msporny at digitalbazaar.com Tue Aug 7 13:31:21 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Aug 7 13:31:23 2007 Subject: [uf-new] hAudio ISSUE #1: image-summary is redundant In-Reply-To: <21e770780708071231o391733b8r26f83067da4e0912@mail.gmail.com> References: <46B689CE.7070804@digitalbazaar.com> <1186397079.16632.19.camel@localhost.localdomain> <21e770780708070250h5cd96f5epc993d4c890ed3646@mail.gmail.com> <1186508693.10531.6.camel@localhost.localdomain> <84ED5BDD-1309-4B62-A3C2-7F16984325A8@makedatamakesense.com> <21e770780708071231o391733b8r26f83067da4e0912@mail.gmail.com> Message-ID: <46B8D699.8050003@digitalbazaar.com> Brian Suda wrote: > --- like scott was saying, when developing the format, you can also > define the parsing rules. If you look at hReview, it uses hCards and > PHOTO. To disambinguate the two it is a matter of PHOTO inside an > hCard and PHOTO not inside an hCard. This is already something that > hReview deals with and that has been working pretty well so far. > > hReview is a good example, because it can use an hCard to be the thing > reviewed, and an hCard for the reviewer. So you have multiple FNs, > PHOTOs, all over the place and it manages to get sorted out just fine, > it is just a matter of parsing rules. Do we have several examples of hReviews that use hCards that contain multiple FNs and PHOTOs in the wild? -- manu From martin at weborganics.co.uk Tue Aug 7 15:03:03 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Tue Aug 7 15:01:32 2007 Subject: [uf-new] hAudio ISSUE #1: image-summary is redundant In-Reply-To: <21e770780708071231o391733b8r26f83067da4e0912@mail.gmail.com> References: <46B689CE.7070804@digitalbazaar.com> <1186397079.16632.19.camel@localhost.localdomain> <21e770780708070250h5cd96f5epc993d4c890ed3646@mail.gmail.com> <1186508693.10531.6.camel@localhost.localdomain> <84ED5BDD-1309-4B62-A3C2-7F16984325A8@makedatamakesense.com> <21e770780708071231o391733b8r26f83067da4e0912@mail.gmail.com> Message-ID: <1186524183.10531.26.camel@localhost.localdomain> On Tue, 2007-08-07 at 19:31 +0000, Brian Suda wrote: > On 8/7/07, Scott Reynen wrote: > > On Aug 7, 2007, at 11:44 AM, Martin McEvoy wrote: > > > > > Do you think the use of PHOTO may interfere with the hCard that is > > > already part of the hAudio proposal, Suppose I wanted to mark up my > > > hAudio hcard's with Photos of the band members? isn't that breaking > > > the > > > don't repeat yourself rule? > > --- like scott was saying, when developing the format, you can also > define the parsing rules. If you look at hReview, it uses hCards and > PHOTO. To disambinguate the two it is a matter of PHOTO inside an > hCard and PHOTO not inside an hCard. This is already something that > hReview deals with and that has been working pretty well so far. > > hReview is a good example, because it can use an hCard to be the thing > reviewed, and an hCard for the reviewer. So you have multiple FNs, > PHOTOs, all over the place and it manages to get sorted out just fine, > it is just a matter of parsing rules. Right! Im afraid I am not an expert when it comes to parsing rules :) I'd just like to be happy that there wouldn't be any issues using PHOTO in hAudio, And I would like to be sure that PHOTO is an accurate term when describing an artistic representation or summary of a piece of Music. The more I think about it the more uncomfortable I am with using simply PHOTO it seems to fall short of what we are actually trying to describe, It seems like a very loose term? Martin > > -brian > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2171 bytes Desc: not available Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070807/50289986/smime.bin From martin at weborganics.co.uk Wed Aug 8 07:20:40 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 8 07:19:15 2007 Subject: [uf-new] hAlbum Microformat brainstorming and proposal pages created In-Reply-To: <46B69CEF.40303@digitalbazaar.com> References: <46B69CEF.40303@digitalbazaar.com> Message-ID: <1186582840.16297.5.camel@localhost.localdomain> Is A hAlbum Microformat necessary? I would much prefer to expand hAudio a little to include tracks There Is an example here to try and explain what I mean [1]. [1] http://weborganics.co.uk/files/hAudio.html Thanks Martin On Mon, 2007-08-06 at 00:00 -0400, Manu Sporny wrote: > To get ready for the hAlbum Microformat discussion, separate > brainstorming and proposal pages have been created. > > hAlbum was cleaved from hAudio several months ago because it was > complicating issues. The decision was made to tackle audio collections > at a later date, thus we dropped all discussion at that time. The plan > is to revive discussion on hAlbum now that we've gone through an > implementation cycle with hAudio. > > The new pages can be found here... they are rough, but should outline > what we're planning on discussing. hAlbum borrows very heavily from hAudio: > > http://microformats.org/wiki/audio-album-brainstorming > http://microformats.org/wiki/audio-album-proposal > > Once some of the hAudio issues have been addressed we can move on to > hAlbum... the page is up if people want to make changes, or start > commenting on the audio-album-issues page. > > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2171 bytes Desc: not available Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070808/8fe3663a/smime-0001.bin From brian.suda at gmail.com Wed Aug 8 07:35:44 2007 From: brian.suda at gmail.com (Brian Suda) Date: Wed Aug 8 07:35:47 2007 Subject: [uf-new] hAlbum Microformat brainstorming and proposal pages created In-Reply-To: <1186582840.16297.5.camel@localhost.localdomain> References: <46B69CEF.40303@digitalbazaar.com> <1186582840.16297.5.camel@localhost.localdomain> Message-ID: <21e770780708080735l68f393aek88f5ae04121042a5@mail.gmail.com> On 8/8/07, Martin McEvoy wrote: > Is A hAlbum Microformat necessary? > I would much prefer to expand hAudio a little to include tracks --- from my understanding, hAudio is ONLY about individual tracks, an hAlbum, would be a collection of hAudios. Given, that i would prefer to let the current hAudio work be expanded to include collections, and you see the current proposal of hAudio to be expanded to include individual instances, i think we have a serious communications and understanding of what this microformat is actually trying to accomplish. All this time now for the past months, some people have been talking about tracks, while others hear albums, now we talk about albums and some people want tracks! We have been talking past each other and "voting" on issues that people don't understand, or understand only in their context this whole time. we need to all get on the same page before we can properly discuss these ideas further. -brian -- brian suda http://suda.co.uk From msporny at digitalbazaar.com Wed Aug 8 08:10:48 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Aug 8 08:10:52 2007 Subject: [uf-new] hAudio ISSUE #1: image-summary is redundant In-Reply-To: <1186524183.10531.26.camel@localhost.localdomain> References: <46B689CE.7070804@digitalbazaar.com> <1186397079.16632.19.camel@localhost.localdomain> <21e770780708070250h5cd96f5epc993d4c890ed3646@mail.gmail.com> <1186508693.10531.6.camel@localhost.localdomain> <84ED5BDD-1309-4B62-A3C2-7F16984325A8@makedatamakesense.com> <21e770780708071231o391733b8r26f83067da4e0912@mail.gmail.com> <1186524183.10531.26.camel@localhost.localdomain> Message-ID: <46B9DCF8.4030304@digitalbazaar.com> Martin McEvoy wrote: > Right! Im afraid I am not an expert when it comes to parsing rules :) > I'd just like to be happy that there wouldn't be any issues using PHOTO > in hAudio, And I would like to be sure that PHOTO is an accurate term > when describing an artistic representation or summary of a piece of > Music. The more I think about it the more uncomfortable I am with using > simply PHOTO it seems to fall short of what we are actually trying to > describe, It seems like a very loose term? Martin, you're correct - it is a looser term than image-summary. The arguments for PHOTO are: - It is a pre-existing class, we wouldn't have to invent a new class (image-summary). Re-use is good. - It is less accurate, but still accurate enough to convey the meaning of what it is ("a photograph/image of the hAudio in question") - It shouldn't conflict when implemented properly... and if it does, we can always change it back. Since we're also implementing the parser for hAudio, I think that using PHOTO is do-able for the majority of the examples that we've analyzed to date. I say we give it a shot... we have enough of an understanding of the parsing requirements to say that "it should be possible to disambiguate hcard/haudio PHOTOs in the parser". So far, there are 3 votes for PHOTO (Brian, myself, and I'm counting you Scott, as you didn't seem opposed to the idea of PHOTO), 1 opposed. It would help if others would weight in on this so we can put the issue to rest. -- manu From msporny at digitalbazaar.com Wed Aug 8 08:14:34 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Aug 8 08:14:37 2007 Subject: [uf-new] hAudio ISSUE #3: published-date is redundant In-Reply-To: <21e770780708070230w79507b88ufd45e9ed86eb08a1@mail.gmail.com> References: <46B68BB2.105@digitalbazaar.com> <21e770780708070230w79507b88ufd45e9ed86eb08a1@mail.gmail.com> Message-ID: <46B9DDDA.30804@digitalbazaar.com> Brian Suda wrote: > If you look at the wiki page which lists our classes, > http://microformats.org/wiki/classes > you will see that we have several ways of specifying a date > hCard uses REV, which is the REVISION date > hCalendar uses LAST-MODIFIED, the time the calendar was last changes > hAtom uses UPDATED and PUBLISHED > > I agree it should use the ISO date-time pattern every other date > format is using. So, we've got 3 votes for PUBLISHED using date-time pattern, none opposed. I'd like some others to weigh in before we resolve this. A simple AGREE/+1 would suffice, or DISAGREE with logical argument. -- manu From msporny at digitalbazaar.com Wed Aug 8 08:17:10 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Aug 8 08:17:14 2007 Subject: [uf-new] hAudio ISSUE #1: image-summary is redundant In-Reply-To: <21e770780708070250h5cd96f5epc993d4c890ed3646@mail.gmail.com> References: <46B689CE.7070804@digitalbazaar.com> <1186397079.16632.19.camel@localhost.localdomain> <21e770780708070250h5cd96f5epc993d4c890ed3646@mail.gmail.com> Message-ID: <46B9DE76.9000400@digitalbazaar.com> Brian Suda wrote: > Also, the current spec says that this MUST use an , i would say > this should be changed to SHOULD, not MUST. There could be cases were > you might want to simply give the URL to the image or use an AREA or > OBJECT element. Or possibly use other elements in RSS. We should avoid > mandating how/where to encoding specific microformat properties. Sure - I wouldn't be opposed to changing the language from MUST to SHOULD. Is there any opposition to this change? Speak up now, please... AGREE/+1 for the change, or DISAGREE with a logical argument. -- manu From msporny at digitalbazaar.com Wed Aug 8 08:59:01 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Aug 8 08:59:06 2007 Subject: [uf-new] hAlbum Microformat brainstorming and proposal pages created In-Reply-To: <21e770780708070310k5bb653b2y9217bce57409b89e@mail.gmail.com> References: <46B69CEF.40303@digitalbazaar.com> <21e770780708070310k5bb653b2y9217bce57409b89e@mail.gmail.com> Message-ID: <46B9E845.2070406@digitalbazaar.com> Brian Suda wrote: > On 8/6/07, Manu Sporny wrote: >> The new pages can be found here... they are rough, but should outline >> what we're planning on discussing. hAlbum borrows very heavily from hAudio: > > --- with the exception of TRACKS an Album has all the identical > properties of the audio proposal. hAlbum also has ALBUM-TITLE, which differs from AUDIO-TITLE in hAudio. There are two differences between hAlbum and hAudio. >> Once some of the hAudio issues have been addressed we can move on to >> hAlbum... the page is up if people want to make changes, or start >> commenting on the audio-album-issues page. > > --- i'm slightly confused at the point of Albums being something different? This goes back to discussions we have previously had on sets, collections, playlists, podcasts and albums [1][2][3][4][5][6][7]. From what I remember, we decided that generic collections shouldn't be discussed and we should focus on the problem at hand: podcasts, playlists and albums. More specifically, we should focus on albums and audio recordings. In an attempt to make the problem simpler, hAudio became the markup for single audio recordings. How we handled albums was TBD. Since we don't want to bloat hAudio... creating hAlbum allows us to re-use most of hAudio, only introduce 1-2 new class names, and solve the album problem. In other words - if you want to talk about single audio recordings, use hAudio. If you want to talk about an audio album, use hAlbum + hAudio. > (Please add the following to the issues pages of your choice) > What happens when you have 10 tracks all reporting to be from > different CDs, different artists, different album art, all .99cents. > Then thoses are inside an hAlbum which is $5.99 (not the same price > summed - this is ok, buy as a whole album or buy individually, like > iTunes) and you have different artwork at the album level and > different artists? You mean, like this? http://microformats.org/wiki/audio-album-proposal#Various_Artists_Album_Example > Wouldn?t it be easier to just NOT have hAlbum, and simply add > something to hAudio called "collection" or something? then all TRACKS > on a page with the same value for COLLECTION could suffice? that fails > to get you an OVERALL price for an album, but then maybe in your > hAudio, simply make the track name optional... so if there is NO track > name, but a collection name, then all the attributes are about the > collection? I think this complicates matters. All of a sudden, hAudio isn't just about individual audio records, but collections of audio recordings. We tried generic collections before and we tried mixing the two concepts, neither of those strategies seemed to work in the past[1][2][3][4][5][6][7]. > Do we need a whole separate format to markup the exact same data twice? Why do you say it's the exact same data? My assumption is that the parsers would inherit any properties defined in hAlbum to all tracks that are a part of that album. So, artist name is only specified once in hAlbum, it doesn't need to be specified for each track. This is how the majority of examples that we collected publish this sort of data. The artist is mentioned once at the hAlbum level, and it is assumed that each track listed on the page is a part of the previously stated album. -- manu [1]http://microformats.org/discuss/mail/microformats-new/2007-April/000152.html [2]http://microformats.org/discuss/mail/microformats-new/2007-April/000183.html [3]http://microformats.org/discuss/mail/microformats-new/2007-April/000227.html [4]http://microformats.org/discuss/mail/microformats-new/2007-June/000449.html [5]http://microformats.org/discuss/mail/microformats-new/2007-June/000449.html [6]http://microformats.org/discuss/mail/microformats-new/2007-June/000451.html [7]http://microformats.org/discuss/mail/microformats-new/2007-June/000482.html From msporny at digitalbazaar.com Wed Aug 8 09:06:27 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Aug 8 09:06:31 2007 Subject: [uf-new] hAlbum Microformat brainstorming and proposal pages created In-Reply-To: <1186582840.16297.5.camel@localhost.localdomain> References: <46B69CEF.40303@digitalbazaar.com> <1186582840.16297.5.camel@localhost.localdomain> Message-ID: <46B9EA03.9090703@digitalbazaar.com> Martin McEvoy wrote: > Is A hAlbum Microformat necessary? I think hAlbum is necessary if we want to keep the simplicity of hAudio. hAudio is used to describe individual recordings. hAlbum is used to describe a collection of hAudios that are released as an album (CD, LP, collection of songs, etc.) We only gain complexity if we combine the two. It will also be easier to discuss each as separate concepts. If we decide to merge them after we have all of the concepts of hAlbum sorted out, we can definitely do that. We don't necessarily know what the hAlbum beast looks like yet, so I'd rather keep discussion separate for now. There will be time and effort put towards merging the two in the future if it makes sense. This is an attempt to solve a smaller problem first (hAlbum). -- manu From brian.suda at gmail.com Wed Aug 8 09:27:21 2007 From: brian.suda at gmail.com (Brian Suda) Date: Wed Aug 8 09:27:25 2007 Subject: [uf-new] hAudio ISSUE #1: image-summary is redundant In-Reply-To: <46B9DCF8.4030304@digitalbazaar.com> References: <46B689CE.7070804@digitalbazaar.com> <1186397079.16632.19.camel@localhost.localdomain> <21e770780708070250h5cd96f5epc993d4c890ed3646@mail.gmail.com> <1186508693.10531.6.camel@localhost.localdomain> <84ED5BDD-1309-4B62-A3C2-7F16984325A8@makedatamakesense.com> <21e770780708071231o391733b8r26f83067da4e0912@mail.gmail.com> <1186524183.10531.26.camel@localhost.localdomain> <46B9DCF8.4030304@digitalbazaar.com> Message-ID: <21e770780708080927s691c0473pe3453e958a624a2d@mail.gmail.com> On 8/8/07, Manu Sporny wrote: > So far, there are 3 votes for PHOTO (Brian, myself, and I'm counting you > Scott, as you didn't seem opposed to the idea of PHOTO), 1 opposed. It > would help if others would weight in on this so we can put the issue to > rest. --- firstly, the original message was sent 2 days ago. The fact that others have not given their opinion on this topic probably has to do with a few factors. 1) 2 days from the original message till now is not enough time for readers to weed through the volume of emails and do the background reading needed. 2) people don't have an opinion 3) people simply don't care and an audio media format is not a interest to them. This could be why there are so many OTHER formats that haven't been worked in months. Someone brought-up the idea. It was floated around, never gained traction and it was filed away until it could be used later. At this time, the discussion on this topic has been conducted by a small sub-set of the community. This is certainly not the best way to gather input or opinions - we have 100% support to use PHOTO, based on 2 people?s yes's and and an assumed yes. Does anyone else think that is anemic at best? (i doubt i'll even get much or a response) maybe it is time to take a breath and let people digest some of the issues, ideas, uses, mark-up and all the background reading for awhile. Otherwise it will be the same 3-4 people talking to each other about other issues and we won't really go anywhere. -brian -- brian suda http://suda.co.uk From msporny at digitalbazaar.com Wed Aug 8 09:40:08 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Aug 8 09:40:14 2007 Subject: [uf-new] Songbird/POTI requirements for hAudio Message-ID: <46B9F1E8.9020006@digitalbazaar.com> We've been having a lively discussion with the folks at Songbird about implementing hAudio: http://www.songbirdnest.com/about They have the following issues with Microformats/hAudio: - They don't think that publishers are going to want to visibly publish as much data as Songbird needs to display via its UI. They would like Microformats to reconsider its "no hidden data" policy. - Ideally, they want ID3v2.3 for the web. - The bare minimum requirement is that hAudio/hAlbum supports all ID3v1.1 tags. Here is the current status of hAudio meeting Songbird's minimum requirements: Song Title : audio-title (hAudio) Artist : contributor (hAudio/hAlbum) Album : album-title (PROPOSED in hAlbum) Year : published (hAudio/hAlbum) Comment : summary (PROPOSED in hAudio/hAlbum) Genre : category Album Track : track-number (FUTURE PROPOSAL for hAudio/hAlbum) If we can't deliver on that as a community - they won't have much interest in implementing Microformats in Songbird. -- manu From scott at makedatamakesense.com Wed Aug 8 10:34:28 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed Aug 8 10:34:38 2007 Subject: [uf-new] Songbird/POTI requirements for hAudio In-Reply-To: <46B9F1E8.9020006@digitalbazaar.com> References: <46B9F1E8.9020006@digitalbazaar.com> Message-ID: <80AE79A7-9763-47A7-8B46-DB280EDFDC18@makedatamakesense.com> On Aug 8, 2007, at 10:40 AM, Manu Sporny wrote: > If we can't deliver on that as a community - they won't have much > interest in implementing Microformats in Songbird. We *can* deliver on that, but that doesn't mean we *should*. Support by any specific tool should always be a lower priority than covering what people are commonly publishing as simply as possible. It sounds like Songbird has very different priorities than microformats. That's okay. -- Scott Reynen MakeDataMakeSense.com From msporny at digitalbazaar.com Wed Aug 8 10:52:25 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Aug 8 10:52:27 2007 Subject: [uf-new] Songbird/POTI requirements for hAudio In-Reply-To: <80AE79A7-9763-47A7-8B46-DB280EDFDC18@makedatamakesense.com> References: <46B9F1E8.9020006@digitalbazaar.com> <80AE79A7-9763-47A7-8B46-DB280EDFDC18@makedatamakesense.com> Message-ID: <46BA02D9.7040708@digitalbazaar.com> Scott Reynen wrote: >> If we can't deliver on that as a community - they won't have much >> interest in implementing Microformats in Songbird. > > We *can* deliver on that, but that doesn't mean we *should*. Support by > any specific tool should always be a lower priority than covering what > people are commonly publishing as simply as possible. It sounds like > Songbird has very different priorities than microformats. That's okay. I should clarify - I think that we can deliver to meet their needs AND stay true to the Microformats process and philosophy. Everything that they need is backed up and supported by all of the examples we have collected. It's a win-win for both uF and Songbird :) -- manu From martin at weborganics.co.uk Wed Aug 8 11:34:21 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 8 11:32:54 2007 Subject: [uf-new] hAudio ISSUE #1: image-summary is redundant In-Reply-To: <46B9DE76.9000400@digitalbazaar.com> References: <46B689CE.7070804@digitalbazaar.com> <1186397079.16632.19.camel@localhost.localdomain> <21e770780708070250h5cd96f5epc993d4c890ed3646@mail.gmail.com> <46B9DE76.9000400@digitalbazaar.com> Message-ID: <1186598061.16297.6.camel@localhost.localdomain> On Wed, 2007-08-08 at 11:17 -0400, Manu Sporny wrote: > Brian Suda wrote: > > Also, the current spec says that this MUST use an , i would say > > this should be changed to SHOULD, not MUST. There could be cases were > > you might want to simply give the URL to the image or use an AREA or > > OBJECT element. Or possibly use other elements in RSS. We should avoid > > mandating how/where to encoding specific microformat properties. > > Sure - I wouldn't be opposed to changing the language from MUST to > SHOULD. Is there any opposition to this change? Speak up now, please... > AGREE/+1 for the change, or DISAGREE with a logical argument. > > -- manu AGREE/+1 > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2171 bytes Desc: not available Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070808/58368861/smime.bin From tantek at cs.stanford.edu Wed Aug 8 11:55:15 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Wed Aug 8 11:55:15 2007 Subject: [uf-new] hAudio ISSUE #3: published-date is redundant In-Reply-To: <46B9DDDA.30804@digitalbazaar.com> Message-ID: On 8/8/07 8:14 AM, "Manu Sporny" wrote: > Brian Suda wrote: >> If you look at the wiki page which lists our classes, >> http://microformats.org/wiki/classes >> you will see that we have several ways of specifying a date >> hCard uses REV, which is the REVISION date >> hCalendar uses LAST-MODIFIED, the time the calendar was last changes >> hAtom uses UPDATED and PUBLISHED >> >> I agree it should use the ISO date-time pattern every other date >> format is using. > > So, we've got 3 votes for PUBLISHED using date-time pattern, none > opposed. I'd like some others to weigh in before we resolve this. A > simple AGREE/+1 would suffice, or DISAGREE with logical argument. In either case, could folks please indicate their agreement or not on the wiki page for the proposal with +/-1, their name, and any additional commentary/explanation for the vote? Let's keep track of content/state on the wiki, not in email please. Thanks, Tantek From martin at weborganics.co.uk Wed Aug 8 12:02:12 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 8 12:00:51 2007 Subject: [uf-new] hAlbum Microformat brainstorming and proposal pages created In-Reply-To: <21e770780708080735l68f393aek88f5ae04121042a5@mail.gmail.com> References: <46B69CEF.40303@digitalbazaar.com> <1186582840.16297.5.camel@localhost.localdomain> <21e770780708080735l68f393aek88f5ae04121042a5@mail.gmail.com> Message-ID: <1186599732.16297.22.camel@localhost.localdomain> On Wed, 2007-08-08 at 14:35 +0000, Brian Suda wrote: > On 8/8/07, Martin McEvoy wrote: > > Is A hAlbum Microformat necessary? > > I would much prefer to expand hAudio a little to include tracks > > --- from my understanding, hAudio is ONLY about individual tracks, an > hAlbum, would be a collection of hAudios. correct.. > > Given, that i would prefer to let the current hAudio work be expanded > to include collections, and you see the current proposal of hAudio to > be expanded to include individual instances, i think we have a serious > communications and understanding of what this microformat is actually > trying to accomplish. No I don't think we do have a misunderstanding, I was just asking a question to the community "can we extend hAudio to suit the needs of hAlbum" the general consensus is No and that's OK with me but someone needs to ask just to clarify what is within the scope of this discussion. > > All this time now for the past months, some people have been talking > about tracks, while others hear albums, now we talk about albums and > some people want tracks! We have been talking past each other and > "voting" on issues that people don't understand, or understand only in > their context this whole time. ? > > we need to all get on the same page before we can properly discuss > these ideas further. Indeed we do. Martin > > -brian > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2171 bytes Desc: not available Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070808/01db5709/smime.bin From alexandrevandesande at gmail.com Thu Aug 9 04:10:25 2007 From: alexandrevandesande at gmail.com (Alexandre Van de Sande) Date: Thu Aug 9 04:10:29 2007 Subject: [uf-new] new html tags Message-ID: <8608a69a0708090410rd548febw5aba122d402c2789@mail.gmail.com> http://www.ibm.com/developerworks/library/x-html5/?ca=dgr-lnxw01NewHTML new html tags are coming in hml for. Those include semanticall-tags such as