thanks - I need to put more thought into this - I am inclined to feel that at the moment that the search api will probably deliver better resuls - as the cost of filtering thousands and thousands of records for even something as basic as a movie called "New York" or "Independence Day" split into independent words will probably be cost intensive and might end up being looking for a needle in the haystack.
Having said that I think Twitter has surely come up with this API with good thought - it's just needs further analysis from my end with regards to whether the cost of filtering outweigh the benefits from getting real time streaming resuls. thanks rahul. On Tue, Mar 9, 2010 at 9:10 PM, Mark McBride <mmcbr...@twitter.com> wrote: > This is correct. The general advice is to choose the most specific keyword > to track (probably "locker" and "blind" in this case), then run an > additional layer of filtering on your side. There are higher access levels > available that grant you more than 200 keywords to track. > > ---Mark > > http://twitter.com/mccv > > > On Tue, Mar 9, 2010 at 12:36 PM, Rahul Dighe <rsdigh...@googlemail.com>wrote: > >> Hello, >> >> Correct me if I am wrong but doesn't the streaming API has limitation that >> allow me to only track 200 keywords.. and also with the added caveat that - >> >> *Track keywords are case-insensitive logical ORs. Terms are >> exact-matched, and also exact-matched ignoring punctuation. Phrases, >> keywords with spaces, are not supported. Keywords containing punctuation >> will only exact match tokens. Some UTF-8 keywords will not match correctly- >> this is a known temporary defect.* >> >> If this is the case how will the api track keywords such as "The Hurt >> Locker" or "The Blind Side"? >> >> Thanks >> Rahul Dighe >> >> >> >> On Mon, Mar 8, 2010 at 11:42 PM, Mark McBride <mmcbr...@twitter.com>wrote: >> >>> This sounds like a perfect use case for the streaming API. The rate >>> limits there are different, but in general more permissive. And because >>> you're doing primarily OR queries, the current track functionality seems >>> sufficient. >>> >>> ---Mark >>> >>> http://twitter.com/mccv >>> >>> >>> >>> On Mon, Mar 8, 2010 at 3:21 PM, Rahul <rsdigh...@googlemail.com> wrote: >>> >>>> Hello, >>>> >>>> I am building an application that monitors tweets about movies(for now >>>> with... other interesting things planned). I have my id whitelisted >>>> but I want to avoid overusing it. >>>> >>>> The challenge that I face is that ideally I want to make full use of >>>> the opportunity to retrieve 100 tweets per call and for that I need >>>> information on the frequency with which users are tweeting about a >>>> movie and then set my call frequency (to call twitter search api) >>>> accordingly so that I maximize the number of tweets returned per call >>>> or atleast. >>>> >>>> Since I presume there is no way to know what frequency is someone >>>> tweeting about a movie - I need help is what is the best way to >>>> optimize for such a situation. >>>> >>>> The challenge is complicated by the fact that users tweet about >>>> different movies at different rates and the rates generally decrease >>>> overtime. >>>> >>>> I have tried combining searches - but the challenge is that lets say I >>>> search for >>>> >>>> (Movie A OR Movie B) >>>> (Movie C OR Movie D) >>>> >>>> it could be the case that people tweet about Movie A & B a lot and >>>> litle to none about C or D or there is a combination in which they >>>> continue to tweet about A but not about B - So I still can end up in a >>>> situation where I am not optimizing my calls. Also situations such as >>>> Oscars can dramatically change what people talk about even about >>>> movies out months ago. >>>> >>>> I have thought of writing something such as a variable frequency >>>> caller that can check the frequency of tweets for the last 3 calls in >>>> order to appreciate the frequency of tweets for a given search and >>>> then continuously vary the time between calls so that I can get as >>>> close to 100 tweets as possible in a call. >>>> >>>> Any ideas suggestions that can suggest ways to alleviate the above >>>> will be highly appreciated. >>>> >>>> Thanks >>>> Rahul. >>>> >>>> >>> >> >
