Re: [uf-new] hAudio - audio-album and audio-podcast
Joe Andrieu wrote: There seemed to be partial agreement that hAudio means the individual audio recording, that being the simplest case to solve, although I agree with the contradiction in the above problem statements. The answer for multiple audio recordings on a page is to have multiple hAudio. Dealing with smart ways to group hAudio is a different problem. I agree with both you and Scott. Martin also made a good point in an off-list e-mail for dropping halbum for now because it is confusing people. So, let's drop audio grouping (halbum) for now. We will re-visit halbum after we get haudio out of the door... Let's clarify haudio to deal with individual audio recording, not groups of audio recordings. I'll update hAudio and post the modifications to the list for feedback. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
RE: [uf-new] hAudio - audio-album and audio-podcast
Manu Sporny wrote: Brian Suda wrote: --- now we are spiraling back to ideas of what people WANT rather than model what is being published. I agree - we should keep our focus on solving demonstrated needs as outlined by the audio-info-examples exploratory discussion. Right now, we are talking about audio albums. Rather than respond in detail to other points, I'd like to make a suggestion. Why don't we stop worrying about albums and just solve audio-info? This seems to be the most atomic, simplest case we can address. Playlists, albums, tracks, CDs, etc., are all complications. Once we get hAudio working, I think it makes sense to talk about what hAlbum might look like--including whether or not it is just another type of hAudio. There are clearly far more audio pieces on the web than albums, even if all albums are (or have) audio characteristics. Can we focus on solving this base case and then build from there? -j -- Joe Andrieu SwitchBook Software http://www.switchbook.com [EMAIL PROTECTED] +1 (805) 705-8651 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
Joe Andrieu wrote: Manu Sporny wrote: Brian Suda wrote: --- now we are spiraling back to ideas of what people WANT rather than model what is being published. I agree - we should keep our focus on solving demonstrated needs as outlined by the audio-info-examples exploratory discussion. Right now, we are talking about audio albums. Rather than respond in detail to other points, I'd like to make a suggestion. Why don't we stop worrying about albums and just solve audio-info? The reason that we are focusing on albums right now is because the first draft of audio-info seems to be done. Nobody seems to have raised any issues related to existing elements in the haudio draft in several weeks. We talked about each element of haudio that was under contention in the following discussions: http://microformats.org/discuss/mail/microformats-new/2007-May/000252.html http://microformats.org/discuss/mail/microformats-new/2007-May/000305.html http://microformats.org/discuss/mail/microformats-new/2007-May/000316.html http://microformats.org/discuss/mail/microformats-new/2007-May/000329.html http://microformats.org/discuss/mail/microformats-new/2007-May/000342.html http://microformats.org/discuss/mail/microformats-new/2007-May/000349.html http://microformats.org/discuss/mail/microformats-new/2007-May/000377.html I believe that the basic haudio draft addresses all of the needs demonstrated by audio-info-examples. The only thing that is left to do is address albums. We need to address albums because they have a very heavy representation in the audio-info-examples page. Can we focus on solving this base case and then build from there? I believe that we have done a good job at addressing the base cases. The only reason I am not saying that we've solved the haudio base case is because you don't solve the problem in the first draft. We need to publish something so that people can start playing around with it and what we have now can address most of the examples (as long as we have some way of specifying albums). The draft doesn't need to address every issue under the sun... we will iterate on the concept as long as a need is demonstrated. We are doing what you are suggesting, Joe - we've done a good job at addressing the base case. Now we're seeing if we can build on top of the base case - audio albums are the first step. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
On Jun 5, 2007, at 6:46 PM, Manu Sporny wrote: Scott Reynen wrote: On Jun 5, 2007, at 4:00 PM, Colin Barrett wrote: A classical recording is a good example -- unlike popular music, the tracks on the album are often merely segments of a larger whole, f.e. Beethoven's Fifth is comprised of four movements. All of the same information that can be applied to a track can be applied to an album or playlist. They're really just divisions of a larger whole. The only information I could see an album of playlist needing that a track wouldn't would be: # of tracks and # of discs. If that's the case, what do we gain from using separate terms for album and track? Either it's useful to distinguish between the two with labels, or it's not. album, summary, and track, when combined with haudio, are more semantically accurate when describing audio albums. They add semantic specificity to haudio which is needed to differentiate haudio that describes an album, and an haudio that describes a track. We shouldn't need to combine terms to arrive at semantic accuracy. Each individual term should describe a specific, easily understood concept by itself. For example, fn describes a name. We all know what a name is. haudio, on the other hand, currently describes a collection of metadata about some type of audio. It's not clear what that really means outside the context of album or track. I don't think I'm going to publish an haudio on my website. I think I'm going to publish a track on my website or I'm going to publish an album on my website. Where are the examples of something that would be haudio being published with no album or track? I'm not finding any such examples in the wiki. I believe that Colin (and I) are arguing against complicating halbum any more than necessary: Right, me too. We just disagree about what is complicated. halbum title contributor image-summary duration payment Why should we do the above, when something much simpler would solve the problem: halbum summary haudio In my view, that's not simpler; it's just fewer concepts. haudio is a new concept, which publishers don't currently understand, so we'd need to explain what it means, which is basically title, contributor, image-summary, etc. I see no reason they should need to learn a new concept for the container of all those already- understood concepts. That you are able to look at haudio and understand title, contributor, etc. does not mean that anyone else will be able to do the same. What you're actually asking publishers to understand and publish is this: halbum summary haudio title contributor image-summary duration payment Which I think is clearly more work for publishers than the same schema without the additional layers of summary and haudio. Also, I think those layers are poor semantics. We're not talking about the title of an haudio of a summary of an album. We're talking about the title of an album, and the markup should clearly reflect that. On Jun 6, 2007, at 1:43 AM, Joe Andrieu wrote: Why don't we stop worrying about albums and just solve audio-info? I think this is a great idea. On Jun 6, 2007, at 8:22 AM, Manu Sporny wrote: The reason that we are focusing on albums right now is because the first draft of audio-info seems to be done. I disagree. Nobody seems to have raised any issues related to existing elements in the haudio draft in several weeks. I don't know how you can possibly think that. Multiple people have suggested changing the wiki entry in just the last few days, and you've said you don't think it should change because there's not enough consensus. Now you're saying there's complete consensus? I still don't understand what exactly class=haudio means. That's hardly a minor issue. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
Scott Reynen wrote: halbum is the grouping Microformat for audio albums specifically - it can aggregate a number of haudio recordings together. halbum is the grouping of albums? I'm guessing this is a miscommunication, as I've seen no previous discussion of groups of albums. Please clarify. Yep, that was a typo... That should've read halbum is one of the grouping Microformats for haudios. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
Scott Reynen wrote: Nobody seems to have raised any issues related to existing elements in the haudio draft in several weeks. I don't know how you can possibly think that. Multiple people have suggested changing the wiki entry in just the last few days, and you've said you don't think it should change because there's not enough consensus. Now you're saying there's complete consensus? I still don't understand what exactly class=haudio means. No, I am not saying that there is complete consensus over everything we're talking about in hAudio. I think there is a rough consensus over the following items being important in haudio: * hAudio (haudio) o fn (aka formatted name). required. text (re-used from hcard). o contributor. optional. using hCard. + suggested 'role's: speaker, artist, composer, band, publisher o published-date. optional. using datetime-design-pattern. o sample. optional. using rel-design-pattern with sample as the mf-rel-value. o rel-enclosure and rel-payment. optional. acquisition using URL and rel-enclosure and rel-payment design patterns. o image-summary. optional. using HTML and XHTML tag img. o category. optional. text. o duration. optional. ISO-8601 time duration using abbr-design-pattern (re-used from hcalendar). o price. optional. using currency-proposal. The halbum topic is currently being debated heavily: halbum summary haudio track haudio track haudio vs. halbum title contributor image-summary duration payment haudio haudio haudio -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
On Mon, 2007-06-04 at 20:42 -0600, Scott Reynen wrote: On Jun 4, 2007, at 6:33 PM, Joe Andrieu wrote: The alternative to the above that I thought you were going for was something like this: halbum playlist/XOXO haudio haudio haudio haudio That makes sense to me. How so? example of the proposed method: halbum haudio [album title,contributor,image-summary, duration, payment] xoxo track haudio [track 1, duration, sample] track haudio [track 2, duration, sample] track haudio [track 3 duration, sample] what doesn't make sense here? guys. The only possible argument here would be the over use of haudio in xoxo as it is not strictly necessary if you nested the playlist in a single hAudio as each li is haudio example: halbum haudio [album title,contributor,image-summary, duration, payment] xoxo track [track 1, duration, sample] track [track 2, duration, sample] track [track 3 duration, sample] hmm problem here, what if our album has multiple content types not all albums are just playable music yes? I don't think we would want to nest hVideo and hImage inside hAudio would we? so Now it becomes useful to define which track is music and which is video or Images. example: halbum haudio [album title,contributor,image-summary, duration, payment] xoxo track hvideo [part 1, duration, sample, aspect, fps] track haudio [part 2, duration, sample] track haudio [part 3, duration, sample] track himage [part 4, size, filetype, compression,etc] But then in your example, you did something like this: halbum haudio playlist/XOXO track haudio track haudio track haudio That was definitely confusing. I was also confused by that. I spent a while trying to figure out what exactly class=haudio would mean in this schema, and it looks like haudio has an incredibly generic meaning along the lines of information about some type of audio where both albums and tracks are potential types of audio. Err No not exactly haudio doesn't have to be playable audio it is also be just information about an album example halbum haudio [album title,contributor,image-summary, duration, payment] maybe you do have a point though in the context of just an album description hAudio becomes a little redundant as this is indeed nothing that is Audio just a description of audio maybe this is better: halbum summary [album title,contributor,image-summary, duration, payment] this would fit into our schemata much more cleanly, Manu did use summary in his original problem solution statement http://microformats.org/discuss/mail/microformats-new/2007-June/000458.html halbum summary [album title,contributor,image-summary, duration, payment] xoxo track hvideo [part 1, duration, sample, aspect, fps, etc] track haudio [part 2, duration, sample] track haudio [part 3, duration, sample] track himage [part 4, size, filetype, compression,etc] I think that's far too general to be useful. The container and item labels should be specific enough to make that unnecessary. If we can't assume class=halbum refers to audio, I think it's a poor class name and another name should be chosen that clearly indicates the content relates to audio without any need for additional labels like haudio. Not when you take into account that hAlbum may contain Audio Video and Images I think class-halbum is an excellent class name its simple, meaningful and it uses terms that people already use. http://www.xspf.org/orig-xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.8 -Martin- -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new smime.p7s Description: S/MIME cryptographic signature ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
Scott Reynen wrote: The alternative to the above that I thought you were going for was something like this: halbum playlist/XOXO haudio haudio haudio haudio That makes sense to me. Ah crap... I seem to have caused confusion with my ramblings. Apologies. The proposal is close to what Joe and Scott have said makes sense: halbum summary (this is the haudio that describes the album) haudio playlist/XOXO track haudio track haudio track haudio The above is the current proposal... which is not set in stone and could change. The wiki hasn't been updated because we have not decided if this is okay with the list. Martin has done some real-world markup to demonstrate the album/track problem solution proposal: http://weborganics.co.uk/haudio Feedback on solving the problem as demonstrated above would be very helpful. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
Joe Andrieu wrote: It seems that halbum means we no longer requires this grouping abstraction. That is correct - but this has only come about in the last couple of days. I usually wait for some sort of concensus before updating the wiki. What is your definition for a playlist? I think we have different definitions. Do you mean A list of playable audio objects.? That's a really good question. I mean a list of audio tracks... We've already had the playlist discussion on this list: http://microformats.org/discuss/mail/microformats-new/2007-April/000155.html A playlist is hAudio + XOXO - simple as that. Respectfully, a few points. First, please don't assume that your most recent statement on the email list is the definitive community answer. We've already had this discussion comes across as patronizing. Apologies if my statements came across as patronizing. They were certainly not intended as such, you have made some very good points and continue to do so. Please take my statements as opinion backed by what I consider solid logical arguments. The reason that I pointed you to that link is that I think you are making an argument for an addition to hAudio grouping called 'playlist'. At the end of the thread, Kevin Marks said: XOXO is a fine way to express simple collections, or nested ones; eg hGeo in XOXO is a sensible form fro waypoints. hAudio in XOXO would be a sequence, or playlist, which is a useful form. Nobody seemed to disagree with that - the thread died there. I think everybody on here is open to talking about playlists. I don't necessarily think that we NEED the concept of a 'playlist' in halbum... we probably don't even need the concept of xoxo in halbum. We're trying to start with the simplest possible solution and we can build on top of that at a later date. I support album as a semantically specific collection, but I'm still unsure why there are two different types of hAudio in your example The example doesn't contain two different types of hAudio. hAudio describes information about an audio recording. Note that this is different from describing an audio file. Describing an audio file is the job of the file-format exploratory discussion: http://microformats.org/wiki/file-format-examples I have several questions with this approach. First, what is that first haudio item, the at halbum-summary-haudio? The first haudio describes the album - which is why it is encased in a 'summary' tag. Is that a playable audio file of the entire album? If somebody wanted to provide a complete audio file of the entire album, they would use the rel-enclosure method in halbum-summary-haudio. Here is an example: div class=halbum div class=summary div class=haudio span class=fnBlack Horse and The Cherry Tree/span a rel=enclosure href=/black-horse-album.mp3Download/a /div /div /div If we are working with hAudio at the most basic component for audio, I would think haudio would be the actual file or at least the meta-data around facsimiles of the same audio content (perhaps different file formats underneath). Describing an audio file is the job of the file-format exploratory discussion. Describing files is not part of the haudio discussion: http://microformats.org/wiki/file-format-examples I pointed you to the It seems that haudio is potentially--and confusingly--presented as both an atomic semantic class and as a grouping construct capable of making collections out of itself. I don't quite understand how you intend to use it. Then, perhaps it would be helpful to think of it this way. We are talking about two Microformats: halbum and haudio haudio is the atomic Microformat that is used to describe audio recordings. halbum is the grouping Microformat for audio albums specifically - it can aggregate a number of haudio recordings together. We are not using hAtom to aggregate hAudio into albums because when we use hAtom, we lose semantic meaning. The same argument could be used as a pro-playlist stance. Second, how would I display just a playlist, one that has never been an album? Is it like this: ol class=xoxo div class=fnMy Party Songs/div li div class=track div class=haudio span class=fnBlack Horse The Cherry Tree/span /div /div /li li div class=track div class=haudio span class=fnOne Day [Live]/span /div /div /li /ol With the current approach it would be like this: ol class=xoxo li div class=haudio span class=fnBlack Horse The Cherry Tree/span /div /li li div class=haudio span class=fnOne Day [Live]/span /div /li /ol if you want to make an argument for adding a playlist container, it could be like this: ol class=playlist li class=track div class=haudio span class=fnBlack Horse The Cherry Tree/span /div /li li class=track div class=haudio span class=fnOne Day [Live]/span /div /li /ol If that is correct, then how am I (as a
Re: [uf-new] hAudio - audio-album and audio-podcast
Martin McEvoy wrote: hmm problem here, what if our album has multiple content types not all albums are just playable music yes? I think what both Scott and Joe are referring to are audio albums. We aren't talking about video albums or multimedia albums. We should concentrate on solving the audio album problem. I don't think we would want to nest hVideo and hImage inside hAudio would we? No, but we may want to nest hAudio, hVideo and hImage inside a hMedia container. I was also confused by that. I spent a while trying to figure out what exactly class=haudio would mean in this schema, and it looks like haudio has an incredibly generic meaning along the lines of information about some type of audio where both albums and tracks are potential types of audio. Err No not exactly haudio doesn't have to be playable audio it is also be just information about an album That is correct - let's not confuse hAudio with the file-format exploratory discussion. The purpose of haudio is to describe information related to audio recordings. example halbum haudio [album title,contributor,image-summary, duration, payment] maybe you do have a point though in the context of just an album description hAudio becomes a little redundant as this is indeed nothing that is Audio just a description of audio maybe this is better: halbum summary [album title,contributor,image-summary, duration, payment] this would fit into our schemata much more cleanly, Manu did use summary in his original problem solution statement The reason 'summary' was included in halbum is because the audio-info-examples demonstrate that we need a way to specify album name, artist, publish date, cover image, sample links and a variety of other things related to both albums and tracks. It makes sense to just use haudio to describe those things because the haudio proposal already contains all that information. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
On Jun 5, 2007, at 4:50 AM, Martin McEvoy wrote: On Mon, 2007-06-04 at 20:42 -0600, Scott Reynen wrote: On Jun 4, 2007, at 6:33 PM, Joe Andrieu wrote: The alternative to the above that I thought you were going for was something like this: halbum playlist/XOXO haudio haudio haudio haudio That makes sense to me. How so? Well, I know what albums are, I know what playlists are, and I know what audio files are, so this is describing familiar concepts, specifically the concepts I thought we were trying to model. example of the proposed method: halbum haudio [album title,contributor,image-summary, duration, payment] xoxo track haudio [track 1, duration, sample] track haudio [track 2, duration, sample] track haudio [track 3 duration, sample] what doesn't make sense here? guys. The label haudio appears to be describing two distinct concepts here (1: album information, 2: individual track information), which I find confusing. That these two concepts share some properties, but that doesn't make them the same thing. I think there are two many layers of abstraction here. haudio should describe something specific, e.g. an audio recording, not a vague collection of metadata that could apply to a wide variety of things. The only possible argument here would be ... Here's the argument I'm making, impossible though you may deem it: I'm confused, and microformats should not be confusing. so Now it becomes useful to define which track is music and which is video or Images. I'd say if track isn't clearly specific to audio, haudio should use a different label which is clearly specific to audio, as that's all haudio is about. example halbum haudio [album title,contributor,image-summary, duration, payment] maybe you do have a point though in the context of just an album description hAudio becomes a little redundant as this is indeed nothing that is Audio just a description of audio maybe this is better: halbum summary [album title,contributor,image-summary, duration, payment] It seems to me we're talking about the title, contributor, etc. *of the album*, not of the summary of the album, nor of the haudio of the album. So I don't see the value of an intermediate container here. So I would suggest the following schema for album information, placing the properties directly within the album container: halbum title contributor image-summary duration payment http://www.xspf.org/orig-xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.8 All of the terms there seem to be audio-specific. I think all of the terms in haudio should be similarly audio-specific. On Jun 5, 2007, at 7:58 AM, Manu Sporny wrote: hAudio describes information about an audio recording. I would suggest that an album is not an audio recording; it's a series of audio recordings. So if hAudio is about audio recordings, it shouldn't be used to describe albums. And I would also suggest that the term track describes an audio recording, so using both haudio and track seems largely redundant here. The first haudio describes the album - which is why it is encased in a 'summary' tag. If it describes the album, why isn't it encased in the halbum element? Isn't that the most obvious place to put something that describes the album? The summary class seems completely meaningless here. What exactly would we lose by taking it out? halbum is the grouping Microformat for audio albums specifically - it can aggregate a number of haudio recordings together. halbum is the grouping of albums? I'm guessing this is a miscommunication, as I've seen no previous discussion of groups of albums. Please clarify. With the current approach it would be like this: ol class=xoxo li div class=haudio span class=fnBlack Horse The Cherry Tree/span /div /li li div class=haudio span class=fnOne Day [Live]/span /div /li /ol I think the divs here are unnecessary markup, which we should avoid as much as possible. We can apply classes to lis: ol class=xoxo li class=haudio span class=fnBlack Horse The Cherry Tree/span /li li class=haudio span class=fnOne Day [Live]/span /li /ol A track is an entry in halbum. It is not specified in the haudio schema because we haven't had enough people agree/disagree with the concept. I disagree with the concept. Any haudio element within an halbum element should be considered part of the album. I see no need for an additional concept here. The album/track discussions are in far too great a state of flux to document it on the wiki. Once we come to some sort of rough consensus, we can put something up there. I disagree. The whole point of the wiki is to allow us to quickly iterate the documents. If there's
Re: [uf-new] hAudio - audio-album and audio-podcast
Colin Barrett wrote: On Jun 5, 2007, at 2:20 PM, Scott Reynen wrote: The label haudio appears to be describing two distinct concepts here (1: album information, 2: individual track information), which I find confusing. That these two concepts share some properties, but that doesn't make them the same thing. I think there are two many layers of abstraction here. haudio should describe something specific, e.g. an audio recording, not a vague collection of metadata that could apply to a wide variety of things. They're actually, IMO, almost entirely the same. I agree with Colin - there really isn't a significant difference between what you proposed for halbum and what haudio already does. They are almost entirely the same. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
On Jun 5, 2007, at 4:00 PM, Colin Barrett wrote: On Jun 5, 2007, at 2:20 PM, Scott Reynen wrote: The label haudio appears to be describing two distinct concepts here (1: album information, 2: individual track information), which I find confusing. That these two concepts share some properties, but that doesn't make them the same thing. I think there are two many layers of abstraction here. haudio should describe something specific, e.g. an audio recording, not a vague collection of metadata that could apply to a wide variety of things. They're actually, IMO, almost entirely the same. A classical recording is a good example -- unlike popular music, the tracks on the album are often merely segments of a larger whole, f.e. Beethoven's Fifth is comprised of four movements. All of the same information that can be applied to a track can be applied to an album or playlist. They're really just divisions of a larger whole. The only information I could see an album of playlist needing that a track wouldn't would be: # of tracks and # of discs. If that's the case, what do we gain from using separate terms for album and track? Either it's useful to distinguish between the two with labels, or it's not. If it's not, we could just embed haudio inside haudio to indicate sub-sections of audio (as suggested in audio-info-proposal). If it is a useful distinction, we should clearly identify the difference. We shouldn't use unnecessary labels. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
On Wed, 2007-06-06 at 00:03 +, Brian Suda wrote: On 6/5/07, Martin McEvoy [EMAIL PROTECTED] wrote: Colin you have a good point here haudio would not be extended far enough to suit the classical communities needs when you take into account that Beethoven has nine symphonies with a total of 37 movements with sub properties of ... On 6/5/07, Colin Barrett [EMAIL PROTECTED] wrote: Another example: You don't mark up information about the song Star Spangled Banner, you mark up the information about Jimi Hendrix's particular recording of it. e.g, year would be 1967, not 1814. --- now we are spiraling back to ideas of what people WANT rather than model what is being published. Another concern i have been having about this prososal is that it is more about exposing existing company Database Schemas, rather than what the average person is publishing. The more i think about it, the more i realise i have never seen a blog talk about the run-time of track 3 of a given CD. It is always, that CD is great, you should buy it. Which is more of a review than any sort of media-format. We are spending alot of time trying to model a database schema of existing companies rather than see what people are publish. we are not talking about blogs though are we? we are talking about music download sites which do have run times and track numbers? We need to avoid, what about ... suggestions, otherwise we will have more endless cyclical conversations. which is, I guess, why the media info discussion ground to a halt? -Martin- -brian smime.p7s Description: S/MIME cryptographic signature ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
Scott Reynen wrote: On Jun 5, 2007, at 4:00 PM, Colin Barrett wrote: A classical recording is a good example -- unlike popular music, the tracks on the album are often merely segments of a larger whole, f.e. Beethoven's Fifth is comprised of four movements. All of the same information that can be applied to a track can be applied to an album or playlist. They're really just divisions of a larger whole. The only information I could see an album of playlist needing that a track wouldn't would be: # of tracks and # of discs. If that's the case, what do we gain from using separate terms for album and track? Either it's useful to distinguish between the two with labels, or it's not. album, summary, and track, when combined with haudio, are more semantically accurate when describing audio albums. They add semantic specificity to haudio which is needed to differentiate haudio that describes an album, and an haudio that describes a track. I believe that Colin (and I) are arguing against complicating halbum any more than necessary: halbum title contributor image-summary duration payment Why should we do the above, when something much simpler would solve the problem: halbum summary haudio -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
Brian Suda wrote: --- now we are spiraling back to ideas of what people WANT rather than model what is being published. I agree - we should keep our focus on solving demonstrated needs as outlined by the audio-info-examples exploratory discussion. Right now, we are talking about audio albums. Another concern i have been having about this prososal is that it is more about exposing existing company Database Schemas, rather than what the average person is publishing. Are you saying that hAudio isn't useful to bloggers or website creators? Or that we should differentiate between independent publishing and corporate publishing? I didn't think that Microformats made that distinction - isn't all published data of importance to this community? -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
RE: [uf-new] hAudio - audio-album and audio-podcast
Manu Sporny wrote: However, I do believe it is the simplest, most atomic problem we could start with. And therefore, probably our best chance for getting traction. The current hAudio proposal says Defining parts of an hAudio will not be complete without a complete grouping draft/specification. That comes across as implying a much more complicated hAudio than the schema and your most recent comments suggests. What we're suggesting is a very simple addition to hAudio. This is the same exact solution that was devised for hAtom... you should take some time and read up on the 'hfeed' property. http://microformats.org/wiki/hatom#Feed What we're talking about adding is 'album'. To quote from the wiki[1]: == tracks, songs, and parts in general are specified by embedding hAudio's inside of hAudios and using the ideas put forth in grouping-brainstorming and grouping-proposal. Defining parts of an hAudio will not be complete without a complete grouping draft/specification. == It seems that halbum means we no longer requires this grouping abstraction. If this is correct, I think it is the right way to go (and we should update the wiki). If I'm misunderstanding and the above quote is still valid, then please explain how grouping fits into the current haudio proposal. What is your definition for a playlist? I think we have different definitions. Do you mean A list of playable audio objects.? That's a really good question. I mean a list of audio tracks... We've already had the playlist discussion on this list: http://microformats.org/discuss/mail/microformats-new/2007-April/000155.html A playlist is hAudio + XOXO - simple as that. Respectfully, a few points. First, please don't assume that your most recent statement on the email list is the definitive community answer. We've already had this discussion comes across as patronizing. Second, you asked for my definition. Please take a moment to respond rather than suggest it is made irrelevant by prior conversations. Third, the link you refer to seems to be discussing XOXO as a general solution to an ordered grouping. Certainly, playlists are an ordered grouping. However, there is more to it than that. They are playslists. A playlist indicates that the following list is meant (or is intrinsically packaged) to be played together. Not every listing of audio is a playlist. For example, considering the combined works of Beethoven as a playlist is a bit excessive, even if the works are all proper hAudio items. However, I believe the current specification has no way to specify that a given XOXO list is a /playlist/ without an oddly redundant haudio that is confusing in more ways than one. In the email cited above you state: == div class=haudio span class=collection Audio albums, DVDs, and photo albums could have the collection specifier, songs, video episodes, and images wouldn't. == However, rather than have album a specific of a generic collection, I believe you are currently suggesting evolving the the proposal have halbum as a first class microformat, which contains other, multiply different haudio elements of fundamentally different types. I support album as a semantically specific collection, but I'm still unsure why there are two different types of hAudio in your example: === Here is a complete example of what we're talking about: div class=halbum div class=summary div class=haudio span class=titleBlack Horse and The Cherry Tree/span by span class=collaborator hcard fnKT Tunstall/span /div ol class=xoxo li div class=track div class=haudio span class=fnBlack Horse The Cherry Tree/span /div /div /li li div class=track div class=haudio span class=fnOne Day [Live]/span /div /div /li /ol /div It's simple design, readable, easy to author, contains a playlist, doesn't have any scary dot-notation, and is semantically rich. === I have several questions with this approach. First, what is that first haudio item, the at halbum-summary-haudio? Is that a playable audio file of the entire album? If we are working with hAudio at the most basic component for audio, I would think haudio would be the actual file or at least the meta-data around facsimiles of the same audio content (perhaps different file formats underneath). It seems that haudio is potentially--and confusingly--presented as both an atomic semantic class and as a grouping construct capable of making collections out of itself. I don't quite understand how you intend to use it. See the wiki example for album markup[2] for an example of haudio used as a collection item for albums. Second, how would I display just a playlist, one that has never been an album? Is it like this: ol class=xoxo div class=fnMy Party Songs/div li div class=track div class=haudio span class=fnBlack Horse The Cherry Tree/span /div /div /li li div class=track div
Re: [uf-new] hAudio - audio-album and audio-podcast
On 5/31/07, Manu Sporny [EMAIL PROTECTED] wrote: What ever happened to working on the media-format? The media-format was far too broad of a problem - that's why it hasn't moved forward in two years even though there are a great number of examples of marking up media on the web. It is far easier to break the problem up into audio, video and images and tackle those individually: --- i would disagree, the Dublin Core group spent many many years and narrowed down the base Metadata to 14 (i think) values. When people propose these new microformats each one wants their little pet-project portion of metadata to get into the new format. In the most basic sense all the media has a creator and some additional metadata. They might be different types of formats, but the metadata is the pretty much the same. I just think there was either, no interest in developing the format, or too many what if we add this happened and it never moved forward. Those are different problems - we aren't addressing those problems with this Microformat. We have a very specific problem statement for audio-info: The problem statement reads: It is difficult for a browser to extract semantic information about an audio recording described on a web page. Metadata such as speaker, musician, publisher, label, title of the work, release date, acquisition link, related image artwork and tags provide relevant context for the audio recording. with the exception of audio recording the could apply to any media format. I don't feel it is that specific for audio. We should stick to the small problem and solve that - not make it bigger and more complicated (boiling the oceans). --- correct, but this doesn't have to mean what formats it encompasses, but the scope of the problem. It shouldn't attempt to have every possible metadata property possible - i agree that is boiling the ocean, but if the same 4-5 metadata properties can apply to multiple formats we should keep that in mind, and i think we have done a good job to keep the scope focused on just the minimal amount of metadata properities needed. I just feel these same properties can simultaniously apply to multiple things. Could you expand on this idea please? I want to make sure I understand you correctly. I'm fine with the concept of non-hyphenated names, are you suggesting something along the lines of: album description haudio track haudio track haudio --- You could have some overarching container, lets call that something like media. That has meta data, much like hfeed. media tags, decription, contributer, ... then, nested in that media is individual items, much like hentry in an hfeed. media tags, description, contributer, ... track track track chapter each of those items (track, chapter, ...) contain additional metadata about themselves. media tags, description, contributer, ... track duration, title, author, price, ... chapter duration, title, author, price, type, ... Last i remember the hAudio proposal basically broke down to just an hReview with a price and a running time. The semantics of audio-info are very different from the semantics of a review. The following are required for audio info (based on the analysis and brainstorming done by this list): fn, contributor, published-date, rel-sample (samples), rel-enclosure (full versions), rel-payment (purchase option), image-summary, category, duration, and price - hardly any of those overlap with hReview. hm, hreview has fn, so does this proposal, it has published-date just like this proposal, it has an image just like this proposal, it has tags just like this proposal's category, hreview has URL which could be used as the download links... like i originally said, it basically broken down to many of the same values in hReview, with the addition of price and duration. The only value required for an hReview is the FN. Then we got all side-tracked with a grouping issue. One of the first steps in proposing a microformat is to see if an existing microformat could fit. After spending along time on the mailing list, simply suggesting things, the whole conversation bascially was pulled back to hReview. Has anyone attempted to simply mark-up their data using hReview with a price and duration (which is already a solved problem in hCalendar)? Lets try to keep this MICRO and not go wild attempting to layer more and more data into hAudio/Media-format. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
RE: [uf-new] hAudio - audio-album and audio-podcast
Manu Sporny wrote: Joe Andrieu wrote: From reviewing the examples [2], Thank you for that very thorough and well thought out argument, Joe. I agree with most of what you had to say, here's my $0.02 on the rest: I think there are five distinct semantic items here, at a minimum: album playlist track audiofile podcast As for your playlist example at the end of your e-mail... you said it best when you noted Albums, podcasts, whatever, aren't they all forms of playlists? haudio with opional hplaylist? Not unless you can provide examples of them being display on the web as the same thing. We need examples of playlists to support your playlist argument... which we don't have. Sure we do. There are a bunch on the examples page, including the FIQL service I mentioned in my email. What we do have, however, is a plethora of album/track/song examples. Let's focus on solving that very specific problem. I support that. But then what you are solving is hAlbum. Not hAudio. Once we figure out hAlbum, we can certainly generalize upward to hAudio, incorporating playlists and podcasts as we go. I think that's a good solution, as it allows us to solve the specifics of how albums group songs into published works, which is much simpler than trying to generalize all the different ways that media properties aggregate and group other media. We just need to note that hAudio is waiting for hAlbum and start through the process with the more limited, more tractable focus on albums, reusing what we've already documented where appropriate. -j -- Joe Andrieu SwitchBook Software http://www.switchbook.com [EMAIL PROTECTED] +1 (805) 705-8651 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
Brian Suda wrote: I just think there was either, no interest in developing the format, or too many what if we add this happened and it never moved forward. It tends to be more of the latter when it comes to this list :) - lots of good ideas... in fact, too many to see clearly, sometimes. That is why it would be good of us to limit this discussion to audio-info only. You also stated that that you feel these same properties can simultaneously apply to multiple things. Yes, absolutely they can - I wouldn't be surprised at all if images and video shared a great number of the elements (such as 'fn', 'image-summary', 'duration', and 'price'). However, we don't know until we do the research - that means collecting 80-100 video site examples and collecting 80-100 image site examples. If somebody on the list wants to go and do that right now, that would be great. However, barring any heroes collecting and analyzing all of those examples - we don't have the data necessary to make the arguments. My gut tells me you are correct, Brian - however, Microformats are not based on gut-feelings... they're based on hard data. --- You could have some overarching container, lets call that something like media. That has meta data, much like hfeed. All good suggestions - why can't we do both album and media? I was defending the position that you are defending just a few days ago. That of generic grouping. As Joe noted, you lose quite a bit of semantic meaning when you use generic containers - that seemed to be a theme in the arguments against hSet. I don't think you're going to find many people that will agree to create another generic container when we just had a very drawn out discussion about generic containers. Has anyone attempted to simply mark-up their data using hReview with a price and duration (which is already a solved problem in hCalendar)? It loses semantic meaning. An album isn't the same thing as a review. You don't tell your friends Hey I just listened to a review called Yeehaw and the Kick Me Brothers last night - it was great!. At that point, they have no idea if you're talking about a movie, a podcast, an album, or a song. You say I listened to this album called Yeehaw and the Kick Me Brothers last night. It is far more semantically accurate. Encapsulating hAudio in hReview when writing a review about a song or album would be a perfect example of using the two together in a proper manner. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
Joe Andrieu wrote: We need examples of playlists to support your playlist argument... which we don't have. Sure we do. There are a bunch on the examples page, including the FIQL service I mentioned in my email. Are we looking at the same examples page? http://microformats.org/wiki/audio-info-examples What we do have, however, is a plethora of album/track/song examples. Let's focus on solving that very specific problem. I support that. But then what you are solving is hAlbum. Not hAudio. Once we figure out hAlbum, we can certainly generalize upward to hAudio, incorporating playlists and podcasts as we go. That's funny... that's exactly what we said about hAudio... we'll start with hAudio and generalize upward to albums, podcasts and playlists. The hAudio Microformat is meant to be delivery/container mechanism agnostic. hAudio is supposed to be encapsulated by the delivery mechanism, be it a playlist, album, podcast, media or other such container. What is your definition for a playlist? I think we have different definitions. Do you mean A list of playable audio objects.? -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
RE: [uf-new] hAudio - audio-album and audio-podcast
Manu Sporny wrote: Joe Andrieu wrote: We need examples of playlists to support your playlist argument... which we don't have. Sure we do. There are a bunch on the examples page, including the FIQL service I mentioned in my email. Are we looking at the same examples page? http://microformats.org/wiki/audio-info-examples Wow. I literally have no idea how I found FIQL. I was sure it was from the examples page. Here are a few examples of playlists: CCMixter http://ccmixter.org/media/view/media/playlists FIQL http://www.fiql.com FNAC Music http://www.fnacmusic.com/pl/95c186a6-ca78-4e69-bb6c-d1fc155cfcdd.aspx Mix Matcher http://www.mixmatcher.com However, your point is correct. The current list of examples are all built around albums and playlists. Most likely because that's pretty much what you restricted it to with the templates. No offense intended, but it's a pretty strong opening constraint at the top of the wiki page. Rather than jump in and violate that structure, I've not added the playlist examples above to the wiki yet. What we do have, however, is a plethora of album/track/song examples. Let's focus on solving that very specific problem. I support that. But then what you are solving is hAlbum. Not hAudio. Once we figure out hAlbum, we can certainly generalize upward to hAudio, incorporating playlists and podcasts as we go. That's funny... that's exactly what we said about hAudio... we'll start with hAudio and generalize upward to albums, podcasts and playlists. Ah... Well, that's ok. But I don't think it is what you are doing as there is much conversation and documentation about albums and grouping. If you want to start with the most basic atomic element, that /could/ be hAudio, although a slightly different hAudio than I was considering. An atomic hAudio is more what I was calling audiofile, i.e., the representation of a single audio resource. I was coming at it from the other direction: that hAudio is a type of hMedia, a peer of hVideo and hBook. In that case, it would contain/be any kind of audio packaging from albums to podcasts to playlists. The hAudio Microformat is meant to be delivery/container mechanism agnostic. hAudio is supposed to be encapsulated by the delivery mechanism, be it a playlist, album, podcast, media or other such container. Ok. That I can support. So, let's step back from the album and grouping concepts and focus on hAudio as this paragraph suggests. Frankly, whether this is called hAudio or hAudiofile is not so interesting. However, I do believe it is the simplest, most atomic problem we could start with. And therefore, probably our best chance for getting traction. The current hAudio proposal says Defining parts of an hAudio will not be complete without a complete grouping draft/specification. That comes across as implying a much more complicated hAudio than the schema and your most recent comments suggests. What is your definition for a playlist? I think we have different definitions. Do you mean A list of playable audio objects.? That's a really good question. I mean a list of audio tracks. They need not be playable in the sense of having a downloadable reference, but if they were to be found, then each of the items should produce audio when played using the appropriate application or device. So, althought I know this doesn't hit the 80/20 rule, for me, a playlist should work for offline and fictional songs. For example a playlist of Elvis From the Dead with Elvis song titles adjusted for Halloween. Yes, I know this is totally outside the scope of what we should waste our time on, but it illustrates one of the boundaries of what a playlist could be. More practically, one might create a playlist wishlist for songs they don't know where or how to find online or that they don't care to, because they have the CDs and that's what the DJ will be using at the bar mitzvah this weekend. You get the idea, I think. In my conception: . Album: playlist(s) + meta-data (including cover-art, etc.) . Playlist: track(s) + meta-data . Track: option audiofile(s), each the same audio in different formats or from different distribution points + meta-data . Podcast: playlist(s) + meta-data; although I think 80/20 suggests podcasts are usually a single track, single audiofile . Audiofile: a specific downloadable media file that contains audio + meta-data. So, I'm good with focusing current efforts on the simplest case. I would call that an audiofile, but by no means do I think that's the important term. What would you call what I've been referring to as hAudio, a type of hMedia and a peer to the as-yet-to-be-defined hVideo and hBook? Also, I bet that cleaning up the current hAudio to focus entirely on just this atomic item, and none of the grouping... including album... Would make this a lot more tractable and understandable for folks. In fact, I would suggest moving all of the album
Re: [uf-new] hAudio - audio-album and audio-podcast
On Thu, 2007-05-31 at 12:56 +, Brian Suda wrote: On 5/31/07, Manu Sporny [EMAIL PROTECTED] wrote: There are only two things that are strongly supported by the audio-info-examples right now. Audio albums and audio podcasts (collections of audio). Here are the options: Option #1: audio-album/audio-podcast as a container Option #2: audio-album/audio-album-item as container/subcontainer Option #3: audio-collection (instead of audio-album/audio-podcast) Feedback on each option or proposal of new options would be helpful. --- firstly, microformats are not a how should we do this it is more of a how are things already being done? Your use of audio-album could cause problems later in the semantic meaning, iTunes has many celebrity playlists, which are not actually ALBUMS, but are a collection of related songs. The term podcast seems very 2005, in 4 years will we still use 'podcats' maybe, maybe not? I think manu was just trying to be obvious in his descriptions. What ever happened to working on the media-format? this seems like a similar problem to DVD chapters, and other multi-media issues? I agree that maybe we have been too far down this path that the discussion around separating audio, video, and images and then tackling Media info has gone stale and maybe not the right direction to chose, we can no longer see the cow path never-mind pave it I vote for moving this discussion back to media info, and go from there, I am not saying that this discussion has been a waste of time indeed far from it we have discovered many of the main elements needed of any media info proposal fn, contributor, role's speaker, artist, composer, band, publisher, published-date. rel-sample rel-enclosure and rel-payment, image-summary, category, duration, price, you can add type atributes, audio/mpeg, image/jpeg, video/mpeg, or any other type listed at IANA or here: http://en.wikipedia.org/wiki/Internet_media_type and we would be somewhere near hMedia later we can find ways to mark up codec, sample rate, channels, bitrate for audio, and codec, aspect, and fps for video and we will be done. so how about we move this on? I would also prefer that these property names NOT be hypenated. Why not just use something like: media/track? then you could use 'track' independantly of album/media, and album/media potentially independant of track? for instance, discographies/videographies/DVD, that lists just albums and films. Last i remember the hAudio proposal basically broke down to just an hReview with a price and a running time. -brian smime.p7s Description: S/MIME cryptographic signature ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
Brian Suda wrote: --- firstly, microformats are not a how should we do this it is more of a how are things already being done? Option #2 is how it is already being done. The options were more about if we wanted to generalize the scope of the hAudio Microformat. It was to see if anybody had a preference and why... Your use of audio-album could cause problems later in the semantic meaning, iTunes has many celebrity playlists, which are not actually ALBUMS, but are a collection of related songs. The term podcast seems very 2005, in 4 years will we still use 'podcats' maybe, maybe not? We're not concerned with what might happen in the future. We're concerned with what's already there - the cow paths. The two major types of grouping in the audio-examples are podcasts and albums. What ever happened to working on the media-format? The media-format was far too broad of a problem - that's why it hasn't moved forward in two years even though there are a great number of examples of marking up media on the web. It is far easier to break the problem up into audio, video and images and tackle those individually: http://microformats.org/discuss/mail/microformats-new/2007-April/000143.html In the end we might come up with a grand Microformat that covers audio, video and images. Although, even that goes against some of the concepts of Microformats - solving simple problems, defining simple Microformats, etc. this seems like a similar problem to DVD chapters, and other multi-media issues? Those are different problems - we aren't addressing those problems with this Microformat. We have a very specific problem statement for audio-info: http://microformats.org/wiki/audio-info-examples#The_Problem We should stick to the small problem and solve that - not make it bigger and more complicated (boiling the oceans). I would also prefer that these property names NOT be hypenated. Why not just use something like: media/track? then you could use 'track' independantly of album/media, and album/media potentially independant of track? for instance, discographies/videographies/DVD, that lists just albums and films. Could you expand on this idea please? I want to make sure I understand you correctly. I'm fine with the concept of non-hyphenated names, are you suggesting something along the lines of: album description haudio track haudio track haudio Last i remember the hAudio proposal basically broke down to just an hReview with a price and a running time. The semantics of audio-info are very different from the semantics of a review. The following are required for audio info (based on the analysis and brainstorming done by this list): fn, contributor, published-date, rel-sample (samples), rel-enclosure (full versions), rel-payment (purchase option), image-summary, category, duration, and price - hardly any of those overlap with hReview. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
Martin McEvoy wrote: Your use of audio-album could cause problems later in the semantic meaning, iTunes has many celebrity playlists, which are not actually ALBUMS, but are a collection of related songs. The term podcast seems very 2005, in 4 years will we still use 'podcats' maybe, maybe not? I think manu was just trying to be obvious in his descriptions. Yes, I was attempting to offer several options - each having it's own set of trade-offs and see which ones people chose and for which reasons. What ever happened to working on the media-format? this seems like a similar problem to DVD chapters, and other multi-media issues? I agree that maybe we have been too far down this path that the discussion around separating audio, video, and images and then tackling Media info has gone stale and maybe not the right direction to chose, we can no longer see the cow path never-mind pave it I vote for moving this discussion back to media info, and go from there, I strongly disagree - media info was a very broad problem. So broad that almost no progress has been made on it in over eighteen (18) months. Splitting the exploratory discussion into smaller pieces helped us focus on solving a manageable problem - audio-info. Audio-info has seen a great deal of progress in the past 3 months. We are 90% of the way there - the only item left for discussion is deciding the naming for the grouping (album and podcast). The first draft of the hAudio Microformat would be done at that point. you can add type atributes, audio/mpeg, image/jpeg, video/mpeg, or any other type listed at IANA or here: http://en.wikipedia.org/wiki/Internet_media_type and we would be somewhere near hMedia Nope - we would actually be a very far way from hMedia. Remember the Microformats process - we would need to collect and analyze examples for video and images. You can't say that all we would have to do is add 'type' attributes and we would almost be there without collecting enough hard data to back that statement up. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
