Seems rather odd that I can enter where a work was premiered (via the Area → Premiered in" relationship), and even who commissioned it (via Artist → Commissioned by), but not who played that premiere.
For more modern works, I guess you’d do that by entering a recording in the catalog. But I’m tagging classical, and the premiere predates recording technology.
With far more research (or again with more modern works), possibly I could enter an event in—but I don’t have that information, and making up a pseudo-event (“That time so-and-so quartet played whoever back in 1860”) doesn’t seem like a sane approach.
Seems like there should be a relationship for who played the premiere.
It’s perfectly fine to create events which don’t have all possible data entered. For example If date isn’t known it can be left empty. I agree that it’s more work to create events for little data but I believe it’s still better if we don’t allow adding similar data on multiple entities. We already got lot of duplicates when people add exactly same data on multiple entities.
It’s more than the date that isn’t known—all I know is that “so and so quartet premiered the work in Berlin, November 1880”. So I don’t even have a name for the event—can’t leave that blank, so I’d have to make one up.
That strikes me as very likely to lead to even more duplicate events in the database.
If event is linked to work with premiered at-relationship it can’t be added twice to same work. Adding premiere event duplicates isn’t currently possible.
Even with only couple of details I see adding events valuable. I agree that separate work-relationships might save some time. But later when we add more data to it there could be a need for creating an event and for removing work-relationships because of duplicates. We could save some time now or spend more of it later.
I agree that event name shouldn’t be necessary. We already have an open ticket (MBS-8006) for not requiring it anymore.
How about “Premiere of [Name of Work] by [Performer]” or “[Performer] in [Area] on [Date]”? A lot of events don’t have proper names but are just named “[Artist] at [Place]”. If a better name comes along later, it can always be changed then.
I agree with @ListMyCDs.com that I’d rather see “stub” events linked to the Works (“premiered at”) than an Artist-Work “first performed by” relationship.
[quote=“Freso, post:7, topic:22246”]
agree with @ListMyCDs.com that I’d rather see “stub” events linked to the Works
[/quote]I agree, but then shouldn’t the Work-Place premiere relationship be deprecated? And data migrated to a “premiere” event?
I agree that we could get rid of Work-Place & Work-Area premiere relationships. I’m happy to help moving these to event level.
Like mentioned before, many events don’t have names. If we encourage people to create events we could decide to use [no name] (or similar) as a name until it’s possible to enter events without names. Events without actual names would be easier to identify when people wouldn’t make up some bogus titles. Bots or our editors could later easily remove [no name] .
[no name] seems like it’d only be appropriate if I’d actually done the research at e.g., an archive, found the announcements, and determined it actually had no name… I don’t know if concerts had names back in the 19th century. Classical concerts seem to often have names today.
And searching for one of those event entries would be difficult. E.g., when find out that two works premiered together. Pretty minor, as of course you can just chase the link from the other work.
The pro-forma title @Freso suggests doesn’t have those problem. I like the latter one ("[Performer] in [Area] on [Date]"); that way you get the essential info on the album page.
Notice that I was proposing it only to be a temporary solution until MB supports nameless events and also hinted that name could be different. For example it could be named as [unknown] and be defined similarly like special purpose artist: “used when a particular name is unknown, but is potentially discoverable with further research”.
For me it doesn’t make any sense to duplicate same data we already store in text format just to have something as a name. If there’s really a need for artificial names these could be easily generated for UI. There’s no need to store this data twice on DB.
When we deal with multiple languages it’s just getting harder to know if name is actually official or fan made. We should clearly define that this field should be used for storing official names.
I guess [unknown] doesn’t have that problem. Of course saying they could easily be generated for the UI… doesn’t help until they are.
I agree having to duplicate data is annoying (and lets things easily become inconsistent). There is a lot of duplication entering stuff in—and that’s hardly the most annoying. Parts of works not inheriting things from the work they’re part of is by far worse.