The End of "Genres"

[steltz]

Brilliant, thank you, my double bass player(s) will be happy to see the extra works.

[imslp]

@Davydov:

1. A test project is fine, however, instead of doing 100 works, do 10. I say this because the purpose of it is for me to understand the general structure; whatever pages end up being done will have to be re-done when the tagging system is in place, because the technical solution for that is significantly different. You can choose the pages to do, and document which pages are done. Post the link on my talk page and I'll check it out.

2. Now I understand your insistence on having fine categories. My opposition was not towards your idea, but towards the implementation. Now that I know why exactly you want these combined categories, I fully support you wanting other people to be able to list the combinations for which there actually are pieces. However, there is a better way to achieve the same goal without actually having to create categories for the purpose.

So, instead, I will write a "Category Walker" special page. What it does is that it lists the other categories that are included in the pages in that category. For example, a category walk for "Sonata" may show up "Violin and Piano (20)", "Viola and Piano (5)" and etc (the numbers being the # of pages that are in both the "Sonata" and the other category). The benefits of this system are its flexibility (you don't need to walk only a genre/instrumentation combination; you can do it for any combination of categories, for example, a large composer category) and its malleability (I can change the entire system very easily via programming if there are problems).

3. I read your last post, and I wanted to express concern about using instrumentation categories that are too detailed. I am not opposed per se, but I think we should think about whether this system is supposed to replace the level of detail for the "Instrumentation" field on the page (except, of course, for the orchestral pieces which vary wildly), or whether it is supposed to be an abstraction of general instrumentation types. I am not hugely concerned because the tagging system will be able to combine categories should there be too many, but it is something that might be kept in mind. If it is expedient or necessary to do so, I do not mind revamping the instrumentation classification in the process. This is not a question that needs to be answered right now, though I would suggest putting a limit on the number of instruments for which there is a detailed category (i.e. any instrument combination above that number will need more generalized categories). But ultimately I leave the decision up to the librarians. However, I would like to hear your thoughts on this right now so I can better understand the system.

@Everyone else:

Now that I think I have a handle on what exactly the tagging system is about, I will describe the technical solution. It may sound strange at first, but I believe it is the most efficient.

There are three core components:
1. Tag resolution system. This system consists of two parts: (a) a tag translation page (TTP) in the style of normal translation pages (e.g. Mediawiki:FTE:composer:Messages and co.) (b) the mechanism inside #fte:imslppage which resolves the tag into actual categories. So, for example, a tag might be like "|Tag=SON, VLNP" on the work page, the corresponding TTP section being "*SON|Sonata" and "*VLN|Violin and Piano", the entire thing resolving into "[[Category:Sonata]][[Category:Violin and Piano]]". The reason for this translation is twofold: (a) it deters people from messing with the system (plus, the translation page can be locked to prevent tag creation by normal users), and (b) it allows for very cheap renaming and combining of categories, which is a huge plus because we cannot foresee what will happen in this project and people may well disagree or change their minds later. Additionally, a tag may be tied to two categories if necessary (e.g. "*SON|Sonata|Chamber works" = "[[Category:Sonata]][[Category:Chamber works]]"), and there is huge leeway for all sorts of different interpretations and tricks that one can do with tags.
2. Category intersect system. Basically this will be a modified version of the current system, adding two functionalities: (a) can intersect more than 2 categories, and (b) can do negative intersects (i.e. intersects pages not in category X).
3. Category walker. Basically what I told Davydov above. This will be combined with the category intersect system to create a fully and automatically navigable category system.

There are also a few optional components in planning that may make the entire project more pleasant to work with, but they are not essential to the project.

Any suggestions/comments welcome.

[Davydov]

Thanks for that, Feldmahler. Converting the tags into categories is a means to an end, and if your "Category walker" will fo the same thing, then so much the better.

Just one thing that concerns me a little. The lookup table you mentioned (with codes like "SON" for Sonatas, "VLN" for violin and piano) could be very awkward to use, as it will be necessary to lookup or remember all the codes each time a work is tagged. I'm not sure we could anticipate every eventuality beforehand, so a way would also have to be found to decide on and allocate new codes, which is likely to make for a very cumbersome process. Could a way be found to retain the textural element, so that, say, the tag "Sonatas|Violin and piano" would resolve in the same way to "[[Category:Sonatas]][[Category:Violin and Piano]]"?

I've already prepared some draft notes on the construction of the tags, which you may already have seen here. I've already made the point there that "It's important to be clear that the work tag is not intended to duplicate the detailed data that is (or should be) already displayed in the general information box of the work page. Instead, the tag should summarise this information as concisely as possible". Under these guidelines the theoretical limit on the number of solo instruments listed would be ten (for dectets/dixtuors), but in practice most of them will relate to the standard groupings that have already been discussed, and won't result in multitudes of fine categories. If we do find too many unwieldy examples cropping up then maybe we could review that limit later.

Similarly the large list of "work types" shown in the draft notes (adapted from the MLA list) is likely to vastly exceed our requirements (and is another good reason for not creating lots of empty categories in advance!)

The rest of your ideas sound very good, and I'll give some thought to the pilot over the next couple of days. At least it should stop me eating and drinking too much over the holidays

All the best to you, and to everyone involved with IMSLP, if you're celebrating this weekend.

[Lyle Neff]

I should think that "march" should not be listed under "Dances," but under a large category of "Military," as would bugle calls, soldier's songs, etc. (Of course, not all marches are military in their specific context, e.g., processional marches in operas for royalty, etc. -- but it's definitely not a "dance.")

