Re: [uf-new] The Process (was: hAudio case study)
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes Document the implicit schemas that the content examples imply. Every word in that sentence matters. On the contrary: implicit is redundant. The alternative: Document the schemas implied by the content examples. reads better. -- Andy Mabbett ___ 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. microformats-new@microformats.org 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
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. microformats-new@microformats.org 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: span class=collection span class=typeAlbum/span: span class=valueSticky Fingers/span /span 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
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 ___ microformats-new mailing
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
