[uf-new] Re: hAudio issue: position

[Michael Smethurst]

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" <andy at pigsonthewing.org.uk> 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.