Hamlet;195754 Wrote:
> If the three searches that you listed are made available on SN than they
> might be the appropriate types of searches needed. I suppose than that
> it is just a matter of it being implemented by SD?
Well, there's also the issue of the desirability of those searches.
They assume (they sort of have to assume) that you're spelling things
correctly, or else the combinatorial problem gets insane.
Thing of "Carole King". So you type "Carol Ki"; An actual text match
won't help at all here; you've misspelled her first name. What we
really need to do is look for soundalikes/synonyms on "Carol", and then
"starts with" on "Ki". However, the search engine isn't really smart
enough to figure that out; instead it would have to figure out all the
terms that "Carol" and "Ki" sound like, and then look for all the terms
that start with (or maybe incorporate) those sounds.
Basically, once you want to do partial matches, it can get pretty
brutal. Not to say that it can't be done, but it's a hard service to
provide any kind of real performance on, especially as we have
timeliness issues ... when an artist breaks on Tuesday, people want to
find it in searches on Tuesday. We can't really afford a slow
background process adding new data. I already get grief for our
searches being 7 hours behind (and we're working on that!).
Hamlet;195754 Wrote:
> I am curious about your references to relevancy and Google type
> searches, as I'm not seeing the connection between web searching and
> finding a song or artist in Rhapsody's database. Have you guys at
> Rhapsody concluded or seen data showing that users are searching or
> want to search for music in this way? As I am reasoning it, a Google
> relevancy type search would almost always be inferior and less
> desirable to a string search for this purpose. Perhaps you guys see it
> different for some reason, and out of curiosity I'd welcome being
> enlightened as to the rationale of it.
We actually do have a lot of really good data on this. Basically, the
problem breaks down into a few general sorts of areas :
1. I know the artist/album/track I want, I know how to spell its name
(or almost do), and I want to get there as quickly as I can.
2. I sort of know the name of the thing, or I'm a terrible speller.
3. I'm looking for things like things I like (or my friends
recommend).
4. I know something arbitrary about the thing ("an English band from
around 1970, they sound like the Beatles kind of")
I'm going to gloss over 4, as we don't do a great job with it, and we
don't get many requests for it, but we'd love to do it.
I feel like Rhapsody does a pretty good job with 3, through our
recommendations engines, our automatic playlist and channels, and our
rich editorial content. We can do better, but we feel like we're doing
really well here. We're always doing significant overhauls here,
another one is coming soon. (We really do regard this as part of our
"special sauce".)
For 1, we've created the "fast find" methods, because you want to find
something you already know about. So they're prefix oriented, designed
to have fast response times, so you could build an Ajax or Tivo style
UI, where as you type, you can see the list quickly winnow down.
But that leaves 2. Somebody types "rolin" into a search box. Rolling
Stones? Henry Rollins? Any of the many other bands that have "Rolling"
in their name? So we need to have a relevance ranked search that says
"Here are the things that you're most likely looking for." based on a
mix of how close the actual text is to the correct spelling, how close
it might sound to things, the popularity of the candidate items, and
maybe even the kinds of music you've already indicated you listen to.
Because the most expansive case is #2, it's the sort that's exposed by
default. Unfortunately, as I've already explained, it doesn't do such a
good job with limited input devices, because the model breaks down
dreadfully with partial term searches.
So, to make a long story short (too late!), that's why we added the
fast finds. I don't think that I would say "Oh, only use the fast
finds" for SB (mostly because it can't react as you type each letter!),
but a combination of the two might be very clever ... use fast find
first; if it returns nothing, do a regular search? Or use fast find, if
it fails, use fast find without the last letter, if that fails, use
regular search?
Does that sort of answer your question?
--
sstatman
Let Your Music Discover You
http://www.rhapsody.com
------------------------------------------------------------------------
sstatman's Profile: http://forums.slimdevices.com/member.php?userid=9603
View this thread: http://forums.slimdevices.com/showthread.php?t=34386
_______________________________________________
squeezenetwork mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/squeezenetwork
