From msporny at digitalbazaar.com Sat Nov 3 07:23:25 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sat Nov 3 07:25:05 2007 Subject: [uf-new] Closing outstanding hAudio issues In-Reply-To: <47293226.7050206@digitalbazaar.com> References: <47293226.7050206@digitalbazaar.com> Message-ID: <472C926D.2010508@digitalbazaar.com> Manu Sporny wrote: > The following hAudio issues have been resolved with the latest update to > the hAudio proposal (hAudio v0.8). If there are no objections, I'd like > to mark all of them as resolved. Seeing no objections, issues 2, 9, 10, 11 and 13 have been resolved. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk Launches World's First Open Music Recommendation Service http://blog.digitalbazaar.com/2007/09/09/bitmunk-music-recommendation/ From msporny at digitalbazaar.com Sat Nov 3 07:42:26 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sat Nov 3 07:44:05 2007 Subject: [uf-new] hAudio Specification Page is published Message-ID: <472C96E2.2030003@digitalbazaar.com> The hAudio Draft Specification has a new home: http://microformats.org/wiki/haudio We're working on an implementation in Operator and will start evangelizing hAudio use in the coming weeks. For those that are interested in hAudio, please have a look through the page and let us know if there are any outstanding issues with the current proposal. -- manu From martin at weborganics.co.uk Sat Nov 3 15:09:23 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 3 15:08:56 2007 Subject: [uf-new] hAudio Specification Page is published In-Reply-To: <472C96E2.2030003@digitalbazaar.com> References: <472C96E2.2030003@digitalbazaar.com> Message-ID: <1194131363.7646.10.camel@localhost.localdomain> On Sat, 2007-11-03 at 11:42 -0400, Manu Sporny wrote: > The hAudio Draft Specification has a new home: > > http://microformats.org/wiki/haudio Well done all Thanks Manu the: http://microformats.org/wiki/haudio-cheatsheet Has been updated to the hAudio 0.8 Draft For testing purposes http://weborganics.co.uk/haudio which has been used throughout the hAudio process has also been updated to Version 0.8 A new test case of hAudio in hAtom, designed to be a syndicated format similar to a podcast is available for testing: http://weborganics.co.uk/hypercast single static html file http://tools.microformatic.com/transcode/atom/hatom/http://weborganics.co.uk/hypercast/ Transformation into atom http://feeds.feedburner.com/microformats/HyperCast Transformation into a rss podcast via feedburner Thanks Martin McEvoy > > We're working on an implementation in Operator and will start > evangelizing hAudio use in the coming weeks. For those that are > interested in hAudio, please have a look through the page and let us > know if there are any outstanding issues with the current proposal. > > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From martin at weborganics.co.uk Sat Nov 3 16:53:31 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 3 16:53:03 2007 Subject: [uf-new] hAudio Specification Page is published In-Reply-To: <472C96E2.2030003@digitalbazaar.com> References: <472C96E2.2030003@digitalbazaar.com> Message-ID: <1194137611.8037.5.camel@localhost.localdomain> On Sat, 2007-11-03 at 11:42 -0400, Manu Sporny wrote: > The hAudio Draft Specification has a new home: > > http://microformats.org/wiki/haudio Just some minor points 1, http://microformats.org/wiki/haudio#Price should this not be... ? as per the Currency Proposal http://microformats.org/wiki/currency-proposal and 2. http://microformats.org/wiki/haudio#Item "...No sub-elements should be read from any hAudio contained in a track element" should read.. "...No sub-elements should be read from any hAudio contained in an item element" Thanks Martin > > We're working on an implementation in Operator and will start > evangelizing hAudio use in the coming weeks. For those that are > interested in hAudio, please have a look through the page and let us > know if there are any outstanding issues with the current proposal. > > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From lists at ben-ward.co.uk Sat Nov 3 17:07:16 2007 From: lists at ben-ward.co.uk (Ben Ward) Date: Sat Nov 3 17:07:25 2007 Subject: [uf-new] hAudio Specification Page is published In-Reply-To: <1194137611.8037.5.camel@localhost.localdomain> References: <472C96E2.2030003@digitalbazaar.com> <1194137611.8037.5.camel@localhost.localdomain> Message-ID: On 4 Nov 2007, at 00:53, Martin McEvoy wrote: > 1, > http://microformats.org/wiki/haudio#Price > > > > should this not be... > > ? > > as per the Currency Proposal > http://microformats.org/wiki/currency-proposal No. Should the currency microformat be completed, then that class name would be used in addition. As per existing patterns (such as class="author vcard" in hReview), you might end up with or something. My view is that with currency still being a proposal, it should not be used in examples. That risks causing confusion and may inadvertently push a sub-optimal currency pattern into mainstream usage without it going through the process. I'd like to see that simplified to the text form of price, ala: $14.00 Ben From lists at ben-ward.co.uk Sat Nov 3 17:34:43 2007 From: lists at ben-ward.co.uk (Ben Ward) Date: Sat Nov 3 17:34:48 2007 Subject: [uf-new] hAudio Examples (was: hAudio Specification Page is published) In-Reply-To: <472C96E2.2030003@digitalbazaar.com> References: <472C96E2.2030003@digitalbazaar.com> Message-ID: On 3 Nov 2007, at 15:42, Manu Sporny wrote: > The hAudio Draft Specification has a new home: > > http://microformats.org/wiki/haudio I've been through and edited the examples to fix issues with validation and incorrect closing tags. I have the following issues with them: ? class="price" should not include mark-up from a currency proposal. It could endorse, promote and spread use of mark-up that is later discarded as sub-optimal. I don't think the hAudio spec should advocate use of an unfinished microformat at all. ?1 should be sufficient for these examples at the moment. ? All uses of the ABBR pattern for dates and times should use hyphenated separators. We're still in an accessibility grey spot with regards to the whole thing, but it was noted that splitting dates with hyphens made it acceptable in some cases ("2007-11-03" over "20071103"). I don't know what the effect is of your new duration abbreviations. It's important that someone with access to the right equipment tests those expansions with assistive technology. If it's appropriate to hyphenate the expansions in the time formats, then they should be. ? I'm of the view that whilst use of HTML elements should be neutral wherever possible (SPAN, DIV), use of presentational elements such as BR should not feature in our examples. Some of the examples are using BR to change the presentation. These should be reworked somehow. Ben From lists at ben-ward.co.uk Sat Nov 3 17:41:54 2007 From: lists at ben-ward.co.uk (Ben Ward) Date: Sat Nov 3 17:42:03 2007 Subject: [uf-new] [hAudio] Contributor as an hCard Message-ID: <46CCA82D-BC2F-4A44-928D-E4140286D067@ben-ward.co.uk> On 3 Nov 2007, at 15:42, Manu Sporny wrote: > The hAudio Draft Specification has a new home: > > http://microformats.org/wiki/haudio Contributor: ?The contents of the element should include a valid hCard Microformat.? Results in: This is different from the pattern used in hReview for reviewer, which results in: The hReview form is superior, and already in use. I suggest the hAudio wording be changed to say: "A contributor _should_ be an hCard" Ben From lists at ben-ward.co.uk Sat Nov 3 17:54:23 2007 From: lists at ben-ward.co.uk (Ben Ward) Date: Sat Nov 3 17:54:27 2007 Subject: [uf-new] =?iso-8859-1?q?=5BhAudio=5D_fn_=5For=5F=A0album?= Message-ID: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> Regarding the ?fn and/or album? pattern in hAudio. I'm not convinced this is a good pattern, and it behaves differently to the existing pattern in hCard. Currently, you can produce hAudio with an 'fn', or with an 'album' or with both. However, when compared to hCard ? say the 'fn' and 'org' fields, where organisation name is often also the fn ? hCard takes a more verbose, and in my opinion more consistent and understandable pattern. So in hAudio:
Bodysnatchers
In Rainbows
in hCard:
Thom Yorke
Radiohead
In both hAudio and hCard there is always a formatted name. hCard sets a more verbose and easier to follow precedent of always including ?fn? ? not optimising ?fn? from ?org? or anything more complex. I think hAudio would be clearer to adopt the same pattern, so the second (album) snippet would become:
In Rainbows
Ben From julian at julianstahnke.com Sat Nov 3 18:00:12 2007 From: julian at julianstahnke.com (Julian Stahnke) Date: Sat Nov 3 18:00:38 2007 Subject: =?ISO-8859-1?Q?Re:_[uf-new]_[hAudio]_fn_=5For=5F=A0album?= In-Reply-To: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> Message-ID: <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> > I think hAudio would be clearer to adopt the same pattern, so the > second (album) snippet would become: > >
> In Rainbows >
I second that. Makes more sense, is more consistent. Also makes it easier to write a definition for Operator :D From martin at weborganics.co.uk Sat Nov 3 18:06:21 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 3 18:05:54 2007 Subject: [uf-new] hAudio Examples (was: hAudio Specification Page is published) In-Reply-To: References: <472C96E2.2030003@digitalbazaar.com> Message-ID: <1194141981.8037.38.camel@localhost.localdomain> On Sun, 2007-11-04 at 01:34 +0000, Ben Ward wrote: > On 3 Nov 2007, at 15:42, Manu Sporny wrote: > > The hAudio Draft Specification has a new home: > > > > http://microformats.org/wiki/haudio > > I've been through and edited the examples to fix issues with > validation and incorrect closing tags. > > I have the following issues with them: > > ? class="price" should not include mark-up from a currency proposal. > It could endorse, promote and spread use of mark-up that is later > discarded as sub-optimal. I don't think the hAudio spec should > advocate use of an unfinished microformat at all. > > ?1 should be sufficient for these examples > at the moment. Much Like the hListing proposal http://microformats.org/wiki/hlisting-proposal#Simple_Listing Agreed > > ? All uses of the ABBR pattern for dates and times should use > hyphenated separators. We're still in an accessibility grey spot with > regards to the whole thing, but it was noted that splitting dates > with hyphens made it acceptable in some cases ("2007-11-03" over > "20071103"). I don't know what the effect is of your new duration > abbreviations. It's important that someone with access to the right > equipment tests those expansions with assistive technology. If it's > appropriate to hyphenate the expansions in the time formats, then > they should be. My Preference for now is simply to use 4:44 which I believe is an ISO 8601 time format http://en.wikipedia.org/wiki/ISO_8601#General_principles any use of the abbr design pattern I think should be kept to a minimal in the creation of hAudio, or any new Microformat for that matter. > > ? I'm of the view that whilst use of HTML elements should be neutral > wherever possible (SPAN, DIV), use of presentational elements such as > BR should not feature in our examples. Some of the examples are using > BR to change the presentation. These should be reworked somehow. > > Ben Thanks Martin > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From martin at weborganics.co.uk Sat Nov 3 18:08:32 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 3 18:08:03 2007 Subject: [uf-new] [hAudio] fn =?ISO-8859-1?Q?=5For=5F=A0album?= In-Reply-To: <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> Message-ID: <1194142112.8037.40.camel@localhost.localdomain> On Sun, 2007-11-04 at 02:00 +0000, Julian Stahnke wrote: > > I think hAudio would be clearer to adopt the same pattern, so the > > second (album) snippet would become: > > > >
> > In Rainbows > >
> > I second that. Makes more sense, is more consistent. Also makes it > easier to write a definition for Operator :D Agreed +1 Thanks Martin > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From martin at weborganics.co.uk Sat Nov 3 18:10:23 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 3 18:09:54 2007 Subject: [uf-new] [hAudio] Contributor as an hCard In-Reply-To: <46CCA82D-BC2F-4A44-928D-E4140286D067@ben-ward.co.uk> References: <46CCA82D-BC2F-4A44-928D-E4140286D067@ben-ward.co.uk> Message-ID: <1194142223.8037.42.camel@localhost.localdomain> On Sun, 2007-11-04 at 01:41 +0000, Ben Ward wrote: > do you mean this should be changed to ? Thanks Martin From martin at weborganics.co.uk Sat Nov 3 18:12:36 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 3 18:12:07 2007 Subject: [uf-new] [hAudio] fn =?ISO-8859-1?Q?=5For=5F=A0album?= In-Reply-To: <1194142112.8037.40.camel@localhost.localdomain> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> Message-ID: <1194142356.8037.45.camel@localhost.localdomain> On Sun, 2007-11-04 at 02:08 +0000, Martin McEvoy wrote: > On Sun, 2007-11-04 at 02:00 +0000, Julian Stahnke wrote: > > > I think hAudio would be clearer to adopt the same pattern, so the > > > second (album) snippet would become: > > > > > >
> > > In Rainbows > > >
> > > > I second that. Makes more sense, is more consistent. Also makes it > > easier to write a definition for Operator :D > > Agreed +1 > > Thanks and can also be expressed as ?
In Rainbows
Thanks Martin > > Martin > > _______________________________________________ > > microformats-new mailing list > > microformats-new@microformats.org > > http://microformats.org/mailman/listinfo/microformats-new From julian at julianstahnke.com Sat Nov 3 18:49:10 2007 From: julian at julianstahnke.com (Julian Stahnke) Date: Sat Nov 3 18:49:14 2007 Subject: =?ISO-8859-1?Q?Re:_[uf-new]_[hAudio]_fn_=5For=5F=A0album?= In-Reply-To: <1194142356.8037.45.camel@localhost.localdomain> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> Message-ID: <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> > and can also be expressed as ? > >
> In Rainbows >
No, that?d be a track. From martin at weborganics.co.uk Sat Nov 3 18:56:23 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 3 18:55:54 2007 Subject: [uf-new] hAudio Examples (was: hAudio Specification Page is published) In-Reply-To: <1194141981.8037.38.camel@localhost.localdomain> References: <472C96E2.2030003@digitalbazaar.com> <1194141981.8037.38.camel@localhost.localdomain> Message-ID: <1194144983.9212.9.camel@localhost.localdomain> On Sun, 2007-11-04 at 02:06 +0000, Martin McEvoy wrote: > On Sun, 2007-11-04 at 01:34 +0000, Ben Ward wrote: > > On 3 Nov 2007, at 15:42, Manu Sporny wrote: > > > The hAudio Draft Specification has a new home: > > > > > > http://microformats.org/wiki/haudio > > > > I've been through and edited the examples to fix issues with > > validation and incorrect closing tags. > > > > I have the following issues with them: > > > > ? class="price" should not include mark-up from a currency proposal. > > It could endorse, promote and spread use of mark-up that is later > > discarded as sub-optimal. I don't think the hAudio spec should > > advocate use of an unfinished microformat at all. > > > > ?1 should be sufficient for these examples > > at the moment. > > Much Like the hListing proposal > http://microformats.org/wiki/hlisting-proposal#Simple_Listing > > Agreed In principal although I am unsure of when the proposal adopted the use of class="price" as It was previously agreed that we use the currency proposal http://microformats.org/discuss/mail/microformats-new/2007-June/000563.html Although I am not sure if the proposal has changed since then Maybe someone can point out when? Thanks Martin > > > > > ? All uses of the ABBR pattern for dates and times should use > > hyphenated separators. We're still in an accessibility grey spot with > > regards to the whole thing, but it was noted that splitting dates > > with hyphens made it acceptable in some cases ("2007-11-03" over > > "20071103"). I don't know what the effect is of your new duration > > abbreviations. It's important that someone with access to the right > > equipment tests those expansions with assistive technology. If it's > > appropriate to hyphenate the expansions in the time formats, then > > they should be. > > My Preference for now is simply to use > > 4:44 > > which I believe is an ISO 8601 time format > http://en.wikipedia.org/wiki/ISO_8601#General_principles > > any use of the abbr design pattern I think should be kept to a minimal > in the creation of hAudio, or any new Microformat for that matter. > > > > > ? I'm of the view that whilst use of HTML elements should be neutral > > wherever possible (SPAN, DIV), use of presentational elements such as > > BR should not feature in our examples. Some of the examples are using > > BR to change the presentation. These should be reworked somehow. > > > > Ben > > Thanks > > Martin > > > > > > _______________________________________________ > > microformats-new mailing list > > microformats-new@microformats.org > > http://microformats.org/mailman/listinfo/microformats-new From martin at weborganics.co.uk Sat Nov 3 18:58:43 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 3 18:58:13 2007 Subject: [uf-new] [hAudio] fn =?ISO-8859-1?Q?=5For=5F=A0album?= In-Reply-To: <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> Message-ID: <1194145123.9212.12.camel@localhost.localdomain> On Sun, 2007-11-04 at 02:49 +0000, Julian Stahnke wrote: > > and can also be expressed as ? > > > >
> > In Rainbows > >
> > No, that?d be a track. Are you sure? http://microformats.org/wiki/audio-info-proposal#Multi-part_Podcast_Example something else that need looking at ? Thanks Martin From scott at makedatamakesense.com Sat Nov 3 19:09:06 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Sat Nov 3 19:09:17 2007 Subject: =?WINDOWS-1252?Q?Re:_[uf-new]_[hAudio]_fn_=5For=5F=A0album?= In-Reply-To: <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> Message-ID: <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> On Nov 3, 2007, at 8:49 PM, Julian Stahnke wrote: >>
>> In Rainbows >>
> > No, that?d be a track. That would be an audio recording. It may be a track, or an album, or something else entirely, but there's not enough information in the markup to determine anything more than it's an audio recording. -- Scott Reynen MakeDataMakeSense.com From martin at weborganics.co.uk Sat Nov 3 19:23:11 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 3 19:22:43 2007 Subject: [uf-new] [hAudio] fn =?ISO-8859-1?Q?=5For=5F=A0album?= In-Reply-To: <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> Message-ID: <1194146591.9573.1.camel@localhost.localdomain> On Sat, 2007-11-03 at 21:09 -0600, Scott Reynen wrote: > ...It may be a track, or an album, or > something else entirely, but there's not enough information in the > markup to determine anything more than it's an audio recording. A good description maybe this can be added to the wiki? Thanks Martin From martin at weborganics.co.uk Sat Nov 3 20:05:57 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 3 20:05:34 2007 Subject: [uf-new] [hAudio] fn =?ISO-8859-1?Q?=5For=5F=A0album?= In-Reply-To: <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> Message-ID: <1194149157.9573.37.camel@localhost.localdomain> On Sat, 2007-11-03 at 21:09 -0600, Scott Reynen wrote: > On Nov 3, 2007, at 8:49 PM, Julian Stahnke wrote: > > >>
> >> In Rainbows > >>
> > > > No, that?d be a track. > > > That would be an audio recording. It may be a track, or an album, or > something else entirely, but there's not enough information in the > markup to determine anything more than it's an audio recording. Wasn't there a discussion some time back on WHY we shouldn't clobber the fn attribute ie: "existing uf's are scopless", and It will cause issues with existing uF's, and a "superfluous 'fn' detected" http://microformats.org/discuss/mail/microformats-new/2007-June/000575.html David Janes also pointed out that: "..."fn" isn't available for use (unless "item" or similar is injected, as mentioned earlier in this thread)" http://microformats.org/discuss/mail/microformats-new/2007-June/000576.html this means that if "fn" exists in a class on its own then it must be wrapped in "item" or some similar mechanism eg:
In Rainbows
hence the decision was to use "audio-title" as this wouldn't interfere with existing uF's and make the "audio-title" class name directly attributed as the main hAudio title and wouldn't need heavy markup like the above? the decision to use "fn album" causes concern for me and is unclear, I understand that hAudio uses this mechanism to suggest fn hAudio type seems a bit rushed and I don't think that this proposal warranted an adoption from "audio-title" but it seems every one supported it, so there you go as far as I can see we created a new microformat "album" instead of "audio-title". Does this also mean that all haudio must be regarded as an album? how do we state otherwise? Anyway Scott I don't think that anyone exactly agrees with me on the list, so disregard the above :) just my 2 pence worth. > > -- > Scott Reynen > MakeDataMakeSense.com > > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From martin at weborganics.co.uk Sat Nov 3 20:14:53 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 3 20:14:25 2007 Subject: [uf-new] [hAudio] fn =?ISO-8859-1?Q?=5For=5F=A0album?= In-Reply-To: <1194149157.9573.37.camel@localhost.localdomain> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194149157.9573.37.camel@localhost.localdomain> Message-ID: <1194149693.9781.4.camel@localhost.localdomain> Scott You were a solid supporter of using "audio-title" and helped make the decision NOT to use FN "...We can't both re-use property names and ignore the context of those property names. My dog's FN is not my FN, and if the only way for me to make that clear is to use class="pet-name" instead of FN, that's what will happen." http://microformats.org/discuss/mail/microformats-new/2007-June/000581.html ? What changed your mind ?, this was the statement that made us support the use of "audio-title" Thanks Martin On Sun, 2007-11-04 at 04:06 +0000, Martin McEvoy wrote: > On Sat, 2007-11-03 at 21:09 -0600, Scott Reynen wrote: > > On Nov 3, 2007, at 8:49 PM, Julian Stahnke wrote: > > > > >>
> > >> In Rainbows > > >>
> > > > > > No, that?d be a track. > > > > > > That would be an audio recording. It may be a track, or an album, or > > something else entirely, but there's not enough information in the > > markup to determine anything more than it's an audio recording. > > Wasn't there a discussion some time back on WHY we shouldn't clobber the > fn attribute ie: "existing uf's are scopless", and It will cause issues > with existing uF's, and a "superfluous 'fn' detected" > http://microformats.org/discuss/mail/microformats-new/2007-June/000575.html > > David Janes also pointed out that: > "..."fn" isn't available for use (unless "item" or similar is injected, > as > mentioned earlier in this thread)" > http://microformats.org/discuss/mail/microformats-new/2007-June/000576.html > > this means that if "fn" exists in a class on its own then it must be > wrapped in "item" or some similar mechanism eg: > >
> > In Rainbows > >
> > hence the decision was to use "audio-title" as this wouldn't interfere > with existing uF's and make the "audio-title" class name directly > attributed as the main hAudio title and wouldn't need heavy markup like > the above? > > the decision to use "fn album" causes concern for me and is unclear, I > understand that hAudio uses this mechanism to suggest fn hAudio type > seems a bit rushed and I don't think that this proposal warranted an > adoption from "audio-title" but it seems every one supported it, so > there you go as far as I can see we created a new microformat "album" > instead of "audio-title". Does this also mean that all haudio must be > regarded as an album? how do we state otherwise? > > Anyway Scott I don't think that anyone exactly agrees with me on the > list, so disregard the above :) just my 2 pence worth. > > > > -- > > Scott Reynen > > MakeDataMakeSense.com > > > > > > > > _______________________________________________ > > microformats-new mailing list > > microformats-new@microformats.org > > http://microformats.org/mailman/listinfo/microformats-new From scott at makedatamakesense.com Sat Nov 3 20:54:19 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Sat Nov 3 20:54:27 2007 Subject: =?ISO-8859-1?Q?Re:_[uf-new]_[hAudio]_fn_=5For=5F=A0album?= In-Reply-To: <1194149693.9781.4.camel@localhost.localdomain> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194149157.9573.37.camel@localhost.localdomain> <1194149693.9781.4.camel@localhost.localdomain> Message-ID: <06752781-DE18-429B-8670-3421FD9493F4@makedatamakesense.com> On Nov 3, 2007, at 10:14 PM, Martin McEvoy wrote: > You were a solid supporter of using "audio-title" and helped make the > decision NOT to use FN That's not true. I think you have the order of events confused. > "...We can't both re-use property names and ignore > the context of those property names. My dog's FN is not my FN, and > if the only way for me to make that clear is to use class="pet-name" > instead of FN, that's what will happen." > > http://microformats.org/discuss/mail/microformats-new/2007-June/000581.html > > ? > > What changed your mind ?, this was the statement that made us > support the use of "audio-title" Nothing changed my mind. I was not at all arguing against FN there, rather for the awareness of context that is necessary to use FN with embedded microformats. And I was arguing for that *after* FN was already discarded, because I thought it was unfortunate we had discarded FN rather than solving the context problem. Right now the necessary context is explicitly written into hAudio ITEM ("The element must be processed opaquely"). It still doesn't exist in other microformats, but the general consensus (arrived at on the -dev list despite my protest that it's more than a parsing issue) was that we shouldn't address this until it becomes a more widespread (and thus better documented) problem. Maybe it will never become a bigger problem, or maybe hAudio will force the issue. Either way, I'm for solving this problem with more explicit context rather than inventing new synonymous class names (e.g. audio-title) as a means of working around it. -- Scott Reynen MakeDataMakeSense.com From julian at julianstahnke.com Sun Nov 4 01:28:30 2007 From: julian at julianstahnke.com (Julian Stahnke) Date: Sun Nov 4 01:28:35 2007 Subject: =?WINDOWS-1252?Q?Re:_[uf-new]_[hAudio]_fn_=5For=5F=A0album?= In-Reply-To: <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> Message-ID: >>>
>>> In Rainbows >>>
>> >> No, that?d be a track. > > > That would be an audio recording. It may be a track, or an album, > or something else entirely, but there's not enough information in > the markup to determine anything more than it's an audio recording. Oops, sorry. But why could it be an album, wouldn?t it need to be ?fn album? then? From martin at weborganics.co.uk Sun Nov 4 02:16:50 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Nov 4 02:16:23 2007 Subject: [uf-new] [hAudio] fn =?ISO-8859-1?Q?=5For=5F=A0album?= In-Reply-To: References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> Message-ID: <1194171410.8509.8.camel@localhost.localdomain> Good Morning Julian On Sun, 2007-11-04 at 09:28 +0000, Julian Stahnke wrote: > >>>
> >>> In Rainbows > >>>
> >> > >> No, that?d be a track. > > > > > > That would be an audio recording. It may be a track, or an album, > > or something else entirely, but there's not enough information in > > the markup to determine anything more than it's an audio recording. > > Oops, sorry. But why could it be an album, wouldn?t it need to be ?fn > album? then? This is whats confusing about the whole "fn album" proposal "fn album", means album "album", means album "fn" means the name of the haudio object... which could be and album? three ways of saying the SAME thing, looks like bashing it with a hammer and making it fit to me... not very microformaty at all! Thanks Martin > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From sean at miscoranda.com Sun Nov 4 02:35:11 2007 From: sean at miscoranda.com (Sean B. Palmer) Date: Sun Nov 4 02:35:15 2007 Subject: [uf-new] hTurtle: A GRDDL-Compatible Microformat for Turtle-in-HTML In-Reply-To: References: Message-ID: HTML wasn't really meant for writing RDF, and it's easy to get sick of yet another @class-based microformat. For that reason I've made hTurtle, which lets you embed Turtle in HTML comments. http://inamidst.com/sw/hturtle/ - The hTurtle Microformat A quick example from the page itself: [...]

