I think composition still works well enough for audio books, a piece if writing can still be a composition, i.e you compose a story. But if you can think of something better please share.
I do like this idea overall. A couple of things seem odd about the naming scheme to me (but it’s unlikely to ever affect me so feel free to ignore).
You’ve called the track level composition but linked them all together with the work keyword, so the level 1, level 2 seem in the wrong order - because it’s WORK_PARTOF_LEVEL1 rather than COMPOSITION_PARTOF_LEVEL1. My suggestion here is to use composition to mean the super work, since a typical recording would anyway have a work at the same ‘level’ as it only. Also, composition has composit in it, suggesting a whole of parts.
Would it be better to stick the MUSICBRAINZ with the ID? Partly because they go together and also an alphabetic sort will keep all the bits together. You could even go for MBID to keep it a bit shorter.
An example of a pretty common and well-known work which “is part of” two other works:
Other taggers might eventually adopt this scheme, so it may affect you sometime in the future.
Other MBID tag names are of the form
I more meant because I have very little classical
Thanks. I should have guessed that was following a standard
Shouldnt Le quattro stagioni (“The Four Seasons”) actually have a part relationship to Il cimento dell’armonia e dell’inventione, op. 8
Not really. That’s a set of 12, of which the four concerts usually grouped as “Le quattro stagioni” happen to be part - but they’re two different groupings of the concerts. It makes more sense to link all the 12 parts separately rather than introducing extra levels for these specific 4
Hmm, for me it would be useful to know that that the Four seasons is part of a larger work. But anyway I accept there good reasons why a work might be part of multiple works and this can be represented in Xml as the MusicBrainz schema already allows, but its just simply too complex to represent this within the constraints of the existing tagging systems.
Im using composition as in ‘compose’ rather than as in ‘parts of’ but I se that could be confusing. If you have an alternative list of names please post the complete list as its difficult to work out how it fits together when you only talk about one or two field names.
So I think I’m just suggesting the opposite order to you, so:
WORK recording level work
WORK_COMPOSITION super work
and the TYPE and ID ones as you had them but again this order.
To me this makes more sense as you’re saying WORK PART OF LEVEL1 (the work is part of level 1 is how I read that, rather than the composition is part of level 1…)
Yeah, I get that. It’s not really confusing just a possibility to tie the two ideas together.
An alternative suggestion, which may fit better with audiobooks etc. would be to use piece (which also means a bit of) where you’ve used composition so:
WORK_PIECE recording level work
WORK super work
Thanks, thats the same order as me, the difference is you have renamed WORK_COMPOSITION as WORK and WORK as WORK_COMPOSTION. For me the trouble with this is
- The most importance thing for most users will be the overall work with my naming convention that is the succinct WORK but its yours its the more cumbersome WORK_COMPOSITION.
- You now have the possibility that WORK_COMPOSITION is assumed to be to do with a composition (as I meant it) rather than comprising parts as you meant it so you havent solved that issue.
The alternative of using PIECE does remove any confusion over the work composition but I don’t see PIECE has anything to do with audiobooks and its not a word I would use regarding music although I know it can be used that way i still think a ‘song is a recording of a composition’ is better than ‘song is a recording of a piece’, especially if the piece is not part of a larger work.
I would still think of [Il cimento dell’armonia e dell’inventione, op. 8] (https://musicbrainz.org/work/7044d543-9f9d-4598-8ee7-0f9945d28595) as a composition (in musical terms) - but perhaps I’m wrong - so I don’t see the problem here.
If you don’t like WORK_PIECE my other suggestion would be to add COMPOSITION into each of the levels so
because it’s the recording level work that is “part of” not the super work.
You have a point the difficulty is because there can be anything from 1 to 6 levels in the current db of works what works well for one scenario is not so good for other. The trouble with PIECE is that it sounds like PART and if you have a recording linked to one WORK then its not a piece. I agree that COMPOSITION could be thought of as the top level all encompassing work but as thats the most useful work for most seems better to have simple WORK.
Some applications already do use PART as work, specifically a Movement but the trouble is they only consider a two level work hierachy and cant consider more than that.
Your idea of using WORK_COMPOSITION for all part of levels logically makes sense, but does mean we end up with some rather cumbersome long field names, and long fields are a practical pain
Undecided, Outsidecontext as co-author of tag mapping do you have an answer ?
Unfortunately not. I already tried to write a meaningful reply on this topic. But I realized that nested works is something I neither understand very well nor care much about.
So as I mentioned there is a field defined for VorbisComment as PART and also PARTNUMBER at http://age.hobba.nl/audio/mirroredpages/ogg-tagging.html and referred to in http://wiki.hydrogenaud.io/index.php?title=Tag_Mapping for the case of a something like Concerto the part would be the the work (i.e movement) the recording was linked to, and the PARTNUMBER would be the where that work came in the list of the upper work and it seem to just use the TITLE field for upper work which I would not do.
Of course this mechanism only supports two levels of work but it helpful for use to make use of existing defacto standards wherever possible and use similar for other formats so although PART isnt very descriptive Im now thinking along these lines:
Of course PART doesn’t make much sense if the recording is just linked to a work , and that work is the top level work as most work types of 'son’g are, but in that case perhaps we should just fill in MUSICBRAINZ_WORK_ID, WORK and WORK_TYPE for in this case and leave PART and PARTNUMBER alone
Users who dont know about MusicBrainz can continue to use PART and can deduce WORK, but we now have multiple levels and the Musicbrainz links are availabale for those who know about it
Those OGG tag recommmendations also mention a OPUS tag, how does this fit in? Would that be the most top level work then?
No that is different (but something I am going to add), as I understand it every time a classical composer creates a new top level work such as symphony or concerto they give it a new Opus number, generally starting from Op1. So in the example earlier Il cimento dell’armonia e dell’inventione, op. 8 is Opus 8, i.e Vivaldis eighth major work.
Il cimento dell’armonia e dell’inventione isn’t a work but a set of works. It’s a set of 12 concertos published together. The order of opus numbers with Vivaldi isn’t the order of in which the works were composed. I guess it’s related to publishing like with many earlier composers. Vivaldi used only 12 opus numbers (all for sets, 114 works included) even though he composed over 800 pieces.
Then it might best fit a Series entity (of Works) rather than a Work entity?
Why don’t Classical releases have track artists?
As a structure it would fit well but for many practical reasons it’s better to keep using works.
For example we currently use series for work catalogs but series doesn’t support mixing different types to same series. If op. 1 is a set but op. 2 isn’t these couldn’t be part of the same catalog. There would be also trouble with duplicates because search engine currently support only one entity type at once. Random visitor wouldn’t understand to select “series” when checking if a work already exists and would keep adding new duplicates.
There’s already over 700 000 works/parts on the database and it would be a nightmare to manually convert some of these to new format. It would also need some precious developer time.