Just sayin'.

[perlnerd666]

Actually, I beg to differ; marches in a musical (especially multi-movement) context are almost always basically dances (CF Berlioz Op. 14).

[Lyle Neff]

Actually, I beg to differ; marches in a musical (especially multi-movement) context are almost always basically dances (CF Berlioz Op. 14).

And what are the unique steps for this dance known as the march?

[perlnerd666]

Of course no such exists. However I would say that not all dances have unique steps...

[Melodia]

A march /is/ a dance, in musical terms.
And if you consider dancing as "moving your body in a specific way to a stable rhythm", then marches certainly fit.

[imslp]

Just one thing that concerns me a little. The lookup table you mentioned (with codes like "SON" for Sonatas, "VLN" for violin and piano) could be very awkward to use, as it will be necessary to lookup or remember all the codes each time a work is tagged. I'm not sure we could anticipate every eventuality beforehand, so a way would also have to be found to decide on and allocate new codes, which is likely to make for a very cumbersome process. Could a way be found to retain the textural element, so that, say, the tag "Sonatas|Violin and piano" would resolve in the same way to "[[Category:Sonatas]][[Category:Violin and Piano]]"?

The reason I had those codes was because they deter normal users from messing with them, and they provide standardization. If a category is created just by putting it in a tag, we will run into trouble such as case differences ("Violin and piano" and "Violin and Piano" are two different categories) and all the other variations. And while I do not oppose having more readable tag names if you don't mind users potentially messing with it, due to the standardization it may be such that the librarians will have to remember it anyway (i.e. the exact capitalization, etc). But the decision of what tag names to use is up to the librarians; my examples are just examples. One thing I would suggest though would be to use shortened instrumentation (since there is a standardized system for that), so that the tags are not too long. But again that's only a suggestion.

I don't think you need to worry about creating categories being cumbersome. The system is designed for on-the-fly changing (really actually "creating" since I presume tags are created as the retagging goes along), so creating, destroying and moving tag categories are the easiest possible. However, it is the case that in order to use a tag, you must first list it in the TTP, for the reasons I mentioned above (and a few more such as being able to list all of the Tags, which may be helpful later on). But aside from that, there is nothing else necessary to create these tags.

Of course, if I misunderstood something, do tell me.

Re: the instrumentation. I do remember reading somewhere that it would be restricted to smaller ensembles, but couldn't remember where. Thanks for the clarification.

And one last thing. I wanted to ask if you would be willing to lead the project. You have participated greatly in its creation, and I would be happy if you could lead the project. You clearly have thought about this for a long time, and I trust you to be able to successfully implement the project.

[aldona]

A march /is/ a dance, in musical terms.
And if you consider dancing as "moving your body in a specific way to a stable rhythm", then marches certainly fit.

