Recording Date, Area & Place, beginner’s perspective

MusicBrainz
, , , ,
1

When adding a release, I find it easiest to post first the release with artist, and with that entry set in the database, then Edit relationships.

Recording Date is entered under Recording Area (leave individual artists’ relationships date for now). This is peculiar but explainable, but I do not seem able to set date only (which is often the case with historical recordings, missing area and place info) because Area is a Required field and does not have an [unknown] alternative. This seems to me due to type being Area, but then there should be an equal type Date.

It was not until this answer in another thread that I got the idea that the Recorded in Area field auto-search does not look for Places. Quoting from that thread:

So, as user I am first to set Recording Area (with Date), then Recording Place (with Date) in a field not to be found, and dito Date (to me the obvious superordinate of space:time, already from its standardized number format) only subordinate to other entities? Wrong. But clearly, from experience however newcome, all points to Recording Area being not the place to enter Recording Place? Wrong again.

Digging through Documentation, I get
https://musicbrainz.org/doc/Area & Place - MusicBrainz without answer,
How to Add a Place - MusicBrainz for places not already present in the database
(https://musicbrainz.org/doc/How_to_Add_an_Area yields Page Not Found.)
MusicBrainz Database / Schema - MusicBrainz informative but not really of help here
How to Add a Release - MusicBrainz has a bottommost link “add the various credits” that could be more [Ctrl]+[F]-friendly as “add the various credits: How to Add Relationships
– and there you have it: Post Place MBId URL into Area field! (You get the URL by searching from outside of the Relationship Editor. For reference: [unknown] (Place)) But what happens? With Area Type ‘Recorded in’ set, the Relationship Editor resets Type to ‘Engineered in’ when pasted URL is auto-converted. Since Type field is above entity field (where URL is pasted), this is highly contra-intuitive, therefore missed, and the edit has to be corrected (Edit #42367796 in air for 6 days).

Most probably I have things upside-down, i.e. Date & Place being subordinate because they pertain to Type, Type being subordinate to higher order Relationship Area. But anyway, a user short-hand:

  • When adding/editing, use 2 windows: #1 for adding/editing, #2 for searching (MBId URLs) / checking guidelines and others’ examples
  • For recording place (and possibly other subordinates):
    · Search Place for its MBId URL (if present in database, otherwise add it), copy it.
    · Goto release (in other window), Edit relationships (right pane).
    · Paste Place MBId URL into Relationship Area entity name field, wait for auto-convert to green.
    · Set Type to Place, then (enter Date and) hit [Done].
    · Edit, just learned: In case of mistake (such as ‘Recorded in’ reset to ‘Engineered in’ because you did not do steps in order above), an incorrect Edit needs not be cancelled/deleted/redone and queued, is better edited directly in Relationships Editor.
  • Thank any lurker behind you correcting mess.

Is Recording Area the field meant for Place too? If so, would it not be better, and an easy fix, to have its search include Place too? Or is there another field for Place, then where?

Oh, and when should ‘This relationship has ended.’ be checked? I am not sure how it shows, can but guess. Search syntax “true if know ended even if do not know end date” is a good hint, but if it is meant for all cases of ended relationships (f.i. done recordings), it seems I am not alone in leaving it unchecked with reference to ‘Do not add uncertainty’ guideline.

2 Likes
2

You’re right, that should be in the docs. If it is, I don’t know where.

You’d check that box if the relationship is definitely ended but you don’t know when. e.g. if a person is no longer a member of a band, but you don’t know when that person left.

If something happened in the space of one day put the same date in the ‘begin’ and ‘end’ fields.

As the docs say,

All relationships are added using the same pop up.

What looks like a field label (“Area”) is really a pull-down menu. This is how you select the type of entity you wish to use in the relationship. Or, if you paste an entity’s URL into the field, the correct type will be chosen automatically.

2 Likes
3

That’s true, and we have a ticket for it (MBS-7582); it’s unclear how it could be laid out in a saner way, though.

4

Really, should the box be checked only when relationship is known to have ended but not when? Any newcomer would think it just as ended, even more still, when having also the end date. (The only reason for me not to check it for any normal release f.i. not being part of an ongoing series issued/broadcast in real-time during performance, is my own uncertainty of its meaning.) This Pärt release has been referred to here as a good example (for “composer and performer info” only, but there seems to be no official referent example), so let us have a look at that one:

conductor: (1989-01-17 – 1989-01-27) This relationship has ended.
engineer: (1989-01-17 – 1989-01-27) This relationship has ended.
orchestra: (1989-01-17 – 1989-01-27) This relationship has ended.
producer:
recorded at: (1989-01-17 – 1989-01-27) This relationship has ended.
solo cello: (1989-01-17 – 1989-01-27) This relationship has ended.

Producer alone deviates, so it may be a simple slip of mind (von Bahr’s relationship with BIS does not end with this recording, but his relationship for this release does); but he has no date and the box unchecked too. And all others each with box checked have their dates too. I would by intuition think every artist entity here should have both dates, and box checked too.

If the ‘This relationship has ended.’ box should be checked only when relationship is known to be ended but not when, then user should be duly warned.

[quote=“CallerNo6, post:2, topic:182225”]
As the docs say,

Will do.

Damn, I am blind. The pull-down menu has been known as such all along, I am blinder still. Thinking “I get the hierarchy Area > Place”, I chose ‘Area’ and expected ‘Place’ to turn up anywhere but there, not another alternative in the same menu (on the same level). Ahaa…

[quote=“chirlu, post:3, topic:182225”]
That’s true, and we have a ticket for it (MBS-7582); it’s unclear how it could be laid out in a saner way, though.[/quote]
Inner logic is pre-requisite, yes. Many things just have to be learnt, but MB mechanics will not be my area. Time is my main concern, and I hope to contribute more than questions.

Big thanks to both of you.

5

Oh, and I should also say: I like this kind of post a lot.

if you are editing and hit a point where the answer isn’t obvious, where finding the relevant doc is not easy, please consider making a post describing the problem(s).

4 Likes
6

Yes, when there is an end date, it is automatically ended. Even if an “ended” checkbox is not actually checked when an end date is given, it will be treated as if it was checked.

7

FWIW:

8

Still unclear, what does “will be treated” mean? Is the box in the above Pärt example auto-checked by the system due to user setting an end date? I cannot see a difference, and, from the guideline to check the box only “if the relationship is definitely ended but you don’t know when”, will see dates+checkedbox as an incorrect user edit, and ‘correct’ it.

Or, if GUI system does not check box (user having set end date only) but “treats it” as checked backstage, then the box should be greyed out, or even better:

… something along the just added comment there, that “When an End date is filled out, the Ended checkbox could be both disabled and checked.”

System is not using itself, users are. Things are often enough not structurally connected, but met with as such by users trying to do some “single” thing (say, add recording credits) built from several components, in GUI positioned together, but code-wise completely separate, whose relative proximity in time is governed by sheer human accident.

Back on Earth:
• So how should one notate a recording with known date only? Place has a generic [unknown] in the database, but SG points to Area when Place is unknown, but again Area has no [unknown], but still is a required field.
• And, just to be clear: With neither place nor date known, should the ‘ended’ box be checked? (Its meaning being not really “This relationship has ended.”, but “End date N/A by user.”?)

9

:slight_smile: The recorded at {place} guideline doesn’t say “do not use this relationship if the place is unknown”. But you’re right, the docs could be made more clear on this point.

The use of unknown as a place seems to be well-established. I’m sure it’s safe to use it in a relationship.

I think you’re right. There should probably be an unknown area.

10

That page concerns ‘in Area’, not ‘at Place’, and says: “Use only when the place is unknown!”

This should be the corresponding Place page: http://musicbrainz.org/relationship/ad462279-14b0-4180-9b58-571d0eef7c51

11

Yes, the system auto-set the “ended” flag in the database when an end date has been submitted. But it is not visible prior to edit submission.

The good news is that this ticket is fairly easy to implement and will be fixed within next month.

2 Likes
12

The lack of dates is intentional: the producer’s work doesn’t usually happen at the time of the performance (or at least not exclusively), so dates for that work aren’t readily available.

It not being set as ended is intentional too, but of course, he is done producing it, so theoretically it should be set. It’s just our current implementation means that it’ll show with a “( - ???)” date by it, and semantically this relationship is basically always “ended” anyway, so I skipped it (and most people seem to skip it too, for all these relationships - “ended” is generally used for things like “member of”, “married” and other relationships that might be otherwise understood to still apply up to the present date).

2 Likes
13

The recording date can be added to the “Recording of” relationship (Recording-Work relationship). Ideally the date should be on every relevant relationship, but this is the “default” place to put it (there is a script to propagate it later). If you don’t have any work for the recording, putting it for any performer relationship also works.

3 Likes
14

OK, I now see that credits in earlier releases posted by me have their boxes checked.

Good. I have no clear view of what stage of own evolution MusicBrainz was in when I hopped on, just looked for a open project with reasonably high standards for release documentation (and capacity for cover art). Got a bit more than expected, glad to say.

15

Producer: Ah, of course (but release is released, as expected).

Users need not clear logic underpinning, but clear guidelines.

I have yet no clear understanding of Works (typically different versions of multi-movement classical ones), and classical navigation – it will just have to wait.

16

That’s the guideline you were referring to, isn’t it? When you said [quote=“Griomo, post:8, topic:182225”]
but SG points to Area when Place is unknown
[/quote]

Did I misunderstand your concern? If so, then I’m confused about your confusion.

17

I … tink … so:
Area-Recording / Recorded in says: “Use only when the place is unknown!”
Place-Recording / Recorded at says nothing about when Place is not known.
Since they together constitute Guideline, I read it as Guideline for Place, in case Place is not known, points to Area – even if the actual dictate is present at Area page and missing at Place page. If I am wrong in this, I am right in being confused when Place is not known, since both Area and Place would then be applicable (Area dictated, Place not forbidden).

18

My suggestion would be to change it into “Use only when the exact place is unknown, but the area happens to be known”.

1 Like
19

I think that’s because the docs tend to be written from the perspective of “explaining this when selected in the UI” (and if you don’t know the Place, you wouldn’t normally be trying to add a recording-place relationship), and not necessarily from the perspective of browsing through relationship types to see what they are for.

20

Yes (and no). By intuition, a user not knowing exact location and MB norm (I am avoiding MB nomenclature/taxonomy now.) will try to approximate it. MB has the geographical continuum split in 2, with buildings/venues on the one end and everything else on the other (almost; non-type continent ‘Europe’ but no ‘anywhere’ or ‘unknown’). These 2 are then presented not hierarchically but as separate types, in both menu and search engine. That is as ideal as it gets when put into practice, and no problem in itself.¤

Problem is user, but the entire system is meant for users (mainly not programming ones, that is).

¤ Perhaps Area search could also look through Place, and vice versa, and the then user-chosen entity could force its Type. Sounds kind of expensive, though, and would certainly cause as many mistakes as it would prevent.