Re: [uf-new] hAudio 1.0 Draft Release
Manu Sporny wrote: Martin McEvoy wrote: In Microformats this means that if a propery is used more than 80% of the time then it should be included in the format, We'll call this Statement A. If we were to hold this true, then we would be left with these properties for hAudio. We would pick only the properties that were used in at least 80% of all sites: # album artist: 95.12% # track title: 90.24% # album title: 87.80% # album tracks: 80.49% The above information has been the crux of my issues with the audio-info process, because we haven't YET created a microformat for Music Downloads. The Proposal to create a Microformat for Music Downloads (If any one remembers) was first posted by Marian Steinbach in microformats-discuss[1], and later re-posted to microformats-new[2]: [1] http://microformats.org/discuss/mail/microformats-discuss/2007-February/008848.html [2] http://microformats.org/discuss/mail/microformats-new/2007-March/28.html the question was twofold 1 the automatic discovery of audio files, especially music MP3s, on web pages and 2 Provide users with the correct metadata about the audio files so users know who it's from and whether or not they want the file seems simple doesn't it? Not so... this whole process seems to have been sidetracked to talking about Music Download Sites which are not the same as Music Downloads, Confused now eh? The differences are: (a) A Music Download is a tangible File typically an mp3. (b) Music Download Sites are places where you can buy a Music download, all are typically in the realm of a Product. The whole hAudio process has based its discussion and findings around the Service Publishing of Music examples (Music Download Sites (b)) ... http://microformats.org/wiki/audio-info-examples#Service_Publishing_of_Music ... A problem domain that for the most part are proprietary services, none of which are concerned about distributing their information with each other or with the web at large, their only concern is the sale of a Product, highly relevant to the hListing discussion[1] and the hProduct discussion[2], but not so much the Music Download discussion because the download part is a secondary concern. Add that to the fact that the vast majority of those services rely on SEO's/SEM's to promote their product, which adds a considerable monetary cost, and a lot of questions to changing any aspect of their web sites, I would say that these services are the least desirable target audience because they are unlikely to be the early adopters of an Audio Microformat. [1] http://microformats.org/wiki/hlisting-proposal [2] http://microformats.org/wiki/hproduct-proposal So, I have done a new study on the audio-info-examples[1] page but have excluded all the Service Publishing of Music examples and concentrated on the examples that are about A Music Download(a), mostly MP3's which on the whole seems to have yielded different property results to the ones currently discovered, sorry about posting this info here but I am unsure on where I should put this info as there is a lot , the results are as follows : --- title: hAudio examples analysis url: http://microformats.org/wiki/audio-info-examples date: 2008-10-24T00:01:30 author: Martin McEvoy contact: http://weborganics.co.uk/ --- http://microformats.org/wiki/audio-info-examples#Music_Podcasting http://www.coverville.com/archives/2008/10/coverville_517.html description, title, published, contributor, position, download http://magnatune.com/podcasts/details/magnatune_middle-eastern_podcast_2006_12_14 Feed, title, section, genre, length, published, contributor, interval, download http://www.mutantpop.net/radioclash/archives/2007/03/24/rc-113/ Feed, description, title, photo, format, duration, size, published, contributor, download, category http://www.btpodshow.com/shows/?sId=21mId=5332173 Feed, description, title, episode , category, published, contributor, position http://indiecastwp.podshow.com/?p=76 Feed, description, title, section, format, category, length, published, contributor, episode ttp://www.accidenthash.com/2007/04/02/gray-wet-yuck-monday/ Feed, description, title, category, length, published, contributor, episode, download http://strongwordsinc.com/2007/05/31/episode-20-tranforming-you-into-stds-since-1983/ Feed, description, title, duration, published, episode, download, author http://threehive.libsyn.com/index.php?post_id=111596 Feed, description, title, photo, format, category, published, contributor[s] author, episode, download + [more model examples] http://music.for-robots.com/archives/002495.html Feed, title, published,
Re: [uf-new] hAudio 1.0 Draft Release
On [Oct 29], at [ Oct 29] 7:39 , Martin McEvoy wrote: The above information has been the crux of my issues with the audio- info process, because we haven't YET created a microformat for Music Downloads. The Proposal to create a Microformat for Music Downloads (If any one remembers) was first posted by Marian Steinbach in microformats- discuss[1], and later re-posted to microformats-new[2]: [1] http://microformats.org/discuss/mail/microformats-discuss/2007-February/008848.html [2] http://microformats.org/discuss/mail/microformats-new/2007-March/28.html It seems to me you're conflating two distinct efforts here, understandably as they have a lot in common. But they're not really the same. The emails you cited led to work on a media-info microformat, which seems to match your focus, but never went very far: http://microformats.org/wiki/media-info-brainstorming This has a problem statement that is clearly different from the problem statement of what ultimately came to be known as hAudio, found here: http://microformats.org/wiki/audio-info-examples The end of the latter problem statement explicitly rejects the focus on downloadable files you're seeking: The audio information need not be associated with a file. Note that audio content (The Payback by James Brown) is very different from the audio file format (192Kbps, stereo MP3). The goal of this discussion is to create a Microformat draft for marking up audio metadata and information. This has been the problem statement from the very beginning, and this problem attracted enough interest to push toward a solution. It doesn't seem to be a solution to the problem you want to solve, though. So if hAudio doesn't solve your problem, what do you do now? You tried earlier to start a new microformat with a new focus, but I think your framing of it in terms of hAudio distracted from what you actually wanted to do. It seems to me now that what you want to do is close enough to the previous media-info work that you should consider starting with what's already been done. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 1.0 Draft Release
Martin McEvoy wrote: In Microformats this means that if a propery is used more than 80% of the time then it should be included in the format, this will result in the top 20% of all discovered properties making their way into the final Microformat. You continue to contradict yourself, which is why we're having such a hard time with your argumentation, Martin. Your statement above makes no sense. Let's break it down and use some real numbers to see why: Martin McEvoy wrote: In Microformats this means that if a propery is used more than 80% of the time then it should be included in the format, We'll call this Statement A. If we were to hold this true, then we would be left with these properties for hAudio. We would pick only the properties that were used in at least 80% of all sites: # album artist: 95.12% # track title: 90.24% # album title: 87.80% # album tracks: 80.49% then you go on to state this: Martin McEvoy wrote: this will result in the top 20% of all discovered properties making their way into the final Microformat. Let's call this Statement B. If we were to hold this true, then out of all discovered properties, of which there are 163 properties[1], we would be left with the top 32 properties: 20% of 163 = 32.6 More specifically, we would be left with these properties for hAudio: album artist : 95.12% track title: 90.24% album title: 87.80% album tracks : 80.49% album release date : 73.17% album cover image : 73.17% track number : 70.73% album label: 68.29% track sample : 68.29% track web-based purchase : 60.98% album web-based purchase : 60.98% album genre: 58.54% track artist : 56.10% track length : 51.22% track price: 51.22% album price: 48.78% description: 39.02% album format : 26.83% track release date : 26.83% album sample : 24.39% album length : 21.95% track album: 17.07% track genre: 14.63% album physical-based purchase : 14.63% track label: 14.63% track format : 14.63% album bitrate : 12.20% album number of tracks : 12.20% album reviews : 12.20% track rating : 9.76% track album title : 9.76% album license : 7.32% Quite clearly, Statement A and Statement B say two different things. However, you state that because of Statement A, Statement B follows - even though both statements are talking about the same thing and they contradict each other. You have to pick either Statement A OR Statement B - not both. We're stating that Statement B is the correct understanding of the Pareto Principle as applied to hAudio. You are saying that both of them are the correct understanding - again, a contradiction. Just to be clear, here's what you said: Martin McEvoy wrote: In Microformats this means that if a propery is used more than 80% of the time then it should be included in the format, this will result in the top 20% of all discovered properties making their way into the final Microformat. It is because you keep repeating statements like this that I don't think there is a good reason to remove category, description, sample, payment, or price from hAudio. The removal of all of these properties is based on the statement you have made above - which is a logical fallacy. -- manu [1]http://microformats.org/wiki/audio-info-services-ufa ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 1.0 Draft Release
Hello Manu Manu Sporny wrote: 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? They were logged as issues see: http://microformats.org/wiki?title=haudio-issuesdiff=prevoldid=29669 But I Removed the issues because these are not issues they are properties that should not have been included at all 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. Manu, haudio can not be all inclusive, Including properties that are blow 70% (and I am being fair here) is somewhat akin to boiling the ocean, and confuse what we are actually trying to archive which is a simple microformat for music downloads, NOT to be confused with music download sites which are a different thing altogether as most of which do not relate to the final file location at all and could easily be marked up using hListing Why are we suddenly ignoring 50% of our use cases? We are not ignoring them there simply is not enough evidence top support these extra properties at this time. 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. The point is they are not part of this discussion, simplifying hAudio is the easiest option 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? Because as haudio stands at the moment, It STILL does not answer the problem of a music download, only the problem of music download sites, which more concerns itself with selling audio which can as I said earlier can quite amicably be resolved using hListing. Also haudio Is far to complex for authors to pick up and use it needs to be simplified, the only way I have found to do this reliably is to look at how haudio is currently implemented 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). I will place all the removals on the haudio issues page, I thought I would like to pass it all by you all first 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). I beg to differ all the examples that relate to the final location of a download itself, Mainly in the Podcasting examples and Individual publishers of music do have a length(size) property this is not immediatly evident on the page but is evident when the audio is being downloaded 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? Because how to group haudio has never been an Issue it only became an issue when you merged halbum into haudio, you didn't run that by the list when you published the halbum pages why was that?, I aired my concerns about this off list saying tat any discussion around a halbum microformat should be merged into the haudio discussion, I certainly did not mean that we should change the topic of the audio-download discussion to include collections of audio it is too complex and outside of the scope of hAudio because not answering the problem of grouping enables a simpler cleaner format that can be grouped in any
[uf-new] hAudio 1.0 Draft Release
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: enclosure url=http://www.example.org/myaudiofile.mp3; length=12345 type=audio/mpeg / http://www.ibm.com/developerworks/xml/library/x-atom10.html The above is also true with RSS2 enclosures enclosure url=http://www.scripting.com/mp3s/weatherReportSuite.mp3; length=12216320 type=audio/mpeg / 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/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 1.0 Draft Release
Minor clarification: the intent of the 80/20 rule when applied to deriving implied schema from real world examples *is* per property (that was my original reason/use of the 80/20 rule), not per example. Additionally: in general I agree with the methodology of simplifying/reducing the schema and property set - hence the start as simple as possible principle as documented: http://microformats.org/wiki/principles Thanks Martin, Manu, Scott, Toby for helping move hAudio forward. Tantek -Original Message- From: Martin McEvoy [EMAIL PROTECTED] Date: Wed, 15 Oct 2008 20:18:00 To: For discussion of new microformats.microformats-new@microformats.org Subject: Re: [uf-new] hAudio 1.0 Draft Release Hello Scott. Scott Reynen wrote: On [Oct 15], at [ Oct 15] 7:06 , Martin McEvoy wrote: This email is to announce the hAudio[1] 1.0 Final Draft proposed Schema [1] http://microformats.org/wiki/haudio Hi Martin, I'm confused by the differences between the wiki and your email propsal. If your email is intended to replace what's in the wiki, I think it should go in the wiki (perhaps in brainstorming?) with sufficient detail so we can compare the two and understand what is changing. It will follow why these properties have been removed on the issues page but I will outline them here in full category or tag marked for removal because only 59% of the examples identified this as a property description accept for podcasting and Individual Publishing of Music descriptions or summaries are used in less then 54% of the examples, and when they are such as in podcasting this can easily be marked up using hAtom sample Marked for removal because a sample is an enclosure just smaller in most cases. payment and price buying haudio is not much to do with the audio file itself, and is only referred to in the service publishing of (selling) music examples 60.98% all of which could be better marked up using hListing item Here is the one I had the greatest difficulty with because it is a difficult question to answer, grouping or collections are a little beyond the scope of haudio and should be perhaps moved to a different discussion entirely as it causes the most confusion for authors and the builders of parsers. I had to look at the early implementers of haudio and see how they were using Item, No One currently is using Item and all are preferring a more compact form of haudio, which to me is great. see: http://grabb.it/users/greg and: http://soundcloud.com/speakdeep/speakdeep-present-defense-an-extract I know, for example, that title changed to fn based on a resolved issue, but only because I've been following the discussion rather closely. I wouldn't expect anyone to understand that change simply looking at your email and the links you provided. There are other changes I don't understand at all. Without more detail, I expect discussion around this proposal will be rife with misunderstandings. The hAudio discussion has always been Rife with misunderstandings that is why haudio has taken a year and a half so far, simplifying the schema in these final stages is just part of the process, keeping the useful discovered elements and putting aside those less useful elements Thanks. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new -- Martin McEvoy http://weborganics.co.uk/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 1.0 Draft Release
Tantek Celik wrote: Additionally: in general I agree with the methodology of simplifying/reducing the schema and property set - hence the start as simple as possible principle as documented: In general, I agree with simplifying/reducing the schema and property set as long as it still addresses the problem shown via the examples. However, we should be careful not to over-simplify the problem. We did start with a much smaller set of terms for hAudio and grew into what we have now because of the audio-info-examples[1]. The changes that are currently being proposed ignore a great deal of the examples that were gathered. It over-simplifies the problem due to a mis-understanding of what the Pareto principle means. The audio-info-examples show that both individual audio recordings and collections of audio recordings are prevalent in the sites that were analyzed. Furthermore, the community has gone to great lengths to solve the single recording/multiple recording issues and has created something that seems to work for most of the audio-info-examples. The strongest case for removing the hard work that this community has done is based off of a possible mis-understanding of the Pareto principle (80-20). -- manu [1]http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 1.0 Draft Release
Manu Sporny wrote: Martin McEvoy wrote: Toby Inkster wrote: The 80/20 principle is not meant to be applied this way. In the end Yes it is, if a property doesn't come within 80% of popular publishing patterns It doesn't belong in the format that is why the microformats process is fair. I think that there is a misunderstanding of 80/20 that is at the core of your let's remove all properties that don't have at least 70% coverage argument. I'm not sure if it's your misunderstanding or Toby and my misunderstanding since 80-20 isn't spelled out clearly on the Microformats wiki, but here goes... My understanding of the way this community uses 80-20 is like so: We solve the markup problem for roughly 80% of the websites out there using 20% of the attributes that could be used to solve the problem. Correct... The Pareto principle, states that for many events, 80% of the effects come from 20% of the causes[1]. or from the same source as you cited The Pareto principle (also known as the 80-20 rule, the law of the vital few and the principle of factor sparsity) states that, for many events, 80% of the effects come from 20% of the causes In Microformats this means that if a propery is used more than 80% of the time then it should be included in the format, this will result in the top 20% of all discovered properties making their way into the final Microformat. Another way to look at it is this: [...] Let's clear this up first - as all of your removal of attributes argumentation is based on this premise. Is this everyone else's understanding of how Pareto is applied to Microformats? Yes. Thanks Martin -- manu [1] http://en.wikipedia.org/wiki/Pareto_principle [2] http://microformats.org/wiki/audio-info-services-ufa ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new -- Martin McEvoy http://weborganics.co.uk/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] hAudio 1.0 Draft Release
Answering several messages in one... Martin McEvoy wrote: In Microformats this means that if a propery is used more than 80% of the time then it should be included in the format, this will result in the top 20% of all discovered properties making their way into the final Microformat. Well, that's mathematical nonsense. Say we have 100 examples, each of which have (on average) five properties, but many of these properties are unique, such that overall there are 300 properties discovered. Say also that only three of these properties are common enough to have been found in more than 80% of the examples. This means that you're saying that if the three properties that are used more than 80% of the time are included in the format, this will result in the top 20% of all discovered properties making their way into the microformat. Thus 20% of 300 is 3, right? The Pareto Principle states that 80% of the effects emerge from 20% of the causes. So if there are N potential properties that can be included in the format, we can get 80% of the potential benefit by including the best N/5 of the properties. Also, regarding use of description to include factual information about a recording: Indeed it is useful but can you cite any real life examples of this, where factual information can be read about an individual peice of audio?, I am not saying they dont exist, I would just like to establish the exact source of your problem. Examples include the Product details section on Amazon; or a summary of chart performance (such as what Wikipedia often includes for albums and singles). No it wouldn't but then again I have never seen markup like the above before, is it a review, a listing a blog post? I cant solve hypothetical issues. The example was intended as a simplification, but are you honestly saying you've never seen a description of an album where individual tracks are mentioned in prose, mid-paragraph? Wikipedia, blogs, discussion forums and so on are riddled with examples. In any such cases, item is needed to enable marking up of the tracks within the album without resorting to list markup. (Forcing the use of list markup would not be paving cowpaths.) a rel=enclosure href=my-foo-file type=application/x-fooFoo/a I would just like to make type more explicit in the hAudio format itself. The content type should certainly be made explicit when known, but making it a class name is a mistake - the type attribute should be used as above. Making it into a class takes it away from the link, so you end up with stuff like this, which is meaningless: div class=haudio span class=fnExample/span a rel=enclosure href=foo1download 1/a span class=typeaudio/ogg/span a rel=enclosure href=foo2download 2/a /div Which is the ogg file? hAudio should use the type attribute on the link - it is outside microformats principles to invent ersatz markup patterns for semantics that already exist in HTML. making album a required property seems extremely restrictive to me I don't understand the logic behind it at all. I don't think anyone has suggested making album required. The current draft says that all hAudio instances *must* contain at fn *or* album. That is, album is optional when fn is present, and fn is optional when album is present. I had to look at the early implementers of haudio and see how they were using Item, No One currently is using Item The following use item... The official website of Adele, a singer/songwriter who reached #1 in the UK album chart earlier this year: http://adele.tv/music A review of an album I put together earlier: http://tobyinkster.co.uk/blog/2008/03/28/saturday-nights/ Some example uses of hAudio - contrived admittedly, but not too far away from the kind of stuff that gets published every day on blogs/ wikis/etc: http://buzzword.org.uk/2008/audio/uf http://weborganics.co.uk/haudio-rss/ A playlist on a blog: http://openmediaweb.org/index.php/2008/01/13/publishing-my-workout- music-in-haudio/ The last of these seems to be having server problems right now, but the source code can be verified at archive.org. There are probably others too. (I wish there were a search engine that allowed you to search by grepping through HTML source!) -- Toby A Inkster mailto:[EMAIL PROTECTED] http://tobyinkster.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 1.0 Draft Release
Sigh! Toby A Inkster wrote: Answering several messages in one... Martin McEvoy wrote: In Microformats this means that if a propery is used more than 80% of the time then it should be included in the format, this will result in the top 20% of all discovered properties making their way into the final Microformat. Well, that's mathematical nonsense. Say we have 100 examples, each of which have (on average) five properties, but many of these properties are unique, such that overall there are 300 properties discovered. Say also that only three of these properties are common enough to have been found in more than 80% of the examples. This means that you're saying that if the three properties that are used more than 80% of the time are included in the format, this will result in the top 20% of all discovered properties making their way into the microformat. ... Thus 20% of 300 is 3, right? Wrong! 20 % of 300 is 60 Right? http://www.google.co.uk/search?q=20%25+of+300 ;-) The Pareto Principle states that 80% of the effects emerge from 20% of the causes. correct. So if there are N potential properties that can be included in the format, we can get 80% of the potential benefit by including the best N/5 of the properties. I don't understand that sorry? I will repeat in simple terms how this should be applied to microformats design and proposal... In Microformats this means that if a propery is used more than 80% of the time (the effects) then it should be included in the format, this will result in the top 20% of all discovered properties making their way into the final Microformat (the causes). In Microformats implies that you require only 20% of the properties to solve all cases. Its really basic computer science Toby I am surprised that you of all people have trouble understanding the Pareto Principle? [...] The content type should certainly be made explicit when known, but making it a class name is a mistake - the type attribute should be used as above. Making it into a class takes it away from the link, so you end up with stuff like this, which is meaningless: div class=haudio span class=fnExample/span a rel=enclosure href=foo1download 1/a span class=typeaudio/ogg/span a rel=enclosure href=foo2download 2/a /div Do you ever read any of my emails? ...don't you mean div class=haudio span class=fnExample/span a rel=enclosure href=foo1 type=audio/oggdownload 1/a a rel=enclosure href=foo2 type=audio/oggdownload 2/a /div [...] I had to look at the early implementers of haudio and see how they were using Item, No One currently is using Item The following use item... The official website of Adele, a singer/songwriter who reached #1 in the UK album chart earlier this year: http://adele.tv/music hey I didn't know about this one nice job.. A review of an album I put together earlier: http://tobyinkster.co.uk/blog/2008/03/28/saturday-nights/ Nice too Some example uses of hAudio - contrived admittedly, but not too far away from the kind of stuff that gets published every day on blogs/wikis/etc: http://buzzword.org.uk/2008/audio/uf http://weborganics.co.uk/haudio-rss/ very much contrived, the latter of the two is due to be changed some time soon back to single haudios published inside hAtom, for podcasting in particular this is a better option. A playlist on a blog: http://openmediaweb.org/index.php/2008/01/13/publishing-my-workout-music-in-haudio/ ... The last of these seems to be having server problems right now, I have seen the page quite a few times but the source code can be verified at archive.org. There are probably others too. (I wish there were a search engine that allowed you to search by grepping through HTML source!) Unnecessary I think as all the examples you have cited are not really major implementers, I am not discrediting the authors efforts great job by all of them, but I must assume that all the authors are aware that hAudio has been in heavy almost continual development and knew at the time that the hAudio schema can and probably will from time to time change? Best Wishes -- Martin McEvoy http://weborganics.co.uk/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 1.0 Draft Release
Toby A Inkster wrote: I had to look at the early implementers of haudio and see how they were using Item, No One currently is using Item The following use item... For the Record Item Is a useful property in haudio, It is just defined incorrectly in the proposal In haudio Item is not Opaque, and is used entirely differently to the way existing microformats use item, which do process Item opaquely to save confusion Opaque means not transparent, Opaque glass is difficult to see through, If a Microformat is Opaque it means that nothing should be read from outside an Item (the Parent class) Using Item in an Opaque way represents the Union of things a connection between Microformats so to speak, but at the same time each Item is regarded as an individual or something in its own right. Thanks -- Martin McEvoy http://weborganics.co.uk/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 1.0 Draft Release
On [Oct 15], Martin McEvoy wrote: Sigh! Indeed. The content type should certainly be made explicit when known, but making it a class name is a mistake - the type attribute should be used as above. Making it into a class takes it away from the link, so you end up with stuff like this, which is meaningless: div class=haudio span class=fnExample/span a rel=enclosure href=foo1download 1/a span class=typeaudio/ogg/span a rel=enclosure href=foo2download 2/a /div Do you ever read any of my emails? ...don't you mean div class=haudio span class=fnExample/span a rel=enclosure href=foo1 type=audio/oggdownload 1/a a rel=enclosure href=foo2 type=audio/oggdownload 2/a /div You're both saying the same thing. In haudio Item is not Opaque Another imagined disagreement: Item [...] * The element MUST be processed opaquely. http://microformats.org/wiki/haudio#Item -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 1.0 Draft Release
Scott Reynen wrote: On [Oct 15], at [ Oct 15] 2:58 , Martin McEvoy wrote: None of the proposed removals are issues, I am simply applying the 80/20 rule to the existing schema using the Microformats Process If the 80/20 principle (not rule) hasn't been applied appropriately, that's an issue. How exactly has the 80/20 principle being used appropriately What is appropriate the remaining properties in the 1.0 version of hAudio occur at least 70% of the time in the audio examples pages. 70% is appropriate I think, this is because too many of the discovered properties fell between 70% and 80% mark, there would be almost nothing left of haudio if had applied the 80/20 principle. I am not being unfair in any way I'm not saying you're being unfair; I'm saying you're being unproductive. Quite the opposite I think the proposal is highly productive... You're wasting your own time just as much as anyone else's by presenting a full schema revision without discussion of the issues that prompted it. As we're now witnessing, that discussion is going to happen either way, but it will happen a lot smoother if everyone is talking about the same issue from the beginning. I would just like to move the haudio forward to being something publishers can use with confidence and understanding, in the end we will have a more stable format As would everyone. You can't do that alone, so you need to clearly explain your concerns to everyone else. And that's what issues are for. Scott this Is not an ISSUE, Its simply part of the final hAudio process, nothing more when exactly should I apply *some* principles to this process?, there haven't really been any yet haudio seems to keep growing every time someone wants to tack a new property to haudio, when does it end Scott Where do we say enough, right at the end when haudio is finally a Draft proposal? I am sorry seem to have upset one or two people with my recommendations You certainly haven't upset me with your recommendations. I suspect I agree with many of them. But I won't know that until you clearly explain them. Whether or not we call such explanations issues is beside the point. The point is to describe the problem before recommending a solution, to avoid the sort of talking in circles we're seeing here. No changes have been made yet we are just discussing the proposals here and now, then I wont have to tack more issues to haudio, like haudio is more like boiling the oceans than paving the cow paths..etc..etc. Thanks. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new -- Martin McEvoy http://weborganics.co.uk/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 1.0 Draft Release
Martin McEvoy wrote: http://microformats.org/wiki/haudio#Parser_Processing_Notes Parser Processing Notes * It is important to understand that ITEM is an opaque element. When processing the ITEM element, none of the properties of the child hAudio should be pulled into the parent hAudio. However, it is recommended that child hAudio /SHOULD/ inherit the following parent hAudio properties, if they are not specified on the child: o album o contributor o category o published o photo ...None of the above properties Should be inherited from the parent hAudio, Item is Not opaque when it does inherit all those extra properties and is something unknown to the way current microformats work, If Item is changed to have the ability to glean properties from the parent, then there is nothing opaque about it. The more I look at what Item intends to do the more I am realizing that we are reusing the wrong property Agent from hcard suits our purpose better its just the name that may cause Issues http://www.ietf.org/rfc/rfc2426.txt 3.5.4 AGENT Type Definition A key characteristic of the Agent type is that it represents somebody or something that is separately addressable. ... I don't know If that can be applied to haudio though would be interesting if it could :-) Thanks -- Martin McEvoy http://weborganics.co.uk/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
