#musicbrainz-devel

luks: I created a JIRA about retrieving pre-NGS collaboration artists @ jira.musicbrainz.org/browse/MBS-1123

luks: ping

murdos: ( a rather delayed) pong

ijabz: could you remind me why we have some much artist field for release/recording/release-group/work?

ARTIST_NAME, ARTIST, ARTIST_NAMECREDIT

it's really confusing and not really needed IMO

Iit was added as a response to a gripe you had on this page http://wiki.musicbrainz.org/?title=User:Murdos/..., (that youve now deleted) to do with artist credits

Some fields are required for searching, and some for returning the data

this page explains the search fields http://wiki.musicbrainz.org/Next_Generation_Sch...

we just need 3 fields: ARTIST (including all different names) + ARTIST_ID for searching, and storing ARTIST_CREDIT for output

If you don't have a separate field for individual artists, and the complete artist credit for the album you cannot do exact matches properly because you dont know what the artist is for the album

They are necessary thats why we put them in, and I don't see any advantage in removing size, (index creation time and index time will be affect will be neglible)

I just extremely confusing... Although I'm one of the dev on the search server, I just says WTF when I got not results from http://test.musicbrainz.org/search?query=artist...

where Renaud3 artist does exist: http://test.musicbrainz.org/artist/de1edf40-2b3...

and "artist", "artistname" and "creditname" are not really clear

there's a point where, if you want exact matches properly, you'd better use a database

artist credits ARE confusing :)

but the thoase releases a re credited to renaud not renaud3 so why should renaud3 return matches for the default artist field

but we can perfectly hide this complexity in the search server

ijabz: renaud == renaud3

Yes but one is an alias or somthing

no, "renaud3" is the actual artist name, "renaud" is the specific credit name used for recordings

You can hide the complexity in the user interface, if you want to search both you just search both fields, once you merge into one field youve lost that information

(because I renamed the artist "Renaud" to "Renaud3": http://test.musicbrainz.org/edit/13577883)

sorry, I've to go, but I hope we can clear this issue later

phew, I also need to get on with someting else

warp: I might have to lump a bit of JavaScript work on you

I've done the work to create new artists and labels, and for the most part it works - but the display is kinda messed up :)

At the moment it creates artists if you leave the artist field blank and add a artist credit name. we should probably have an option in the drop down called "add new artist" which fills in the artist credit name and does something special to the artist selection box (maybe italic text saying create new artist or something)

murdos_I thought about your example some more, it is very contrived, I think in reality if you were to change the artist name you might expect the credit names to also change and that is the problem.

Where the artist name and credit name differ it will be important in some cirumstances to search for these individually

and putting both into artist will screw up the scoring applied because recording that contain both variations will score better than one that just matches one of the terms

Typically when searching for a recoriding/release you only take the first page of results, so if a good result doesnt get on that first page because of this you'll miss it

I really see no advantage in removing it

how could a "recording [could] contain both variations"?

err... ignore "[could]"

If the recording has been credited to the artists real name and performance name

or another scnerio if you were to search for songs by an artist, songs that have a artist credit that differs from the artist will score lower because more terms in that reording then another

Similar to the problem we used to have searching for artists that the score returned for an artist was effected by how many aliases they had

hmm... maybe

I'm still wondering about adding a new field for the full artist credit (and put what is currently in artist), and make "artist" a catch all with all different artist names

so you can do simple search, and "expert" search

Dont follow, the artist field already contains the full artist credit (this is the simple search searching for what is on the CD)

and artistname and creditname are the expert searches

i.e the artist field contaisn what is credited on the cd as it is written with the joining phrases which is normally what you want,

not exactly related to this conversation, but I want to enter a ticket about not redirecting to the artist on partial matches at some point, is that a search server or mb_server thing?

and it will score so that if youe neter the exacting matching artist credit such as "Johnny Cash & June Carter" that will give the bet score

s/bet/best

not really. I know artist "Renaud3", and i want to find its recording

and I don't want to make complex query like that one: http://test.musicbrainz.org/search?query=artist...

Thats an expert search because the songs arent credited to Renaud3 they are credited to Renaud

nikki:not sure, I guess its mb_server but you can allocate to search_server first and I'll move it if wrong

ijabz: in which field(s) are you going to add aliases re http://jira.musicbrainz.org/browse/SEARCH-46 ?

Its just three OR clauses

II havent done anymore on it, but I would think if the artist is non latin add it to artist_name, if a name credit is non latin add it to name_credit, and leave artist field alone

ijabz: sure, but how many times are you going to explain to external developers that they got wrong results because they're not using these 3 OR clauses?

by wrong results, I mean no results

But yes this add complexity backups my argument that we need trhese seperate fields

I dont think its Rocket Science, these are webservice devlopers not webiste users

But I dont mind too much if you want to another field containing everything as long as you dont remove the other fields

these are website users too: http://test.musicbrainz.org/search?query=&t... has a "Use advanced query syntax" option

eep

If use select the advanced query syntax (whihc most users dont) you need to understand what you are doing

ocharles: i'm on a cellphone, not home right now.

I use the webservice more than just about anyone and I need these three fields, and I think when other starts using this they will find they need these fields as well so it really isnt on to start removing these...

but if you want to add another field, call this artist and rename artist to artistcredit i dont mind that

ok, I might do that

ijabz: re http://jira.musicbrainz.org/browse/SEARCH-15 there's a problem with release and recording reindexing

they're really too slow to index

Yeah, well I started looking at that and rest assurd they will be alot quicker once I rsolved it

good news

does your solution might work even if I reindex only a few elements?

But I have already put forwad two easy solutions that improve release for me but they were both poo,pooed which is a bit fustraing

that is if there's a long initialization step, it won't work for frequent reindexing

out of curiosity, what are these 2 solutions?

Thats the difficult part the harder soln is the temp table one that wont work well if justbupdating the index, have to do code paths I guess

Create a Release Puid table that is populated by triggers, and the additional index I wanted to add on the track table

not exactly related, I'm considering adding support for searching in multiple indexes, using MultiReader

care to give an example ?

http://www.discogs.com/search?q=renaud&btn=... <= you get both artist, release and label in search results

so its more of a ui thing then really, by that I mean you can already do this by sending three queryies

but the purpose would be to send only one query

since it's more efficient

Yes I understand, but of course behind the scenes the seach server would be doing three queries in parallel

sure, but it's low level and handled directly by lucene

so its quicker from a users pov, but its not anymore efficient from the searchservers pov

Would that require some extra work on mb_serrver

probably

could you mix different types in one MMD response?

So its not going to happen for NGS , unlkess you do it

Yes, i dont see why not

that's not the point, I'm not a paid dev, and I'm not really relying on other people work

Also I don't know if there would be an issue from Robs POV allowing you to do that sort of query, because you are kind of getting extra queries per second

so either I deliver, or I don't

You mean you run search_server standalone, so dont need mb_server

re extra queries, I'm considering allowing only web interface on mb.org to do such queries

ijabz: I would also do the mb_server required work

Hmm, (backtracking) one on my irittations is when you can do something on the website but not with the wenbservice

okay, well i don't have any problem with it myself

teatime ..

nikki: that's an MBS issue

ok

nikki: thanks for the mail, that's exactly what I needed

I'll go with the <old>=link0 option

it's easier to swap them all once they are consistent

k :)