(tries to imagine an army advancing towards the enemy to the tune of Schubert's Marche Militaire D.733/1...)

(visualises enemy forces being overcome and vanquished because they are laughing too hard to fight...)

aldona

[Melodia]

Heh. Well, I'm sure many a marching band over the years has played it.

[Davydov]

Hi Feldmahler. Thanks for your last message, and over the last couple of days I've been testing the tagging system on Beethoven's works, since he was a prolific composer who used a wide variety of work types and instrumental combinations. The tags have not been physically added to the pages, but this was an exercise to demonstrate how the tags would be allocated, and how they would resolve into different categories.

The full results are shown here. A total of 266 works were tagged, but these required only 94 unique tags, which in turn resolved into 49 different categories based on work type and 37 different instrumentation categories.

As you'll see from the examples, the idea is that users browsing any of the categories should be able to see works grouped according to their constituent tags, rather than just be presented with one long alphabetical list of "Dances", for example. This was where the initial idea of converting tags directly to sub-categories came in, as the Wiki software would then automatically display them in this way, but there's probably a neater technical way of achieving the same thing. Anyway, I hope it will give a clear idea of the basic structure behind the system, and ensure that everyone is involved is envisaging the same end result

In answer to your last question: yes, I would really appreciate the chance to oversee the project, as it's a subject I've been interested in for a long time (even before the recent discussions).

[imslp]

Very nice. I believe we are on the same wavelength regarding the tagging system. One small note: the "lower" and "higher" work categories will technically be the same level. However, the category walker will be able to find the "lower" categories within the higher ones, so technically what you want is possible, though not via an hierarchy system.

I will start work on the technical side of things on Jan. 1st. Expect it to be ready within a week of that. If possible I would like the retagging to proceed as soon as possible after that so that I have time to fix anything that pops up before the end of January, when I will again go on hiatus.

I have no problems with the example tags you did. To repeat something I suggested earlier, it may be beneficial to find some abbreviation system such that the tags don't get too long to type, but that is just a suggestion. Especially since the project members will all be librarians, an abbreviation system should work well. But you are the project leader and I leave that up to you. There will be two normal characters that are forbidden in tags (the pipe sign | and the comma ,) but otherwise anything goes (except spaces before and after the tag but I can't imagine why you would want that).

If you want you may begin recruiting librarians now...

Congrats to both of us on finally getting the system sorted out! I apologize if I seemed rude or picky; it is my job to make sure we all understand what exactly the system is, and to work out the best and most efficient solution. I fully expect that this system will put IMSLP miles ahead of almost all digital libraries on the net.

[steltz]

Which section would you like me to help with?

[Davydov]

Thanks, Feldmahler, and I'll clear my diary for next month. I'm actually due back at work on 4 January, but that shouldn't interfere too much

Some of our volunteer "librarians" are already champing at the bit, so I'll start completing the documentation so that everyone's ready when the time comes. I understand your point about abbreviations for tags, but after being involved with an unrelated project that used abbreviated codes, I know how easily things can go wrong when people get them muddled up, and how difficult it can be to detect and put right. I think there's much less chance of that happening if we stick to familar instrument names, and in any case the team will be monitoring the list of new categories created for any anomalies created by errors in the tags. Speaking of which, we'll need to make some adjustments to the tags to omit the forbidden commas, so how about something like this?:

• Songs / 4 voices + 2 violins + viola + cello
• Sonatas / horn + piano

You once told me that almost anything is technically possible on IMSLP! Having seen what you've already achieved I'm quite prepared to believe that, but because we've discussed a few options along the way I hope you won't mind me asking about two key aspects of the new system:
1) Will there be a lookup table in order to resolve the tag for, say, "Lieder / voice + piano" into the categories "Lieder", "Songs" and "Vocal works for soloists and piano"?
2) Will it be possible to display the contents of a category so that people can see the constituent tags, as here in one of the Beethoven examples:

Chamber works for string trio (7)
-- Ländler / 2 violins + bass (1)
-- Ländler / 2 violins + cello (1)
-- Serenades / violin + viola + cello (5)

... in preference to this:

Chamber works for string trio (7)
-- 2 violins + bass (1)
-- 2 violins + cello (1)
-- Ländler (2)
-- Serenadeso (5)
-- violin + viola + cello (5)

... which is likely to be much more confusing for the user. If you're tut-tutting as you read this and muttering "Of course it will!", then I apologise for asking silly questions

Thanks again for being willing to take these ideas on board!