From tantek at cs.stanford.edu Sun Sep 2 15:38:00 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sun Sep 2 15:37:26 2007 Subject: [uf-new] Re: [uf-discuss] hCite status and next steps In-Reply-To: <200708311317.13790.mail@jasoncalabrese.com> Message-ID: On 8/31/07 1:17 PM, "Jason Calabrese" wrote: > I'm going to be using hCite in 1 of the products that I work on. > > Since it will be only used interally for now I'm not going to wait for it to > become a recommended specification. I do plan to stay current though. > > It looks like there are 3 primary issues now. > > 1) Identifiers > 2) Types/Formats > 3) Nesting > > We're going use the uid class with nested type/id elements for identifiers. > For my use the type/format and citation nesting aren't needed so I'm going to > ignore them for now. > > Are there any other open issues? What is being done to resolve the issues? > Let me know how I can help. Hi Jason, Since the citation microformat is still very much underdevelopment, I'm redirecting your query to the microformats-new mailing list, where formats in progress are discussed. Please sign up on microformats-new. http://microformats.org/wiki/mailing-lists#microformats-new Thanks much! Tantek From sean at semanticbible.com Mon Sep 3 16:14:33 2007 From: sean at semanticbible.com (Sean) Date: Mon Sep 3 16:14:40 2007 Subject: [uf-new] proposed semantic HTML for Bible references Message-ID: <000501c7ee80$3063a610$2300000a@L820> I've posted a proposal for POSH to identify reference to Bible passages. An overview of the proposal is at http://www.semanticbible.com/bibleref/bibleref-overview.html: the bottom line is my suggestion to use a format like this: John 3:16 the third chapter of John's Gospel, verse 16 Etc. I see there was a thread on this at http://microformats.org/discuss/mail/microformats-discuss/2005-December/0021 87.html some time ago, but I don't see any resolution. I'd like to hear any comments from the list before pushing this farther along. This was spawned by some recent posts (see http://mattdabbs.wordpress.com/2007/05/14/most-blogged-scriptures/) where somebody was trying to estimate the number of blog posts on different passages by string search (which, as you'd expect, only works imperfectly). Given the thousands of blog posts referencing Bible verses, this seems like a ripe area for some attempts to define a standard. Sean sean@semanticbible.com From andy at pigsonthewing.org.uk Tue Sep 4 01:14:54 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Sep 4 01:16:22 2007 Subject: [uf-new] proposed semantic HTML for Bible references In-Reply-To: <000501c7ee80$3063a610$2300000a@L820> References: <000501c7ee80$3063a610$2300000a@L820> Message-ID: In message <000501c7ee80$3063a610$2300000a@L820>, Sean writes >I've posted a proposal for POSH to identify reference to Bible >passages. Please note the ongoing work at: et seq. -- Andy Mabbett From sean.boisen at gmail.com Thu Sep 6 22:00:59 2007 From: sean.boisen at gmail.com (Sean Boisen) Date: Thu Sep 6 22:01:09 2007 Subject: [uf-new] proposed semantic HTML for Bible references In-Reply-To: References: <000501c7ee80$3063a610$2300000a@L820> Message-ID: <001c01c7f10c$15d30140$0402a8c0@L820> Thanks for pointing out that work, Andy. Existing and well-established practice in citing Bible passages is rather different from most of these: * Book (of the Bible, e.g. Isaiah or Is.), chapter and verse designators are the most common: "Is 40:6" would be a typical case. * Sometimes a specific translation is referenced, usually with an abbreviation: e.g. "KJV" for the King James Version. * Fields like author, publication date, publisher, volume, etc. simply aren't used for 99% of the cases: that's not what people care about when citing Bible passages. So I'm not sure whether it's appropriate for me to add these examples to the wiki pages: thoughts? Sean -----Original Message----- From: Andy Mabbett [mailto:andy@pigsonthewing.org.uk] Sent: Tuesday, September 04, 2007 1:15 AM To: sean@semanticbible.com; For discussion of new microformats. Subject: Re: [uf-new] proposed semantic HTML for Bible references In message <000501c7ee80$3063a610$2300000a@L820>, Sean writes >I've posted a proposal for POSH to identify reference to Bible >passages. Please note the ongoing work at: et seq. -- Andy Mabbett From bhawkeslewis at googlemail.com Thu Sep 6 23:32:47 2007 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Thu Sep 6 23:32:56 2007 Subject: [uf-new] proposed semantic HTML for Bible references In-Reply-To: <001c01c7f10c$15d30140$0402a8c0@L820> References: <000501c7ee80$3063a610$2300000a@L820> <001c01c7f10c$15d30140$0402a8c0@L820> Message-ID: <46E0F08F.10703@googlemail.com> Sean Boisen wrote: > Thanks for pointing out that work, Andy. Existing and well-established > practice in citing Bible passages is rather different from most of these: > * Book (of the Bible, e.g. Isaiah or Is.), chapter and verse designators are > the most common: "Is 40:6" would be a typical case. > * Sometimes a specific translation is referenced, usually with an > abbreviation: e.g. "KJV" for the King James Version. > * Fields like author, publication date, publisher, volume, etc. simply > aren't used for 99% of the cases: that's not what people care about when > citing Bible passages. > > So I'm not sure whether it's appropriate for me to add these examples to the > wiki pages: thoughts? Bible citations are not a unique case. Citations from ancient texts (especially other holy books, and classical and medieval texts) and plays often use similar formats, e.g.: /S?ra/ 18, v. 45 /Plat/, Charm. 173 E3 /Ovid/, Amores 3.1.15 /2 Henry IV/, IV. ii. 8 I think one reason for such conventions is that such texts represent manuscript traditions rather than being defined by a single edition. Along with other specialised formats (e.g. legal citations), hCite needs to at least think about handling all of these. -- Benjamin Hawkes-Lewis > Sean > > -----Original Message----- > From: Andy Mabbett [mailto:andy@pigsonthewing.org.uk] > Sent: Tuesday, September 04, 2007 1:15 AM > To: sean@semanticbible.com; For discussion of new microformats. > Subject: Re: [uf-new] proposed semantic HTML for Bible references > > In message <000501c7ee80$3063a610$2300000a@L820>, Sean > writes > >> I've posted a proposal for POSH to identify reference to Bible >> passages. > > Please note the ongoing work at: > > > > et seq. > From msporny at digitalbazaar.com Fri Sep 7 13:42:40 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Fri Sep 7 13:42:46 2007 Subject: [uf-new] hAudio case study Message-ID: <46E1B7C0.3080800@digitalbazaar.com> Here's some weekend reading for those that are interested. :) We've documented our experience with the Microformats community, the W3C RDFa task force, the Microformat creation process, and the current status of hAudio in a case study: http://wiki.digitalbazaar.com/en/haudio-case-study I'd be interested to hear feedback and suggestions as this case study will probably be incorporated/linked-to in a W3C document (the RDFa Primer, most likely) at some point in the near future. -- manu From tantek at cs.stanford.edu Fri Sep 7 16:40:28 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Fri Sep 7 16:39:50 2007 Subject: [uf-new] hAudio case study In-Reply-To: <46E1B7C0.3080800@digitalbazaar.com> Message-ID: On 9/7/07 1:42 PM, "Manu Sporny" wrote: > Here's some weekend reading for those that are interested. :) > > We've documented our experience with the Microformats community, the W3C > RDFa task force, the Microformat creation process, and the current > status of hAudio in a case study: > > http://wiki.digitalbazaar.com/en/haudio-case-study Manu, that's an exceptionally thorough write-up. I've captured the issues you noted (or at least a pointer to them) here: http://microformats.org/wiki/process-issues While I may not necessarily agree with all the issues/points you raise, I want to thank you for your frank feedback, and I'm hoping that open documentation and resolution of such issues itself addresses at least some of your issues (if not most or all). > I'd be interested to hear feedback and suggestions as this case study > will probably be incorporated/linked-to in a W3C document (the RDFa > Primer, most likely) at some point in the near future. The biggest feedback I have is that there are several assertions (such as about being "scope-less" etc.) that I think are faulty due to no fault or at least intent of yours, but rather due to implicit assumptions, and that rather than stating such assertions as fact, it may be better to state them as questions to be explored. Regarding the community-related issues specifically, expect some particularly swift movement on that front in the next few weeks. Thanks, Tantek From msporny at digitalbazaar.com Sat Sep 8 12:29:45 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sat Sep 8 12:29:49 2007 Subject: [uf-new] The Process (was: hAudio case study) In-Reply-To: References: Message-ID: <46E2F829.2090104@digitalbazaar.com> Tantek ?elik wrote: >> http://wiki.digitalbazaar.com/en/haudio-case-study > > Manu, that's an exceptionally thorough write-up. Thanks :). One of the goals was to lay some more ground work for others that may want to create new Microformats or contribute to semantic web projects, but didn't know where to start. > I've captured the issues you noted (or at least a pointer to them) here: > http://microformats.org/wiki/process-issues Great! That is very helpful as it makes us feel like issues with The Process are being heard outside of the mailing list. I've added an issue that is subtly different from #3: # Issue 4: There is no clear order of operations for "The Process". This makes uF creation a trial-and-error process that can frustrate new members, that may waste time on things that don't matter. It also annoys old members of the community, that have to answer the same questions over and over again. In an attempt to address this issue, Brian Suda and I have been working on a New Microformat HOW-TO document. It gives a straightforward set of steps for anybody that wants to create a new Microformat to follow: http://microformats.org/wiki/how-to-start-a-new-microformat The last three steps aren't completed yet, it's a work in progress that I hope will be completed later this month. The goal of the document is to not only outline the steps, but the logic behind each step. I hope the document will do the following: 1. Give newcomers to Microformats a straight-foward, step-by-step guide on how to create a new Microformat. 2. Explain the logic behind each step, in an attempt to counter-act the notions that a "Cabal" is in charge of Microformats. If we can all agree on the logic behind each step of The Process, then I hope that we can improve cohesion in this community. Thoughts/feedback? -- manu From msporny at digitalbazaar.com Sat Sep 8 12:36:11 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sat Sep 8 12:36:14 2007 Subject: [uf-new] hAudio case study In-Reply-To: References: Message-ID: <46E2F9AB.3060107@digitalbazaar.com> Tantek ?elik wrote: > While I may not necessarily agree with all the issues/points you > raise, I want to thank you for your frank feedback, and I'm hoping > that open documentation and resolution of such issues itself addresses > at least some of your issues (if not most or all). This is why we continue to work with this community - because you and others that started it truly care about the health of the community and continue to foster improvement and resolutions to outstanding issues. Completely open dialog is one of the shining examples of what differentiates Microformats from the other standards organizations. You and the rest of the admins should be commended for managing this most unenviable task. Note that I don't think that drastic changes are required to address our problems with the process and community. In fact, with RDFa in the picture, I think that a huge part of realizing the semantic web has been solved. Microformats will solve 80% of the semantic data markup problems out there while RDFa can solve the remaining 20%. Anything that makes Microformats more complicated should be scrutinized and probably rejected... but not at the cost of ensuring greater Microformat adoption. It is a very tough line to walk... and one that I think the community is doing a good job of thus far. I think the issues that have been raised would take very minor changes to address. >> I'd be interested to hear feedback and suggestions as this case study >> will probably be incorporated/linked-to in a W3C document (the RDFa >> Primer, most likely) at some point in the near future. > > The biggest feedback I have is that there are several assertions (such as > about being "scope-less" etc.) that I think are faulty due to no fault or at > least intent of yours, but rather due to implicit assumptions, and that > rather than stating such assertions as fact, it may be better to state them > as questions to be explored. Some guidance would be good at this point. I did my best to be fair while letting readers know about the current state of the Microformats approach. Some have asserted that Microformats aren't scope-less... but I have not seen evidence to the contrary. Perhaps by answering the following questions you could help me (and others) understand why you don't believe Microformats aren't scope-less. Definition of Scope: """ In computer programming in general, a scope is an enclosing context. Scopes have contents which are associated with them. Various programming languages have various types of scopes. The type of scope determines what kind of entities it can contain and how it affects them. Depending on its type, a scope can: * contain declarations or definitions of identifiers; * contain statements and/or expressions which define an executable algorithm or part thereof; * nest or be nested. """[1] I guess you could argue that there are two scopes for Microformats: * page-scope * declaration-scope. Page scope is the entire web page and this is where some of the elemental Microformats can exist without being enclosed by hCard, hCalendar or hAudio. Declaration scope is the section of the HTML that is enclosed by hCard, hCalendar or hAudio. However, Microformats cannot differentiate between an elemental Microformat that is supposed to be at page-scope and not declaration-scope, correct? When two Microformats overlap, a property can co-exist in both Microformats, correct? If the answer to the above two are yes, the I don't think we can call Microformats a "scoped" approach to this syntax, can we? I know that we can call RDFa scoped, so there is an example of something that is a scoped semantic definition method. Perhaps "scope-less" isn't the best word choice, but I couldn't think of a different word choice to use. Any ideas? -- manu [1] http://en.wikipedia.org/wiki/Scope_(programming) From msporny at digitalbazaar.com Sat Sep 8 13:20:51 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sat Sep 8 13:20:55 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant Message-ID: <46E30423.20404@digitalbazaar.com> Most of hAlbum's properties overlap with hAudio. In fact, the only two properties that do not overlap with hAudio are 'album-title' and 'track'. It has been proposed that we merge these two properties into hAudio to provide a cleaner, more unified way of describing audio songs and albums. Examples of how this would work along with the rest of the arguments are located on the wiki: http://microformats.org/wiki/audio-info-issues#Problem:_hAlbum_is_redundant This approach has a number of benefits: - We'd be able to get rid of hAlbum (which I proposed, but never really liked all that much). One less Microformat is good. Minimalism is good. - It provides an elegant way to extend hAudio to albums, podcasts, toplists and other audio collections. - It would address an issue that the Songbird folks had with hAudio (not being to specify album-title in an hAudio). - Parser implementation is simpler - less code to write to parse both hAudio AND hAlbum. - It would effectively close the debate on using 'fn' or 'audio-title'. Resolving two issues with one proposal. We'll be implementing this in the next several weeks on our website to see how it works. If the implementation goes smoothly, I'd like to adopt this method as the standard way of doing albums in hAudio. Thoughts and comments from everybody on this approach would be great at this point. If you wanted to vote for/against it, the link is here: http://microformats.org/wiki/audio-info-issues#Votes_7 -- manu From martin at weborganics.co.uk Sat Sep 8 17:30:54 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Sep 8 17:30:51 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <46E30423.20404@digitalbazaar.com> References: <46E30423.20404@digitalbazaar.com> Message-ID: <1189297854.19341.22.camel@localhost.localdomain> On Sat, 2007-09-08 at 16:20 -0400, Manu Sporny wrote: > Most of hAlbum's properties overlap with hAudio. In fact, the only two > properties that do not overlap with hAudio are 'album-title' and 'track'. > Does hAudio then describe a collection of hAudio's ? > It has been proposed that we merge these two properties into hAudio to > provide a cleaner, more unified way of describing audio songs and > albums. Examples of how this would work along with the rest of the > arguments are located on the wiki: Great proposal Manu this will save a lot of confusion over hAlbum and hAudio, and save bloating the wiki with proposals that probably wont be used such as hAlbum. > > http://microformats.org/wiki/audio-info-issues#Problem:_hAlbum_is_redundant > > This approach has a number of benefits: > > - We'd be able to get rid of hAlbum (which I proposed, but never really > liked all that much). One less Microformat is good. Minimalism is > good. +1 for that > - It provides an elegant way to extend hAudio to albums, podcasts, > toplists and other audio collections. + for that too should we also add a type class Album Podcast Compilation etc... > - It would address an issue that the Songbird folks had with hAudio > (not being to specify album-title in an hAudio). We need to also address and discuss descriptions for this to become complete. > - Parser implementation is simpler - less code to write to parse both > hAudio AND hAlbum. which is always a plus + > - It would effectively close the debate on using 'fn' or 'audio-title'. > Resolving two issues with one proposal. > > We'll be implementing this in the next several weeks on our website to > see how it works. If the implementation goes smoothly, I'd like to adopt > this method as the standard way of doing albums in hAudio. > > Thoughts and comments from everybody on this approach would be great at > this point. If you wanted to vote for/against it, the link is here: > > http://microformats.org/wiki/audio-info-issues#Votes_7 > > -- manu Thank you Martin > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From andy at pigsonthewing.org.uk Sun Sep 9 02:23:10 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Sep 9 02:24:36 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <46E30423.20404@digitalbazaar.com> References: <46E30423.20404@digitalbazaar.com> Message-ID: In message <46E30423.20404@digitalbazaar.com>, Manu Sporny writes >Most of hAlbum's properties overlap with hAudio. In fact, the only two >properties that do not overlap with hAudio are 'album-title' and >'track'. > >It has been proposed that we merge these two properties into hAudio You prose: # If only 'album-title' is specified, then the hAudio is an album. # If only 'audio-title' is specified, then the hAudio is a song/speech or other singular work. # If both 'album-title' and 'audio-title' is specified, then the hAudio is a song that is part of an album. I think those names are confusing; they should be: albunm-title + track-title or simply: album + track I'm also not clear why, for two tracks on one album, three hAudio microformats are required. Why not:
Live Phish, Volume 15 Phish Sanity (5:48) Highway To Hell (3:39)
Finally, please note that "3:39" is not an abbreviation of "219". -- Andy Mabbett From andy at pigsonthewing.org.uk Sun Sep 9 02:34:56 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Sep 9 02:36:39 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <1189297854.19341.22.camel@localhost.localdomain> References: <46E30423.20404@digitalbazaar.com> <1189297854.19341.22.camel@localhost.localdomain> Message-ID: <6UBkM0DA574GFw0D@pigsonthewing.org.uk> In message <1189297854.19341.22.camel@localhost.localdomain>, Martin McEvoy writes >> - It would address an issue that the Songbird folks had with hAudio >> (not being to specify album-title in an hAudio). > >We need to also address and discuss descriptions for this to become >complete. I've also asked before for a "note" property to be included. I'm also not clear why the property for sleeve artwork is called "image-summary" and not just "image". -- Andy Mabbett From msporny at digitalbazaar.com Sun Sep 9 06:41:21 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Sep 9 06:41:24 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <1189297854.19341.22.camel@localhost.localdomain> References: <46E30423.20404@digitalbazaar.com> <1189297854.19341.22.camel@localhost.localdomain> Message-ID: <46E3F801.6050504@digitalbazaar.com> Martin McEvoy wrote: > On Sat, 2007-09-08 at 16:20 -0400, Manu Sporny wrote: >> Most of hAlbum's properties overlap with hAudio. In fact, the only two >> properties that do not overlap with hAudio are 'album-title' and 'track'. > > Does hAudio then describe a collection of hAudio's ? If we make the proposed change, hAudio will be able to describe a collection of audio recordings and a single audio recording. I think the short answer to your question is 'Yes'. >> - It provides an elegant way to extend hAudio to albums, podcasts, >> toplists and other audio collections. > > + for that too > > should we also add a type class > > Album > Podcast > Compilation That's one of the benefits of this proposal, we won't need a TYPE class! This is because the type can be inferred from the parsing rules that are outlined in the proposal. You will know the type by the contents of the hAudio used: hAudio Contents Type --------------- ----------- audio-title Audio Recording audio-title + album-title Audio Recording with Album info album-title Album toplist-title Top List podcast-title Podcast -- manu -- Manu Sporny President/CEO, Digital Bazaar, Inc. http://blog.digitalbazaar.com/ From msporny at digitalbazaar.com Sun Sep 9 07:18:29 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Sep 9 07:18:32 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: References: <46E30423.20404@digitalbazaar.com> Message-ID: <46E400B5.8020905@digitalbazaar.com> Andy Mabbett wrote: > # If both 'album-title' and 'audio-title' is specified, then the > hAudio is a song that is part of an album. > > I think those names are confusing; they should be: > > albunm-title + track-title > > or simply: > > album + track Of the two, I'd prefer the latter method. What about using RECORDING? This would allow us to re-use that class name in hVideo to denote the name of a video recording. We can't use TRACK as that is the class name we're using to denote the tracks in an album. That being said, would something like this work? hAudio Contents Type --------------- ----------- recording Audio Recording recording + album Audio Recording with Album info album Album toplist Top List podcast Podcast > I'm also not clear why, for two tracks on one album, three hAudio > microformats are required. If we make TRACK a container object, then it must have the exact same semantics as hAudio. If I understand you correctly, TRACK is no different from HAUDIO in your proposal. Do we want to have two CLASS names that have the exact same semantics, but different names? The proposal was to use TRACK to denote individual tracks and HAUDIO to contain all data represented in the track. > (3:39) > > Finally, please note that "3:39" is not an abbreviation of "219". Thanks for catching that :) Duration uses the ISO-8601 format for marking up durations. I've fixed the audio-info-proposal, album-info-proposal, and audio-info-issues pages. > I've also asked before for a "note" property to be included. This issue is recorded as hAudio ISSUE #6: http://microformats.org/wiki/audio-info-issues#Problem:_Summary_Property_is_Missing Please vote on the issue to help resolve it: http://microformats.org/wiki/audio-info-issues#Votes_6 > I'm also not clear why the property for sleeve artwork is called > "image-summary" and not just "image". This issue is recorded as hAudio ISSUE #1: http://microformats.org/wiki/audio-info-issues#image-summary_Property Please vote on the issue to help resolve it: http://microformats.org/wiki/audio-info-issues#Votes -- manu From martin at weborganics.co.uk Sun Sep 9 09:36:19 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Sep 9 09:36:15 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <6UBkM0DA574GFw0D@pigsonthewing.org.uk> References: <46E30423.20404@digitalbazaar.com> <1189297854.19341.22.camel@localhost.localdomain> <6UBkM0DA574GFw0D@pigsonthewing.org.uk> Message-ID: <1189355779.20529.3.camel@localhost.localdomain> On Sun, 2007-09-09 at 10:34 +0100, Andy Mabbett wrote: > In message <1189297854.19341.22.camel@localhost.localdomain>, Martin > McEvoy writes > > >> - It would address an issue that the Songbird folks had with hAudio > >> (not being to specify album-title in an hAudio). > > > >We need to also address and discuss descriptions for this to become > >complete. > > I've also asked before for a "note" property to be included. > The vote at the moment is to use "description" there is a vote on this issue http://microformats.org/wiki/audio-info-issues#Problem:_Summary_Property_is_Missing > I'm also not clear why the property for sleeve artwork is called > "image-summary" and not just "image". There is a vote on this http://microformats.org/wiki/audio-info-issues#image-summary_Property please add your vote here At the moment the vote is for just simply "PHOTO" Martin > From msporny at digitalbazaar.com Mon Sep 10 20:27:10 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Sep 10 20:27:13 2007 Subject: [uf-new] Launching the hVideo exploratory discussion! Message-ID: <46E60B0E.8080108@digitalbazaar.com> The video-info exploratory discussion has been created on the wiki. There are currently 22 examples that have been analyzed so far: http://microformats.org/wiki/video-info-examples Here are the property leaders with the current set of data: # title: 95.65% # comments: 86.96% # image summary: 86.96% # published: 86.96% # category: 82.61% # contributor: 78.26% # description: 78.26% # flash player: 78.26% # popularity rating: 73.91% # number of views: 69.57% # email video url: 60.87% # related content: 56.52% # number of comments: 56.52% # permalink url: 52.17% Example collection and analysis was performed using Microformalyze: http://wiki.digitalbazaar.com/en/Microformalyze The tool allowed analysis to be performed at a rate of around 10 sites per hour. The rate was around 3 sites per hour when working on hAudio. We could really use some help with more links to video sites. If you use a video site, please add it to the list of video sites awaiting analysis: http://microformats.org/wiki/video-info-examples#Video_Sites_Needing_Analysis -- manu From fberriman at gmail.com Tue Sep 11 04:47:06 2007 From: fberriman at gmail.com (Frances Berriman) Date: Tue Sep 11 04:47:11 2007 Subject: [uf-new] hAudio case study In-Reply-To: <46E1B7C0.3080800@digitalbazaar.com> References: <46E1B7C0.3080800@digitalbazaar.com> Message-ID: On 07/09/2007, Manu Sporny wrote: > Here's some weekend reading for those that are interested. :) > > We've documented our experience with the Microformats community, the W3C > RDFa task force, the Microformat creation process, and the current > status of hAudio in a case study: > > http://wiki.digitalbazaar.com/en/haudio-case-study > > I'd be interested to hear feedback and suggestions as this case study > will probably be incorporated/linked-to in a W3C document (the RDFa > Primer, most likely) at some point in the near future. > That's a thoroughly interesting read. Thanks for creating this - I imagine it will be valuable as a primer for those interested in creating some type of microformat (or wondering if microformats are indeed for them) and maybe how the process works. Talking of... I note that one of your encountered problems was with the process itself. Was it just the shifting/vague targets that were the main problem, or do you have others? Any extra feedback would be great, since it would be a good thing to work towards a really solid set of guidelines that we can hopefully make as simple to understand as possible and easy to stick to. As you say... we're in new territory to some degree, so all feedback is helpful. -- Frances Berriman http://fberriman.com From mary at dabble.com Tue Sep 11 09:45:22 2007 From: mary at dabble.com (Mary Hodder) Date: Tue Sep 11 09:45:41 2007 Subject: [uf-new] Launching the hVideo exploratory discussion! In-Reply-To: <46E60B0E.8080108@digitalbazaar.com> References: <46E60B0E.8080108@digitalbazaar.com> Message-ID: Hi Manu, Thanks for sharing your list. Though I would say it appears to reflect what is located in APIs or feeds or html pages from a small subset of video hosting companies, not what we see overall, or what users publish on their own. Is the video microformat use case one that is about video hosters or about what users do, or both? At Dabble, as we take in metadata from both sources, we see users and hosters publishing titles, thumbnail (users don't call it "image summary" and actually, the hosters don't either much), category AND tags, uploader, director or creator, license, description, duration, sometimes size, and almost always, urls for html page, with some people giving multiple download and streaming urls. In fact there is almost always a "permalink url" (how did you come up with 58% on that one?) because no one would be able to get to it if that didn't exist. What we never see is "published" (what does that mean?) or "email video url" in a feed or api.. sometimes that's on a page and often buried in flash or dhtml .. but it wouldn't be very helpful, as it's actually the same as the html url usually with extra code for email. Also most individual users never publish "popularity rating" or "number of views" etc. I thought the point of the microformat was for users and publishing companies to be able to put out data that would be easily readable in both an RSS feed and via spidering an html page, that was commonly published online? I think the basic set of commonly published items includes: title html url (sometimes same and sometimes different from the url to embed, or link directly to the video) video url (if existing - could be multiple, see Blip or Revver or soon to be Youtube) category and / or tags description license creator or uploader or both (many youtube videos have both, with "director" as the creator designation) embed code size duration We see these all elements highly published. We don't typically see any comments come through feeds or apis, but they are certainly on the page at the site, and if say, like Youtube, they can be spidered, then yes.. there are comments. If the goal is to make microformats for publishers, then it might make sense to include: number of views comments number of comments popularity ratings Also, the sense I get from your write up here: http://microformats.org/wiki/video-info-examples is that you are more interested in the use-case of microformats for selling video or other content. But I don't think most video on the web is about that, nor will it be. I expect much of that will die out over the next two years, as some of what was there two years ago died out (see google video's retraction of for-pay video, or the increase in video that iTunes carries for free). And I don't see a lot of it now. my 2 cents.. i hope that's helpful. mary Mary Hodder On Sep 10, 2007, at 8:27 PM, Manu Sporny wrote: > The video-info exploratory discussion has been created on the wiki. > There are currently 22 examples that have been analyzed so far: > > http://microformats.org/wiki/video-info-examples > > Here are the property leaders with the current set of data: > > # title: 95.65% > # comments: 86.96% > # image summary: 86.96% > # published: 86.96% > # category: 82.61% > # contributor: 78.26% > # description: 78.26% > # flash player: 78.26% > # popularity rating: 73.91% > # number of views: 69.57% > # email video url: 60.87% > # related content: 56.52% > # number of comments: 56.52% > # permalink url: 52.17% > > Example collection and analysis was performed using Microformalyze: > > http://wiki.digitalbazaar.com/en/Microformalyze > > The tool allowed analysis to be performed at a rate of around 10 sites > per hour. The rate was around 3 sites per hour when working on hAudio. > > We could really use some help with more links to video sites. If > you use > a video site, please add it to the list of video sites awaiting > analysis: > > http://microformats.org/wiki/video-info- > examples#Video_Sites_Needing_Analysis > > -- manu > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Tue Sep 11 12:11:36 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Sep 11 12:11:40 2007 Subject: [uf-new] Launching the hVideo exploratory discussion! In-Reply-To: References: <46E60B0E.8080108@digitalbazaar.com> Message-ID: <46E6E868.20308@digitalbazaar.com> Mary Hodder wrote: > Is the video microformat use case one that is about video hosters or > about what users do, or both? Both... we're going for general video metadata markup. :) > At Dabble, as we take in metadata from both sources, we see users and > hosters publishing titles, thumbnail (users don't call it "image > summary" and actually, the hosters don't either much), category AND > tags, uploader, director or creator, license, description, duration, > sometimes size, and almost always, urls for html page, with some people > giving multiple download and streaming urls. Just to be clear, those names are "property names"... they are not the official Microformat "class name" that we are going to use in hVideo. It is too early to decide on a vocabulary yet... expect most of those names to change (re-used from other Microformats if possible, created if there is no other choice). We do, however, define what every one of those property names mean on the video-info-examples page: http://microformats.org/wiki/video-info-examples#Properties > In fact there is almost > always a "permalink url" (how did you come up with 58% on that one?) The Permalink URLs are for sites that explicitly state a Permalink URL on the page. Believe it or not, only 58% of the examples had permalinks. I was surprised as well, but it shows us why we collect examples. > because no one would be able to get to it if that didn't exist. > > What we never see is "published" (what does that mean?) or "email video > url" in a feed or api.. All definitions of property names are listed on the video-info-examples page: http://microformats.org/wiki/video-info-examples#Properties published - The Published Date specifies the date that a video file was made available to the public. Examples include: The airing date of a video podcast, the air date of a television show, or the release date of a movie. > sometimes that's on a page and often buried in > flash or dhtml .. but it wouldn't be very helpful, as it's actually the > same as the html url usually with extra code for email. If the data is in the DOM somewhere, we included the property. If the data doesn't reside in the DOM, then we did not include the property. > Also most individual users never publish "popularity rating" or "number > of views" etc. Got a list of examples that we could merge into the video-info-examples page? That would be very helpful... > I thought the point of the microformat was for users and publishing > companies to be able to put out data that would be easily readable in > both an RSS feed and via spidering an html page, that was commonly > published online? It is! Most users are publishing video via MySpace, Yahoo Video, Google Video and YouTube... service websites. However, if you have another subculture that we should examine, please give us some links so that we may analyze those sites as well. > I think the basic set of commonly published items includes: > > title > html url (sometimes same and sometimes different from the url to embed, > or link directly to the video) > video url (if existing - could be multiple, see Blip or Revver or soon > to be Youtube) > category and / or tags > description > license > creator or uploader or both (many youtube videos have both, with > "director" as the creator designation) > embed code > size > duration > > We see these all elements highly published. We need your examples, then! :) > Also, the sense I get from your write up here: > http://microformats.org/wiki/video-info-examples > > is that you are more interested in the use-case of microformats for > selling video or other content. Nope... in fact, what we're finding is that most of the video sites do not sell content! Bummer, as we were hoping we'd find that they do... :) but since we can't find many examples of this happening, it nullifies the idea that this is a use-case for selling video or other content. Thanks for the input Mary, always appreciated :). Do these statements help clarify matters? -- manu From mary at dabble.com Tue Sep 11 12:45:38 2007 From: mary at dabble.com (Mary Hodder) Date: Tue Sep 11 12:45:56 2007 Subject: [uf-new] Launching the hVideo exploratory discussion! In-Reply-To: <46E6E868.20308@digitalbazaar.com> References: <46E60B0E.8080108@digitalbazaar.com> <46E6E868.20308@digitalbazaar.com> Message-ID: <9DF1E035-1BBD-48FB-9AE7-08CBE1DB48CC@dabble.com> Hi Manu, So the names you use here: http://microformats.org/wiki/video-info- examples#Properties don't all make sense to me. Where did they come from? Some of them I've never seen used before. Published? that does mean anything without the explanation. Why can't you just use "date" so that we know what you are talking about? No need for long explanations if we do that. There are examples here: http://microformats.org/wiki/media-info-examples#Video Why do you need more examples? In the new page you just made here: http://microformats.org/wiki/video-info-examples Why not combine? You've surveyed the hosters (which I'd already done somewhat on the old page here: http://microformats.org/wiki/media-info-examples#Video) and we have the individually published items here at this page (p:// microformats.org/wiki/video-info-examples). So our combined info, spread across two wiki pages, makes the case for the simple list of metadata about video for publishers based upon what they do in practice. I'm not really sure what you are getting at with your list of properties then? We know what the examples are, we've documented them, and the properties list takes us askew. We know people, all over the web, across the 27 million videos Dabble has indexed, as well as the rest of the videos we don't have but are mostly hosted by those same 1000 hosters, that this list rings true: >> title >> html url (sometimes same and sometimes different from the url to >> embed, >> or link directly to the video) >> video url (if existing - could and needs to have multiples, see >> Blip or Revver or soon >> to be Youtube) >> category and / or tags >> description >> license >> creator or uploader or both (many youtube videos have both, with >> "director" as the creator designation) >> embed code >> size >> duration and if you want to have it, then add these: views comments ratings If most video is not for sale, why does your properties list have "purchase url" and "price" or why have "report url".. that isn't used at all by anyone in any feeds or published video we see at all. What is the difference between "flash player url" and "embed" .. they are the same thing and given in tags typically. By putting price and purchase URL right at the top of the definitions you are giving me the impression that you care most about that. If you'd like, I can edit the wiki list to make sense to regular people (ie change published to date or whatever) and then we can make a simple microformat out of a more simple list. But the list you provided, in the order you provided, is not what we see people publish, and it's not reflected in the example on either wiki page (my older one, or your newer one). mary On Sep 11, 2007, at 12:11 PM, Manu Sporny wrote: > Mary Hodder wrote: >> Is the video microformat use case one that is about video hosters or >> about what users do, or both? > > Both... we're going for general video metadata markup. :) > >> At Dabble, as we take in metadata from both sources, we see users and >> hosters publishing titles, thumbnail (users don't call it "image >> summary" and actually, the hosters don't either much), category AND >> tags, uploader, director or creator, license, description, duration, >> sometimes size, and almost always, urls for html page, with some >> people >> giving multiple download and streaming urls. > > Just to be clear, those names are "property names"... they are not the > official Microformat "class name" that we are going to use in > hVideo. It > is too early to decide on a vocabulary yet... expect most of those > names > to change (re-used from other Microformats if possible, created if > there > is no other choice). We do, however, define what every one of those > property names mean on the video-info-examples page: > > http://microformats.org/wiki/video-info-examples#Properties > >> In fact there is almost >> always a "permalink url" (how did you come up with 58% on that one?) > > The Permalink URLs are for sites that explicitly state a Permalink URL > on the page. Believe it or not, only 58% of the examples had > permalinks. > I was surprised as well, but it shows us why we collect examples. > >> because no one would be able to get to it if that didn't exist. >> >> What we never see is "published" (what does that mean?) or "email >> video >> url" in a feed or api.. > > All definitions of property names are listed on the video-info- > examples > page: > > http://microformats.org/wiki/video-info-examples#Properties > > published - The Published Date specifies the date that a video file > was > made available to the public. Examples include: The airing date of a > video podcast, the air date of a television show, or the release > date of > a movie. > >> sometimes that's on a page and often buried in >> flash or dhtml .. but it wouldn't be very helpful, as it's >> actually the >> same as the html url usually with extra code for email. > > If the data is in the DOM somewhere, we included the property. If the > data doesn't reside in the DOM, then we did not include the property. > >> Also most individual users never publish "popularity rating" or >> "number >> of views" etc. > > Got a list of examples that we could merge into the video-info- > examples > page? That would be very helpful... > >> I thought the point of the microformat was for users and publishing >> companies to be able to put out data that would be easily readable in >> both an RSS feed and via spidering an html page, that was commonly >> published online? > > It is! Most users are publishing video via MySpace, Yahoo Video, > Google > Video and YouTube... service websites. However, if you have another > subculture that we should examine, please give us some links so > that we > may analyze those sites as well. > >> I think the basic set of commonly published items includes: >> >> title >> html url (sometimes same and sometimes different from the url to >> embed, >> or link directly to the video) >> video url (if existing - could be multiple, see Blip or Revver or >> soon >> to be Youtube) >> category and / or tags >> description >> license >> creator or uploader or both (many youtube videos have both, with >> "director" as the creator designation) >> embed code >> size >> duration >> >> We see these all elements highly published. > > We need your examples, then! :) > >> Also, the sense I get from your write up here: >> http://microformats.org/wiki/video-info-examples >> >> is that you are more interested in the use-case of microformats for >> selling video or other content. > > Nope... in fact, what we're finding is that most of the video sites do > not sell content! Bummer, as we were hoping we'd find that they > do... :) > but since we can't find many examples of this happening, it nullifies > the idea that this is a use-case for selling video or other content. > > Thanks for the input Mary, always appreciated :). Do these statements > help clarify matters? > > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Tue Sep 11 12:54:13 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Sep 11 12:54:22 2007 Subject: [uf-new] The Process (was: hAudio case study) In-Reply-To: References: <46E1B7C0.3080800@digitalbazaar.com> Message-ID: <46E6F265.9090801@digitalbazaar.com> Frances Berriman wrote: > I imagine it will be valuable as a primer for those interested in > creating some type of microformat (or wondering if microformats are > indeed for them) and maybe how the process works. Good, as that is one of the goals of the document :) > Talking of... I note that one of your encountered problems was with > the process itself. Was it just the shifting/vague targets that were > the main problem, or do you have others? Shifting/vague targets was the most frustrating part of the process. The idea that Microformat authors now are being held to a different standard than the ones that created hCard, hCalendar and hReview. For example, once we had collected around 30 examples for hAudio, we thought we had enough. After all, review-examples (hReview) only has 17 examples collected. However, some on the list kept going on about collecting more examples before a decision could be made. After we had 50 examples, the same issue was brought up that we needed more examples. Thus we went overboard and collected over 100 examples. To us it seemed like this was an unfair argument that was thrown out there whenever we disagreed with somebody that was "more senior" in the community. The argument came across as "Well, you're just not analyzing the correct sites - otherwise, you'd see my point... so why don't you go and analyze more examples until you can prove us right". The person making the previous statement doesn't have to do anything to defend their viewpoint and the person creating the Microformat now has to spend tens of hours collecting more examples. In the end, it made hAudio better - but at the expense of frustrating the Microformat authors. The other issue seemed to deal with being surprised by things that you couldn't do with Microformats, as the wiki doesn't necessarily focus on what you can't do with a Microformat. For example: overlapping Microformats is a problem, so is the lack of namespaces, global identification on pages, and the scoping issue outlined in the hAudio case study. We felt that the community wasn't very upfront about these shortcomings of Microformats. We didn't even know that the community understood that Microformats had these shortcomings until we were 7 months into the process. I think we as a community should be very honest about what one can't do with Microformats. In an attempt to address these issues, I've authored the following document (with help from Martin McEvoy and Brian Suda): http://microformats.org/wiki/how-to-start-a-new-microformat The document attempts to outline The Process more clearly and in a step-by-step manner. We found ourselves missing steps or not understanding what needed to be accomplished at certain points in the process. Our general view of The Process when going through it the first time was that it seemed to be being made up as we went along. There are several community members that have their own take on each step of the process and their advice sometimes conflicted with what other members of the community advised us to do. In short - there didn't seem to be a consensus on the process, which led to frustration when attempting to get to the next step. I think the best thing that the community could do at this point regarding the creation of new Microformats is to smooth and refine The Process. It is not very easy to grok until you've been through it... and after you go through the New Microformat meat grinder, you really don't want to do it again. :) -- manu From msporny at digitalbazaar.com Tue Sep 11 20:32:02 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Sep 11 20:32:05 2007 Subject: [uf-new] hVideo: Added 11 more examples and analysis Message-ID: <46E75DB2.1020505@digitalbazaar.com> All of the video examples that Mary pointed out on the old media-info page have been moved over to the video-info-examples page. We did a re-analysis of the data to ensure that the property names stayed consistent with the video service publishing data. There are now 33 video sharing examples on the video-info-examples page: http://microformats.org/wiki/video-info-examples I think that we should shoot for 50 examples (an arbitrary number picked out of thin air) before proceeding to the brainstorming step... so if you have video links, now would be a great time to add them to the wiki: http://microformats.org/wiki/video-info-examples#Video_Sites_Needing_Analysis -- manu From msporny at digitalbazaar.com Tue Sep 11 21:31:13 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Sep 11 21:31:17 2007 Subject: [uf-new] video-info-examples page clarifications Message-ID: <46E76B91.1080003@digitalbazaar.com> This is a partial continuation of the following thread: http://microformats.org/discuss/mail/microformats-new/2007-September/000823.html I wanted to make some clarifications about the video-info-examples page before we go down a rabbit hole. Or rather... this is an attempt not to go down a rabbit hole :) Mary Hodder wrote: > So the names you use here: http://microformats.org/wiki/video-info- > examples#Properties don't all make sense to me. Where did they > come from? Some of them I've never seen used before. They are names that I picked from the previous media-info-examples pages and discussions. Some of them are new because of freshly discovered properties on web pages that were not identified in the first analysis pass of video services. > Published? that doesn't mean anything without the explanation. Why > can't you just use "date" so that we know what you are talking > about? No need for long explanations if we do that. We could use "date". What does "date" mean? Does it mean "published date", or "released date", or "posted date"... because all of those are different for the video examples that are currently being analyzed. I used "published" because it has a very specific meaning in Microformats: "published" - Publish date of a weblog/microcontent entry[1] That being said, I went ahead and changed "published" to "post date", and added "release date" to the set of properties that websites could have. > Why do you need more examples? In the new page you just made here: > http://microformats.org/wiki/video-info-examples > Why not combine? I've taken your suggestion and combined the individual publishing examples of media-info-examples with the video-info-examples page. That added 10 more examples to the analysis. I think we still need more. The reason I say this is that somebody arguing against hVideo could say that we do not have a statistically significant data yet. You said that there are over 1,000 sites that you collect data from. If we wanted to state something with a confidence level of 95% and an confidence interval of 5% in a population of 1000, we would have to take 278 samples. We currently have 33. There's a middle ground here. I'm trying to make sure that it is much harder for somebody to dismiss the research that we are doing by falling back on the "you didn't analyze enough examples" argument. Thus I don't think that 33 examples are good enough to make our point. > I'm not really sure what you are getting at with your list of > properties then? The list of properties is defined so that everybody understands what each property means. This is important because we don't want to have any misunderstandings about the definition of a property name. So, if a website on the video-info-examples page has a 'trackback url', we can look its definition up and know that it means the following: "The trackback URL lets you know who has linked to the current blog entry."[3] Perhaps I have done a bad job with the property definitions on the video examples page? The goal was to create a common vocabulary with specific definitions for analysis without getting too attached to the terms. > We know people, all over the web, across the 27 million videos Dabble > has indexed, as well as the rest of the videos we don't have but are > mostly hosted by those same 1000 hosters, that this list rings true: I trust that you have the data and have done the analysis, so would it be possible to release that data and analysis to this list so that we may integrate hard numbers into the wiki? Adding 1,000 examples that have already been analyzed for the Microformats community would be fantastic! > By putting price and purchase URL right at the top of the definitions > you are giving me the impression that you care most about that. Well, that certainly wasn't intended. I've added the following text to the properties section, does the following help? "These properties are in alphabetical order and in no way represent the frequency of their use in the examples. The property names are also not final and probably will not be used when the Microformat vocabulary is decided. Deciding the vocabulary of the Microformat is not performed at this stage of examples collection and analysis. These property names and definitions are listed here in an attempt to keep the current and future example analysis teams using the same definitions for property names."[3] Here's to hoping that this e-mail helped clarify more than it muddied :) -- manu [1] http://microformats.org/wiki/existing-classes [2] http://www.surveysystem.com/sscalc.htm [3] http://microformats.org/wiki/video-info-examples#Properties From fberriman at gmail.com Wed Sep 12 02:58:17 2007 From: fberriman at gmail.com (Frances Berriman) Date: Wed Sep 12 02:58:21 2007 Subject: [uf-new] The Process (was: hAudio case study) In-Reply-To: <46E6F265.9090801@digitalbazaar.com> References: <46E1B7C0.3080800@digitalbazaar.com> <46E6F265.9090801@digitalbazaar.com> Message-ID: On 11/09/2007, Manu Sporny wrote: > To us it seemed like this was an unfair argument that was thrown out > there whenever we disagreed with somebody that was "more senior" in the > community. The argument came across as "Well, you're just not analyzing > the correct sites - otherwise, you'd see my point... so why don't you go > and analyze more examples until you can prove us right". The person > making the previous statement doesn't have to do anything to defend > their viewpoint and the person creating the Microformat now has to spend > tens of hours collecting more examples. > > In the end, it made hAudio better - but at the expense of frustrating > the Microformat authors. Yeah - that frustration is understandable, but I don't think it's easy to say at the start of a project how much (# wise) is enough. Perhaps that should be iterative itself... go off and find 30, do you have conclusive evidence... if not, find another 20..? I wonder if review got by with less, because there's just less data out there already? The general idea is just to get "as many as you can" but that's almost like saying "how long is a piece of string", I agree. We'll have to give this one some more thought. Does anyone else have good ideas about how to iron this out? > We felt that the community wasn't very upfront about these shortcomings > of Microformats. We didn't even know that the community understood that > Microformats had these shortcomings until we were 7 months into the > process. I think we as a community should be very honest about what one > can't do with Microformats. That's fair. I think it would be very beneficial to be upfront about this. After all, it'll save everyone time in the long run. I think devoting a page to "are microformats for you or your project?" would be worthwhile. > I think the best thing that the community could do at this point > regarding the creation of new Microformats is to smooth and refine The > Process. It is not very easy to grok until you've been through it... and > after you go through the New Microformat meat grinder, you really don't > want to do it again. :) It's rigorous, but yeah, I agree... any effort to make it less meat-grinder like and more "super fun adventure" is a good thing. But at the same time, it's been that harsh to prevent frivolous formats being created. That document is a great start. I still have issues with using "POSH" over simply saying "create good, semantic HTML", but I think I already got ignored over that one. :) Simple language and clearly defined steps is a reasonable and achievable goal. -- Frances Berriman http://fberriman.com From brian.suda at gmail.com Wed Sep 12 03:33:12 2007 From: brian.suda at gmail.com (Brian Suda) Date: Wed Sep 12 03:33:16 2007 Subject: [uf-new] The Process (was: hAudio case study) In-Reply-To: References: <46E1B7C0.3080800@digitalbazaar.com> <46E6F265.9090801@digitalbazaar.com> Message-ID: <21e770780709120333g79d8d518u3862880f5cc5e470@mail.gmail.com> On 9/12/07, Frances Berriman wrote: > Yeah - that frustration is understandable, but I don't think it's easy > to say at the start of a project how much (# wise) is enough. > The general idea is just to get "as many as you can" but that's almost > like saying "how long is a piece of string", I agree. > > We'll have to give this one some more thought. Does anyone else have > good ideas about how to iron this out? --- it is NEVER a good idea to use number quotas. All they do is mask potential shortcomings. If you say that you need 10 examples, they only the first 10 will ever be looked at. If you say you need 50, but only find 45, then 5 additional will be created "in your favour" purely to meet the quota. If you set it at 500 then it is an unachievable goal. Edward Deming set-out 14 points. http://en.wikipedia.org/wiki/W._Edwards_Deming#Deming.27s_14_points #11. Eliminate numerical goals, numerical quotas, and management by objectives. Substitute leadership. At the end of the day, we should avoid "voting" on issues and examples purely by the numbers and base it more on experience, leadership and good reasoning, NOT because 25 of my 27 examples show this... because someone else can go out and (create or document) 50 more to counter the previously gathered examples. IMHO numeric quotas (much like those voting polls where you can vote as many times as you want) do not reflect the truth, but instead a meter to which people do as little work as possible to achieve the goal and then say "but i did what you told me", even though it might be crap. Quantity does not equate quality! The other thing that might help the example gathering is if more people were involved. If one person goes out and finds 200 examples, but no one else is helping, then is there really a reason to keep pushing the process? Microformats work best when there is an "itch to scratch", not a personal issue to solve. Many formats have collected many, many examples, but there is just no interest at the current time to move it forward. Just because things can be checked on the process list doesn?t mean it should. This is the current state of the media-info, people did some homework, and saw there wasn?t community interest. This is the perfect opportunity to take a step back an use POSH for awhile, test it and report back with results. No need to hammer on the process. > It's rigorous, but yeah, I agree... any effort to make it less > meat-grinder like and more "super fun adventure" is a good thing. But > at the same time, it's been that harsh to prevent frivolous formats > being created. --- this is also why POSh has been pushed more. We have also been adding things to the process, like "first make sure you site is POSH, it validates and uses existing microformats". Then and ONLY then should more people be allowed to propose new formats. This would also FORCE an understanding of some of the more basic things before a proposal and frustration of "not understanding". -brian -- brian suda http://suda.co.uk From scott at makedatamakesense.com Wed Sep 12 06:54:37 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed Sep 12 06:54:46 2007 Subject: [uf-new] The Process (was: hAudio case study) In-Reply-To: References: <46E1B7C0.3080800@digitalbazaar.com> <46E6F265.9090801@digitalbazaar.com> Message-ID: <128BD659-6839-42C7-8CE5-9D57A5A5939D@makedatamakesense.com> On Sep 12, 2007, at 4:33 AM, Brian Suda wrote: > Quantity does not equate quality! Right. I think we tend to get caught up in whether or not the numbers are convincing to our fellow community members, and lose track of the important question: whether or not the end result is convincingly useful for publishers. Most publishers don't care if the examples we collect are statistically significant; they only care if it looks useful for them. More examples helps with that goal, but there's not really quantifiable finish line. I suspect much of this problem could be resolved with better scope definitions. When someone says "these examples don't cover my needs," rather than collecting more examples to prove those needs are edge cases, we could be referring back to the scope definition and saying "sorry, your needs are outside the defined scope of this microformat." But that only works when the scope is very clearly defined in advance. -- Scott Reynen MakeDataMakeSense.com From msporny at digitalbazaar.com Wed Sep 12 07:06:55 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Sep 12 07:06:58 2007 Subject: [uf-new] The Process In-Reply-To: References: <46E1B7C0.3080800@digitalbazaar.com> <46E6F265.9090801@digitalbazaar.com> Message-ID: <46E7F27F.40208@digitalbazaar.com> Frances Berriman wrote: >> We felt that the community wasn't very upfront about these shortcomings >> of Microformats. We didn't even know that the community understood that >> Microformats had these shortcomings until we were 7 months into the >> process. I think we as a community should be very honest about what one >> can't do with Microformats. > > That's fair. I think it would be very beneficial to be upfront about > this. After all, it'll save everyone time in the long run. I think > devoting a page to "are microformats for you or your project?" would > be worthwhile. I think we should call it what it is: "The Accepted Limitations of Microformats" > It's rigorous, but yeah, I agree... any effort to make it less > meat-grinder like and more "super fun adventure" is a good thing. But > at the same time, it's been that harsh to prevent frivolous formats > being created. That harshness has also sent good people elsewhere... you don't have to be harsh to prevent frivolous formats or unwanted behavior. In fact, this goes against the Microformats "be nice" principle. -- manu From Michael.Smethurst at bbc.co.uk Wed Sep 12 08:24:53 2007 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Wed Sep 12 08:25:06 2007 Subject: [uf-new] The Process (was: hAudio case study) In-Reply-To: Message-ID: On 12/9/07 10:58, "Frances Berriman" wrote: > On 11/09/2007, Manu Sporny wrote: >> To us it seemed like this was an unfair argument that was thrown out >> there whenever we disagreed with somebody that was "more senior" in the >> community. The argument came across as "Well, you're just not analyzing >> the correct sites - otherwise, you'd see my point... so why don't you go >> and analyze more examples until you can prove us right". The person >> making the previous statement doesn't have to do anything to defend >> their viewpoint and the person creating the Microformat now has to spend >> tens of hours collecting more examples. >> >> In the end, it made hAudio better - but at the expense of frustrating >> the Microformat authors. > > Yeah - that frustration is understandable, but I don't think it's easy > to say at the start of a project how much (# wise) is enough. Perhaps > that should be iterative itself... go off and find 30, do you have > conclusive evidence... if not, find another 20..? I wonder if review > got by with less, because there's just less data out there already? > The general idea is just to get "as many as you can" but that's almost > like saying "how long is a piece of string", I agree. > > We'll have to give this one some more thought. Does anyone else have > good ideas about how to iron this out? Just to chip in here - I've never been entirely convinced that auditing sites for markup standards is all that beneficial If you were proposing a tracklist uf you could look at: Bbc.co.uk/radio1 And find text with line breaks If you were proposing a recipe uf you could look at: Bbc.co.uk/food And find text with line breaks Same goes elsewhere for news, travel etc. And not just at the bbc. More or less everywhere I've worked has had legacy markup produced by legacy systems. Look outside of html and the same holds. I was recently looking through: http://gonze.com/playlists/playlist-format-survey.html For tips on music markup and every one was a mess of proprietary, legacy markup Would it not be better for ufs to standardise markup based on the domain model than waste time wading through flakey html? [Perhaps] http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From Michael.Smethurst at bbc.co.uk Wed Sep 12 08:38:40 2007 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Wed Sep 12 08:38:47 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <46E400B5.8020905@digitalbazaar.com> Message-ID: On 9/9/07 15:18, "Manu Sporny" wrote: > > Of the two, I'd prefer the latter method. What about using RECORDING? > This would allow us to re-use that class name in hVideo to denote the > name of a video recording. We can't use TRACK as that is the class name > we're using to denote the tracks in an album. That being said, would > something like this work? > > hAudio Contents Type > --------------- ----------- > recording Audio Recording > recording + album Audio Recording with Album info > album Album > toplist Top List > podcast Podcast Can I suggest release instead of album? It just captures albums, singles, eps better... http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From fberriman at gmail.com Wed Sep 12 08:50:29 2007 From: fberriman at gmail.com (Frances Berriman) Date: Wed Sep 12 08:50:55 2007 Subject: [uf-new] The Process In-Reply-To: <46E7F27F.40208@digitalbazaar.com> References: <46E1B7C0.3080800@digitalbazaar.com> <46E6F265.9090801@digitalbazaar.com> <46E7F27F.40208@digitalbazaar.com> Message-ID: On 12/09/2007, Manu Sporny wrote: > I think we should call it what it is: > > "The Accepted Limitations of Microformats" Yeah, that would work. > That harshness has also sent good people elsewhere... you don't have to > be harsh to prevent frivolous formats or unwanted behavior. In fact, > this goes against the Microformats "be nice" principle. > I agree - and I think that these new pieces of documentation will help everyone be more supportive rather than exclusive in any way. -- Frances Berriman http://fberriman.com From scott at makedatamakesense.com Wed Sep 12 08:53:03 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed Sep 12 08:53:14 2007 Subject: [uf-new] The Process (was: hAudio case study) In-Reply-To: References: Message-ID: <2EB0A848-DDFA-41B3-B887-8C939B760294@makedatamakesense.com> On Sep 12, 2007, at 9:24 AM, Michael Smethurst wrote: > Would it not be better for ufs to standardise markup based on the > domain > model than waste time wading through flakey html? [Perhaps] I don't believe looking at current publishing practices is a waste of time at all. Much the opposite, I think it's the most important part of the process. Domain models that don't account for what is published on the real web tend to be less useful on the real web. -- Scott Reynen MakeDataMakeSense.com From msporny at digitalbazaar.com Wed Sep 12 09:06:53 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Sep 12 09:06:57 2007 Subject: [uf-new] The Process In-Reply-To: <21e770780709120333g79d8d518u3862880f5cc5e470@mail.gmail.com> References: <46E1B7C0.3080800@digitalbazaar.com> <46E6F265.9090801@digitalbazaar.com> <21e770780709120333g79d8d518u3862880f5cc5e470@mail.gmail.com> Message-ID: <46E80E9D.1000207@digitalbazaar.com> Brian Suda wrote: > Edward Deming set-out 14 points. > http://en.wikipedia.org/wiki/W._Edwards_Deming#Deming.27s_14_points > > #11. Eliminate numerical goals, numerical quotas, and management by > objectives. Substitute leadership. With all due respect, Brian... we're back to hand-waving... which is frustrating. "Substitute leadership" is vague... what kind of leadership should we substitute? Authoritarian? Benevolent dictator? Constitutional Republic? Mob Rule? Should the "leadership" be of the Microformats author, or of somebody in The Cabal? I agree with you in philosophy... but we need some more specific guidelines. When we don't have clearly defined goals, it's difficult to know if we're getting anywhere. We don't have to use hard numbers, but we need something more specific than what you have just outlined. Why can't we agree to a simple set of guiding principles of when a Microformat should be considered? For example: A Microformat should be considered if: 1. There are more than 100 websites that mark up the type of data in the problem statement of the proposed Microformat. A Microformat should be created if: 1. There are more than 1000 websites that mark up the type of data in the problem statement of the proposed Microformat. > Quantity does not equate quality! I agree with you in principle, but I think the Microformats community is botching the execution on this. > The other thing that might help the example gathering is if more > people were involved. If one person goes out and finds 200 examples, > but no one else is helping, then is there really a reason to keep > pushing the process? Yes! They have found 200 examples of the data in the wild... that shows that the data exists out there! If they can find 200 examples, that probably means that there are many more websites that contain that data. You say that we shouldn't use numbers... but now you're saying that the number of people working on a Microformat is relevant? > Microformats work best when there is an "itch to > scratch", not a personal issue to solve. What constitutes an "itch to scratch"? I'd say that the number of websites that are publishing the data in a Microformat Problem Statement is very relevant. I don't think anybody would argue that if we could find 10,000 websites publishing a certain type of data, that we shouldn't consider a Microformat for those websites. > Many formats have collected > many, many examples, but there is just no interest at the current time > to move it forward. Just because things can be checked on the process > list doesn?t mean it should. This is the current state of the > media-info, people did some homework, and saw there wasn?t community > interest. Again, with all due respect Brian, I disagree completely. As you can already tell, I'm not a very big fan of goals that can't be measured. So, here is how I'm proposing that we measure "interest in a Microformat". Interest in a Microformat should not be measured at the beginning, but over the lifetime of the Microformat. From beginning to the point of the final draft. This can be measured quite easily by looking at the number of contributors on all of the pages for each Microformat, and the number of people that took part in the discussion on the mailing list and normalizing that number by the number of months the format has been active. Here's an analysis that I've been doing in my spare time of how this applies to some of the current Microformats: hCard contributors: 263 normalized (26 months): 10.11 authors : 2 hCalendar contributors: 85 normalized (26 months): 3.27 authors : 2 hAtom contributors: 62 normalized (22 months): 2.81 authors : 3 hResume contributors: 54 normalized (20 months): 2.70 authors : 5 hAudio contributors: 35 normalized ( 6 months): 5.83 authors : 2 hReview contributors: 53 normalized (26 months): 2.03 authors : 6 VoteLinks contributors: 23 normalized (26 months): 0.88 authors : xFolk contributors: 12 normalized (26 months): 0.46 authors : 1 With these examples above, we can see several patterns. hAudio has a fairly high "normalized interest level"... but it has been proposed that we not move that forward until there is "more interest". It's interest level is higher than all the other Microformats listed, except for hCard. This is part of what is frustrating - even when we present data like this, it is sometimes ignored by the Microformats administration. > --- this is also why POSh has been pushed more. We have also been > adding things to the process, like "first make sure you site is POSH, > it validates and uses existing microformats". Then and ONLY then > should more people be allowed to propose new formats. This would also > FORCE an understanding of some of the more basic things before a > proposal and frustration of "not understanding". I'm a big supporter of asking everybody to POSH-ify their website before attempting to create a Microformat. However, that only gives you a very basic knowledge of what it takes to create a Microformat. It also has nothing to do with The Process. The frustration that I'm outlining is that The Process is quite vague related to accomplishing certain key New Microformat tasks. -- manu From msporny at digitalbazaar.com Wed Sep 12 09:14:23 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Sep 12 09:14:26 2007 Subject: [uf-new] The Process In-Reply-To: References: <46E1B7C0.3080800@digitalbazaar.com> <46E6F265.9090801@digitalbazaar.com> <46E7F27F.40208@digitalbazaar.com> Message-ID: <46E8105F.4020501@digitalbazaar.com> Frances Berriman wrote: > On 12/09/2007, Manu Sporny wrote: >> I think we should call it what it is: >> >> "The Accepted Limitations of Microformats" > > Yeah, that would work. I have created the wiki page, everyone please feel free to note issues and add other sections on the page: http://microformats.org/wiki/accepted-limitations-of-microformats -- manu From msporny at digitalbazaar.com Wed Sep 12 09:32:59 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Sep 12 09:33:20 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: References: Message-ID: <46E814BB.7010805@digitalbazaar.com> Michael Smethurst wrote: > Can I suggest release instead of album? It just captures albums, singles, > eps better... Your idea has been noted on the wiki, Michael: http://microformats.org/wiki/audio-info-issues#album-title_Property I'm somewhat opposed to changing 'release' to 'album-title' at the moment. album-title is more inline with where we're going with hAudio, hVideo and the media-info discussion in general. However, you've mentioned something that could be re-used quite heavily between all of the media Microformats. I think it makes a great deal of sense and it wouldn't take much to convince me to drop album-title in favor of 'release' if you can answer the following: What do we use for 'podcast-title', 'toplist-title', and other collection names? Andy made a good point before, the names should be simple and narrow in definition. I think right now, we're leaning towards 'album', 'podcast', and 'toplist' as the collection class names. -- manu From Michael.Smethurst at bbc.co.uk Wed Sep 12 09:39:54 2007 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Wed Sep 12 09:40:00 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <46E814BB.7010805@digitalbazaar.com> Message-ID: On 12/9/07 17:32, "Manu Sporny" wrote: > > What do we use for 'podcast-title', 'toplist-title', and other > collection names? > > Andy made a good point before, the names should be simple and narrow in > definition. I think right now, we're leaning towards 'album', 'podcast', > and 'toplist' as the collection class names. Release, podcast and chart? Oh and playlist for tv/radio episodes Which is where I came in ;-) > > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From mary at dabble.com Wed Sep 12 09:52:02 2007 From: mary at dabble.com (Mary Hodder) Date: Wed Sep 12 09:52:07 2007 Subject: [uf-new] The Process (was: hAudio case study) In-Reply-To: <2EB0A848-DDFA-41B3-B887-8C939B760294@makedatamakesense.com> References: <2EB0A848-DDFA-41B3-B887-8C939B760294@makedatamakesense.com> Message-ID: <8B727BE6-84DA-4555-BE11-F660C3E86AE6@dabble.com> I'd second that. Even if users are just plopping blobs of data that is recognizable to humans when presented in a blog, but unstructured, we can still make sense of those blobs and structure them. Seeing what people want to do makes more sense that imposing from on high. That is typical of standard's bodies and in practice not often followed. For an example of this, where some standards from on high, are compared to some standards that emerged, in video metadata, see this: http://microformats.org/wiki/media-metadata-examples#Comparison_Table mary Mary Hodder Founder: Dabble Blogs: Dabble.com/blog Napsterization.org/stories On Sep 12, 2007, at 8:53 AM, Scott Reynen wrote: > On Sep 12, 2007, at 9:24 AM, Michael Smethurst wrote: > >> Would it not be better for ufs to standardise markup based on the >> domain >> model than waste time wading through flakey html? [Perhaps] > > I don't believe looking at current publishing practices is a waste > of time at all. Much the opposite, I think it's the most important > part of the process. Domain models that don't account for what is > published on the real web tend to be less useful on the real web. > > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From mary at dabble.com Wed Sep 12 09:55:35 2007 From: mary at dabble.com (Mary Hodder) Date: Wed Sep 12 09:55:46 2007 Subject: [uf-new] The Process In-Reply-To: References: <46E1B7C0.3080800@digitalbazaar.com> <46E6F265.9090801@digitalbazaar.com> <46E7F27F.40208@digitalbazaar.com> Message-ID: I have to second this one as well. In fact I blogged about this some time ago: http://napsterization.org/stories/archives/000583.html nicely of course, but the reality was that for 2 years, I got slammed and treated badly by the folks who started it, and then once I made them sit down and explain the process, I was able to follow the rules. But it was harsh. Many people commented privately to me after the two blog posts on process that it helped them a lot because they had the same experience. I don't see why hazing helps the process. You can have high standards without being mean. mary On Sep 12, 2007, at 8:50 AM, Frances Berriman wrote: > On 12/09/2007, Manu Sporny wrote: >> I think we should call it what it is: >> >> "The Accepted Limitations of Microformats" > > Yeah, that would work. > > >> That harshness has also sent good people elsewhere... you don't >> have to >> be harsh to prevent frivolous formats or unwanted behavior. In fact, >> this goes against the Microformats "be nice" principle. >> > > I agree - and I think that these new pieces of documentation will help > everyone be more supportive rather than exclusive in any way. > > > -- > Frances Berriman > http://fberriman.com > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From mary at dabble.com Wed Sep 12 09:58:26 2007 From: mary at dabble.com (Mary Hodder) Date: Wed Sep 12 09:58:31 2007 Subject: [uf-new] video-info-examples page clarifications In-Reply-To: <46E76B91.1080003@digitalbazaar.com> References: <46E76B91.1080003@digitalbazaar.com> Message-ID: <6B5A9A46-B587-4A68-A920-39D0C683143A@dabble.com> Hi Manu, Appreciate the clarifications. Very helpful. I will get one of my engineers to run some queries, to see what percentages we have across 27 mil videos and then post them here and in the wiki. And post a few examples. But i really think a few hundred examples is plenty.. esp when you see the patterns over and over. Also, regarding terminology, i think having as close to real meaningful terms as possible is best. For example, I'd suggest "date published" and "date released" because at least they are clear and require no explanation. mary Mary Hodder Founder: Dabble Blogs: Dabble.com/blog Napsterization.org/stories On Sep 11, 2007, at 9:31 PM, Manu Sporny wrote: > This is a partial continuation of the following thread: > > http://microformats.org/discuss/mail/microformats-new/2007- > September/000823.html > > I wanted to make some clarifications about the video-info-examples > page > before we go down a rabbit hole. Or rather... this is an attempt > not to > go down a rabbit hole :) > > Mary Hodder wrote: >> So the names you use here: http://microformats.org/wiki/video- >> info- >> examples#Properties don't all make sense to me. Where did they >> come from? Some of them I've never seen used before. > > They are names that I picked from the previous media-info-examples > pages > and discussions. Some of them are new because of freshly discovered > properties on web pages that were not identified in the first analysis > pass of video services. > >> Published? that doesn't mean anything without the explanation. Why >> can't you just use "date" so that we know what you are talking >> about? No need for long explanations if we do that. > > We could use "date". What does "date" mean? Does it mean "published > date", or "released date", or "posted date"... because all of those > are > different for the video examples that are currently being analyzed. > > I used "published" because it has a very specific meaning in > Microformats: > > "published" - Publish date of a weblog/microcontent entry[1] > > That being said, I went ahead and changed "published" to "post date", > and added "release date" to the set of properties that websites > could have. > >> Why do you need more examples? In the new page you just made here: >> http://microformats.org/wiki/video-info-examples >> Why not combine? > > I've taken your suggestion and combined the individual publishing > examples of media-info-examples with the video-info-examples page. > That > added 10 more examples to the analysis. I think we still need more. > > The reason I say this is that somebody arguing against hVideo could > say > that we do not have a statistically significant data yet. You said > that > there are over 1,000 sites that you collect data from. If we wanted to > state something with a confidence level of 95% and an confidence > interval of 5% in a population of 1000, we would have to take 278 > samples. We currently have 33. > > There's a middle ground here. I'm trying to make sure that it is much > harder for somebody to dismiss the research that we are doing by > falling > back on the "you didn't analyze enough examples" argument. Thus I > don't > think that 33 examples are good enough to make our point. > >> I'm not really sure what you are getting at with your list of >> properties then? > > The list of properties is defined so that everybody understands what > each property means. This is important because we don't want to > have any > misunderstandings about the definition of a property name. So, if a > website on the video-info-examples page has a 'trackback url', we can > look its definition up and know that it means the following: > > "The trackback URL lets you know who has linked to the current blog > entry."[3] > > Perhaps I have done a bad job with the property definitions on the > video > examples page? The goal was to create a common vocabulary with > specific > definitions for analysis without getting too attached to the terms. > >> We know people, all over the web, across the 27 million videos Dabble >> has indexed, as well as the rest of the videos we don't have but are >> mostly hosted by those same 1000 hosters, that this list rings true: > > I trust that you have the data and have done the analysis, so would it > be possible to release that data and analysis to this list so that we > may integrate hard numbers into the wiki? Adding 1,000 examples that > have already been analyzed for the Microformats community would be > fantastic! > >> By putting price and purchase URL right at the top of the definitions >> you are giving me the impression that you care most about that. > > Well, that certainly wasn't intended. I've added the following text to > the properties section, does the following help? > > "These properties are in alphabetical order and in no way represent > the > frequency of their use in the examples. The property names are also > not > final and probably will not be used when the Microformat vocabulary is > decided. Deciding the vocabulary of the Microformat is not > performed at > this stage of examples collection and analysis. These property > names and > definitions are listed here in an attempt to keep the current and > future > example analysis teams using the same definitions for property > names."[3] > > Here's to hoping that this e-mail helped clarify more than it > muddied :) > > -- manu > > [1] http://microformats.org/wiki/existing-classes > [2] http://www.surveysystem.com/sscalc.htm > [3] http://microformats.org/wiki/video-info-examples#Properties > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Wed Sep 12 10:15:34 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Sep 12 10:15:37 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: References: Message-ID: <46E81EB6.30703@digitalbazaar.com> Michael Smethurst wrote: > Release, podcast and chart? > > Oh and playlist for tv/radio episodes Added a new hAudio ISSUE #10: http://microformats.org/wiki/audio-info-issues#Collection_Names -- manu From msporny at digitalbazaar.com Wed Sep 12 10:29:35 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Sep 12 10:29:39 2007 Subject: [uf-new] video-info-examples page clarifications In-Reply-To: <6B5A9A46-B587-4A68-A920-39D0C683143A@dabble.com> References: <46E76B91.1080003@digitalbazaar.com> <6B5A9A46-B587-4A68-A920-39D0C683143A@dabble.com> Message-ID: <46E821FF.7050405@digitalbazaar.com> Mary Hodder wrote: > Appreciate the clarifications. Very helpful. I will get one of my > engineers to run some queries, to see what percentages we have across 27 > mil videos and then post them here and in the wiki. Make sure to ask them to not duplicate data sources. Don't analyze 400 URLs from the same site. Instead, analyze 400 URLS from different sites. Make sure that they generate a machine-readable data file (tab delimited, comma separated, or XML) and that you can show that data file to the Microformats community. We need hard, demonstrable numbers so nobody can assert that the data is not legitimate. More importantly, we need to be able to verify any findings and prove their existence to others in the community. > Also, regarding terminology, i think having as close to real meaningful > terms as possible is best. Agreed. > For example, I'd suggest "date published" and "date released" because > at least they are clear and require no explanation. Thanks for the suggestions, I'll update all the Microformalyze data files tonight or tomorrow and upload your suggested changes to the wiki. -- manu From mary at dabble.com Wed Sep 12 10:40:21 2007 From: mary at dabble.com (Mary Hodder) Date: Wed Sep 12 10:40:30 2007 Subject: [uf-new] video-info-examples page clarifications In-Reply-To: <46E821FF.7050405@digitalbazaar.com> References: <46E76B91.1080003@digitalbazaar.com> <6B5A9A46-B587-4A68-A920-39D0C683143A@dabble.com> <46E821FF.7050405@digitalbazaar.com> Message-ID: <427E63C4-2F69-4B8C-8927-C18591158D74@dabble.com> Oh. Got it. I thought you wanted 1000 examples from anywhere. Yes, I can get one from each, but actually that's much harder because it has to be hand done, than doing a query across 27 million videos. mary Mary Hodder Founder: Dabble Blogs: Dabble.com/blog Napsterization.org/stories On Sep 12, 2007, at 10:29 AM, Manu Sporny wrote: > Mary Hodder wrote: >> Appreciate the clarifications. Very helpful. I will get one of my >> engineers to run some queries, to see what percentages we have >> across 27 >> mil videos and then post them here and in the wiki. > > Make sure to ask them to not duplicate data sources. Don't analyze 400 > URLs from the same site. Instead, analyze 400 URLS from different > sites. > > Make sure that they generate a machine-readable data file (tab > delimited, comma separated, or XML) and that you can show that data > file > to the Microformats community. We need hard, demonstrable numbers so > nobody can assert that the data is not legitimate. More > importantly, we > need to be able to verify any findings and prove their existence to > others in the community. > >> Also, regarding terminology, i think having as close to real >> meaningful >> terms as possible is best. > > Agreed. > >> For example, I'd suggest "date published" and "date released" >> because >> at least they are clear and require no explanation. > > Thanks for the suggestions, I'll update all the Microformalyze data > files tonight or tomorrow and upload your suggested changes to the > wiki. > > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From martin at weborganics.co.uk Wed Sep 12 12:25:40 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Sep 12 12:25:30 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <46E81EB6.30703@digitalbazaar.com> References: <46E81EB6.30703@digitalbazaar.com> Message-ID: <1189625140.5682.9.camel@localhost.localdomain> Hello Manu, Michael... On Wed, 2007-09-12 at 13:15 -0400, Manu Sporny wrote: > Michael Smethurst wrote: > > Release, podcast and chart? > > > > Oh and playlist for tv/radio episodes > > Added a new hAudio ISSUE #10: > > http://microformats.org/wiki/audio-info-issues#Collection_Names I vote we use something more generic and call audio-title, album-title or in fact any media related title just "media-title", you can re-use it for albums, podcasts, toplists, downloads, charts, video, images. Thanks Martin > > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Wed Sep 12 12:58:36 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Sep 12 12:58:40 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <1189625140.5682.9.camel@localhost.localdomain> References: <46E81EB6.30703@digitalbazaar.com> <1189625140.5682.9.camel@localhost.localdomain> Message-ID: <46E844EC.1010802@digitalbazaar.com> Martin McEvoy wrote: > I vote we use something more generic and call audio-title, album-title > or in fact any media related title just "media-title", you can re-use it > for albums, podcasts, toplists, downloads, charts, video, images. Martin, If we do that, we will lose the ability to differentiate between an album, podcast, toplist, download, and chart. These are differentiations that we need to make because of the examples discovered thus far. By using something like "podcast" or "album" we not only define the type of the hAudio, but the collection property as well. We address two issues (how do we specify hAudio type, and how do we specify hAudio collections) with one class name. -- manu From martin at weborganics.co.uk Wed Sep 12 15:11:38 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Sep 12 15:11:23 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <46E844EC.1010802@digitalbazaar.com> References: <46E81EB6.30703@digitalbazaar.com> <1189625140.5682.9.camel@localhost.localdomain> <46E844EC.1010802@digitalbazaar.com> Message-ID: <1189635098.5682.72.camel@localhost.localdomain> On Wed, 2007-09-12 at 15:58 -0400, Manu Sporny wrote: > Martin McEvoy wrote: > > I vote we use something more generic and call audio-title, album-title > > or in fact any media related title just "media-title", you can re-use it > > for albums, podcasts, toplists, downloads, charts, video, images. > > Martin, > > If we do that, we will lose the ability to differentiate between an > album, podcast, toplist, download, and chart. These are differentiations > that we need to make because of the examples discovered thus far. > > By using something like "podcast" or "album" we not only define the type > of the hAudio, but the collection property as well. We address two > issues (how do we specify hAudio type, and how do we specify hAudio > collections) with one class name. I think tat we are forgetting about context and the way hAudio may be published for example http://odeo.com/audio/270407/view haudio elements here are title, download, duration and image minimal markup the rest is context describing the published haudio using markup or to coin a phrase POSH another http://www.bradsucks.net/music/ haudio elements title payment enclosure and image minimal markup the rest is context describing the published haudio using markup or to coin a phrase POSH (yes i did copy and paste that) I am not trying to be too simplistic here but I hope you can see what I am trying to say, We may have identified the important elements in hAudio using some fantastic methods for analyzing our data, but I am a Publisher, first I look at not just the elements but the way people publish their audio visually and the markup they use by using just Firefox and firebug. If we bloat haudio in the ways you and others are suggesting then the actual use of hAudio (in my opinion) will be very slow indeed. I do not think hAudio will benefit from any such use of podcast-title, toplist-title, album-title or any derivative there-of Im sure I dont want to have to shoe_horn_haudio into my markup! We do however need a Track element even maybe a type and description element but the rest must be left up to publishers Thanks Martin > > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From scott at makedatamakesense.com Wed Sep 12 16:01:24 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed Sep 12 16:01:36 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <46E844EC.1010802@digitalbazaar.com> References: <46E81EB6.30703@digitalbazaar.com> <1189625140.5682.9.camel@localhost.localdomain> <46E844EC.1010802@digitalbazaar.com> Message-ID: On Sep 12, 2007, at 1:58 PM, Manu Sporny wrote: > If we do that, we will lose the ability to differentiate between an > album, podcast, toplist, download, and chart. Can you explain a bit more what exactly we gain with that ability, in terms of practical capabilities? How would a hypothetical application treat two documents differently if they were otherwise identical, but one said "album-title" and the other "podcast-title"? Everything else, I thought, was determined to be out of scope. You previously wrote [1]: > There are only two things that are strongly supported by the > audio-info-examples right now. Audio albums and audio podcasts > (collections of audio). Has that since changed? [1] http://microformats.org/discuss/mail/microformats-new/2007-May/ 000442.html -- Scott Reynen MakeDataMakeSense.com From tantek at cs.stanford.edu Wed Sep 12 16:46:49 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Wed Sep 12 16:46:05 2007 Subject: [uf-new] The Process In-Reply-To: Message-ID: On 9/12/07 9:55 AM, "Mary Hodder" wrote: > I have to second this one as well. > > In fact I blogged about this some time ago: > > http://napsterization.org/stories/archives/000583.html > Mary and Manu, Thank you both (again in your case Manu) for your frank comments, and more importantly... for being here and volunteering your valuable time participating in these discussions. In addition, for doing so in an objectively critical fashion. You are both setting good examples for the community, and your persistence and continued civility are an inspiration. > nicely of course, but the reality was that for 2 years, I got slammed > and treated badly by the folks who started it, and then once I made > them sit down and explain the process, I was able to follow the > rules. But it was harsh. Many people commented privately to me > after the two blog posts on process that it helped them a lot because > they had the same experience. > > I don't see why hazing helps the process. You can have high > standards without being mean. > > mary You're absolutely right Mary, any such hazing is wrong, and for any and all part that I played in that, I apologize and take full responsibility. Thanks for sticking with us through our growing pains (both personally and as a community). We can and should have high standards (in both senses) without being mean. Thanks, Tantek From tantek at cs.stanford.edu Wed Sep 12 17:51:43 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Wed Sep 12 17:50:53 2007 Subject: [uf-new] The Process (was: hAudio case study) In-Reply-To: <2EB0A848-DDFA-41B3-B887-8C939B760294@makedatamakesense.com> Message-ID: On 9/12/07 8:53 AM, "Scott Reynen" wrote: > On Sep 12, 2007, at 9:24 AM, Michael Smethurst wrote: > >> Would it not be better for ufs to standardise markup based on the >> domain >> model than waste time wading through flakey html? [Perhaps] > > I don't believe looking at current publishing practices is a waste of > time at all. Much the opposite, I think it's the most important part > of the process. Domain models that don't account for what is > published on the real web tend to be less useful on the real web. You're both right. Michael, the "gather real world examples" for analysis step of the process is specifically focusing on the *data* published, and NOT the patterns (or lack thereof) of markup. This is why the *-examples step says: "Document the implicit schemas that the content examples imply." Every word in that sentence matters. *implicit* schemas, that is, you have to look at the *content* of the examples and note what abstract notions/fields/properties that people are publishing. That's very deliberate in that it is MUCH less important (if at all) what flakey html is being used. Scott is right in that analysis of current publishing practices helps us prioritize what problems are worth solving (i.e. there is already demonstrated incentive for people to publish such information) as opposed to what problems are purely theoretical, or wishful thinking (e.g. if only everyone would publish metadata ABC then we could build applications XYZ). In fact, I have seen this question asked (or this step of the process misinterpreted regarding example data vs example markup) sufficient times that I think this merits documentation as an FAQ. Might as well start with this one. Thanks, Tantek From andy at pigsonthewing.org.uk Thu Sep 13 01:10:44 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Sep 13 01:11:57 2007 Subject: [uf-new] The Process (was: hAudio case study) In-Reply-To: References: <2EB0A848-DDFA-41B3-B887-8C939B760294@makedatamakesense.com> Message-ID: In message , Tantek ?elik writes >"Document the implicit schemas that the content examples imply." > >Every word in that sentence matters. On the contrary: "implicit" is redundant. The alternative: "Document the schemas implied by the content examples." reads better. -- Andy Mabbett From chris.newell at rd.bbc.co.uk Thu Sep 13 03:33:22 2007 From: chris.newell at rd.bbc.co.uk (Chris Newell) Date: Thu Sep 13 03:33:26 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant Message-ID: <6.2.0.14.2.20070913095452.02e2a9b8@pop3> >Date: Wed, 12 Sep 2007 23:11:38 +0100 >From: Martin McEvoy >Subject: Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant >To: "For discussion of new microformats." > >Message-ID: <1189635098.5682.72.camel@localhost.localdomain> >Content-Type: text/plain > >If we bloat haudio in the ways you and others are suggesting then the >actual use of hAudio (in my opinion) will be very slow indeed. >I do not think hAudio will benefit from any such use of podcast-title, >toplist-title, album-title or any derivative there-of. I don't think having a single "collection-title" field would bloat the spec. Something generic like "parent" would do. The tendency to aggregate music into collections is too strong to ignore. Chris From chris.newell at rd.bbc.co.uk Thu Sep 13 03:58:42 2007 From: chris.newell at rd.bbc.co.uk (Chris Newell) Date: Thu Sep 13 03:58:46 2007 Subject: Subject: Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant Message-ID: <6.2.0.14.2.20070913115619.02d907a0@pop3> >Date: Wed, 12 Sep 2007 15:58:36 -0400 >From: Manu Sporny >Subject: Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant >To: "For discussion of new microformats." > >Message-ID: <46E844EC.1010802@digitalbazaar.com> >Content-Type: text/plain; charset=ISO-8859-1 > >Martin McEvoy wrote: >> I vote we use something more generic and call audio-title, album-title >> or in fact any media related title just "media-title", you can re-use it >> for albums, podcasts, toplists, downloads, charts, video, images. > >Martin, > >If we do that, we will lose the ability to differentiate between an >album, podcast, toplist, download, and chart. These are differentiations >that we need to make because of the examples discovered thus far. Manu, If there is a single, generic collection-title field could you use the "type" and "value" construction to achieve this? For example: Album: Sticky Fingers Chris From tantek at cs.stanford.edu Thu Sep 13 04:00:10 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Thu Sep 13 03:59:20 2007 Subject: [uf-new] The Process (was: hAudio case study) In-Reply-To: Message-ID: On 9/13/07 1:10 AM, "Andy Mabbett" wrote: > In message , Tantek ?elik > writes > >> "Document the implicit schemas that the content examples imply." >> >> Every word in that sentence matters. > > On the contrary: "implicit" is redundant. Quite. > The alternative: > > "Document the schemas implied by the content examples." > > reads better. Agreed. Updated process page. Thanks! Tantek From msporny at digitalbazaar.com Thu Sep 13 07:46:39 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Sep 13 07:46:42 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <1189635098.5682.72.camel@localhost.localdomain> References: <46E81EB6.30703@digitalbazaar.com> <1189625140.5682.9.camel@localhost.localdomain> <46E844EC.1010802@digitalbazaar.com> <1189635098.5682.72.camel@localhost.localdomain> Message-ID: <46E94D4F.20003@digitalbazaar.com> Martin McEvoy wrote: > I am not trying to be too simplistic here but I hope you can see what I > am trying to say, I don't think I see everything that you're trying to say, Martin... but I'll try to summarize what I think you are saying: I think you're making an argument for not bloating hAudio by adding too many new class names. I think you think that I'm making an argument for adding album, toplist, podcast, playlist, and others. I am definitely not making this argument, although reading back through the thread, I can see how it might be construed that I am proposing adding a 5-7 new class names to hAudio. This thread started by trying to eliminate the hAlbum proposal. I think we should still do that, the question is... how do we eliminate hAlbum, but keep the functionality of hAlbum? > If we bloat haudio in the ways you and others are suggesting then the > actual use of hAudio (in my opinion) will be very slow indeed. I don't think any of us want to bloat hAudio. Right now, I am proposing adding two things to hAudio in order to eliminate hAlbum: ALBUM and TRACK -- manu From msporny at digitalbazaar.com Thu Sep 13 10:02:30 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Sep 13 10:02:40 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: References: <46E81EB6.30703@digitalbazaar.com> <1189625140.5682.9.camel@localhost.localdomain> <46E844EC.1010802@digitalbazaar.com> Message-ID: <46E96D26.8080408@digitalbazaar.com> Scott Reynen wrote: >> If we do that, we will lose the ability to differentiate between an >> album, podcast, toplist, download, and chart. > > Can you explain a bit more what exactly we gain with that ability, in > terms of practical capabilities? Here is the premise: It is important to be able to differentiate between types of audio collections. At least three different types of audio are backed up by the audio-info-examples: audio recordings, audio albums and audio podcasts. Here are our goals: - Eliminate hAlbum, but support its functionality in hAudio. - Add as little as possible to hAudio to support audio collections. This thread has been split into three issues: hAudio ISSUE #8: http://microformats.org/wiki/audio-info-issues#Problem:_hAlbum_is_redundant hAudio ISSUE #9: http://microformats.org/wiki/audio-info-issues#album-title_Property hAudio ISSUE #10: http://microformats.org/wiki/audio-info-issues#Collection_Names We should continue to talk about ISSUE #8 in this thread. ISSUE #9 and ISSUE #10 are in regard to what we call these new classes. What we name these new classes should be in a different thread of conversation and should happen after we decide what to do with hAlbum. Issue 9 and 10 become rather easy decisions if we decide not to go forward with the proposed solution to issue 8. > How would a hypothetical application > treat two documents differently if they were otherwise identical, but > one said "album-title" and the other "podcast-title"? Here are the parsing rules. I will use the existing hAudio terms (audio-title, album-title) in an attempt to not confuse this issue with issue #9 or issue #10: * If only 'album-title' is specified, then the hAudio is an album. * If only 'audio-title' is specified, then the hAudio is a song/speech or other singular work. * If both 'album-title' and 'audio-title' is specified, then the hAudio is a song that is part of an album. * If 'album-title' and one or more 'track's are specified, the hAudio is an album containing tracks. Each track is an hAudio. None of the track properties should be added to the hAudio album. In other words, the parser shouldn't parse the contents of the TRACK hAudio into the non-track hAudio object, TRACK operates similarly to the 'mfo' proposal[1]. The issue is that of semantics. None of the examples explicitly state this is an "album" or this is a "track", however, they implicitly state this fact. This is the reason putting a TYPE class into hAudio doesn't make sense. Only a few of the examples ever explicitly state that they're talking about an album, a single recording or a podcast. It is implied by the context in the page. Since Microformats do not allow hidden data, we can't propose the use of TYPE - there is no text on the page to mark up even if we did use TYPE. Thus, in order to get the concept of an album, a single audio recording, or a track across we must figure out a clever way to imply these semantics without having the publisher explicitly state "this is an album" in their HTML. The current proposal is an attempt to imply the type of the hAudio without requiring the publisher to put "album" in their HTML. For software, it is important to know the semantic difference between an audio recording, an album, and a podcast. For example - it could determine which search service you use to find more information about the recording, album or podcast. On Bitmunk, our REST XML Web API allows one to specify whether the title that you're sending it is an album, or a song. The results you get back can be heavily dependent on the type of media that you're sending it. Another use case is for the Operator plug-in. How you display an album, a podcast, and a single song to a user could (and probably would) use a slightly different UI layout. It is not enough just to call something an audio object and be done with it. The type of audio object has a great deal of semantic meaning to human beings, and that is what we're trying to encapsulate with this proposal. > Everything else, I thought, was determined to be out of scope. You > previously wrote [1]: > >> There are only two things that are strongly supported by the >> audio-info-examples right now. Audio albums and audio podcasts >> (collections of audio). > > Has that since changed? Not, it has not and it should not... it seems that I've done a bad job of explaining that. :) By bringing up podcast-title and toplist-title, I was attempting to outline how we would go about naming these other "types" of hAudio. I was attempting to demonstrate that this naming mechanism and approach scales well. We don't end up with a Microformat for each type, we just end up with the lesser of two evils, one more class in hAudio. At the very least, we're talking about adding the following to hAudio: album-title track Does that help clarify hAudio ISSUE #8? -- manu [1] http://microformats.org/wiki/mfo From msporny at digitalbazaar.com Thu Sep 13 11:28:50 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Sep 13 11:28:53 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <6.2.0.14.2.20070913115619.02d907a0@pop3> References: <6.2.0.14.2.20070913115619.02d907a0@pop3> Message-ID: <46E98162.6020000@digitalbazaar.com> Chris Newell wrote: > If there is a single, generic collection-title field > could you use the "type" and "value" construction to > achieve this? > > For example: > > > Album: > Sticky Fingers > I tried to find examples that would support a proposal for adding TYPE to hAudio several months ago, but what I found was that most service sites and individual sites don't specify whether something is an album, audio recording or podcast. For example: http://www.digirama.co.nz/albumdetails.aspx?MediaID=335907 The above example, which is representative of the rest of the music service examples, does not specify the type at all... however, it is implied by the web page as an album. In the off-chance that they do specify it, a variety of language to specify the same thing: album: album, CD, CD Release, EP, LP, hit, collection, record song : song, hit, recording podcast: podcast, audio blog, mp3 blog If we let somebody put anything into the type field, it will be difficult for parsers and software to determine the type... even if we could convince publishers to start stating "album" or "podcast" or "recording" in their HTML (which they aren't doing now). We're attempting to capture semantics in the examples. There is an implicit statement that an album, song or podcast exists... but there is NOT an explicit statement about the same. -- manu From martin at weborganics.co.uk Thu Sep 13 16:40:55 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Sep 13 16:40:37 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <46E94D4F.20003@digitalbazaar.com> References: <46E81EB6.30703@digitalbazaar.com> <1189625140.5682.9.camel@localhost.localdomain> <46E844EC.1010802@digitalbazaar.com> <1189635098.5682.72.camel@localhost.localdomain> <46E94D4F.20003@digitalbazaar.com> Message-ID: <1189726855.11330.42.camel@localhost.localdomain> On Thu, 2007-09-13 at 10:46 -0400, Manu Sporny wrote: > Martin McEvoy wrote: > > I am not trying to be too simplistic here but I hope you can see what I > > am trying to say, > > I don't think I see everything that you're trying to say, Martin... but > I'll try to summarize what I think you are saying: > > I think you're making an argument for not bloating hAudio by adding too > many new class names. I was...! > > I think you think that I'm making an argument for adding album, toplist, > podcast, playlist, and others. I am definitely not making this argument, > although reading back through the thread, I can see how it might be > construed that I am proposing adding a 5-7 new class names to hAudio. > You are not!!... so why all the votes for adding these class names ? http://microformats.org/wiki/audio-info-issues#Collection_Names sorry I vote for none :( hAudio is the container class if we we make hAlbum redundant which I am in strong favour of. haudio haudio-title track media-title I use haudio-title here to say that this is our main haudio title and we have been forbidden talk about just *title* because of its conflicts with the title attribute in hCard. and media-title is a generic name for what we are trying to describe. Personally I don't like the use of Track either when there already is something that describes our need if we use *item* from the item-brainstorming page. http://microformats.org/wiki/item-brainstorming haudio haudio-title item media-title this coupled with the addition of a description, or note as Andy has been in favour of haudio haudio-title description item media-title description can be reused from xFolk http://microformats.org/wiki/xfolk and I would say we have got something worth shouting about. > This thread started by trying to eliminate the hAlbum proposal. I think > we should still do that, the question is... how do we eliminate hAlbum, > but keep the functionality of hAlbum? > > > If we bloat haudio in the ways you and others are suggesting then the > > actual use of hAudio (in my opinion) will be very slow indeed. > > I don't think any of us want to bloat hAudio. Right now, I am proposing > adding two things to hAudio in order to eliminate hAlbum: > > ALBUM and TRACK > > -- manu Thanks Martin > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Thu Sep 13 20:56:11 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Sep 13 20:56:15 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <1189726855.11330.42.camel@localhost.localdomain> References: <46E81EB6.30703@digitalbazaar.com> <1189625140.5682.9.camel@localhost.localdomain> <46E844EC.1010802@digitalbazaar.com> <1189635098.5682.72.camel@localhost.localdomain> <46E94D4F.20003@digitalbazaar.com> <1189726855.11330.42.camel@localhost.localdomain> Message-ID: <46EA065B.5010301@digitalbazaar.com> Martin McEvoy wrote: > so why all the votes for adding these class names ? > > http://microformats.org/wiki/audio-info-issues#Collection_Names Looks like I was getting ahead of myself :) - I have removed my votes for CHART and PLAYLIST. I still support ALBUM, PODCAST and TRACK, though. > http://microformats.org/wiki/item-brainstorming We can't use item :(, it is limited to using a small set of class names that have almost nothing in common with hAudio [1]: """ As a microformat, this is very much analogous to hCard and we shall reuse all applicable attributes: * fn - the name of an item * url - the web address of an item * photo - a photo of an item * adr - the address of an item (for example, a house) * geo - likewise """ > haudio > haudio-title > item > media-title Let's look at an example using your proposal: ...listening to May the Rain found on Paper Tigers by... With the album-keyword-based proposal, here's the markup: ...listening to
May the Rain found on Paper Tigers
by... with the haudio-title-based proposal, here's how we would do that: ...listening to
May the Rain
found on Paper Tigers
by... The haudio-title-based proposal has the following issues compared to the album-keyword-based proposal: - It is more verbose, requiring publishers to write more HTML. - It requires hAudio nesting to mark up a simple song and album example. - You cannot differentiate an album from a podcast. What about using SECTION instead of TRACK? It could be used in hVideo and hAudio. SECTION makes sense for albums, podcasts, clips, television, movies... but doesn't really work for charts or playlists. -- manu [1] http://microformats.org/wiki/item-brainstorming#Notes From chris.newell at rd.bbc.co.uk Fri Sep 14 03:47:43 2007 From: chris.newell at rd.bbc.co.uk (Chris Newell) Date: Fri Sep 14 03:47:47 2007 Subject: [uf-new] hAudio ISSUE #10: Collection Names In-Reply-To: <46E96D26.8080408@digitalbazaar.com> References: <46E81EB6.30703@digitalbazaar.com> <1189625140.5682.9.camel@localhost.localdomain> <46E844EC.1010802@digitalbazaar.com> <46E96D26.8080408@digitalbazaar.com> Message-ID: <6.2.0.14.2.20070914103828.02e5b558@pop3> Manu, I don't think "TRACK" belongs in the list of Collection Names shown in issue #10 on the audio-info-issue page. It refers to an item, rather than a collection, and is a good choice for this role IMHO. Cheers, Chris From chris.newell at rd.bbc.co.uk Fri Sep 14 04:16:16 2007 From: chris.newell at rd.bbc.co.uk (Chris Newell) Date: Fri Sep 14 04:16:24 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <46EA065B.5010301@digitalbazaar.com> References: <46E81EB6.30703@digitalbazaar.com> <1189625140.5682.9.camel@localhost.localdomain> <46E844EC.1010802@digitalbazaar.com> <1189635098.5682.72.camel@localhost.localdomain> <46E94D4F.20003@digitalbazaar.com> <1189726855.11330.42.camel@localhost.localdomain> <46EA065B.5010301@digitalbazaar.com> Message-ID: <6.2.0.14.2.20070914120110.02df16a0@pop3> Manu, Just a suggestion but wouldn't it be good practice to use an ordered list in the hierarchical example? (on the audio-info-issues page). BTW I think the three structures proposed are excellent (the only outstanding issue that concerns me is the signalling of collection type). Chris From chris.newell at rd.bbc.co.uk Fri Sep 14 08:22:11 2007 From: chris.newell at rd.bbc.co.uk (Chris Newell) Date: Fri Sep 14 08:22:15 2007 Subject: [uf-new] hAudio ISSUE #8: hAlbum is redundant In-Reply-To: <46E98162.6020000@digitalbazaar.com> References: <6.2.0.14.2.20070913115619.02d907a0@pop3> <46E98162.6020000@digitalbazaar.com> Message-ID: <6.2.0.14.2.20070914150031.04209418@pop3> At 19:28 13/09/2007, Manu Sporny wrote: >Chris Newell wrote: >> If there is a single, generic collection-title field >> could you use the "type" and "value" construction to >> achieve this? >> >> For example: >> >> >> Album: >> Sticky Fingers >>