Both the Artist entity and the Label entity have an Area field. I believe the style instructions for Artist.Area and Label.Area are not clear enough. I propose to improve them.
I understand that these fields, Artist.Area and Label.Area, were originally Country fields in an earlier database schema. Their purpose was to provide a rough disambiguator, or identifier, for Artists and Labels. Changing them to Area fields permitted identifying more specific associations. However, the project hasn’t been clear about taking advantage of this. And, many Artist and Label entries have legacy country-level values in their Area fields.
–STYLE-427– (2015) generated some discussion and an update to Style/Artist. It revealed disagreement between treating the Area fields as Country fields still, or taking advantage of the possibility of more specific values where appropriate. The new Style/Artist language didn’t resolve the issue. This causes forum discussions like Artist Area: Country vs City/Higher Specicifity , and changes of city values into country values in some cases.
I propose that the Style guide and documentation for both fields be changed to welcome a more specific Area value, likely a city, if available; while also accepting a country-level value if that’s what the editor knows. I also propose that we define these fields in terms of “primarily associated with” rather than “born or founded in”.
The field was originally used for a country. Changing the definition of it now would invalidate a lot of existing data.
A city isn’t more specific than a country here; it’s an entirely different claim, the difference between “Taylor Swift lives in New York” and “Taylor Swift is American”.
A single field can’t accurately represent this relationship. If I care that Taylor Swift is “associated” with New York, I probably also care that she lived in Buenos Aires from 2004-2007. Using the area field, the only way to represent this is to replace one area with another, losing the historical data. If we want to say an artist is based in a specific city, that needs to be an area-artist relationship.
We need a field for some kind of nationality. When people talk about artists, they say things like “Australian rock band AC/DC” or “Pretentious untalented Icelandic singer Björk”. A database about music should be able to express that.
@stupidname, those are good arguments. But I have counterarguments.
The field was originally named “Country”, with a data structure that accepted only Country values. But then it was changed to a structure that accepted any Area value, and it was renamed to “Area”, and there was no style guideline which said “We only mean for this to hold Country values”. Quite the contrary, there is a style guideline which says City values are preferreed sometimes. I argue that the field’s meaning has already changed, to be quite broad. I’m just proposing to change the emphasis within that broad range. This doesn’t invalidate existing data.
“We need a field for some kind of nationality.” Fair enough. But I’d argue that Artist.Area doesn’t store “nationality”. According to the current guidelines, it usually stores “place of birth or origin”. Nationality can change during an Artist’s lifetime. Maybe we should have an Area-Artist relationship “Nationality”?
I’ll observe that “Taylor Swift lives in New York" is a claim about residence, “Taylor Swift is American” is a claim about nationality or legal status. I argue that Artist.Area should be a claim about “is mostly associated with”. These are three different claims. It would be good for us to be more clear about which claim Artist.Area makes.
You are right that a single field can’t represent multiple values for nationality, or residence, or “is mostly associated with”, especially as they change over time. For that, relationships are a better data structure. Ticket MBS-9155, Replace artist and label areas with relationships proposes this change.
artist based in a city (currently “founded in”), so this is covered
artist’s nationality
artist’s “scene”, past and present
artist’s area of residence, past and present
Let me know if there are even more options that I forgot. Currently you can add any of the last 3 into the area field, which often creates confusion and disagreements. There should be a way to either enter all 3 into different fields or only pick one of them for the definition of the area field. I also like the relationship change, but I think most people (especially new editors) don’t enter relationships, but they do enter the fields in the add artist form.
Giving my perspective, there’s plenty of artists where “primarily associated with” isn’t particularly relevant – they release their work almost exclusively online (I’m thinking Soundcloud, Bandcamp, and such here) and rarely if ever play live. I have been filling the field with whatever’s listed on those pages if it’s not obviously false, but other editors have taken a couple of those and stripped them of everything but the country. It’s not been important enough to contest, but I would definitely appreciate a concrete decision one way or the other.
For your examples:
I’d actually say this is what Artist.Area currently holds – “founded in” only applies with group artists; it’s replaced with “born in” for individuals, which is obviously not the same as “based in” (for either, really)
This is the main argument for country-only, but I’m not convinced it’s as important; depending on what you’re interested in, you can typically figure it out by looking at the other associated areas, and if you can’t, how much of a role does it actually play?
On the one hand, rather subjective – where do you draw the line between “scene” and “occasionally plays in”? – but on the other, probably one of the more relavant relationships for the listening-oriented users
Not quite as important except in guessing nationality, but probably still important for the data-oriented users
The whole point is to make guidelines more specific.
This field is currently neither “Artist is based in City” or “Artist is from Country”, it is “primarily associated with”.
If you want those fields to exist, then you should open a ticket for them.
The current change from ‘artist is primarily associated with [country]’ to ‘artist is primarily associated with [city, country]’ doesn’t lose data, and it would clearly store Australia for AC/DC and Iceland for Bjork.
If Bjork moved to Japan, the current field wouldn’t change to ‘Japan’, and under the new proposals it wouldn’t change to ‘Japan’ either, unless she was there for long enough/made a big fuss about it that it would be the primary country/area that you now associate her with. (again, no change from current guidelines)
No, it doesn’t. The country that a city is in is not the same as the country of origin of an artist based in that city. For an Australian artist who is currently based in Tokyo, the country displayed would now be Japan.
As I said, “Artist is based in City” and “Artist is from Country” are two different claims.
which reads more to me like @Jim_DeLaHunt’s “is mostly associated with” than either “current residence” or “place of origin”. Note that this is the current style guideline and @Jim_DeLaHunt’s proposal is merely to clarify this further, not to fundamentally change it (in my reading anyway).
The fact is that some artists have different nationalities, live in, represent or work/perform in a country other than the one they are “mostly associated with”. Maybe we should refine/extend the database schema about this to get rid of ambiguity about the meaning of artist’s area field. I doubt that just changing the wording of the style guideline about artist’s area will stop people misusing it.
Thinking about it more, you may be onto something. Seems like we’re currently considering the “Title”/“Name” field a remnant of the older database model, and hoping to eventually replace it with aliases. Maybe this is the same thing: something that has a historical meaning of an ill-defined “primarily associated with” but will eventually be split into “born in”, “based out of” (representing where they typically record/compose/etc. and being a bit less revealing than “resides in”), and the areas of the events they performed at. If the majority of “based out of” credits are in Australia, they’re probably Australian; if they only perform in a few tightly-clustered locations, they’re probably a local band.
I do agree that a more realistic solution would be to reword this. People misuse the field because they don’t know what it is – there’s only a few of us in this thread so far, and we already have a long list of potential interpretations. If we have something concrete to point to and say “this is what we mean here” and especially if we advertise it on the blog, sure there will always be people who don’t pay attention, but they should be a minority (certainly by edit count) and the rest of us will be able to work against a standard rather than spending time unnecessarily stripping cities – whether because those cities are clearly accepted or because they aren’t added in the first place.
If we want to extend the database schema to be able to represent several distinct facts like nationality, residence area, work location, as well as “mostly associated with” area, then I think ticket MBS-9155, Replace artist and label areas with relationships, is the place to continue that discussion.
With STYLE-855, I want to make it easier and clearer to use the present schema correctly. The proposal does this by making it clearer that that Artist.Area and Label.Area mean “mostly associated with” rather than other meanings, and by clearly allowing city or local values (when appropriate) as well as country values.
I would argue that the biggest difference between these claims is the difference between “is based in” and “is from”, not the difference between “City” (which implies Country) and “Country”.
Good question. My attempt to answer it is in the proposed wording in the ticket for STYLE-855. I welcome improvements to that wording.
Update: added more replies to this post, because Discourse software nagged me about it.
This is the main argument for country-only, but I’m not convinced it’s as important; depending on what you’re interested in, you can typically figure it out by looking at the other associated areas, and if you can’t, how much of a role does it actually play?
I find nationality useful for disambiguating between similar artists.
Just keep in mind that we don’t currently have a way of stating “nationality”. We can say where someone was born(/founded, for groups) and we can say what area they’re associated with. Neither of which are necessarily their nationality.
I hope STYLE-855 will have the effect of making clear that the purpose of Artist.Area and Label.Area is to disambiguate between similar artists (labels). Knowing the purpose will help editors choose correct values.
But won’t “is associated with” Area but just as good for disambiguating? Maybe better, even: artists like Angela Lansbury, Dave Matthews, and Alanis Morissette changed citizenship during their lifetime, so “nationality” or “birth area” won’t always be as useful as “is associated with” for disambiguation.
P.S. “nationality” might mean something different than “citizenship” for some editors; and where they are different, I expect the difference will be hard to define.
All right, I’ll give you that, with the caveats the others pointed out. My question, then, is how putting nationality in the area field (which is then only visible on their own page) is any better for disambiguation than putting that as text in the disambiguation field and using the area for “primarily associated with”, however we wind up defining it?
I’m not saying that it’s better to enter the nationality into the area field and not into the disambiguation field. I’m saying if the nationality is already entered in the area field, it can be helpful for disambiguating the artist. And the area is not only visible on the artist page, but in search as well, which is the place where it’s the most helpful.