Re: [mb-users] Sorting sub-works and more generally ARs

2013/10/23 Tom Crocker <[email protected]>

> On 23 October 2013 08:53, Frederic Da Vitoria <[email protected]> wrote:
>
>> 2013/10/23 tommycrock <[email protected]>
>>
>>> Frederic Da Vitoria wrote
>>> > Here is my suggestion: add a simple number to ARs which could be used
>>> by
>>> > the AR types which we find relevant. This number would of course be
>>> used
>>> > for ordering.
>>>
>>> Unfortunately there's various places that wouldn't achieve what I want.
>>> It
>>> won't work where the links aren't all to one entity or where there's
>>> multiple sets of ordered links to one work. For example, with medleys, if
>>> the performance is split over several recordings the numbering wouldn't
>>> work. Alternatively, if there are two medleys on one recording again it
>>> wouldn't work.
>>>
>>
>> Could you explain why it wouldn't work?
>>
>
> With the work sub-parts example you have work a linked to parts x, y and
> z. That works fine with numbered ARs.
>
> a) medley with recordings split into component works:
> The ARs are between
> recording - work
> a - x
> b - y
> c - z
> So there's nothing apart from perhaps some versions of a tracklist to tie
> them together.
>

Interesting, I hadn't thought of that: in a Recording-Work AR, the "parent"
is the Recording. But that doesn't change anything IMO, simple numbering
would still work.

>
> b) two medleys on one recording:
> the recording is linked to works p, q and r (medley 1) and x, y and z
> (medley 2). I guess with some kind of 1.1 numbering system this might be
> able to be handled, but probably not gracefully and not sure how it would
> interact with other works linked to the same recording that aren't part of
> a medley...
>

Ah, now I see. But in this case, I believe the recording should be split in
p, q, r, x, y and z using the Compilation Relationship, and then the r and
z recordings should themselves be ARed using the medley AR. Thus the
structure of the data would reflect the structure of the recording.


  I'd like to see an ordered list of relationships. However, if something
>>> like
>>> that wouldn't be implemented for several years and the simple numbering
>>> could be quickly then it'd be worth doing that as it would cover many
>>> cases.
>>>
>>
>> What could you be waiting for? What is it which could possibly only be
>> done in a long time?
>>
>
> It wouldn't necessarily take a long time, I'm just aware that the
> developers have a very long list of requests and only so much time, so
> changing the structure of the database is necessarily a long way down the
> list.
> The mechanics I'm thinking of would be a defined relationship between ARs.
> Something like a table of ordered types (medley, sub-parts, ...), a table
> that defines that grouping (medley 1, medley 2 in my examples above), and a
> table that links the grouping to the AR and defines the order. There's
> probably a more elegant / robust solution but anyway, something that would
> achieve that kind of thing.
> A simple number could more easily be added, but the UI for that would
> still be tricky to get right.
>

I hope that we don't need the complexity you are describing, because if
this true, then AR ordering is probably still for the far future.

-- 
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org

_______________________________________________
MusicBrainz-users mailing list
[email protected]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users