Difference between "recorded at" and "recorded in"?

[InvisibleMan78]

I found two different relationships types for recorded, one is called “recorded at”

and the other is called “recorded in”

What is the difference? When should be used the one or the other?

[Griomo]

Notice the greyed-out set choice left to the highlight:
[Place:] recorded at
[Area:] recorded in

I too had long trouble with that:

Recording Date, Area & Place, beginner’s perspective

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 …

[InvisibleMan78]

I totally missed that. Thank you for your very useful hint!

[IvanDobsky]

When watching a gig you are “at” a concert hall, “in” a city.

Usually if you know the name of the building the gig was “at” you will find it under “place”.

If you only have a vague city or country name then you’ll find it under “area”.

You don’t need to put both “place” and “area” as a place will always include the area in its description.

[tigerman325]

One is an area type, one is for place names. anything “in” is talking about the area when the exact place isn’t known. Especially common on older recordings. You’ll see a lot of of Recorded in England or Recorded in New York, etc. We don’t know what studio, etc. Recorded “at” is when we know the actual place. Recorded “at” Abbey Road.

[yindesu]

Also note that you are supposed to avoid Recorded in (“Use only when the place is unknown!”).

[tigerman325]

If a release says it’s recorded in New York and that’s all you have, than it’s OK. Yes, if you then find out later it was recorded at Sony Studios, then you can remove it as we probably wouldn’t want both.

[Griomo]

N.b. that systemic bulkhead between Area and Place: Both can have sub- and superparts, but a place cannot be part of an Area (and vice versa):

Areas: country \ region \ city \ district

Places: university \ building \ auditorium; studio

[jesus2099]

@Griomo

but a place cannot be part of an Area

Erh, yes it can.
You can set the Area of a Place, completely.

And from an Area, you can see its Places.

[reosarevok]

But they are completely different entities, so one can’t be linked to the other with the “part of” relationship I assume that’s what @Griomo meant there.

A concert hall (a place) can be part of a building (a place) which can be part of a university (a place), which is in a city (an area) which is part of a state/province (an area) which is part of a country (an area). Fun!

[Griomo]

Of course. I was unclear and reosarevok said it better. IRL all things bigger can contain all things smaller all the same: a building (however small) always contains its floor area (smaller); but MB editors must be aware of a “sudden” shift of entity type between Area and Place.

[jesus2099]

@Griomo

all things bigger can contain all things smaller all the same: a building (however small) always contains its floor area (smaller); but MB editors must be aware of a “sudden” shift of entity type between Area and Place.

Mmm, ?
Then it’s not only areas and places, it’s also areas and artists, places and artists, releases and recordings, areas and labels, etc.

Sometimes you have fields, sometimes you have relationships, between entities of different or same types.

The problem is that you maybe don’t feel enough the difference between area and place entities.