Hello,
I wonder if it would be possible to have a different wording, on a relationship to relationship basis for the date ranges.
The current wording is the same for all relationships: « _____ from YYYY-MM-DD to YYYY-MM-DD »
But, when I use those date ranges, I often would like to read them as between / and rather than as from / to. Here are a few relationship types for which it sounds better to me:
___ performed ___ on ___ by ___ between date and date
___ by ___ was recorded at ___ between date and date
etc.
Because when we have a date span printed for some recording sessions, we know for sure that each one of the songs was not recorded continuously from date to date. But we mean that this song was recorded somewhere between date and date.
Aaactually, I would like to be able to give inexact dates on both the start and end date. For the full monty we would need four dates – schema change alert!
Let’s take the member-of relation as an example. Sometimes we know exactly when a person quit from a band but only vaguely know when they joined. One kinda-sorta can specify this by omitting the day of month, or the month, but this works only for some instances, and falls down for „Winter of 2006“ or „beggining of 1960s“
Finally, there are performances that span midnight, so from/to would be appropriate. Some even last 639 years.
Your proposal, while a good stepping stone, would prevent entering these. Four timestamps (including seconds, because: why not?) could catch them all.
I don’t understand which four timestamps?
I needed seasons as well a few times and also around/circa, early and late qualifiers as well.
By here I was proposing a smaller step but still useful.
We need more than that. For example, pretty much everything Seattle Symphony Media puts out will tell you, for everything recorded live September 15th and September 17th. That’s not 15–17; we know for sure that no recording was done on the 16th. What’s happened is they give each concert twice, and they’ve assembled together parts from both night’s recordings.
Worse, I’ve got some things where the several recordings that were assembled together are four different performances, over the course of more than a year.
Personally I deal with it by putting in multiple “recorded at” entries, each with one of the dates. Then just use the range for all the other relationships (because duplicating everything is ridiculous).
Strikes me if we’re going to have a schema change, ought to see about solving that problem too.
It remind me of an old discussion.
What I do when they say the album was recorded like that, as we cannot know for a particular track if it was recorded this or that date, is that I use a date range, reading it as between / and rather than from / to.
In this case, we would need an orconnector?
Once again, maybe my minimal change, while not perfect nor ideal, would be a good small step. Even if it is not the final solution, it could be pulled out super faster.
Well, classical releases often tell you very clearly when each track (or at least each work) was recorded. Here, I suspect, each track probably contains parts from both performances. I like the Thursday performance better, but there’s that annoying cough in the middle—so I’ll grab that part from Saturday…
But yeah, sometimes they don’t say.
And I wouldn’t object too much to changing day x and day x+2 to days x…x+2, as that’s only a 1-day difference. But changing “may 16 and 18, 2004; june 15, 2005” to 2004-05-16 to 2005-06-15 loses a lot of information.
If there’s actually enough people (including of course some people to do the coding) that want to improve date support, probably a good idea to put some thought in to it. Dates are… complicated. Especially since MB dates go back fairly far—before the Gregorian calendar. But a lot of that complexity we’re probably best off simply declaring we don’t care.
I think in this very case where for one track they tell you all the recording dates, there is no ambiguity problem with the current system, as you can set each date of recording (that makes double the relationships but it is not ambiguate).
The relation came into effect at some time between begin_start and begin_finish, but we are not sure when exactly. The relation ceased at some time between end_start and end_finish. That’s four times.
@derobert is correct, we can’t store every possibility with that … including my own example of „Winter of 2006“, unless you just ignore „Winter“.
By all means, I don’t want perfect to be the enemy of the good here.
That’s not a bad solution at all. IMO we „just“ need better UI for it.
A member joining and leaving a band multiple times is also common. I don’t think we should (or can) implement arbitrary complex time sets for a single relation.
I’m looking at https://musicbrainz.org/release/76031424-5fd4-3948-a1f0-60eccc7c6d6e and it has live recordings that according to Wikipedia are mixes of performances from as much as 5 different dates! I added individual record dates for each night and used a span on the work relationship, but how would this be handled on the disambiguation? Kinda hard especially since some of the recordings used in their mix aren’t even from the same location either. Do I just ignore “live” disambiguation rules and just put something like “Pulse mix”?
Multiplying the relationships by the number of recording dates is a problem—consider that some tracks have many credited performers, and three or more dates—that’s a lot of extra relationships.
With the current UI, that’s unmanageable. Even with a perfect UI, I doubt we’d want that much denormalization in the DB.
A bunch of other relationships also need those better dates… The recording-work relationship, the other performers. It’s a solution that makes the data available, but it doesn’t fully solve the problem. (It also fails entirely in the rare case that the booklet gives dates but not location.)
There really needs to be a list of dates for the recording itself, and the other relationships would default to those dates—and then you’d only put a list of dates on those relationships if it’s not the same as the recording.
Yes, the duplication you have to do with adding dates to every recording-related relation is pretty insane – even if you have a simple point in time or time range, not a complex set of times.
… and I’m doing this stuff without the help of any userscripts.
Sounds to me like you should add an Event for each of the two occasions which can host the date/time and location information and then link the Recordings to each of these, instead of linking the Recordings to the locations directly.
Granted, this won’t solve a lot of the problems date range issues, but I still think it’s better than multiple dated Place relationships.
I put in the event too (at least when I can find information about it—they seem to like deleting old info from their web site). Unfortunately it doesn’t seem anything really inherits information across relationships, so I get to put in the place/recorded-at relationship again anyway.
The „why“ is twofold: first, I really would like to experience „vanilla“ Musicbrainz – like an editor would, if she added maybe one album a month, and couldn’t be bothered to install extra stuff into her browser.
The second and heavier reason is that I use MB exclusively through Tor Browser which discourages add-ons for security reasons. Meaning: it is possible to add Greasemonkey and userscripts, but it’s an uphill battle with unknown privacy implications.
In conclusion, I think we would all like the website to be useable without userscripts.
