Brian Suda wrote: > On 5/1/07, Manu Sporny <[EMAIL PROTECTED]> wrote: >> We need feedback on the hAudio Microformat proposal. > >> hAudio (haudio) >> - title. required. text. > title is already taken to mean something else, so TITLE is not an > option. hCard uses TITLE for job-title. I would suggest FN instead.
Sorry, that was a typo (in what would be the worst place possible). It should have been 'work-title'. The name was chosen because it can be re-used for the audio, video and image microformats. We could use FN, but 'work-title' is far more accurate. Thoughts from the rest of the community? > collaborator. optional. using hCard. > > --- collaborator might be changed to more of the Dublin core terms > such as contributer A good suggestion, backed by favorable reception from the list... the change has been made. > release-date. optional. using datetime-design-pattern. > > --- is release-date different than 'published-date'? Another good suggestion. Going back through the data - it is clear that it should have been 'published-date', not 'release-date'. Martin has a point - they are different... but the data backs up the need to use 'published-date' instead of 'released-date'. > sample. optional. using rel-design-pattern with sample as the mf-rel-value. > > --- by 'sample' do you mean 'clip' or 'download'? what if it isn't a > SAMPLE, but a full download? Like Martin said - A sample is never for a full download (per the examples). A sample is always a partial/incomplete/preview recording. If a full download is to be specified via a URL, the 'acquire' rel-design-pattern should be used. > acquire. optional. using rel-design-pattern with acquire as the > mf-rel-value. > > --- there is aleady the 'enclosure' used for ATOM and Podcasts Again, Martin is correct - enclosure is for direct links to files that should be cached. Most of the examples never link directly to the download, instead they link to some method of acquisition (usually a buying or login process). > image-summary. optional. using HTML and XHTML tag img. > > --- image-summary? why not re-use LOGO or PHOTO? We could - anybody else on the list have any arguments for or against? Here's are two arguments related to using logo or photo: Against LOGO or PHOTO: - It would be nice if image-summary could be used for video and images as well. Using PHOTO wouldn't make much sense for images. It wouldn't be an accurate name for video either. - LOGO has nothing to do with a pictoral representation of content. Logo has more to do with branding, marketing and advertising. For IMAGE-SUMMARY: - The language is neutral - it can be used for video, image and audio Microformats. > genre. optional. text. > >> genre sounds alot like TAGS or CATEGORIES to me? we should recycle >> terms in existing microformats What Andy Mabbett said... not all authors want to mark up genres as URLs. There are enough examples that don't mark up the genre to not require the use of a URL-based TAGS/CATEGORIES approach. >> is there a reason you want to get this done in the next week or >> two? Because I'm the jerk that is going to persistently push the draft forward :). It would really help the Songbird, Firefox, Operator and music blog community out - they want a standard. We owe it to them to deliver it in a timely manner. The sooner we get a community consensus the better... I'm sure all of us would like to see *thoroughly vetted* Microformats used sooner rather than later. -- manu _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
