I dont normally get into content editing, but in developing my app, i have come across an issue that keeps rubbing me the wrong way.
What to do with “Producers” listed as Artists of a compilation Album who are clearly not any of the Artists, who are in turn properly listed on the individual recordings/tracks.
And then does the album cover listing a “Presented by: DJ Nobody” matter in the equation?
So wouldn’t be proper to remove the producer name from artist, and perhaps add it to the comment/disambig or even tag…
Worst off, they are clearly not the Artists and this screws up an otherwise easy database match.
Maybe its the inner Artist in me, but i find this really irritating.
If there was a place for producers then there would be a place for the producers.
Please advise
PS, fwiw, in the editor, it clearly states “Various Artists (Add compilations to this Artist)”
I can understand this logic from a style point of view, but strictly speaking in terms of searching the database, this frivolous data kills things
For perhaps my main problem with it is that when you have bonafide info, i seem to lack the correct algorithm to pull the right release
for example, what would be a query that would get me the correct release with this valid info for the above linked release:
track: Ghost
album: Ultra Trance 07
artist: JES
dont seem to get me to the right place…
Take away that no name dj and bam! things work.
Here you have a bonafide Track, Album, and Artist, but some otherwise irrelevant Artist data is preventing a proper outcome.
If having a prominent artist data for a compilation is important for a reason i may not realize, then it seems search algorithms should be improved to at least value the recording artist as much as the Album artist.
Especially when searching FOR RECORDINGS!
Perhaps im missing something but this seems the way things are (not) working…
Ahhhhh but you cheated, a bit.
Notice your using the exact name of the album with the ‘.’ (dot) character in the middle, that you would only have AFTER you get results… Ultra.Trance
Though if you used strictly what was suggested “Ultra Trance” you get nothing.
Now one might say well you are not searching for the exact Album, but that is a rather strict outlook as these types of punctuation characters are often either mistakenly included by users or improperly filtered out by provider services.
Surely if such strict search requirements are necessary to overpower otherwise irrelevant information then improvement is needed, and in this case i think it is simply not to encourage use of non artist info in the reserved artist field
In fact now reading your original reasoning again, to me it sounds like your describing a disambiguation, and to that i would agree, use your same logic but if its not an artist dont put it as one, put it in the disambiguation
I would say the problem is not having “frivolous data” (and I disagree that this is ), the problem is more that our data is too advanced for our tooling around it (e.g., the search server in this case). Unfortunately being a non-profit open source means we don’t have that money to spend on non-critical development, which means a lot of the tooling gets developed at a slower pace than the core database. The best solution to this would be if more people in the community helped out with development, but we don’t seem to have that many developers around, unfortunately.
You may to read over this topic as well for some more “philosophical”/“ideological” discussion:
your right the data is not frivolous, not sure why I stated it like that, but I do feel strongly the data is being allowed to be misplaced.
artists are artists, others whom are not artists are not artists but rather disambiguations until the day someone volunteers to add more categories to the database…
I can sympathize with the lack of man power, that may end up the sad story of my life, certainly didn’t mean to criticize.
so to not confused the issue any further, making clear the defect at hand for any future efforts;
current searches using bonifide data may fail due to certain accepted philosophies.
), the problem is more that our data is too advanced for our tooling around it (e.g., the search server in this case). Unfortunately being a non-profit open source means we don’t have that money to spend on non-critical development, which means a lot of the tooling gets developed at a slower pace than the core database. The best solution to this would be if more people in the community helped out with development, but we don’t seem to have that many developers around, unfortunately. 