I suspect I've thrown a red herring into the mix with the mention of classical music... apologies
My point was really that when a track from an album is played in isolation from that album (so on a radio episode tracklist or in a personal playlist) the track position on the album is still important data. Which means encoding this data as a property of the list ordering wouldn't work here. So I'd vote to keep position as a separate attribute I threw classical into the mix cos sometimes multiple tracks on an album can have the same title (dependent on how the record company has segmented the audio). In this case the track number is necessary to disambiguate which track was played The same is also true of audio books which often have multiple tracks per chapter all having the same chapter title. Somewhat embarrassingly my ipod currently contains Alan Bennett reading The Wind in the Willows were: Track 1 = The River Bank Track 2 = The River Bank Track 3 = The Open Road Track 4 = The Open Road Etc In terms of marking up acts and scenes and movements and works and etc I'd encourage hAudio to steer well clear. It's a hideous minefield and I suspect hAudio can solve 80% of the problem by avoiding this stuff. For an idea of the complexity I'd point semweb minded people at the fine work of Yves Raimond on the music ontology (which incidentally it would be nice to see used in the rdf-a hAudio spec): http://musicontology.com/ On 14/1/08 17:43, "Andy Mabbett" <[EMAIL PROTECTED]> wrote: > On Mon, January 14, 2008 17:19, Michael Smethurst wrote: > >> In the case of classical music identifying the track played by ordinality >> on the release is extremely useful. So a way to markup ordinality other >> than as a list would be preferable > > > In the following, for "piece" read "piece", "sequence" or some other term: > > <foo class="item start-piece">Piece 1, part 1</foo> > <foo class="item">Piece 1, part 2</foo> > <foo class="item">Piece 1, part 3</foo> > <foo class="item end-piece">Piece 1, part 4</foo> > <foo class="item start-piece">Piece 2, part 1</foo> > <foo class="item">Piece 2, part 2</foo> > <foo class="item">Piece 2, part 3</foo> > <foo class="item end-piece">Piece 2, part 4</foo> > > or: > > <foo class="piece"> > <foo class="item">Piece 1, part 1</foo> > <foo class="item">Piece 1, part 2</foo> > <foo class="item">Piece 1, part 3</foo> > <foo class="item">Piece 1, part 4</foo> > </foo> > <foo class="piece"> > <foo class="item">Piece 2, part 1</foo> > <foo class="item">Piece 2, part 2</foo> > <foo class="item">Piece 2, part 3</foo> > <foo class="item">Piece 2, part 4</foo> > </foo> > > though the latter again causes problems in tables (unless a TBODY is used > for each piece; which is arguably good practice). > > "Item" is an absolutely awful (and semantically-barren) name; it might be > best to use "piece and "subpiece" or something like that, assuming that > the piece's name is shown (unlike the above examples). > > Perhaps you have some real examples in mind? How any levels of > sub-division are there? > > I have recently posted links to others' efforts to solve the problem of > codifying the structure of disparate types of music: > > <http://tinyurl.com/2uval5> > > on the wiki. In particular, see: > > <http://oakroadsystems.com/genl/itunes.htm> 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 [email protected] http://microformats.org/mailman/listinfo/microformats-new
