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