The hTurtle Microformat

Note that the link/@href is indeed a relative URI, to a service which converts an hTurtle document using a CGI into an XSLT stylesheet that transforms the hTurtle into RDF/XML. "But wait!", you say. "Does this mean that you had to implement a Turtle parser in XSLT?". Of course not. The CGI does the heavy lifting, being, as Chimezie Ogbuji put it, a "transformation generating service that's the function of the GRDDL source document". Put an hTurtle document's URI in, and get the appropriate GRDDL XSLT 1.0 transform out. It's a way of bootstrapping non-XSLT conversion services into the XSLT-only GRDDL circle of love. Anyway, the documentation and source code explains this quite thoroughly. Have at, and enjoy! -- Sean B. Palmer, http://inamidst.com/sbp/ From martin at weborganics.co.uk Sun Nov 4 04:05:01 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Nov 4 04:04:32 2007 Subject: [uf-new] [hAudio] fn =?ISO-8859-1?Q?=5For=5F=A0album?= In-Reply-To: <06752781-DE18-429B-8670-3421FD9493F4@makedatamakesense.com> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194149157.9573.37.camel@localhost.localdomain> <1194149693.9781.4.camel@localhost.localdomain> <06752781-DE18-429B-8670-3421FD9493F4@makedatamakesense.com> Message-ID: <1194177901.8509.54.camel@localhost.localdomain> On Sat, 2007-11-03 at 22:54 -0600, Scott Reynen wrote: > On Nov 3, 2007, at 10:14 PM, Martin McEvoy wrote: > > > You were a solid supporter of using "audio-title" and helped make the > > decision NOT to use FN > > That's not true. I think you have the order of events confused. > > > "...We can't both re-use property names and ignore > > the context of those property names. My dog's FN is not my FN, and > > if the only way for me to make that clear is to use class="pet-name" > > instead of FN, that's what will happen." > > > > http://microformats.org/discuss/mail/microformats-new/2007-June/000581.html > > > > ? > > > > What changed your mind ?, this was the statement that made us > > support the use of "audio-title" > > Nothing changed my mind. I was not at all arguing against FN there, > rather for the awareness of context that is necessary to use FN with > embedded microformats. And I was arguing for that *after* FN was > already discarded, because I thought it was unfortunate we had > discarded FN rather than solving the context problem. Right, the thought at the time was that "fn" was being delivered out of context, so it was better to use "audio-title" which was at the time the only other proposition we had. This sounds like I am evangelizing the use of "audio-title", I am not however, I like the use of FN but I am concerned that it is being delivered incorrectly and out of context. we are adopting the use of "fn" directly from hCard which on its own as hAudio uses it (outside of a hCard and not within an Item), Is a first case usage scenario, which basicly means that we are re-using "fn" in a different context as previously defined in hCard and http://www.ietf.org/rfc/rfc2426.txt. Truthfully Scott more discussion was needed about the adoption of "fn album" before any such changes were made, Its such an important element within hAudio that it has to be clear in what this means. I WAS going to start supporting that we create a new Very Much needed Microformat in the absence of a "title" microformat, class="subject" which would have made hAudio look like this:
Start Wearing Purple by Gogol Bordello found on Underdog World Strike
original example http://microformats.org/wiki/audio-info-proposal#Song_and_Album_Example I think It may have been better to set the subject of an hAudio object other than try to set a type by using "fn album" which is not setting the hAudio type at all, just setting the type of "fn" within the hAudio object. Any way we will have to see what happens maybe more feedback from the wiki, will help lay to rest the problems that exist by using the "fn album" formula. Thanks Martin > > Right now the necessary context is explicitly written into hAudio ITEM > ("The element must be processed opaquely"). It still doesn't exist in > other microformats, but the general consensus (arrived at on the -dev > list despite my protest that it's more than a parsing issue) was that > we shouldn't address this until it becomes a more widespread (and thus > better documented) problem. Maybe it will never become a bigger > problem, or maybe hAudio will force the issue. Either way, I'm for > solving this problem with more explicit context rather than inventing > new synonymous class names (e.g. audio-title) as a means of working > around it. > > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From lists at ben-ward.co.uk Sun Nov 4 05:00:16 2007 From: lists at ben-ward.co.uk (Ben Ward) Date: Sun Nov 4 05:00:50 2007 Subject: =?ISO-8859-1?Q?Re:_[uf-new]_[hAudio]_fn_=5For=5F=A0album?= In-Reply-To: <1194177901.8509.54.camel@localhost.localdomain> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194149157.9573.37.camel@localhost.localdomain> <1194149693.9781.4.camel@localhost.localdomain> <06752781-DE18-429B-8670-3421FD9493F4@makedatamakesense.com> <1194177901.8509.54.camel@localhost.localdomain> Message-ID: <388559B4-539E-47A0-B631-B38C5C66CE2B@ben-ward.co.uk> On 4 Nov 2007, at 12:05, Martin McEvoy wrote: > I think It may have been better to set the subject of an hAudio object > other than try to set a type by using "fn album" which is not setting > the hAudio type at all, just setting the type of "fn" within the > hAudio > object. That's not right. class="fn album" does *not* mean ?fn of type ?album?? it states two separate things: ? The value is the FN of the hAudio ? The value is the Album [Album Name] of the hAudio Just as in hCard class="fn org" states two separate things: ? The value of FN of the hCard ? The value of Organisation-Name of the hCard (with optimisation) Combining them into one element does not change ?fn? in any way, it's just that the values are the same. I've actually hit a problem with this though. Take the following examples:
The Bends from The Bends by Radiohead
The Bends by Radiohead is amazing!
The Bends ? the title track of the album ? by Radiohead is fantastic live.
In the first example, we're explicitly talking about a track. The structure is: hAudio FN: The Bends ALBUM: The Bends Contributor: Radiohead FN and ALBUM are separate, so we can imply that this is a track of an album of the same name, despite the values being the same. In the second, we're just talking about the album. The structure is: hAudio FN: The Bends ALBUM: The Bends Contributor: Radiohead Because FN and ALBUM are on the same element, we _could_ imply that we're talking about an album. But, the third example breaks it. The structure is: hAudio FN: The Bends ALBUM: The Bends Contributor: Radiohead Because FN and ALBUM are on the same element, we could imply that we're talking about an album. But we're not. We're talking about the track and the album name is implied in the prose. Perhaps the hCard parallel is valid again here. Bear in mind that FN in hCard is not a lone property. FN in hCard can be a persons name or an organisation name. Persons name in N, organisation name in ORG. The bug in hAudio, is that FN can be ALBUM or ?track title?. But there is no TRACK. It's like having hCard with ORG but not N. An implied FN optimisation could be used later in hAudio, but the FN must optimise _to_ something. Ben From scott at makedatamakesense.com Sun Nov 4 06:22:14 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Sun Nov 4 06:22:22 2007 Subject: =?WINDOWS-1252?Q?Re:_[uf-new]_[hAudio]_fn_=5For=5F=A0album?= In-Reply-To: References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> Message-ID: On Nov 4, 2007, at 2:28 AM, Julian Stahnke wrote: >>>>
>>>> In Rainbows >>>>
>>> >>> No, that?d be a track. >> >> That would be an audio recording. It may be a track, or an album, >> or something else entirely, but there's not enough information in >> the markup to determine anything more than it's an audio recording. > > Oops, sorry. But why could it be an album, wouldn?t it need to be > ?fn album? then? It would, but the lack of that doesn't make it not an album; it just makes it ambiguous. On Nov 4, 2007, at 3:16 AM, Martin McEvoy wrote: > This is whats confusing about the whole "fn album" proposal > > "fn album", means album > "album", means album > "fn" means the name of the haudio object... which could be and album? Trying thinking of it like this: 1) class="album" means name of album 2) class="fn" means name of audio 3) If name of album and name of audio are same, audio is album. The third factor is not a re-definition of the property names when combined (there is no such thing in HTML); it's a consequence of two distinct properties having the same value (whether or not they're in the same element). -- Scott Reynen MakeDataMakeSense.com From scott at makedatamakesense.com Sun Nov 4 06:36:43 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Sun Nov 4 06:36:57 2007 Subject: [uf-new] hTurtle: A GRDDL-Compatible Microformat for Turtle-in-HTML In-Reply-To: References: Message-ID: On Nov 4, 2007, at 3:35 AM, Sean B. Palmer wrote: > HTML wasn't really meant for writing RDF, and it's easy to get sick of > yet another @class-based microformat. For that reason I've made > hTurtle, which lets you embed Turtle in HTML comments. > > http://inamidst.com/sw/hturtle/ > - The hTurtle Microformat Hi Sean, I don't want to discourage what you're doing at all, but you may want to read through the microformat process (assuming you haven't already) to get a better idea of what we mean when we use the term "microformat" and why your application of this term to something that (apparently) didn't follow this process is, well, wrong: http://microformats.org/wiki/process This may seem pedantic, but given your interest in semantics, I'm sure you can appreciate our interest in keeping the term "microformat" meaningful, not just another buzz word. -- Scott Reynen MakeDataMakeSense.com From tom at tommorris.org Sun Nov 4 07:16:59 2007 From: tom at tommorris.org (Tom Morris) Date: Sun Nov 4 07:17:03 2007 Subject: [uf-new] hTurtle: A GRDDL-Compatible Microformat for Turtle-in-HTML In-Reply-To: References: Message-ID: On 11/4/07, Scott Reynen wrote: > This may seem pedantic, but given your interest in semantics, I'm sure > you can appreciate our interest in keeping the term "microformat" > meaningful, not just another buzz word. > I prefer to use the term "semantic data format" for microformats that have not gone through The Process for this reason. -- Tom Morris http://tommorris.org/ From tantek at cs.stanford.edu Sun Nov 4 07:31:38 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sun Nov 4 07:30:12 2007 Subject: [uf-new] hTurtle not a microformat nor even POSH In-Reply-To: Message-ID: On 11/4/07 7:16 AM, "Tom Morris" wrote: > On 11/4/07, Scott Reynen wrote: >> This may seem pedantic, but given your interest in semantics, I'm sure >> you can appreciate our interest in keeping the term "microformat" >> meaningful, not just another buzz word. >> > > I prefer to use the term "semantic data format" for microformats that have > not gone through The Process for this reason. It's actually one of the reasons we came up with POSH - Plain Old Semantic HTML, for semantic HTML conventions which have not gone through the process. In the case of "hTurtle" however, there are several principles being violated: 1. Invisible data. The data in comments is invisible. 2. Comment hack. Comments and their contents aren't markup. Putting data into comments isn't using markup, it's abusing the syntax of markup. 3. Violating DRY. In the example the information is duplicated in the

and in the comment. 4. Premature naming. "DO NOT start with even labeling your effort "hXYZ". This is a very common mistake." http://microformats.org/wiki/process#Naming_considerations So as Scott said, "hTurtle" is not a microformat, but worse than that, it is also not even POSH. Tantek From martin at weborganics.co.uk Sun Nov 4 08:14:47 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Nov 4 08:14:23 2007 Subject: [uf-new] [hAudio] fn =?ISO-8859-1?Q?=5For=5F=A0album?= In-Reply-To: References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> Message-ID: <1194192887.9516.66.camel@localhost.localdomain> On Sun, 2007-11-04 at 07:22 -0700, Scott Reynen wrote: > On Nov 4, 2007, at 2:28 AM, Julian Stahnke wrote: > > >>>>
> >>>> In Rainbows > >>>>
> >>> > >>> No, that?d be a track. > >> > >> That would be an audio recording. It may be a track, or an album, > >> or something else entirely, but there's not enough information in > >> the markup to determine anything more than it's an audio recording. > > > > Oops, sorry. But why could it be an album, wouldn?t it need to be > > ?fn album? then? > > It would, but the lack of that doesn't make it not an album; it just > makes it ambiguous. > > On Nov 4, 2007, at 3:16 AM, Martin McEvoy wrote: > > > This is whats confusing about the whole "fn album" proposal > > > > "fn album", means album > > "album", means album > > "fn" means the name of the haudio object... which could be and album? > > Trying thinking of it like this: > > 1) class="album" means name of album > 2) class="fn" means name of audio > 3) If name of album and name of audio are same, audio is album. Which is the clearest definition I have read yet thank you Scott. "3) If name of album and name of audio are same, audio is album." This is the bit that's causing me concern "fn album" is being used to set a fn type of album, all other use cases of "fn" in Microformats depend on a predicate being set and the subject matter? eg: in hListing http://microformats.org/wiki/hlisting#Extended_Examples

Parking space [...] the predicate is "item" hlisting => item => fn the subject is Parking space in hReview http://microformats.org/wiki/hreview#Multidimensional_Restaurant_Review

Cafe Borrone
[...] again the predicate is "item" hreview => item => vcard => fn the subject is a vcard fn exists here as not part of the hreview but as part of the reviewer vcard another example of this is http://microformats.org/wiki/hreview#Product_review
Album cover photo: The Postal Service: Give Up. The Postal Service: Give Up [...] the predicate is "item" hreview => item => url => fn the subject is The Postal Service: Give Up What seems to be proposed is a new First case usage of "fn" being used outside of hCard and without it being part of item... Now can you see why I am concerned about this proposal? Thanks Martin > > The third factor is not a re-definition of the property names when > combined (there is no such thing in HTML); it's a consequence of two > distinct properties having the same value (whether or not they're in > the same element). > > -- > Scott Reynen > MakeDataMakeSense.com > > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From sean at miscoranda.com Sun Nov 4 13:26:27 2007 From: sean at miscoranda.com (Sean B. Palmer) Date: Sun Nov 4 13:26:29 2007 Subject: [uf-new] Re: hTurtle: A GRDDL-Compatible Microformat for Turtle-in-HTML Message-ID: Scott Reynen wrote: > This may seem pedantic, but given your interest in semantics, > I'm sure you can appreciate our interest in keeping the term > "microformat" meaningful, not just another buzz word. It doesn't seem pedantic, and I do appreciate your interest. I also don't believe that it's wrong to call hTurtle a microformat. Ajax once meant Javascript + XMLHttpRequest but now it just means Javascript done well. Google used to not be a verb, and the company still think it isn't. A Hoover used to be only those devices made by The Hoover Company, a former division of the Whirlpool Corporation sold to Techtronic Industries. When you publish an HTML document that doesn't have a DOCTYPE declaration, or one which has one but is invalid, do you not call it HTML? These are examples of where semantic sloppiness isn't really sloppiness at all. You're right, I am rather interested in semantics. I'm rather interested in the philosophy of linguistics too, and things like descriptivism and prototypicality and all that lark. I do sympathise that you want to regulate the term "microformat" and any word matching h[A-Z][a-z]+, and I think that The Process has some excellent design points; design points which hTurtle utterly violates. But that's not to say that it's not a microformat. Consider. There are three ways that terms can get misused: * Good misuse that gets heavily adopted until everybody forgets that it's misuse and it becomes a standard (google as a verb and the other examples I gave above). * Bad misuse that gets heavily adopted until everybody wants to give the business up and become a carpenter (Web 2.0, RSS N.N, etc., perhaps). * Either quality of misuse that doesn't get heavily adopted and as a consequence changes nothing. Which of these categories does hTurtle come under? Do edge cases disqualify themselves? Words are radial categories; you don't own the term "microformat" in some yer-in-or-yer-out formal system. And it doesn't matter that you don't, because the whole process of grassroots standardisation, to use one of irritating recent buzzwords, is emergent. hTurtle is part of the deal now, but it's not a deal breaker. Many thanks for your calm feedback, on what probably seemed like somewhat of a troll from me; I didn't intend it that way! I just picked the most appropriate looking microformats list at the last moment because I thought you guys would like to know whatever you thought about it... Thanks again, -- Sean B. Palmer, http://inamidst.com/sbp/ From sean at miscoranda.com Sun Nov 4 13:41:19 2007 From: sean at miscoranda.com (Sean B. Palmer) Date: Sun Nov 4 13:41:23 2007 Subject: [uf-new] Re: hTurtle: A GRDDL-Compatible Microformat for Turtle-in-HTML Message-ID: Tantek ?elik wrote: > 1. Invisible data. The data in comments is invisible. Oh dear. You should tell that to whoever wrote this section: http://www.w3.org/TR/html401/interact/scripts.html#h-18.3.2 It's not invisible to the XML Infoset, or the DOM, or SAX parsers, or XSLT, or regular expressions, or so on, which is how hTurtle is able to meet its requirements. hTurtle's requirements mightn't align with those stated in The Process, of course. See my message to Scott for more about that. (I've been told that "data" is a plural, incidentally!) > 2. Comment hack. Comments and their contents aren't markup. What about QNames in attribute values? If I'd been using an SGML NOTATION section or something then I'd understand your concern?or The Process's concern. Masahide Kanzaki has one of my favourite examples of exploiting the joy of comments: http://www.kanzaki.com/parts/xsltdoc.xsl I agree that it's a crap way to do it in HTML, but then that's grafting arms onto the HTML hamburger for you. > 3. Violating DRY. Okay, this is a point that I utterly concede. It's absolutely stupid to have to repeat the information, and that's a poor demonstration of hTurtle. I couldn't think of anything else that was as simple and yet shows clearly what it does. In actual use one might be providing a machine readable form of say prose describing the model of an RDF Schema. Of course you can go from the RDF to the HTML rather than embedding the RDF in the HTML, but I'm not saying that hTurtle is an especially good idea as a format. It does, speaking from an engineering point of view, work, however. You get triples from it. > 4. Premature naming. "DO NOT start with even labeling your > effort "hXYZ". This is a very common mistake." I think I addressed this in my reply to Scott. Please let me know if I didn't. When someone pointed out that I'd got replies on microformats-new, they did it by saying "you've awoken the Tantek!", which I think is coded speak for you've elicited a rare reply from a supreme honcho. I still owe you a big one for your forgiveness after I tore the design of your weblog a new ass when in fact you were just adapting common designs to be standards compliant. So now I owe you two big ones. -- Sean B. Palmer, http://inamidst.com/sbp/ From scott at makedatamakesense.com Sun Nov 4 14:18:12 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Sun Nov 4 14:18:21 2007 Subject: [uf-new] Re: hTurtle: A GRDDL-Compatible Microformat for Turtle-in-HTML In-Reply-To: References: Message-ID: <909AA078-8C1C-4F8F-A2F8-140AA7E235C2@makedatamakesense.com> On Nov 4, 2007, at 2:41 PM, Sean B. Palmer wrote: >> 1. Invisible data. The data in comments is invisible. > > It's not invisible to the XML Infoset, or the DOM, or SAX parsers, or > XSLT, or regular expressions, or so on, which is how hTurtle is able > to meet its requirements. No, it's invisible to people, and focusing on data that's *visible* to people is a (maybe *the*) distinguishing characteristic of microformats. That's what people in this community mean when we say "microformat," so coming here and using that term meaning something completely different is like going to China and speaking to everyone in English. There's little to be gained from this, and much to be lost. -- Scott Reynen MakeDataMakeSense.com From scott at makedatamakesense.com Sun Nov 4 16:24:50 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Sun Nov 4 16:24:57 2007 Subject: =?ISO-8859-1?Q?Re:_[uf-new]_[hAudio]_fn_=5For=5F=A0album?= In-Reply-To: <1194192887.9516.66.camel@localhost.localdomain> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> Message-ID: On Nov 4, 2007, at 9:14 AM, Martin McEvoy wrote: > "3) If name of album and name of audio are same, audio is album." > > "fn album" is being used to > set a fn type of album No, it indicates the type of audio, not the type of name. There is no joint "fn album" property; that's two completely separate properties that happen to be classifying the same element. In HTML, one class name has no effect on the meaning of another. FN in HAUDIO *always* means "name of audio." Imagine in real life someone asks you if you've heard "Unicorns are Awesome." From that, you know "Unicorns are Awesome" is the name of some audio. Now imagine two weeks later someone asks you if you've seen the new album they bought, and you ask them what it's called, and they say "Unicorns are Awesome." Now you know "Unicorns are Awesome" is the name of an album. You can put those two independent pieces of information together to infer a third piece of information: the album and the piece of audio are very likely the same thing because they have the same name. That third piece of information comes from the previous two pieces of information, but it doesn't change them at all. The name of the audio is still the name of the audio, and the name of the album is still the name of the album. Similarly, an hCard analogy: if you asked me who I work for, I might tell you "John Deere," and give you the contact information for my employer (though that's not actually who I work for). Without any more information, you'd probably assume "John Deere" is a person, my boss. But then if someone told you there's an organization named "John Deere," you'd probably put that together and realize my employer is actually an organization, because an organization and my employer have the same name. hAudio and hCard parsing is just requiring parsers to make this same sort of deduction from existing information. > Now can you see why I am concerned about this proposal? I believe you're confused about the proposal and objecting to something that isn't actually proposed. I completely agree we shouldn't redefine FN, but because we're not talking about doing that, that's not really an objection to the hAudio proposal. -- Scott Reynen MakeDataMakeSense.com From andreluis.pt at gmail.com Sun Nov 4 17:21:45 2007 From: andreluis.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Sun Nov 4 17:21:50 2007 Subject: [uf-new] Re: hTurtle: A GRDDL-Compatible Microformat for Turtle-in-HTML In-Reply-To: <909AA078-8C1C-4F8F-A2F8-140AA7E235C2@makedatamakesense.com> References: <909AA078-8C1C-4F8F-A2F8-140AA7E235C2@makedatamakesense.com> Message-ID: On Nov 4, 2007 10:18 PM, Scott Reynen wrote: > > No, it's invisible to people, and focusing on data that's *visible* to > people is a (maybe *the*) distinguishing characteristic of > microformats. That's what people in this community mean when we say > "microformat," so coming here and using that term meaning something > completely different is like going to China and speaking to everyone > in English. There's little to be gained from this, and much to be lost. > +1 I totally agree, Scott. >From what Sean is describing, if people wanted to display the information in the turtle/rdf format to normal users, they would have to write it twice in different languages. POSH and then hTurtle. See? Just there, I wasn't able to put hturtle and POSH in the same sack... Now, I don't mean to say there's no point in hTurtle. There is, I'm just not sure it fits in the microformats group. Can't we have something in between ufs and pure rdf? Cheers, Andr? Lu?s From msporny at digitalbazaar.com Sun Nov 4 17:52:45 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Nov 4 17:52:50 2007 Subject: [uf-new] Re: hTurtle: A GRDDL-Compatible Microformat for Turtle-in-HTML In-Reply-To: References: <909AA078-8C1C-4F8F-A2F8-140AA7E235C2@makedatamakesense.com> Message-ID: <472E776D.9050709@digitalbazaar.com> Andr? Lu?s wrote: > From what Sean is describing, if people wanted to display the > information in the turtle/rdf format to normal users, they would have > to write it twice in different languages. POSH and then hTurtle. See? > Just there, I wasn't able to put hturtle and POSH in the same sack... > > Now, I don't mean to say there's no point in hTurtle. There is, I'm > just not sure it fits in the microformats group. Can't we have > something in between ufs and pure rdf? There already is something between uFs and pure RDF: RDFa http://www.w3.org/TR/xhtml-rdfa-primer/ Although, marking up Turtle using RDFa is a bit pedantic... :) Just curious... why didn't you use RDFa to do this, Sean? Scott and the rest on this thread are correct - what you have isn't a microformat as this community understands the term, it's something else... for what that's worth. What exactly is the use case behind hTurtle? What are you attempting to accomplish? There are so few in this world that understand the concept of N3, triples and RDF that I wonder how many people have the need for hTurtle? curiously, -- manu From martin at weborganics.co.uk Mon Nov 5 06:38:12 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 5 06:37:47 2007 Subject: [uf-new] [hAudio] fn =?ISO-8859-1?Q?=5For=5F=A0album?= In-Reply-To: References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> Message-ID: <1194273492.18358.38.camel@localhost.localdomain> Hello Scott On Sun, 2007-11-04 at 17:24 -0700, Scott Reynen wrote: > No, it indicates the type of audio, not the type of name. There is > no > joint "fn album" property; that's two completely separate properties > that happen to be classifying the same element. In HTML, one class > name has no effect on the meaning of another. FN in HAUDIO *always* > means "name of audio." Manu and Brian had quite a debate on fn audio (nine days) which started off in the Item/track debate http://microformats.org/discuss/mail/microformats-new/2007-October/001151.html That ended up as the Proposal being ... HAUDIO parts are denoted by ITEM: Track Name EXAMPLES: Album with two tracks, simple example: Best Before 1984 Crass
Hokkaido Dream
Tokyo Groove
Album with two tracks, more detailed: Best Before 1984 Crass Hokkaido Dream 3:24 Tokyo Groove 4:46 ... Best Before 1984 is not both a track and Album, Its just an album The context in which "fn album" is used in the above example is pretty much a re-use from "fn org" where "fn album" is used to imply that fn type is an album. This is my Axe that I am grinding if: Best Before 1984 Is an album and Best Before 1984 is also an Album where are the advantages of using Best Before 1984 over just Best Before 1984 ? It seems correct and understandable to simply markup hAudio like this: A track unknown album, detailed: Hokkaido Dream 3:24 a single track known Album, detailed: Best Before 1984 Hokkaido Dream 3:24 Album with two tracks, detailed: Best Before 1984 Crass Hokkaido Dream 3:24 Tokyo Groove 4:46 No misunderstandings, and easy to understand. I don't understand what benefits a publisher has using "fn album" over simply just "album" Microformats are supposed to use "simple conventions" and "use brief, descriptive class names", sorry about the quotes I am just emphasising my Issue. Thanks Martin From julian at julianstahnke.com Mon Nov 5 07:07:27 2007 From: julian at julianstahnke.com (Julian Stahnke) Date: Mon Nov 5 07:07:35 2007 Subject: =?ISO-8859-1?Q?Re:_[uf-new]_[hAudio]_fn_=5For=5F=A0album?= In-Reply-To: <1194273492.18358.38.camel@localhost.localdomain> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> <1194273492.18358.38.camel@localhost.localdomain> Message-ID: <7959F731-46FB-4416-AE4F-581EEC3A1116@julianstahnke.com> > No misunderstandings, and easy to understand. I don't understand what > benefits a publisher has using "fn album" over simply just "album" > Microformats are supposed to use "simple conventions" and "use brief, > descriptive class names", sorry about the quotes I am just emphasising > my Issue. Wouldn?t that be like trying to use just ?org? in an hcard to say that something is an organisation? If we model this aspect of haudio after vcard, shouldn?t it behave the same? From scott at makedatamakesense.com Mon Nov 5 07:14:38 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Mon Nov 5 07:14:47 2007 Subject: =?ISO-8859-1?Q?Re:_[uf-new]_[hAudio]_fn_=5For=5F=A0album?= In-Reply-To: <1194273492.18358.38.camel@localhost.localdomain> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> <1194273492.18358.38.camel@localhost.localdomain> Message-ID: <16DB8B84-23B2-4272-B95B-6A074A73A854@makedatamakesense.com> On Nov 5, 2007, at 7:38 AM, Martin McEvoy wrote: > where are the advantages of using Best Before > 1984 over just Best Before 1984 ? The former indicates the album is the same as the audio (because they have the same name), whereas the latter may just be an album related to the audio. This allows publishers to focus primarily on individual songs or on albums as they do naturally. > A track unknown album, detailed: > > > Hokkaido Dream > 3:24 > > That adds an extra layer of container where none really exists. Item of what? We're only talking about a single song here, so why can't a publisher just focus on that song without wrapping a container around it? Not every song even belongs to an album, so it's not just unknown albums this would be forcing publishers to markup; it's also non- existent albums. -- Scott Reynen MakeDataMakeSense.com From msporny at digitalbazaar.com Mon Nov 5 07:33:07 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Nov 5 07:33:35 2007 Subject: [uf-new] [hAudio] fn _or_ album In-Reply-To: <7959F731-46FB-4416-AE4F-581EEC3A1116@julianstahnke.com> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> <1194273492.18358.38.camel@localhost.localdomain> <7959F731-46FB-4416-AE4F-581EEC3A1116@julianstahnke.com> Message-ID: <472F37B3.3080201@digitalbazaar.com> Julian Stahnke wrote: >> No misunderstandings, and easy to understand. I don't understand what >> benefits a publisher has using "fn album" over simply just "album" >> Microformats are supposed to use "simple conventions" and "use brief, >> descriptive class names", sorry about the quotes I am just emphasising >> my Issue. > > Wouldn?t that be like trying to use just ?org? in an hcard to say that > something is an organisation? Doing this is perfectly OK to do in the VCARD format, AFAIK. It would be up to the application to understand that since no other fields are present, the displayable name should be the same value as ORG and the VCARD is about an ORG. > If we model this aspect of haudio after vcard, shouldn?t it behave the same? Jeez, this issue just won't die, will it :) How about this proposal: It takes everybody's input into account in this thread and follows the current hCard specification exactly. ------------------------------------------------------------------------ PROPOSAL: FN is required for hAudio. It is used to identify the name of the audio recording. ALBUM is optional. It is used to identify the name of the album that the audio recording belongs to. If both FN and ALBUM are present and the same, the application MUST deduce that the recording being discussed is an audio album. ALBUM SHOULD NOT exist unless FN is specified. ------------------------------------------------------------------------ Does that work for everybody? -- manu From msporny at digitalbazaar.com Mon Nov 5 07:40:31 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Nov 5 07:40:58 2007 Subject: [uf-new] [hAudio] fn _or_ album In-Reply-To: <1194273492.18358.38.camel@localhost.localdomain> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> <1194273492.18358.38.camel@localhost.localdomain> Message-ID: <472F396F.10809@digitalbazaar.com> Martin McEvoy wrote: > It seems correct and understandable to simply markup hAudio like this: > > A track unknown album, detailed: > > > Hokkaido Dream > 3:24 > > Why do you need the extra ITEM in there... it's not necessary from a semantic standpoint. Your example above would be better expressed like so: Hokkaido Dream 3:24 > a single track known Album, detailed: > > > Best Before 1984 > Hokkaido Dream > 3:24 > > Again, ITEM isn't needed to imply the proper semantics: Best Before 1984 Hokkaido Dream 3:24 > Album with two tracks, detailed: > > Best Before 1984 > Crass > > Hokkaido Dream > 3:24 > > > Tokyo Groove > 4:46 > > This one is correct... but the formatted name of the top-most hAudio is "Best Before 1984"... why wouldn't you want to explicitly specify what the formatted name of the hAudio is? The only argument that I can see for that approach is that you want to have an optimization by not putting the FN in there. It would be easier to type. > No misunderstandings, and easy to understand. I don't understand what > benefits a publisher has using "fn album" over simply just "album" You are being explicit about the formatted name, not implicit about its formatted name. > Microformats are supposed to use "simple conventions" and "use brief, > descriptive class names", sorry about the quotes I am just emphasising > my Issue. I'd just like to point out that we're arguing over not having to type out 2 letters - FN :) -- manu From martin at weborganics.co.uk Mon Nov 5 09:03:08 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 5 09:02:43 2007 Subject: [uf-new] [hAudio] fn =?ISO-8859-1?Q?=5For=5F=A0album?= In-Reply-To: <16DB8B84-23B2-4272-B95B-6A074A73A854@makedatamakesense.com> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> <1194273492.18358.38.camel@localhost.localdomain> <16DB8B84-23B2-4272-B95B-6A074A73A854@makedatamakesense.com> Message-ID: <1194282188.18654.14.camel@localhost.localdomain> On Mon, 2007-11-05 at 08:14 -0700, Scott Reynen wrote: > > A track unknown album, detailed: > > > > > > Hokkaido Dream > > 3:24 > > > > > > That adds an extra layer of container where none really exists. > Item > of what? We're only talking about a single song here, so why can't > a > publisher just focus on that song without wrapping a container > around > it? Not every song even belongs to an album, so it's not just > unknown > albums this would be forcing publishers to markup; it's also non- > existent albums. Yeh I thought that item it wasn't needed too, but In the concept of haudio, hAudio isnt a track Its an Album, if I marked up my hAudio like this Hokkaido Dream 3:24 There is no way to know if this is a Track, also FN is apearing out of context because FN is a child of Item when describing tracks in hAudio Is hAudio to be regarded as a track too? It would be nice if we could do something like Hokkaido Dream 3:24 To describe a single track Item and hAudio have identical meaning in this context? Thanks Martin From msporny at digitalbazaar.com Mon Nov 5 09:27:34 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Nov 5 09:28:04 2007 Subject: [uf-new] [hAudio] fn _or_ album In-Reply-To: <1194282188.18654.14.camel@localhost.localdomain> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> <1194273492.18358.38.camel@localhost.localdomain> <16DB8B84-23B2-4272-B95B-6A074A73A854@makedatamakesense.com> <1194282188.18654.14.camel@localhost.localdomain> Message-ID: <472F5286.8070402@digitalbazaar.com> Martin McEvoy wrote: > On Mon, 2007-11-05 at 08:14 -0700, Scott Reynen wrote: >>> A track unknown album, detailed: >>> >>> >>> Hokkaido Dream >>> 3:24 >>> >>> >> That adds an extra layer of container where none really exists. >> Item >> of what? We're only talking about a single song here, so why can't >> a >> publisher just focus on that song without wrapping a container >> around >> it? Not every song even belongs to an album, so it's not just >> unknown >> albums this would be forcing publishers to markup; it's also non- >> existent albums. > > Yeh I thought that item it wasn't needed too, but In the concept of > haudio, hAudio isnt a track Its an Album Ah-ha! Here is the issue with this thread. You are assuming that hAudio, by default, is an album. It is absolutely not. I thought we had addressed this issue, but quite clearly we have not. hAudio does not default to being a track or an album. You seem to claim one or the other when we talk about this topic and I think you are missing something very fundamental about hAudio. hAudio is not about TRACKS or ALBUMS by default. hAudio is about an audio recording. This is the fundamental underpinning to hAudio. We cannot move forward in this thread until everybody agrees that hAudio is about an audio recording. A track is an audio recording. An album is an audio recording. However, to say that hAudio is an album by default is wrong. hAudio is an audio recording by default. ONLY when ALBUM is specified do we know that the hAudio is about an audio recording that is an album. > > Hokkaido Dream > 3:24 > > > There is no way to know if this is a Track, also FN is apearing out of > context because FN is a child of Item when describing tracks in hAudio Yes, that is correct. Remember, we killed the concept of a TRACK. There is no such thing anymore. The only thing that we know about the above example is that the hAudio is describing an audio recording. hAudio has the concept of an audio recording. hAudio has the concept of an audio recording that is an album. > Is hAudio to be regarded as a track too? hAudio is an audio recording. Don't use the term TRACK as that is leading to confusion, people might think that you mean the TRACK proposal of a couple of weeks ago. > It would be nice if we could do something like > > > Hokkaido Dream > 3:24 > > > To describe a single track Item and hAudio have identical meaning in > this context? ITEM isn't needed in this case, you'd write it as the following: Hokkaido Dream 3:24 The hAudio above is about an audio recording. That is all we know. It could be about a track, a song, a podcast, an opera, a sound effect, an audio book, or a poem. We don't know... but what we do know is that it is about an audio recording. -- manu From martin at weborganics.co.uk Mon Nov 5 12:18:46 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 5 12:18:22 2007 Subject: [uf-new] [hAudio] fn =?ISO-8859-1?Q?=5For=5F=A0album?= In-Reply-To: <7959F731-46FB-4416-AE4F-581EEC3A1116@julianstahnke.com> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> <1194273492.18358.38.camel@localhost.localdomain> <7959F731-46FB-4416-AE4F-581EEC3A1116@julianstahnke.com> Message-ID: <1194293926.18654.34.camel@localhost.localdomain> Hello Julian On Mon, 2007-11-05 at 15:07 +0000, Julian Stahnke wrote: > > No misunderstandings, and easy to understand. I don't understand what > > benefits a publisher has using "fn album" over simply just "album" > > Microformats are supposed to use "simple conventions" and "use brief, > > descriptive class names", sorry about the quotes I am just emphasising > > my Issue. > > Wouldn?t that be like trying to use just ?org? in an hcard to say that > something is an organisation? If we model this aspect of haudio after > vcard, shouldn?t it behave the same? Yes It should.. ;) Thanks Martin From martin at weborganics.co.uk Mon Nov 5 13:21:12 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 5 13:20:58 2007 Subject: [uf-new] [hAudio] fn _or_ album In-Reply-To: <472F5286.8070402@digitalbazaar.com> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> <1194273492.18358.38.camel@localhost.localdomain> <16DB8B84-23B2-4272-B95B-6A074A73A854@makedatamakesense.com> <1194282188.18654.14.camel@localhost.localdomain> <472F5286.8070402@digitalbazaar.com> Message-ID: <1194297672.18654.61.camel@localhost.localdomain> On Mon, 2007-11-05 at 12:27 -0500, Manu Sporny wrote: > Martin McEvoy wrote: > > On Mon, 2007-11-05 at 08:14 -0700, Scott Reynen wrote: > >>> A track unknown album, detailed: > >>> > >>> > >>> Hokkaido Dream > >>> 3:24 > >>> > >>> > >> That adds an extra layer of container where none really exists. > >> Item > >> of what? We're only talking about a single song here, so why can't > >> a > >> publisher just focus on that song without wrapping a container > >> around > >> it? Not every song even belongs to an album, so it's not just > >> unknown > >> albums this would be forcing publishers to markup; it's also non- > >> existent albums. > > > > Yeh I thought that item it wasn't needed too, but In the concept of > > haudio, hAudio isnt a track Its an Album > > Ah-ha! Here is the issue with this thread. You are assuming that hAudio, > by default, is an album. It is absolutely not. I thought we had > addressed this issue, but quite clearly we have not. > > hAudio does not default to being a track or an album. You seem to claim > one or the other when we talk about this topic and I think you are > missing something very fundamental about hAudio. Thank You Manu > > hAudio is not about TRACKS or ALBUMS by default. hAudio is about an > audio recording. This is the fundamental underpinning to hAudio. Although Almost exclusively throughout the entire development of hAudio we have been talking about "albums" and "tracks" both in our discussions and in our examples http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services so forgive my misunderstanding, haudio is a about nothing specific other than a recording correct? Thanks Martin > > We cannot move forward in this thread until everybody agrees that hAudio > is about an audio recording. > > A track is an audio recording. An album is an audio recording. However, > to say that hAudio is an album by default is wrong. hAudio is an audio > recording by default. ONLY when ALBUM is specified do we know that the > hAudio is about an audio recording that is an album. > > > > > Hokkaido Dream > > 3:24 > > > > > > There is no way to know if this is a Track, also FN is apearing out of > > context because FN is a child of Item when describing tracks in hAudio > > Yes, that is correct. Remember, we killed the concept of a TRACK. There > is no such thing anymore. The only thing that we know about the above > example is that the hAudio is describing an audio recording. > > hAudio has the concept of an audio recording. > > hAudio has the concept of an audio recording that is an album. > > > Is hAudio to be regarded as a track too? > > hAudio is an audio recording. Don't use the term TRACK as that is > leading to confusion, people might think that you mean the TRACK > proposal of a couple of weeks ago. > > > It would be nice if we could do something like > > > > > > Hokkaido Dream > > 3:24 > > > > > > To describe a single track Item and hAudio have identical meaning in > > this context? > > ITEM isn't needed in this case, you'd write it as the following: > > > Hokkaido Dream > 3:24 > > > The hAudio above is about an audio recording. That is all we know. > > It could be about a track, a song, a podcast, an opera, a sound effect, > an audio book, or a poem. We don't know... but what we do know is that > it is about an audio recording. > > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Mon Nov 5 13:33:15 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Nov 5 13:33:48 2007 Subject: [uf-new] [hAudio] fn _or_ album In-Reply-To: <1194297672.18654.61.camel@localhost.localdomain> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> <1194273492.18358.38.camel@localhost.localdomain> <16DB8B84-23B2-4272-B95B-6A074A73A854@makedatamakesense.com> <1194282188.18654.14.camel@localhost.localdomain> <472F5286.8070402@digitalbazaar.com> <1194297672.18654.61.camel@localhost.localdomain> Message-ID: <472F8C1B.5090501@digitalbazaar.com> Martin McEvoy wrote: >> hAudio is not about TRACKS or ALBUMS by default. hAudio is about an >> audio recording. This is the fundamental underpinning to hAudio. > > Although Almost exclusively throughout the entire development of hAudio > we have been talking about "albums" and "tracks" both in our discussions > and in our examples > http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services Yes, we talked about "albums" and "tracks", I understand where the confusion started. We're just trying to end the confusion and have a very solid definition for what hAudio is right now. :) These discussions are helpful because others on this list may have been under the same impression. Keep in mind that we also talked about "podcasts", "top lists", "operas", "sound effects", multi-disc CD sets and various other things. The one thing that all of these have in common is that they are all audio recordings. > haudio is a about nothing specific other than a recording correct? Yes, that is correct. hAudio, in and of itself, is about nothing specific other than an audio recording. We do have the capability to be more specific if we want to by using the ALBUM property. However, if the ALBUM property is not in an HAUDIO, it must be assumed that the HAUDIO is about an audio recording and nothing more. -- manu From martin at weborganics.co.uk Mon Nov 5 13:58:07 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 5 14:00:11 2007 Subject: [uf-new] [hAudio] fn _or_ album In-Reply-To: <472F8C1B.5090501@digitalbazaar.com> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> <1194273492.18358.38.camel@localhost.localdomain> <16DB8B84-23B2-4272-B95B-6A074A73A854@makedatamakesense.com> <1194282188.18654.14.camel@localhost.localdomain> <472F5286.8070402@digitalbazaar.com> <1194297672.18654.61.camel@localhost.localdomain> <472F8C1B.5090501@digitalbazaar.com> Message-ID: <1194299887.21401.8.camel@localhost.localdomain> On Mon, 2007-11-05 at 16:33 -0500, Manu Sporny wrote: > Martin McEvoy wrote: > >> hAudio is not about TRACKS or ALBUMS by default. hAudio is about an > >> audio recording. This is the fundamental underpinning to hAudio. > > > > Although Almost exclusively throughout the entire development of hAudio > > we have been talking about "albums" and "tracks" both in our discussions > > and in our examples > > http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services > > Yes, we talked about "albums" and "tracks", I understand where the > confusion started. We're just trying to end the confusion and have a > very solid definition for what hAudio is right now. :) > > These discussions are helpful because others on this list may have been > under the same impression. Keep in mind that we also talked about > "podcasts", "top lists", "operas", "sound effects", multi-disc CD sets > and various other things. The one thing that all of these have in common > is that they are all audio recordings. > > > haudio is a about nothing specific other than a recording correct? > > Yes, that is correct. hAudio, in and of itself, is about nothing > specific other than an audio recording. > > We do have the capability to be more specific if we want to by using the > ALBUM property. However, if the ALBUM property is not in an HAUDIO, it > must be assumed that the HAUDIO is about an audio recording and nothing > more. so why not call it hRecording and have done with it?, hAlbum is redundant, too specific, so is hAudio I think? but its too late for that now... Thanks Martin > > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From scott at makedatamakesense.com Mon Nov 5 14:00:45 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Mon Nov 5 14:00:49 2007 Subject: [uf-new] [hAudio] fn _or_ album In-Reply-To: <1194297672.18654.61.camel@localhost.localdomain> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> <1194273492.18358.38.camel@localhost.localdomain> <16DB8B84-23B2-4272-B95B-6A074A73A854@makedatamakesense.com> <1194282188.18654.14.camel@localhost.localdomain> <472F5286.8070402@digitalbazaar.com> <1194297672.18654.61.camel@localhost.localdomain> Message-ID: <5F9B3C34-101E-4C4C-ADB6-5347292BC63D@makedatamakesense.com> On Nov 5, 2007, at 2:21 PM, Martin McEvoy wrote: > haudio is a about nothing specific other than a recording correct? Sort of. I think that depends what you mean by "haudio." class="haudio" classifies something as an audio recording and more specific subproperties of such an element identify more specific aspects of audio recordings, e.g. class="duration", class="fn", class="album", rel="payment", etc. But "hAudio" is also a convenient way to refer to the whole collection of those properties ("the hAudio proposal"), in which case the specificity of what it's "about" is entirely dependent on which of those properties are in use. For example, hAudio including class="duration" around "04:45" is specifically about audio that is 4 minutes and 45 seconds long. And hAudio including class="fn album" is specifically about audio with the same formatted name as an album (and thus itself an album). So it may be confusing two different issues to say "hAudio" is about "nothing specific" just as it was apparently confusing to talk about "tracks" in both the colloquial and microformat sense without specifying the difference. -- Scott Reynen MakeDataMakeSense.com From alan at high-beyond.com Mon Nov 5 14:19:03 2007 From: alan at high-beyond.com (Alan Slater) Date: Mon Nov 5 14:18:35 2007 Subject: [uf-new] OpenShapes - a tentative proposal for a Microformat for diagrams Message-ID: <472F96D7.8020702@high-beyond.com> According to the Wikipedia definition: ?A diagram is a simplified and structured visual representation of concepts, ideas, constructions, relations, statistical data, anatomy etc used in all aspects of human activities to visualize and clarify the topic.? Some examples of the kinds of domains that we might wish to produce diagrams for are: * Organization charts * Flowcharts * Network diagrams * UML Component models * UML Deployment models * Office seating layouts * Website navigation maps * High level architectural diagrams * Mind-maps Of course, if you think that this sounds a bit like the domain of Microsoft Visio or perhaps even specialized UML modeling tools then you would not be completely wide of the mark! An example of a diagram in a potential XHTML-based microformat could look like:
XSL-FO File
Processor
PostScript File
Note that this microformat can only partially define the appearance of diagrams - additional presentational information has to be provided seperately in definitions that describe how each shape is to be drawn. A more detailed outline of this proposal can be found at: http://www.high-beyond.com/downloads/OpenShapesProposal.pdf This document actually has some diagrams in it as well as discussing small points like potential implementation strategies and integration with other systems such as wikis. All comments appreciated! Cheers Alan Slater alan@high-beyond.com From msporny at digitalbazaar.com Mon Nov 5 14:18:15 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Nov 5 14:18:48 2007 Subject: [uf-new] [hAudio] fn _or_ album In-Reply-To: <1194299887.21401.8.camel@localhost.localdomain> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> <1194273492.18358.38.camel@localhost.localdomain> <16DB8B84-23B2-4272-B95B-6A074A73A854@makedatamakesense.com> <1194282188.18654.14.camel@localhost.localdomain> <472F5286.8070402@digitalbazaar.com> <1194297672.18654.61.camel@localhost.localdomain> <472F8C1B.5090501@digitalbazaar.com> <1194299887.21401.8.camel@localhost.localdomain> Message-ID: <472F96A7.6000004@digitalbazaar.com> Martin McEvoy wrote: > so why not call it hRecording and have done with it? Because video is a type of recording too... What is hRecording? A video recording or an audio recording? > hAlbum is > redundant, too specific, so is hAudio I think? but its too late for that > now... It's not that it is too late for that... hRecording just doesn't make sense for what we're talking about. You could argue that we could name it: hVideoRecording and hAudioRecording... but then someone would make the argument that the recording part is redundant between the two microformat names... which means we end up with hVideo and hAudio using that line of reasoning as well. This thread is going a bit off track... we are talking about FN and ALBUM. Is everyone comfortable with the idea that hAudio is about audio recordings? -- manu PS: What Scott said is also very accurate... and I agree with him 100%. From martin at weborganics.co.uk Mon Nov 5 15:24:35 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 5 15:24:12 2007 Subject: [uf-new] [hAudio] fn _or_ album In-Reply-To: <472F96A7.6000004@digitalbazaar.com> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> <1194273492.18358.38.camel@localhost.localdomain> <16DB8B84-23B2-4272-B95B-6A074A73A854@makedatamakesense.com> <1194282188.18654.14.camel@localhost.localdomain> <472F5286.8070402@digitalbazaar.com> <1194297672.18654.61.camel@localhost.localdomain> <472F8C1B.5090501@digitalbazaar.com> <1194299887.21401.8.camel@localhost.localdomain> <472F96A7.6000004@digitalbazaar.com> Message-ID: <1194305075.21538.1.camel@localhost.localdomain> On Mon, 2007-11-05 at 17:18 -0500, Manu Sporny wrote: > Martin McEvoy wrote: > > so why not call it hRecording and have done with it? > > Because video is a type of recording too... What is hRecording? A video > recording or an audio recording? > > > hAlbum is > > redundant, too specific, so is hAudio I think? but its too late for that > > now... > > It's not that it is too late for that... hRecording just doesn't make > sense for what we're talking about. You could argue that we could name it: > > hVideoRecording and hAudioRecording... > :) > but then someone would make the argument that the recording part is > redundant between the two microformat names... which means we end up > with hVideo and hAudio using that line of reasoning as well. > > This thread is going a bit off track... we are talking about FN and ALBUM. > > Is everyone comfortable with the idea that hAudio is about audio > recordings? a single audio recording? Thanks Martin > > -- manu > > PS: What Scott said is also very accurate... and I agree with him 100%. > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From bhawkeslewis at googlemail.com Mon Nov 5 15:48:02 2007 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Mon Nov 5 15:48:16 2007 Subject: [uf-new] OpenShapes - a tentative proposal for a Microformat for diagrams In-Reply-To: <472F96D7.8020702@high-beyond.com> References: <472F96D7.8020702@high-beyond.com> Message-ID: <472FABB2.9010901@googlemail.com> Alan Slater wrote: > An example of a diagram in a potential XHTML-based microformat could > look like: > >
>
> XSL-FO File >
>
> Processor >
>
> PostScript File >
> > >
> > Note that this microformat can only partially define the appearance of > diagrams - additional presentational information has to be provided > seperately in definitions that describe how each shape is to be drawn. > > A more detailed outline of this proposal can be found at: > > http://www.high-beyond.com/downloads/OpenShapesProposal.pdf > I'm confused. Why are you trying to do this in XHTML at all, especially when "the primary means for displaying Open Shapes content will be graphical and that this will not be directly supported by browsers" and you intend to render the diagrams using other technologies like Silverlight? Your paper gives three reasons: 1. "The ability to embed diagrams into XHTML pages and retain validity without employing new namespaces etc." What's wrong with OBJECT and IMG? If you want to inline diagram markup inside the same document, you can retain XML validity by mixing XHTML with other XML languages such as SVG. Why is avoiding namespaces such a crucial goal? 2. "Relative friendliness for search engine crawlers". Not as friendly as a HTML long description of the same diagram, though. 3. "The ability to render something if the content cannot be displayed graphically. Particularly important for accessibility ? this should always be a major concern." Well, yes, but can you elaborate on how such markup like your example is going to be meaningful to users of existing user agents and assistive technologies, seeing as your links have no link text and AFAIK no current consuming agent will do anything special with rel="from" and rel="to"? -- Benjamin Hawkes-Lewis From scott at makedatamakesense.com Mon Nov 5 16:05:34 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Mon Nov 5 16:05:48 2007 Subject: [uf-new] [hAudio] fn _or_ album In-Reply-To: <1194305075.21538.1.camel@localhost.localdomain> References: <978B2FAE-A30C-43E1-8D29-AF4E05803C8D@ben-ward.co.uk> <5CB4CA16-69DA-4ECC-BC25-5686FD0FD31F@julianstahnke.com> <1194142112.8037.40.camel@localhost.localdomain> <1194142356.8037.45.camel@localhost.localdomain> <8F36317B-A270-4388-AF53-13541A49E8D7@julianstahnke.com> <98133D7F-03DB-4DF7-911F-29817864BDBA@makedatamakesense.com> <1194192887.9516.66.camel@localhost.localdomain> <1194273492.18358.38.camel@localhost.localdomain> <16DB8B84-23B2-4272-B95B-6A074A73A854@makedatamakesense.com> <1194282188.18654.14.camel@localhost.localdomain> <472F5286.8070402@digitalbazaar.com> <1194297672.18654.61.camel@localhost.localdomain> <472F8C1B.5090501@digitalbazaar.com> <1194299887.21401.8.camel@localhost.localdomain> <472F96A7.6000004@digitalbazaar.com> <1194305075.21538.1.camel@localhost.localdomain> Message-ID: <1D805F6B-36CE-496F-84DD-AF6BAFEF6741@makedatamakesense.com> On Nov 5, 2007, at 4:24 PM, Martin McEvoy wrote: > a single audio recording? Again, that depends what you mean by "single." If you mean "one item," then yes. An album is one piece of audio, a song is one piece of audio, an opera is one piece of audio, etc. If you mean "contains no sub-items," then no. But of course that's not true of anything we markup with microformats. Events can be divided into sub-events, organizations into sub-organizations, a list into sub-lists, and so on. But why are you asking? Is there specific audio you're unsure of how to publish with the current hAudio proposal? If it's audio, put it in class="haudio". If it has sub-items, put them in class="item". Beyond that, it gets rather philosophical. Does anything really have meaning beyond the sum of its parts? We don't really need to answer that, so let's not. -- Scott Reynen MakeDataMakeSense.com From alan at high-beyond.com Mon Nov 5 16:34:01 2007 From: alan at high-beyond.com (Alan Slater) Date: Mon Nov 5 16:33:37 2007 Subject: [uf-new] OpenShapes - a tentative proposal for a Microformat for diagrams In-Reply-To: <472FABB2.9010901@googlemail.com> References: <472F96D7.8020702@high-beyond.com> <472FABB2.9010901@googlemail.com> Message-ID: <472FB679.5020001@high-beyond.com> Hi there, Thanks for the comments. The work described was actually fairly well underway when I actuall "got" the Microformat approach of overloading base XHTML with "semantic" information - comparing the custom schema that I had been working on with a (directly equivalent) XHTML representation the latter seemed, to me at least, intuitively more appealing. However, I appreciate that the benefits aren't fantastically well thought out - which is why I marked the proposal as tentative. I guess I'm particularly interested in being able to capture semantically rich diagrams (notably UML) within a "lowercase semantic web" approach. > Your paper gives three reasons: > > 1. "The ability to embed diagrams into XHTML pages and retain validity > without employing new namespaces etc." What's wrong with OBJECT and > IMG? If you want to inline diagram markup inside the same document, > you can retain XML validity by mixing XHTML with other XML languages > such as SVG. Why is avoiding namespaces such a crucial goal? Well, I wouldn't say avoiding namespaces is "crucial" but I do find the simplicitly of microformats a rather welcome "breath of fresh" air after years of dealing with complex industry-specific XML "standards". YMMV Part of floating this idea was to see whether there was any mileage in using an XHTML-based microformat - in terms of actual coding using a native schema is probably a bit easier! Incidentally, although I don't mention this anwhere in the paper I will admit that this approach was probably heavily influenced by using pic and troff - but that's probably me showing my age! e.g. http://www.troff.org/prog.html#pic > 2. "Relative friendliness for search engine crawlers". Not as friendly > as a HTML long description of the same diagram, though. Yes, but in the kind of collaborative environment that I see this potentially being useful (mainly graphical wikis), nobody is going to bother writing a separate "long description". > 3. "The ability to render something if the content cannot be displayed > graphically. Particularly important for accessibility ? this should > always be a major concern." Well, yes, but can you elaborate on how > such markup like your example is going to be meaningful to users of > existing user agents and assistive technologies, seeing as your links > have no link text and AFAIK no current consuming agent will do > anything special with rel="from" and rel="to"? I think I copied the "links without link text" from one of the other Microformat examples... but I agree that this is no excuse! Thanks again for the feedback. Cheers Alan From msporny at digitalbazaar.com Mon Nov 5 19:28:19 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Nov 5 19:28:23 2007 Subject: [uf-new] hAudio for Operator updated Message-ID: <472FDF53.20007@digitalbazaar.com> The hAudio plug-in for Operator has been updated to match the current hAudio specification: http://microformats.org/wiki/haudio An updated version of Operator and the hAudio plug-in can be downloaded from the Digital Bazaar wiki: http://wiki.digitalbazaar.com/en/Firefox_Operator_Extensions Once installed, you can see Operator+hAudio in action here (and any of the over 88,500+ albums on Bitmunk): http://www.bitmunk.com/view/media/2217341 There are a couple of known bugs with this version of hAudio that will require several feature additions to Operator (in the very least, I'll have to chat with Mike Kaply about some of the hAudio implementation issues): 1. Opaque properties. Operator will need to have support for opaque properties in order to fully support hAudio. We need opaque properties for the ITEM property. 2. Implicit typing on properties. Operator currently does not have, at least to my knowledge, a way of stating that an ITEM is of type HAUDIO without specifying both ITEM and HAUDIO together. In other words, Operator will not find the two songs listed below if the data is marked up like so:
Album Name
Song Name 1 live
Song Name 2 studio
Instead, you have to mark the above up like this:
Album Name
Song Name 1 live
Song Name 2 studio
The only change is from "item" to "item haudio" for the song. This "bug" will eventually get fixed once we chat a bit with Mike Kaply. 3. No optimizations have been implemented yet. If you use the software and find any further bugs, please report them on the wiki or send me an e-mail: http://wiki.digitalbazaar.com/en/Firefox_Operator_Extensions#Known_Bugs -- manu From lists at ben-ward.co.uk Tue Nov 6 01:46:36 2007 From: lists at ben-ward.co.uk (Ben Ward) Date: Tue Nov 6 01:46:55 2007 Subject: [uf-new] OpenShapes - a tentative proposal for a Microformat for diagrams In-Reply-To: <472FB679.5020001@high-beyond.com> References: <472F96D7.8020702@high-beyond.com> <472FABB2.9010901@googlemail.com> <472FB679.5020001@high-beyond.com> Message-ID: On 6 Nov 2007, at 01:34, Alan Slater wrote: > I think I copied the "links without link text" from one of the > other Microformat examples... but I agree that this is no excuse! If you happen to come across that example again please let me know as it's very likely an error that needs fixing. Ben From jeff at jeffmcneill.com Tue Nov 6 16:34:09 2007 From: jeff at jeffmcneill.com (Jeff McNeill) Date: Tue Nov 6 16:34:14 2007 Subject: [uf-new] OpenShapes - a tentative proposal for a Microformat for diagrams In-Reply-To: <472F96D7.8020702@high-beyond.com> References: <472F96D7.8020702@high-beyond.com> Message-ID: <519fa62f0711061634p33b497c7j30957c7870fb9b5f@mail.gmail.com> Aloha Alan, Have you taken a look at GraphViz and its toolset? That and SVG seem the best fit for this sort of thing, with dot syntax being much more human-readable, and therefore perhaps viable as a basis for extension into xhtml markup. http://www.graphviz.org/ Cheers, Jeff McNeill http://jeffmcneill.com/ On 11/5/07, Alan Slater wrote: > > According to the Wikipedia definition: > > "A diagram is a simplified and structured visual representation of concepts, ideas, constructions, relations, statistical data, anatomy > etc used in all aspects of human activities to visualize and clarify the topic." > > Some examples of the kinds of domains that we might wish to produce diagrams for are: > > * Organization charts > * Flowcharts > * Network diagrams > * UML Component models > * UML Deployment models > * Office seating layouts > * Website navigation maps > * High level architectural diagrams > * Mind-maps > > Of course, if you think that this sounds a bit like the domain of Microsoft Visio or perhaps even specialized UML modeling tools then you would not be completely wide of the mark! > > An example of a diagram in a potential XHTML-based microformat could look like: > >
>
> XSL-FO File >
>
> Processor >
>
> PostScript File >
> > >
> > Note that this microformat can only partially define the appearance of diagrams - additional presentational information has to be provided seperately in definitions that describe how each shape is to be drawn. > > A more detailed outline of this proposal can be found at: > > http://www.high-beyond.com/downloads/OpenShapesProposal.pdf > > This document actually has some diagrams in it as well as discussing small points like potential implementation strategies and integration with other systems such as wikis. > > All comments appreciated! > > Cheers > > Alan Slater > alan@high-beyond.com > > > > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -- Sincerely, Jeff McNeill http://jeffmcneill.com/ From martin at weborganics.co.uk Thu Nov 8 12:14:35 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Nov 8 12:14:14 2007 Subject: [uf-new] hAudio for Operator updated In-Reply-To: <472FDF53.20007@digitalbazaar.com> References: <472FDF53.20007@digitalbazaar.com> Message-ID: <1194552875.9841.13.camel@localhost.localdomain> On Mon, 2007-11-05 at 22:28 -0500, Manu Sporny wrote: > The hAudio plug-in for Operator has been updated to match the current > hAudio specification: > > http://microformats.org/wiki/haudio > > An updated version of Operator and the hAudio plug-in can be downloaded > from the Digital Bazaar wiki: > > http://wiki.digitalbazaar.com/en/Firefox_Operator_Extensions > > Once installed, you can see Operator+hAudio in action here (and any of > the over 88,500+ albums on Bitmunk): > > http://www.bitmunk.com/view/media/2217341 Thanks Manu Couldn't get it to work on FF2 seemed to be something to do with the RDFa hAudio stuff :( Anyway, I hacked the script and removed all the RDFa specific script and for cleanliness, also removed any proprietary linking stuff the stripped version can be found here: http://darkstarserver.co.uk/scripts/haudio.js also being a little Impatient (you know me) I hacked together a haudio-item script, based on the original haudio script, with extra actions such as bookmarking the Item with Firefox. The good thing about the item script is that It hooks hReview, and hListing Items too. the script can be downloaded from here: http://darkstarserver.co.uk/scripts/haudio-item.js the intresting thing is it works without relying on the hAudio script being installed so good thing eh? Thanks Have Fun Martin > > There are a couple of known bugs with this version of hAudio that will > require several feature additions to Operator (in the very least, I'll > have to chat with Mike Kaply about some of the hAudio implementation > issues): > > 1. Opaque properties. Operator will need to have support for opaque > properties in order to fully support hAudio. We need opaque properties > for the ITEM property. > > 2. Implicit typing on properties. Operator currently does not have, at > least to my knowledge, a way of stating that an ITEM is of type HAUDIO > without specifying both ITEM and HAUDIO together. In other words, > Operator will not find the two songs listed below if the data is marked > up like so: > >
> Album Name >
> Song Name 1 > live >
>
> Song Name 2 > studio >
>
> > Instead, you have to mark the above up like this: > >
> Album Name >
> Song Name 1 > live >
>
> Song Name 2 > studio >
>
> > The only change is from "item" to "item haudio" for the song. This "bug" > will eventually get fixed once we chat a bit with Mike Kaply. > > 3. No optimizations have been implemented yet. > > If you use the software and find any further bugs, please report them on > the wiki or send me an e-mail: > > http://wiki.digitalbazaar.com/en/Firefox_Operator_Extensions#Known_Bugs > > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From alan at high-beyond.com Sun Nov 11 15:25:10 2007 From: alan at high-beyond.com (Alan Slater) Date: Sun Nov 11 15:24:42 2007 Subject: [uf-new] OpenShapes - a tentative proposal for a Microformat for diagrams In-Reply-To: <519fa62f0711061634p33b497c7j30957c7870fb9b5f@mail.gmail.com> References: <472F96D7.8020702@high-beyond.com> <519fa62f0711061634p33b497c7j30957c7870fb9b5f@mail.gmail.com> Message-ID: <47378F56.8090802@high-beyond.com> Hi there, > Have you taken a look at GraphViz and its toolset? That and SVG seem > the best fit for this sort of thing, with dot syntax being much more > human-readable, and therefore perhaps viable as a basis for extension > into xhtml markup. > That does look interesting. However, I wouldn't expect much of the markup for diagrams (whether this is in an XHTML-based microformat or not) to be hand generated - I'm currently interested in in-browser editors as the main mechanism for graphical content being created and edited. Perhaps with import of existing diagrams being the next (e.g. from Visio). Cheers Alan From paul_wilkins at xtra.co.nz Sun Nov 11 15:57:20 2007 From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz) Date: Sun Nov 11 15:57:24 2007 Subject: [uf-new] OpenShapes - a tentative proposal for a Microformat for diagrams Message-ID: <486402.27824.qm@web96007.mail.aue.yahoo.com> From: Alan Slater > I'm currently interested in in-browser > editors as the main mechanism for graphical content being created and > edited. Amaya already lets you do this in the browser. I must try to use it more. http://www.w3.org/Amaya/screenshots/screen6_small.png -- Paul Wilkins From ernadb at gmail.com Mon Nov 19 10:04:40 2007 From: ernadb at gmail.com (Ernad Besirevic) Date: Mon Nov 19 10:04:40 2007 Subject: [uf-new] I*-Notation MF Message-ID: <4741D038.504@gmail.com> Hy! I should develop a microformat for I*-Notation. The problem is, I am new with this. Could someone help me and tell me how can I develop my own mf? Thanks in advance. Regards Ernad From scott at makedatamakesense.com Mon Nov 19 10:36:13 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Mon Nov 19 10:36:16 2007 Subject: [uf-new] I*-Notation MF In-Reply-To: <4741D038.504@gmail.com> References: <4741D038.504@gmail.com> Message-ID: On Nov 19, 2007, at 11:04 AM, Ernad Besirevic wrote: > Hy! > > I should develop a microformat for I*-Notation. The problem is, I am > new with this. Could someone help me and tell me how can I develop > my own mf? Thanks in advance. Welcome. The first thing you should probably know is that microformats are intended for widespread use, so it's not really something you develop on your own. You can (and should) use semantic HTML on your own, but that's not really a microformat. If you haven't already, you should read the process outlined here: http://microformats.org/wiki/process Basically you should start by trying out some of the existing microformats to get an idea of how they work and also how they might help solve your problem. I have no idea what I*-Notation is, so I'm not sure which microformats to point you toward. But if it involves people, for example, you'd want to familiarize yourself with hCard: http://microformats.org/wiki/hcard -- Scott Reynen MakeDataMakeSense.com From ernadb at gmail.com Mon Nov 19 10:47:22 2007 From: ernadb at gmail.com (Ernad Besirevic) Date: Mon Nov 19 10:47:46 2007 Subject: [uf-new] I*-Notation MF In-Reply-To: References: <4741D038.504@gmail.com> Message-ID: <4741DA3A.90301@gmail.com> Scott Reynen wrote: > On Nov 19, 2007, at 11:04 AM, Ernad Besirevic wrote: > >> Hy! >> >> I should develop a microformat for I*-Notation. The problem is, I am >> new with this. Could someone help me and tell me how can I develop my >> own mf? Thanks in advance. > Basically you should start by trying out some of the existing > microformats to get an idea of how they work and also how they might > help solve your problem. I have no idea what I*-Notation is, so I'm > not sure which microformats to point you toward. But if it involves > people, for example, you'd want to familiarize yourself with hCard: > > http://microformats.org/wiki/hcard Ok. Thanks for your answer. I'll try to analyze the hCard and I hope can use this to develop my own MF. More about I*-Notation you can find here: http://istar.rwth-aachen.de/tiki-index.php?page=iStarQuickGuide. It is not so simple specially for someone whoe has contact for the first time with MFs. Thanks. regards From danny.ayers at gmail.com Mon Nov 19 14:59:22 2007 From: danny.ayers at gmail.com (Danny Ayers) Date: Mon Nov 19 14:59:26 2007 Subject: [uf-new] I*-Notation MF In-Reply-To: <4741DA3A.90301@gmail.com> References: <4741D038.504@gmail.com> <4741DA3A.90301@gmail.com> Message-ID: <1f2ed5cd0711191459q113205e2q52227e6bf7a7403d@mail.gmail.com> On 19/11/2007, Ernad Besirevic wrote: > Ok. Thanks for your answer. I'll try to analyze the hCard and I hope can > use this to develop my own MF. More about I*-Notation you can find here: > http://istar.rwth-aachen.de/tiki-index.php?page=iStarQuickGuide. It is > not so simple specially for someone whoe has contact for the first time > with MFs. Thanks. Just to reemphasize what Scott said, it's not just about the markup, a key part of microformats is their community development process: http://microformats.org/wiki/process I hadn't encountered I*-Notation before either, thankfully it has a Wikipedia entry: [[ i* (pronounced "i star") or i* framework is a modeling language suitable for an early phase of system modeling in order to understand the problem domain. ]] http://en.wikipedia.org/wiki/I* Interesting stuff, and some of the terms I encountered a while ago, when trying to put together a general-purpose project vocabulary in RDF: http://purl.org/stuff/project/ (oops, looks like I have a bit of server config to do there - the doc is also at: http://dannyayers.com:88/xmlns/project/index.htm ) - which suggests some other ways in which you could express i* in HTML: 1. a custom, microformats-style vocabulary without the microformats process (essentially as Scott suggested, using Plain Old Semantic HTML) 2. an eRDF representation (http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml) 3. an RDFa representation (http://www.w3.org/TR/xhtml-rdfa-primer) While all three allow data to be read from the HTML, there's a subtle difference in emphasis: Plain Old Semantic HTML could be more domain-oriented syntax; eRDF is regular HTML but with conventions for class names etc which are mapped to RDF constructs; RDFa is an extension to HTML with a document type which allows extra RDF-oriented attributes to be included. All three approaches, like microformats (assuming a profile URI is used) allow automatic interpretation of RDF data using GRDDL: http://www.w3.org/TR/grddl-primer/ btw, I've an update to my project vocab planned for the near future, mostly doc tweaks (must read up on i* first!). I also want to map relevant parts to the terms that are available in existing microformats - essentially TODO (tasks) and date/times from iCalendar/hCalendar. Cheers, Danny. From lucapost at gmail.com Thu Nov 29 08:45:32 2007 From: lucapost at gmail.com (LucaP) Date: Thu Nov 29 08:45:36 2007 Subject: [uf-new] Data Values & Measures Message-ID: How come the interest and discussion on such a fundamental issue as representing data-values, unit-measures and measurement-erros seems so low in the Microformats community? This would be a building block which many other microformats can exploit; badly needed in many fields, from recipes to technical/scientific applications! I posted about this in here and on the wiki over a month ago, but nothing happened; is there any hope to get this going any soon? ciao! Luca : ( 21.7 +/- 0.2 ) Kilometers. From gl at brixlogic.com Thu Nov 29 09:09:36 2007 From: gl at brixlogic.com (Guillaume Lebleu) Date: Thu Nov 29 09:09:56 2007 Subject: [uf-new] Data Values & Measures In-Reply-To: References: Message-ID: <474EF250.7060501@brixlogic.com> Luca, Take a look at http://microformats.org/wiki/measure and particularly http://microformats.org/wiki/measure-brainstorming#Straw_man If I understand your suggestion correctly, what is currently missing is the margin of error. The need for microformatting margins of error hasn't surfaced before your post, I believe. It would be useful as a first step to collect some samples from the Web and post them in the examples section to justify to the community that there is such a need. Hope this helps, Guillaume From thom at glow-internet.com Thu Nov 29 09:38:01 2007 From: thom at glow-internet.com (Thom Shannon) Date: Thu Nov 29 09:38:08 2007 Subject: [uf-new] Bank Account numbers Message-ID: <474EF8F9.4000600@glow-internet.com> has this been discussed before? I did have a look but couldn't find anything. I think it would be useful to have a way to markup bank account numbers, they're usually made up of a couple of constituent parts like sort code and account number (vary between countries). Since the growth of online banking people are increasingly using bank transfers to move money between friends and pay for goods and services (this is certainly true in the UK at least). A microformat for account numbers would allow people to act on the data in a page and avoid the terrible consequences of getting a bank account number wrong! This could function as an extension to the hCard format or stand alone, similar to adr. I've not found any solutions already out there, it occured that a bank account URL format would be very useful but the finance industry isn't usually What do people think? Is there enough of a pattern in account number formats that we could have a simple standard. Is this a problem that Microformats should solve? Should I just go away? :) From gl at brixlogic.com Thu Nov 29 10:23:06 2007 From: gl at brixlogic.com (Guillaume Lebleu) Date: Thu Nov 29 10:23:09 2007 Subject: [uf-new] Bank Account numbers In-Reply-To: <474EF8F9.4000600@glow-internet.com> References: <474EF8F9.4000600@glow-internet.com> Message-ID: <474F038A.7000508@brixlogic.com> Thom, I am very interested in looking into the value of such an idea. I have been researching the representation of bank account numbers in XML for a standard organization in a recent past, have learnt about the limitations of such an XML representation, and have been playing with POSH representations of bank account numbers/identifiers. I would be very happy to contribute my thoughts. That said, I think we need to start with the "What are we trying to accomplish" and "is a microformat relevant or only POSH". Re: "What are we trying to accomplish" question: what application could benefit from such a microformat? The one I can think of is REST/(X)HTML-based financial messaging, for instance, sending a payment message that would be both human and machine readable, and URL-addressable. That seems quite a departure from the current highly structured data structures and messaging practices of the financial industry, so simply coming up with a new way of doing old things would probably not be enough to drive adoption. We need a "killer app", even if it is something that the bank account number is simply a building block of. I would be curious to hear your ideas of killer applications that such a bank account number microformat would specifically enable. Re: "is a microformat relevant or only POSH" my thoughts on that is that account numbers are usually not published on the public Web, and less and less are even published on private Web spaces i.e. your Web banking application or Paypal app (obfuscating identifiers such as XXXX-98989 are increasingly preferred). My understanding is that the microformat community is more geared towards data on the public Web. I may have simply misunderstood, but this aspect of bank account number may be a non-starter for a microformat (which does not mean we can't take the discussion elsewhere). Perhaps, more knowledgeable community members could enlighten us on this particular question. Thanks in advance, Guillaume From m at klml.de Thu Nov 29 16:15:52 2007 From: m at klml.de (Klaus Mueller) Date: Thu Nov 29 16:15:59 2007 Subject: [uf-new] Bank Account numbers In-Reply-To: <474F038A.7000508@brixlogic.com> References: <474EF8F9.4000600@glow-internet.com> <474F038A.7000508@brixlogic.com> Message-ID: <474F5638.2070309@klml.de> Hi Guillaume, > > Re: "is a microformat relevant or only POSH" my thoughts on that is > that account numbers are usually not published on the public Web, and > less and less are even published on private Web spaces i.e. your Web > banking application or Paypal app (obfuscating identifiers such as > XXXX-98989 are increasingly preferred). You are right if you look at personal banking accounts, but companies, especially webshops often publish their account details: http://neckermann.de/hilfe/impressum/index.mb1?mb_f020_id=3HKDzVFKivYHBEmqMNF2l-DWPDaHQHW9&ne_cl_area=Topframe http://www.amazon.de/gp/help/seller/shipping.html?ie=UTF8&seller=A11MRI5N4LBZ82#policies etc I would like it to "click" to remit an amount instead of "copy paste" three times. (Holder, Accountnumber, BLZ) And even for personal issues you can use html-email. Yes I also dislike html-emails, but if it protects me from mistypes. greetz Klaus From thom at glow-internet.com Thu Nov 29 16:29:00 2007 From: thom at glow-internet.com (Thom Shannon) Date: Thu Nov 29 16:29:05 2007 Subject: [uf-new] Bank Account numbers In-Reply-To: <474F5638.2070309@klml.de> References: <474EF8F9.4000600@glow-internet.com> <474F038A.7000508@brixlogic.com> <474F5638.2070309@klml.de> Message-ID: <474F594C.5060200@glow-internet.com> > You are right if you look at personal banking accounts, but companies, > especially webshops often publish their account details: > http://neckermann.de/hilfe/impressum/index.mb1?mb_f020_id=3HKDzVFKivYHBEmqMNF2l-DWPDaHQHW9&ne_cl_area=Topframe > http://www.amazon.de/gp/help/seller/shipping.html?ie=UTF8&seller=A11MRI5N4LBZ82#policies > etc > Those are the sort of use cases I'm thinking of. Organisations publish their account numbers to help people pay them, or donate. Individuals share their accounts numbers amongst themselves, via email or in other ways. I might want to share my account number with my friends via my Facebook profle. Ideally you'd want to act on the data and have it load up your internet banking, ready to enter the amount and process the transaction. From swhitley at whitleymedia.com Thu Nov 29 16:55:49 2007 From: swhitley at whitleymedia.com (Shannon Whitley) Date: Thu Nov 29 16:55:53 2007 Subject: [uf-new] PR/Marketing Microformat Proposal Message-ID: <4e4a64f20711291655g1a8fb34ep8f204d9f5bb67503@mail.gmail.com> Greetings, The New Media Release Group (http://groups.google.com/group/newmediarelease) was created last year by Chris Heuer (Social Media Club). Its members have been discussing various options for taking the 100-year-old press release and updating it for the Internet. Almost from the beginning, the next version of the press release was envisioned as a Microformat. Consequently, the label, "hRelease," was applied and stuck at an early stage in the discussions. In October of this year, I inherited the technical management of the new media release specification. I have been working with several other members of a small working group to create a discussion document that is based on the business needs of the PR/Marketing community. Next week, I plan to present the following working document to the New Media Release Group: http://www.socialtext.net/hrelease/index.cgi?hrelease I plan to present it as a discussion document and not a completed draft. There will be modifications and additions based on feedback from the New Media Release Group. These discussions will be largely focused on business requirements, as we know that technical requirements will be discussed in depth at Microformats.org When the New Media Release Group is ready, we will plan to present a proposal to this group (Microformats-new). I anticipate questions from this group regarding our compliance with the Microformats Process. Please understand that it is our intent to follow the process, however, many actions have already taken place out-of-sequence. That is the nature of this project's history. The hRelease working document is an attempt to prototype the new schema. As in Rapid Application Development, iterations of the prototype are expected. Thank you for your consideration. This message is just meant as an introduction and I look forward to presenting a proposal to you in a few weeks. Shannon Whitley New Media Release Working Group From gl at brixlogic.com Thu Nov 29 20:09:54 2007 From: gl at brixlogic.com (Guillaume Lebleu) Date: Thu Nov 29 20:09:58 2007 Subject: [uf-new] Bank Account numbers In-Reply-To: <474F594C.5060200@glow-internet.com> References: <474EF8F9.4000600@glow-internet.com> <474F038A.7000508@brixlogic.com> <474F5638.2070309@klml.de> <474F594C.5060200@glow-internet.com> Message-ID: <474F8D12.705@brixlogic.com> Thom, Klaus, I created a page on the wiki to document the examples you mentioned: http://microformats.org/wiki/bankaccount-examples Guillaume From ernadb at gmail.com Thu Nov 29 23:18:09 2007 From: ernadb at gmail.com (Ernad Besirevic) Date: Thu Nov 29 23:18:26 2007 Subject: [uf-new] I*-Notation MF In-Reply-To: <1f2ed5cd0711191459q113205e2q52227e6bf7a7403d@mail.gmail.com> References: <4741D038.504@gmail.com> <4741DA3A.90301@gmail.com> <1f2ed5cd0711191459q113205e2q52227e6bf7a7403d@mail.gmail.com> Message-ID: <474FB931.1060506@gmail.com> Thanx. regards Ernad From thom at glow-internet.com Fri Nov 30 03:20:41 2007 From: thom at glow-internet.com (Thom Shannon) Date: Fri Nov 30 03:21:33 2007 Subject: [uf-new] Bank Account numbers In-Reply-To: <474F8D12.705@brixlogic.com> References: <474EF8F9.4000600@glow-internet.com> <474F038A.7000508@brixlogic.com> <474F5638.2070309@klml.de> <474F594C.5060200@glow-internet.com> <474F8D12.705@brixlogic.com> Message-ID: <474FF209.6060103@glow-internet.com> That's a great start! Thanks Guillaume Lebleu wrote: > Thom, Klaus, > > I created a page on the wiki to document the examples you mentioned: > > http://microformats.org/wiki/bankaccount-examples > > Guillaume > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > > -- *** OPEN COFFEE 6 - with FACT - http://upcoming.yahoo.com/event/323358 *** Glow New Media t: 0151 707 9770 m: 07730 987 574 www.glow-internet.com Suite 712 Gostins Building 32-36 Hanover Street Liverpool L1 4LN Map: http://tinyurl.com/2f5nxd