FrontPage › Project~Twitter_Pattern
Project »Twitter_Pattern

Difference between r1.77 and the current

@@ -1,21 +1,82 @@
[[tableofcontents]]
== 데이터 수집 사전 준비 ==
== 스케줄 ==
|||||| '''연구일정''' ||
||<|4>6월||2주||연구계획서 정리, 데이터 수집준비||
||3주||화이트리스팅 신청,데이터 수집 계획 검토, 프로그램 코딩||
||4주||프로그램 코딩||
||5주||데이터 수집 준비 완료, 화이트리스팅 등록||
||<|5>7월||1주||데이터 수집 시작, weilbull 분석 준비 ||
||2주||데이터 수집, weilbull 분석 준비 ||
||3주||데이터 수집, weilbull 분석 준비 완료 ||
||4주||데이터 수집 완료, weilbull 분석 준비 완료 ||
||5주||weilbull 분석을 통한 메시지 패턴 구하기 ||
== 연구 주제 ==
'''연구 주제''':: '뉴미디어 환경에서의 메시지 확산에 대한 탐구: 트위터 사례분석을 통한 마이크로블로그를 중심으로'
(쉽게말해 트위터에서 메시지가 어떻게 전파되는지 보고싶다!!)
* 마이크로블로그에서 특정 주제에 관한 확산의 패턴과 특징에 관한 탐구
a. Weibull distribustion에 따른 메시지 분류해 보고 그 특징과 의미를 찾아본다
a. 기존의 확산연구와의 비교를 통해 마이크로블로그가 메시지 확산에 갖는 의미
||||[http://en.wikipedia.org/wiki/Weibull_distribution Weibull Distribustion]||
||||http://wiki.commres.org/Project~Twitter?action=download&value=fx.png||
||http://wiki.commres.org/Project~Twitter?action=download&value=weibul2.png <그림1>람다값의 변화||http://wiki.commres.org/Project~Twitter?action=download&value=weibull1.png <그림2>누적그래프||
== 연구 목적 ==
http://wiki.commres.org/Project~Twitter?action=download&value=fx.png
위의 공식은 연속확률밀도 함수의 하나인 Weibull 분포(distribution)를 만드는 공식으로 앞의 계수 부분 중 케이(k)값은 그래프의 형태를 결정하고, 람다(λ)값은 스케일을 결정한다. 이 곡선은 가로축을 시간으로 생각하고 세로축을 RT의 수라 하면, 메시지가 시간에따른 RT의 분포로 표현할 수 있다. 이를 통해 메시지의 전파 형태를 그려볼 수 있고 형태에 따른 메시지 구분도 가능하게 된다. 덧붙여 위에 제시된 <그림2>과 같은 누적 곡선은 Rogers의 확산이론에 소개된 S곡선도 설명할수도 있다.
본 연구는 메시지가 확산의 경로를 추적하여 메시지 확산 패턴을 구성하고 이 특성에 따라서 메시지들의 성격이나 특성이 어떻게 나누어지는가를 살펴보고자 한다. 구체적으로 Weibull distribution을 이용해 메시지 확산의 패턴을 분류하고 그 군집 별로 어떤 특성이 있는가에 대해서 알아보는 것을 목적으로 한다.
== 연구 방법 ==
=== 데이터 수집 ===
==== 데이터 수집 사전 준비 ====
1. __장비 준비__
a. 석혜정 교수님 렌더링 컴퓨터 20대 사용 허락
a. 컴퓨터 운영체제 및 IP 확인하기
a. (PHP, APAHCE, Mysql) or (JAVA, Eclipse, Oracle)
a. [http://dev.twitter.com/pages/libraries Twitter Libraries]
a. TwitterLibraries
1. __API Documents__
a. [http://dev.twitter.com/pages/api_overview Api Overview]
a. [http://apiwiki.twitter.com/Twitter-API-Documentation Wiki]
a. [http://dev.twitter.com/ Developer page]
1. __White Listing 신청__
a. [http://apiwiki.twitter.com/Rate-limiting White Listing이란?]
a. [http://twitter.com/help/request_whitelisting 신청양식]
a. form attachment:whitelisting.png
1. __데이터 수집 사례__
a. [http://an.kaist.ac.kr/traces/WWW2010.html 카이스트 연구1]:
a. [http://an.kaist.ac.kr/traces/WWW2010.html 카이스트 연구1]
'''41.7 million user accounts''':: In order to collect user profiles, we began with Perez Hilton who has over one million followers and crawled breadth-first along the direction of follwers and followings. Twitter rate-limits 20,000 requests per hour per whitelisted IP. Using 20 machines with different IPs and self-requlating collection rate at 10,000 requests per hour. To crawl users not connected to the Giant Connected Component of the Twitter network, we additionally collected profiles of theose who refer to trending topics in their tweets from June to August. The final tally of user profiles we collected is 41.7 million.
a. [http://twitter.mpi-sws.org/ 카이스트 연구2]
'''54,981,152 user accounts''':: These accounts were in-use in August 2009. We obtained the list of user IDs by repeatedly checking all possible IDs from 0 to 80 million. We scanned the list twice at a two week time gap. We did not look beyond 80 million, because no single user in the collected data had a link to a user whose ID was greater than that value.
1. __기타__
a. 트위터 가입자를 1억 5천명정도로 예상하면 150000000request / (20000request/hour*ip) = 7500 hour*ip
a. 7500hour*ip/24=312.5day*ip
a. 312.5day*ip / 20ip = 15.625day 적어도 20개의 ip를 사용한다면 15일정도 소요됨.
a. Time_zone이나 Location은 사용자가 직접 설정해야 함. => 따라서 전체 트윗에서 Time_Zone이나 Location의 비율을 살펴보고 어느 지역에서 일어난 일인지 짐작하는 것이 합리적일 것이라 생각함.
1. __Some service?__
a. [http://apiwiki.twitter.com/Streaming-API-Documentation Streaming API]
==== 데이터 수집 순서 ====
1. 전체 사용자 기본 데이터 수집=> Numeric ID
2. 지역(미국,한국)에 따른 사용자 추출 => Time_zone
3. 일정 기간 동안 한번도 글을 쓰지 않은 사용자 제거 => UserTimeLine Statuses
4. 사용자 특성(팔로잉,팔로워)에 따른 사용자 집단 세분화 => the number of Following and Follower,the daversity of Media Use

== 데이터 수집 순서 ==
=== 사용자 수집 ===
attachment:data_gathering_process.png,width=800,align=center
===== 사용자 수집 =====
a. API: [http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show api/user show]
- Returns a single status, specified by the id parameter below. The status's author will be returned inline.

Parameters:
- user_id
o Example: http://api.twitter.com/1/users/show.xml?user_id=1401881
a. API2: [http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids api/friends id]
- Returns an array of numeric IDs for every user the specified user is following.
a. API2: [http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-followers%C2%A0ids api/followers id]
- Returns an array of numeric IDs for every user following the specified user.
a. 대상:
- (데이터 수집일을 기준으로)최근 한달동안 적어도 한 번 포스팅한 사용자
- 사용자의 국적이 미국과 한국인 사용자
@@ -37,13 +98,13 @@
- 작성시간 created_at
- 글 아이디 id
a. 데이터베이스로 정리(msql)
|'''DB Table'''||||||||| '''User''' ||
||User ID||Num_Folloing||Num_Follower||Created at||TimeZone(Location)||
|| || || || || ||
|| || || || || ||

||User ID||Num_Folloing||Num_Follower||Created at||Location||
|| || || || || ||
|| || || || || ||
=== Tweet 수집 ===
a. API1: [http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-user_timeline api/user_timeline], [http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweets api/retweets]
===== Tweet 수집 =====
a. API1: [http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-user_timeline api/user_timeline]
- Returns the 20 most recent statuses posted from the authenticating user. It's also possible to request another user's timeline via the id parameter. This is the equivalent of the Web /<user> page for your own user, or the profile page for a third party.
- Note: For backwards compatibility reasons, retweets are stripped out of the user_timeline when calling in XML or JSON (they appear with 'RT' in RSS and Atom). If you'd like them included, you can merge them in from statuses retweeted_by_me.

@@ -68,17 +129,94 @@
- count. Optional. Specifies the number of retweets to retrieve. May not be greater than 100.
o Example: http://api.twitter.com/1/statuses/retweets/5466220198.xml?count=5

a. 문제: 현재 retweets api를 이용해서는 최근 100개의 retweet만을 얻을 수 있다.
- http://www.mail-archive.com/twitter-development-talk@googlegroups.com/msg18826.html
- [http://groups.google.com/group/twitter-development-talk 개발자포럼]
- [http://apiwiki.twitter.com/REST-API-Changelog REST-API-Changelog]
- [http://jinsnet.com/53 RT이슈들]
- [http://blog.twitter.com/2010/02/measuring-tweets.html 트윗통계]
- => [http://dev.twitter.com/doc/get/statuses/:id/retweeted_by/ids 차선책???] => ex. http://api.twitter.com/1/statuses/15316085365/retweeted_by/ids.xml?count=100&page=2
- 차선책 tweet단위로 접근(문제는 수집하는 시간이 너무 길어진다는 것,시간이 길어지면 팔로잉,팔로워 수가 수집시점과 전파시점에 차이가 생길 수 있다는 것) => ex. http://api.twitter.com/1/statuses/show/15840409304.xml
- attachment:RT.png
a. 대상:
- (데이터 수집일을 기준으로)수집 대상인 사용자들의 최근 한달동안 포스팅된 모든 글: 이때 리트윗한 글은 수집되지 않는다.
- 순수하게 포스팅된 글을 기준으로 리트윗한 글들을 찾아 포함시킨다.

a. 데이터베이스로 정리(msql)
|'''DB Table'''||||||||| '''Tweet''' ||
||Tweet ID||Created at||Media||User ID||Num_RT||Length_RT_Depth||Text||
|| || || || || || || ||
|| || || || || || || ||
|'''DB Table'''||||||||||||||| '''(A)Tweet''' ||
||Tweet ID||Created at||Media||User ID||Num_RT||Length_RT_Depth||Text||pattern||
|| || || || || || || || ||
|| || || || || || || || ||

|'''DB Table'''||||||| '''Re-Tweet''' ||
|'''DB Table'''||||||||||| '''(B)Re-Tweet''' ||
||Tweet ID||Created at||Media||User ID||From_Tweet ID||Current_RT_Depth||
|| || || || || || ||
|| || || || || || ||
|'''DB Table'''||||||||||||||||||| '''(A+B)Tweets''' ||
||Tweet ID||Created at||Media||User ID||From_Tweet ID||From_User ID||From_Source_Tweet ID||Text||Num_RT||pattern||
|| || || || || || || || || || ||
|| || || || || || || || || || ||
a. 참고사항:
- [http://groups.google.com/group/twitter-api-announce/browse_thread/thread/5152a34a8ae6ccb6 Upcoming changes to the way status IDs are sequenced]: We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. '''However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random'''.
- [http://www.scribd.com/doc/30146338/map-of-a-tweet map of a tweet]
a. API0: [http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search search], [http://dev.twitter.com/doc/get/search search2]
- Returns tweets that match a specified query.
Parameters:
- since: Optional. Returns tweets with since the given date. Date should be formatted as YYYY-MM-DD
o Example: http://search.twitter.com/search.atom?q=twitter&since=2010-02-28
- '''text''':@twitterapi http:\/\/tinyurl.com\/ctrefg
- '''from_user''':jkoum
- '''id''':1478555574
- '''source''': twitter
- '''created_at''':Wed, 08 Apr 2009 19:22:10 +0000
===== Temp =====
a. Twitted message first (with trend)
a. Users with the messages
a. Trace their social networks
>> One of the biggest mistake companies and brands make about Twitter is that they think it is one more "shout channel" like TV and Radio and Magazine ads or Press Releases. Twitter is not that. Twitter is a "conversation channel", a place where you can find the audience relevant to you (and your company and products and services and jihad) and engage in a conversation with them. It is not pitching, it is enriching the value of the ecosystem by participating. from [http://www.kaushik.net/avinash/2009/11/social-media-analytics-twitter-quantitative-qualitative-analysis.html Social Media Analytics: Twitter: Quantitative & Qualitative Metrics ToughTwitter is amongst new media channels that are ]
== 참고문헌 ==
[http://danzarrella.com/all-about-retweets All about retweets]
[http://danzarrella.com/how-retweets-spread.html How retweets spread]
[http://www.kaushik.net/avinash/2009/11/social-media-analytics-twitter-quantitative-qualitative-analysis.html Social Media Analytics: Twitter: Quantitative & Qualitative Metrics]
[[ISBN(0470529393)]] [[ISBN(0470562315)]]
[http://topsy.com/]
[http://klout.com/kscore/ Klout score], explanation
http://www.graphedge.com/report.php?guid=390b1996-adeb-11de-9d14-00304833c5e8
== 참고자료 ==
__Weibull distribution__
* http://www.wessa.net/rwasp_fitdistrweibull.wasp?edit=T
* http://www.qualitydigest.com/jan99/html/body_weibull.html
* http://www.dplot.com/registration.htm
__API__
* [http://help.twitter.com/entries/13920-frequently-asked-questions frequently-asked-questions]
* [http://apiwiki.twitter.com/Twitter-API-Documentation 트위터API]
* http://www.newwebplatform.com/tips-and-tutorials/Twitter
* http://tweetstats.com/trends | TweetStats;Trends관련 서비스
* http://trendistic.com/ | Trendistic.com
* http://www.flaptor.com/ | Trendistic만든 곳의 홈페이지
* http://www.crowdeye.com | Crowdeye.com
* http://ir.uiowa.edu/polisci_nmp/6/ | The 2009 Philippines Flood and Twitter:Trendistic데이터사용
* http://visitmix.com/Opinions/the-archivist | Twitter Data 관련: Archivist 소개
* http://flotzam.com/archivist/ | Archivist 홈페이지 및 설치
* http://mashable.com/2008/10/02/dipity-public/# | Dipity소개@mashable
* http://www.dipity.com/ | Dipity.com
* http://blog.twitter.com/ | 트위터 블로그
* http://search.twitter.com/about | 트위터 Search 소개
* http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search | 트위터 Search API
* http://apiwiki.twitter.com/Libraries#Javanbsp | Twitter JAVA API
* http://www.winterwell.com/software/jtwitter/javadoc/ | Twitter JAVA API 문서
== API USE ==
* http://dev.twitter.com/doc/get/statuses/user_timeline
* http://dev.twitter.com/doc/get/users/show



1. 스케줄

연구일정
6월2주연구계획서 정리, 데이터 수집준비
3주화이트리스팅 신청,데이터 수집 계획 검토, 프로그램 코딩
4주프로그램 코딩
5주데이터 수집 준비 완료, 화이트리스팅 등록
7월1주데이터 수집 시작, weilbull 분석 준비
2주데이터 수집, weilbull 분석 준비
3주데이터 수집, weilbull 분석 준비 완료
4주데이터 수집 완료, weilbull 분석 준비 완료
5주weilbull 분석을 통한 메시지 패턴 구하기

2. 연구 주제

연구 주제
'뉴미디어 환경에서의 메시지 확산에 대한 탐구: 트위터 사례분석을 통한 마이크로블로그를 중심으로'
(쉽게말해 트위터에서 메시지가 어떻게 전파되는지 보고싶다!!)

  • 마이크로블로그에서 특정 주제에 관한 확산의 패턴과 특징에 관한 탐구
    1. Weibull distribustion에 따른 메시지 분류해 보고 그 특징과 의미를 찾아본다
    2. 기존의 확산연구와의 비교를 통해 마이크로블로그가 메시지 확산에 갖는 의미
    • [http]Weibull Distribustion
    <그림1>람다값의 변화
    <그림2>누적그래프

    3. 연구 목적


    위의 공식은 연속확률밀도 함수의 하나인 Weibull 분포(distribution)를 만드는 공식으로 앞의 계수 부분 중 케이(k)값은 그래프의 형태를 결정하고, 람다(λ)값은 스케일을 결정한다. 이 곡선은 가로축을 시간으로 생각하고 세로축을 RT의 수라 하면, 메시지가 시간에따른 RT의 분포로 표현할 수 있다. 이를 통해 메시지의 전파 형태를 그려볼 수 있고 형태에 따른 메시지 구분도 가능하게 된다. 덧붙여 위에 제시된 <그림2>과 같은 누적 곡선은 Rogers의 확산이론에 소개된 S곡선도 설명할수도 있다.

    본 연구는 메시지가 확산의 경로를 추적하여 메시지 확산 패턴을 구성하고 이 특성에 따라서 메시지들의 성격이나 특성이 어떻게 나누어지는가를 살펴보고자 한다. 구체적으로 Weibull distribution을 이용해 메시지 확산의 패턴을 분류하고 그 군집 별로 어떤 특성이 있는가에 대해서 알아보는 것을 목적으로 한다.

    4. 연구 방법

    4.1. 데이터 수집

    4.1.1. 데이터 수집 사전 준비

    1. 장비 준비
      1. 석혜정 교수님 렌더링 컴퓨터 20대 사용 허락
      2. 컴퓨터 운영체제 및 IP 확인하기
      3. (PHP, APAHCE, Mysql) or (JAVA, Eclipse, Oracle)
      4. [http]Twitter Libraries
        1. TwitterLibraries
    2. API Documents
      1. [http]Api Overview
      2. [http]Wiki
      3. [http]Developer page
    3. White Listing 신청
      1. [http]White Listing이란?
      2. [http]신청양식
      3. form
        whitelisting.png
        [PNG image (49.98 KB)]

    4. 데이터 수집 사례
      1. [http]카이스트 연구1
        41.7 million user accounts
        In order to collect user profiles, we began with Perez Hilton who has over one million followers and crawled breadth-first along the direction of follwers and followings. Twitter rate-limits 20,000 requests per hour per whitelisted IP. Using 20 machines with different IPs and self-requlating collection rate at 10,000 requests per hour. To crawl users not connected to the Giant Connected Component of the Twitter network, we additionally collected profiles of theose who refer to trending topics in their tweets from June to August. The final tally of user profiles we collected is 41.7 million.
      2. [http]카이스트 연구2
        54,981,152 user accounts
        These accounts were in-use in August 2009. We obtained the list of user IDs by repeatedly checking all possible IDs from 0 to 80 million. We scanned the list twice at a two week time gap. We did not look beyond 80 million, because no single user in the collected data had a link to a user whose ID was greater than that value.
    5. 기타
      1. 트위터 가입자를 1억 5천명정도로 예상하면 150000000request / (20000request/hour*ip) = 7500 hour*ip
      2. 7500hour*ip/24=312.5day*ip
      3. 312.5day*ip / 20ip = 15.625day 적어도 20개의 ip를 사용한다면 15일정도 소요됨.
      4. Time_zone이나 Location은 사용자가 직접 설정해야 함. => 따라서 전체 트윗에서 Time_Zone이나 Location의 비율을 살펴보고 어느 지역에서 일어난 일인지 짐작하는 것이 합리적일 것이라 생각함.
    6. Some service?
      1. [http]Streaming API

    4.1.2. 데이터 수집 순서

    1. 전체 사용자 기본 데이터 수집=> Numeric ID
    2. 지역(미국,한국)에 따른 사용자 추출 => Time_zone
    3. 일정 기간 동안 한번도 글을 쓰지 않은 사용자 제거 => UserTimeLine Statuses
    4. 사용자 특성(팔로잉,팔로워)에 따른 사용자 집단 세분화 => the number of Following and Follower,the daversity of Media Use

    data_gathering_process.png
    [PNG image (58.38 KB)]

    4.1.2.1. 사용자 수집
    1. API: [http]api/user show
      - Returns a single status, specified by the id parameter below. The status's author will be returned inline.

      2. Parameters:
      - user_id
      o Example: http://api.twitter.com/1/users/show.xml?user_id=1401881

    2. API2: [http]api/friends id
      - Returns an array of numeric IDs for every user the specified user is following.

    3. API2: [http]api/followers id
      - Returns an array of numeric IDs for every user following the specified user.

    4. 대상:
      - (데이터 수집일을 기준으로)최근 한달동안 적어도 한 번 포스팅한 사용자
      - 사용자의 국적이 미국과 한국인 사용자
    5. 사용자 정보:
      - 사용자 아이디 id
      - 사용자 닉네임 screen_name
      - 지역 location
      - 소개글 description
      - 홈페이지 주소 url
      - 팔로워 수 followers_count
      - 친구수 friends_count
      - 가입일 created_at
      - 관심지정수 favourites_count
      - utc_offset
      - 타임존 time_zone
      - 트윗수 statuses_count
      - 언어 en
      - 최근글 status
      - 작성시간 created_at
      - 글 아이디 id
    6. 데이터베이스로 정리(msql)
    DB Table
    User
    User IDNum_FolloingNum_FollowerCreated atTimeZone(Location)

    4.1.2.2. Tweet 수집
    1. API1: [http]api/user_timeline
      - Returns the 20 most recent statuses posted from the authenticating user. It's also possible to request another user's timeline via the id parameter. This is the equivalent of the Web /<user> page for your own user, or the profile page for a third party.
      - Note: For backwards compatibility reasons, retweets are stripped out of the user_timeline when calling in XML or JSON (they appear with 'RT' in RSS and Atom). If you'd like them included, you can merge them in from statuses retweeted_by_me.

      2. Parameters:
      - user_id. Optional. Specfies the ID of the user for whom to return the user_timeline. Helpful for disambiguating when a valid user ID is also a valid screen name.
      o Example: http://api.twitter.com/1/statuses/user_timeline.xml?user_id=1401881
      - since_id. Optional. Returns only statuses with an ID greater than (that is, more recent than) the specified ID.
      o Example: http://api.twitter.com/1/statuses/user_timeline.xml?since_id=12345
      - max_id. Returns only statuses with an ID less than (that is, older than) or equal to the specified ID.
      o Example: http://api.twitter.com/1/statuses/user_timeline.xml?max_id=54321
      - count. Optional. Specifies the number of statuses to retrieve. May not be greater than 200. (Note the the number of statuses returned may be smaller than the requested count as retweets are stripped out of the result set for backwards compatibility.)
      o Example: http://api.twitter.com/1/statuses/user_timeline.xml?count=200
      - page. Optional. Specifies the page of results to retrieve. Note: there are pagination limits.
      o Example: http://api.twitter.com/1/statuses/user_timeline.rss?page=3

    2. API2: [http]api/retweets
      - Returns up to 100 of the first retweets of a given tweet.

      3. Parameters:
      - id. Required. The numerical ID of the tweet you want the retweets of.
      o Example: http://api.twitter.com/1/statuses/retweets/5466220198.xml
      - count. Optional. Specifies the number of retweets to retrieve. May not be greater than 100.
      o Example: http://api.twitter.com/1/statuses/retweets/5466220198.xml?count=5

    3. 문제: 현재 retweets api를 이용해서는 최근 100개의 retweet만을 얻을 수 있다.
      - http://www.mail-archive.com/twitter-development-talk@googlegroups.com/msg18826.html
      - [http]개발자포럼
      - [http]REST-API-Changelog
      - [http]RT이슈들
      - [http]트윗통계
      - => [http]차선책??? => ex. http://api.twitter.com/1/statuses/15316085365/retweeted_by/ids.xml?count=100&page=2
      - 차선책 tweet단위로 접근(문제는 수집하는 시간이 너무 길어진다는 것,시간이 길어지면 팔로잉,팔로워 수가 수집시점과 전파시점에 차이가 생길 수 있다는 것) => ex. http://api.twitter.com/1/statuses/show/15840409304.xml
      -
      RT.png
      [PNG image (50.6 KB)]

    4. 대상:
      - (데이터 수집일을 기준으로)수집 대상인 사용자들의 최근 한달동안 포스팅된 모든 글: 이때 리트윗한 글은 수집되지 않는다.
      - 순수하게 포스팅된 글을 기준으로 리트윗한 글들을 찾아 포함시킨다.

    5. 데이터베이스로 정리(msql)
    DB Table
    (A)Tweet
    Tweet IDCreated atMediaUser IDNum_RTLength_RT_DepthTextpattern

    DB Table
    (B)Re-Tweet
    Tweet IDCreated atMediaUser IDFrom_Tweet IDCurrent_RT_Depth

    DB Table
    (A+B)Tweets
    Tweet IDCreated atMediaUser IDFrom_Tweet IDFrom_User IDFrom_Source_Tweet IDTextNum_RTpattern

    1. 참고사항:
      - [http]Upcoming changes to the way status IDs are sequenced: We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random.
      - [http]map of a tweet

    2. API0: [http]search, [http]search2
      - Returns tweets that match a specified query.
      3. Parameters:
      - since: Optional. Returns tweets with since the given date. Date should be formatted as YYYY-MM-DD
      o Example: http://search.twitter.com/search.atom?q=twitter&since=2010-02-28

      - text:@twitterapi http:\/\/tinyurl.com\/ctrefg
      - from_user:jkoum
      - id:1478555574
      - source: twitter
      - created_at:Wed, 08 Apr 2009 19:22:10 +0000

    4.1.2.3. Temp
    1. Twitted message first (with trend)
    2. Users with the messages
    3. Trace their social networks

      One of the biggest mistake companies and brands make about Twitter is that they think it is one more "shout channel" like TV and Radio and Magazine ads or Press Releases. Twitter is not that. Twitter is a "conversation channel", a place where you can find the audience relevant to you (and your company and products and services and jihad) and engage in a conversation with them. It is not pitching, it is enriching the value of the ecosystem by participating. from [http]Social Media Analytics: Twitter: Quantitative & Qualitative Metrics ToughTwitter is amongst new media channels that are

    5. 참고문헌

    6. 참고자료

    7. API USE

    Valid XHTML 1.0! Valid CSS! powered by MoniWiki
    last modified 2012-05-08 14:46:26
    Processing time 0.0348 sec