Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
I like how the format is coming together, but have two questions. Firstly, when looking at the complete album example markup, I wondered why haudio needs to be nested in track. Could those two things maybe be the same element? Like so: ... instead of having to write which seems slightly bloated to me, especially considering hCalendar allows for this format with location and hCard (as seen here: http:// microformats.org/wiki/hcalendar-location-hcard-example). The same could be done for contributer and hCard, do they really need to be nested or could those two classnames be on the same element? Secondly, is there any means of marking up *just* an artist? I guess that might be out of the scope of the haudio microformat, but it would be quite important to have this possibility. There certainly are pages out there who only mention an artist without naming any specific tracks, and the role property of hCard seems not very suitable for that task as very few people would write—in a blog post, for example—‘the artist so-and-so’. I’m sorry if the second thing doesn’t belong in this thread, I’ve never before used a mailing list. Should I open a separate issue for this? —Julian On 28 Sep 2007, at 8:10pm, Martin McEvoy wrote: On Fri, 2007-09-28 at 11:34 -0400, Manu Sporny wrote: Martin McEvoy wrote: ...listening to May the Rain found on Paper Tigers by... *Item* works here as a root class on its own and is used as a semantic finger pointing out the interesting or important parts... Sorry Martin, I missed this e-mail for some reason until just now. No worries:) I had the same problems with one of your posts to the list... I agree with you in concept, we need /something/ to point out that one haudio is a part of another haudio (containers and items in those containers). We are, however, barred from using 'item' because it was previously defined as this in hReview and we can't change it's definition: The definition Is perhaps incorrect? When to take into account that ITEM means something entirely different in other cases consider RSS.. millions of feeds synicated all over the world in every language all using the same term ITEM http://cyber.law.harvard.edu/rss/rss.html#hrelementsOfLtitemgt another example http://web.resource.org/rss/1.0/modules/audio/ the definition here certainly matches the ITEM definition I am proposing for hAudio do you think? item info. required. fn (url || photo ) | hCard (for person or business) | hCalendar (for event) That means that we cannot put an hAudio in ITEM. Got any other suggestions? The best we've been able to come up with thus far has been TRACK or SECTION. I am also suggesting parts that can be reused in other media related uF's, item and media-title. Just *title* would be great but...we know the story on that one:) Again, I agree with you in principle... it's just a matter of word choice. We can re-use TRACK in CDs, albums, and possibly DVDs. However, we can't do that in movies, podcasts, or other container formats. That is why I suggested that we use SECTION instead of TRACK. We can use SECTION in CDs, albums, movies, television episodes, podcasts and other container formats. hItem technically I would say already exists as a uF on its own wouldn't you? Nope, I wouldn't go that far. ITEM does exist, but it already has pre-defined semantics that, while we would like to change, attempting to do so in the past has been disastrous[1]. how about breaking title off from hCard so we can explore title In other contexts I mean *Title* , and *Item* in the real world has so many definitions why hog them up in such a ways that it makes it impossible to be used in other uF's ? this seems bad to me! 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. ...how do you summarise section? You could use the proposed DESCRIPTION element, if it is approved and if there is enough evidence for it. http://microformats.org/wiki/audio-info-proposal#Description -- manu Thanks Martin_ [1]http://microformats.org/discuss/mail/microformats-new/2007-June/ 000511.html ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
On Fri, 2007-09-28 at 11:34 -0400, Manu Sporny wrote: > Martin McEvoy wrote: > > ...listening to > > > > > > May the Rain > > > > found on Paper Tigers > > > > by... > > > > *Item* works here as a root class on its own and is used as a semantic > > finger pointing out the interesting or important parts... > > Sorry Martin, I missed this e-mail for some reason until just now. No worries:) I had the same problems with one of your posts to the list... > I > agree with you in concept, we need /something/ to point out that one > haudio is a part of another haudio (containers and items in those > containers). > > We are, however, barred from using 'item' because it was previously > defined as this in hReview and we can't change it's definition: The definition Is perhaps incorrect? When to take into account that ITEM means something entirely different in other cases consider RSS.. millions of feeds synicated all over the world in every language all using the same term ITEM http://cyber.law.harvard.edu/rss/rss.html#hrelementsOfLtitemgt another example http://web.resource.org/rss/1.0/modules/audio/ the definition here certainly matches the ITEM definition I am proposing for hAudio do you think? > > item info. required. fn (url || photo ) | hCard (for person or business) >| hCalendar (for event) > > That means that we cannot put an hAudio in ITEM. Got any other > suggestions? The best we've been able to come up with thus far has been > TRACK or SECTION. > > > I am also suggesting parts that can be reused in other media related > > uF's, item and media-title. Just *title* would be great but...we know the story on that one:) > > Again, I agree with you in principle... it's just a matter of word > choice. We can re-use TRACK in CDs, albums, and possibly DVDs. However, > we can't do that in movies, podcasts, or other container formats. That > is why I suggested that we use SECTION instead of TRACK. We can use > SECTION in CDs, albums, movies, television episodes, podcasts and other > container formats. > > > hItem technically I would say already exists as a uF on its own wouldn't > > you? > > Nope, I wouldn't go that far. ITEM does exist, but it already has > pre-defined semantics that, while we would like to change, attempting to > do so in the past has been disastrous[1]. how about breaking title off from hCard so we can explore title In other contexts I mean *Title* , and *Item* in the real world has so many definitions why hog them up in such a ways that it makes it impossible to be used in other uF's ? this seems bad to me! > > >> 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. > > > > ...how do you summarise section? > > You could use the proposed DESCRIPTION element, if it is approved and if > there is enough evidence for it. > > http://microformats.org/wiki/audio-info-proposal#Description > > -- manu Thanks Martin_ > > [1]http://microformats.org/discuss/mail/microformats-new/2007-June/000511.html > ___ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
Martin McEvoy wrote: > ...listening to > > > May the Rain > > found on Paper Tigers > > by... > > *Item* works here as a root class on its own and is used as a semantic > finger pointing out the interesting or important parts... Sorry Martin, I missed this e-mail for some reason until just now. I agree with you in concept, we need /something/ to point out that one haudio is a part of another haudio (containers and items in those containers). We are, however, barred from using 'item' because it was previously defined as this in hReview and we can't change it's definition: item info. required. fn (url || photo ) | hCard (for person or business) | hCalendar (for event) That means that we cannot put an hAudio in ITEM. Got any other suggestions? The best we've been able to come up with thus far has been TRACK or SECTION. > I am also suggesting parts that can be reused in other media related > uF's, item and media-title. Again, I agree with you in principle... it's just a matter of word choice. We can re-use TRACK in CDs, albums, and possibly DVDs. However, we can't do that in movies, podcasts, or other container formats. That is why I suggested that we use SECTION instead of TRACK. We can use SECTION in CDs, albums, movies, television episodes, podcasts and other container formats. > hItem technically I would say already exists as a uF on its own wouldn't > you? Nope, I wouldn't go that far. ITEM does exist, but it already has pre-defined semantics that, while we would like to change, attempting to do so in the past has been disastrous[1]. >> 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. > > ...how do you summarise section? You could use the proposed DESCRIPTION element, if it is approved and if there is enough evidence for it. http://microformats.org/wiki/audio-info-proposal#Description -- manu [1]http://microformats.org/discuss/mail/microformats-new/2007-June/000511.html ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
Manu Sporny wrote on Thu, 13 Sep 2007 20:59:18 -0700 > 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... Neither YOU or I would markup hAudio like that? ...listening to May the Rain found on Paper Tigers by... *Item* works here as a root class on its own and is used as a semantic finger pointing out the interesting or important parts... I am also suggesting parts that can be reused in other media related uF's, item and media-title. Also its worth adding at this point that hReview has a similar type mechanism that works in a similar way pointing out items in a review http://microformats.org/wiki/hreview#Schema hItem technically I would say already exists as a uF on its own wouldn't you? > > 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. ...how do you summarise section? > > -- manu > Thanks Martin. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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 >> > >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... hCard tackles this problem by defining a list of "type" values (and a default). However, this doesn't really solve the problem that few people specify the "type" explicitly. Chris ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Subject: Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
>Date: Wed, 12 Sep 2007 15:58:36 -0400 >From: Manu Sporny <[EMAIL PROTECTED]> >Subject: Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant >To: "For discussion of new microformats." > >Message-ID: <[EMAIL PROTECTED]> >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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
>Date: Wed, 12 Sep 2007 23:11:38 +0100 >From: Martin McEvoy <[EMAIL PROTECTED]> >Subject: Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant >To: "For discussion of new microformats." > >Message-ID: <[EMAIL PROTECTED]> >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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
On 12/9/07 17:32, "Manu Sporny" <[EMAIL PROTECTED]> 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. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
On 9/9/07 15:18, "Manu Sporny" <[EMAIL PROTECTED]> 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 > --- --- > recordingAudio Recording > recording + albumAudio Recording with Album info > albumAlbum > 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. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
On Sun, 2007-09-09 at 10:34 +0100, Andy Mabbett wrote: > In message <[EMAIL PROTECTED]>, Martin > McEvoy <[EMAIL PROTECTED]> 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 > ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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 --- --- recordingAudio Recording recording + albumAudio Recording with Album info albumAlbum 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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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-titleAudio Recording with Album info album-title Album toplist-titleTop List podcast-titlePodcast -- manu -- Manu Sporny President/CEO, Digital Bazaar, Inc. http://blog.digitalbazaar.com/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
In message <[EMAIL PROTECTED]>, Martin McEvoy <[EMAIL PROTECTED]> 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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
In message <[EMAIL PROTECTED]>, Manu Sporny <[EMAIL PROTECTED]> 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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] hAudio ISSUE #8: hAlbum is redundant
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
