From martin at weborganics.co.uk Wed Oct 15 06:06:23 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Oct 15 06:14:09 2008 Subject: [uf-new] hAudio 1.0 Draft Release Message-ID: <48F5EACF.2090405@weborganics.co.uk> Hello This email is to announce the hAudio[1] 1.0 Final Draft proposed Schema Properties that are 70% or over of discovered elements determined by the audio-info examples[2] haudio (required) fn (required) contributor album enclosure type published duration position photo Removed properties that are 70% or less of discovered elements category description sample payment price item Recommended addition length(size) all the examples that relate to the final download itself when clicked have a file size, a user agent has to first download a small part of the audio to determine the file size. haudio in part reuses the concept of an atom enclosure and length is a required element of an atom:enclosure eg: http://www.ibm.com/developerworks/xml/library/x-atom10.html The above is also true with RSS2 enclosures http://cyber.law.harvard.edu/rss/rss.html Publishing Recommendations hAtom[3] or XOXO[4] should be used for grouping audio hAtom should be used for human edited content relating to an audio such as a description or press release about the audio content hReview[5] should be used to rate and review an audio. I hope to make the above recommendations Final and make the above changes within the next week or so. [1] http://microformats.org/wiki/haudio [2] http://microformats.org/wiki/audio-info-examples [3] http://microformats.org/wiki/hatom [4] http://microformats.org/wiki/xoxo [5] http://microformats.org/wiki/hreview Best wishes -- Martin McEvoy http://weborganics.co.uk/ From msporny at digitalbazaar.com Wed Oct 15 07:24:49 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Oct 15 07:24:55 2008 Subject: [uf-new] hAudio 1.0 Draft Release In-Reply-To: <48F5EACF.2090405@weborganics.co.uk> References: <48F5EACF.2090405@weborganics.co.uk> Message-ID: <48F5FD31.6030101@digitalbazaar.com> Martin McEvoy wrote: > This email is to announce the hAudio[1] 1.0 Final Draft proposed Schema It's good to see this moving forward as I haven't had any time to work on hAudio over the past couple of months. :) > Removed properties that are 70% or less of discovered elements > > category > description > sample > payment > price > item A couple of issues with the approach that is being taken: 1. These are very large, substantiative changes. There are currently no issues logged against any one of these attributes[1]. Shouldn't there be an issue logged against each one of these removals so that we can discuss the removal as per the uF Process? 2. Why remove all properties below 70% coverage? I thought we were attempting to solve the problem for roughly 80% of the sites out there? This proposal has us solving the problem for roughly 30% of the sites out there. Why are we suddenly ignoring 50% of our use cases? 3. I'm afraid that removing these properties will delay hAudio from reaching draft stage for much longer. Each removal requires a discussion, since we have had very long discussions to get each one of these elements into hAudio. There are currently no issues on the hAudio issues page for all of these removals. The only issue that we have to resolve right now to get hAudio to draft stage is this one: http://microformats.org/wiki/haudio-issues#D5:_2008-01-10__there_is_no_way_of_linking_to_an_interim_page Now we're talking about adding roughly 8 new issues that are going to be highly contentious to the debate. Why don't we just address hAudio Issue D5 and proceed to Draft? Issue D5 is your issue Martin - if you dropped it, we could proceed to draft immediately. Or we could find enough examples to support it, adopt it and proceed to Draft. Your proposal has us delaying hAudio for another 6-8 months (based on how long it's taken us to get through the five issues logged against hAudio in the first place). > Recommended addition > > length(size) While I agree that this would be a useful addition, we currently don't have any examples to back up the addition of this attribute to hAudio. We'd have to provide enough examples - even by your requirements outlined above, we'd have to prove that 70% of the sites out there publish this information (which they don't). > Publishing Recommendations > > hAtom[3] or XOXO[4] should be used for grouping audio We've had very long discussions on using item for grouping hAudio and it has been shown to work quite well. Why are we suddenly changing this? > I hope to make the above recommendations Final and make the above > changes within the next week or so. I certainly hope that we won't change hAudio so drastically over the next week, especially since there are no logged issues against any of these ideas. -- manu [1] http://microformats.org/wiki/haudio-issues From mail at tobyinkster.co.uk Wed Oct 15 07:59:31 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Oct 15 08:00:06 2008 Subject: [uf-new] hAudio 1.0 Draft Release Message-ID: <5DB179ED-97BA-4751-8AD9-EBBD623E81EB@tobyinkster.co.uk> Firstly, I'd like to say that the proposal for a way of marking up file sizes is a good idea. Perhaps it should not be part of hAudio in particular though, but adopted as part of the wider rel-enclosure/ downloads effort. e.g. give class="length" a meaning when found within rel-enclosure: Some File (12345 bytes) However, I strongly object to the removal of terms from hAudio - category, description and item in particular. My reasons are as follows: 1. I think this is a misapplication of the 80/20 principle. The idea of the principle is not to discard any properties which are used less than 80% of the time, but rather to create a format which covers 80% of use cases. Looking through the audio examples list on the wiki shows that at least half of them include, say, some form of categorisation - so if we leave out "category", then at least half of them can't be fully described using hAudio, so we haven't created a format which covers 80% of use cases. If the 80/20 principle worked the way Martin is applying it here, hCard would only include 3 properties: "fn", "url" and "email" (and the latter two would be at risk). 80% of the time a person is mentioned on the web, telephone numbers are not provided (e.g. my email signature, Martin's email signature), so "tel" would go. 80% of the time a person is mentioned on the web, addresses aren't provided, so "adr" would go to. Et cetera. The 80/20 principle is not meant to be applied this way. 2. Regarding "category" in particular, it should be noted that a form of categorisation (either class="category" or rel-tag) is adopted by almost all compound microformats. It provides a valuable extensibility mechanism to encompass bits of data which the designers of the microformat didn't take into account. e.g. tagging hCards as "Male" or "Female" is the officially recommended workaround for the lack of a "gender" property. A large number of the examples on the audio-info-examples wiki pages include the record label, the album genre and the audio medium (e.g. CD, download, LP, cassette, etc). All of those could be marked up using a categorisation mechanism. 3. Regarding "description", you suggest that hReview should be used instead. When a review of the audio item is being offered, then I agree that this is the best way of doing it. However, "description" has other purposes - it may contain factual information which is not a review. e.g. it could mention the location where some audio was recorded. In that sense, it also provides another extensibility mechanism for marking up information about a recording which is otherwise beyond the scope of hAudio. 4. Regarding "item", you suggest XOXO as a replacement. XOXO relies on