Take a typical classical release each recording has a ‘recording of’ relationship with a work, and that work has a ‘part of’ relationship with another work, that in the case of a symphony or concerto represents the complete symphony/concerto.
If that classical release is an Opera the second work probably represents an Act and then there is another ‘part of’ relationship to another work representing the complete Opera
I’m trying to find the correct words to describe these two levels/ three level of works
In what way do you want to describe them? You have the main work and its parts (which might have parts themselves, like Opera › Act › Scene). I’m not sure if there’s anything more to it.
I was coming it from the other end , looking for a word that would correct for the first work connected to the recording regardless of whether it part of an Opera or not and so on for the purposes of labelling these fields as part of a tag mapping that could be encoded into the songs themselves
Doesn’t the exact wording depend on the kind of work? So for an opera it is something like what is described above, while for a pop song you would probably just talk of the “song”.
So “work” is probably the most abstract thing you can apply for as a general wording without limiting it to a specific kind of work.
Yes but Im trying to differentiate between the different levels of works.
Consider the Tag Mapping used by Picard/Jaikoz
For a recording with one level of works we could extend and add
WORK_ID
WORK_NAME
Bur if two level of works, we could have but which way round is it, which level is which
WORK_ID
WORK_NAME
PART_OF_WORK_ID
PART_OF_WORK_NAME
But if three levels of works, what do we do now. My example was for Opera but there may be other three level works that aren’t Opera and I would want to rename the fields so that you now had
SCENE_NAME
ACT_NAME
OPERA_NAME
so incompatible with the other names
Ive come to realization that properly supportoing this level of works for classical is reuired for proper tagging of classical releases, any ideas ?
I see works more as a way to centralise creator relations, and less useful during tagging. So by all means, use the work’s composer, writer etc. information for tagging! But adding work titles in a structured fashion doesn’t buy you much. IMO, of course.
Here is an example when I think its useful, cases when you have an album containing two concertos as is often the case. For many users they want to see the recordings in each concerto linked together, the album name doesnt do this as it links both concertos together, but if the work was used as an album name that gives you two ‘albums’ which is more useful.
I think it’d be great to have work attribute indicating how it fits into a hierarchy. (part, scene, act, whatever) I’d call it work type if that name weren’t already taken
I’m sure there are non-opera cases of three-level nesting. e.g. The Wall is a super-work, which contains the multi-part composition “Another Brick in the Wall”.
Recording to work link we call COMPOSITION because that’s what it essentially is, and give us a fixed name for this relationship.
The top level work after traversing the various part of relationships we call WORK, and this top level work is likely to be what people are most interested in so good to have a fixed name
Then for all the works inbetween we have
PART_OF1
PART_OF2
PART_OF3
…
That way of naming depends on perspective: if you compare a recording of a main work to a recording of one of the parts of that main work, you’d end up with different work types for the same work.
It could be useful to simply store a level: the main work (like an opera) would be level 1, an act level 2 and a scene level 3. That way you don’t even need any involvement from an editor: you could automatically look up how many related works there are above a certain work. If you look up a scene, it would see that there is an act above it which itself is part of an opera, and assign level 3 to the scene.
I still don’t really see a need for this information, but these levels would be easy to implement and not depend on the kind of work.
Right so in your example one of your recordings is a single recording of the complete work, and one recording is a recording one part of the work. In the first case I’m not bothered about the levels below the work because there is a one-one correspondance between the recording and the top level work so both COMPOSITION and WORK would contain the same work. in the other case I am bothered so the lowest level one would be COMPOSITION and the top level WORK, because it is only two level I wouldnt need the PART OF fields
Doing this it this way in both cases the user can look at the COMPOSITION field to see the composition the recording is of, and the WORK field to see the overall WORK that the recording is (partly) of.
If I only use level likes you say then it makes the data more difficult to use for end users because they dont know what level the composition will be at without checking levels from 1 until they dont exist.
Did you go Work > Level 2 > Level 1 > Composition on purpose? In my mind, the Work is “top level” (i.e. level 0), but maybe you’re thinking of it differently?
Overall, I think this is a clever idea, giving the top and bottom levels names and simply numbering anything in between.
As this is related to tagging the starting point is the song because the metadata will be stored at song level.
So I am going song ->composition -> level 1 -> level 2 -> work because the counting begins from the song end.I agree that Work is top level but the counting is from the song end.
If metadata changes then updating the song would update should update all the metadata, I dont see a particular problem with an additional work existing at some point.
Somehow I missed work_type, this is very useful information for classical, no need to have NAME for WORK_NAME and I also realised the fieldnames for ids have to be clear that they are musicbrainz ids so added MUSICBRAINZ
I don’t like “composition” very much; there’ll be recordings (especially for audiobooks), where the work is text only. That makes “composition” not a great fit.
In and of itself I don’t see a problem including the full work hierarchy in tags. But I’m not sold on special names for the bottom/top cases.
Given an option for including the full work hierarchy, Picard could set
Fixed names at top and bottom make those tags accessible to taggers/players that dont have the option of complex plugin scripts, the idea is to get the data in the songs in a way that makes the data most easily available to the end user.
If a work has part of relationships with multiple works that is just too difficult to model within the constraints of the tagging systems available (ID3, VorbisComment) so I would just pick the first one and ignore the rest. Im not trying to replicate everything within Musicbrainz within the songs themselves just data that is of real use in playing songs in a way the user requires.
