Skip to main content
हमारी तुलना गाइड देखें:

X API: एंटरप्राइज़ डेटा डिक्शनरी

परिचय

Enterprise पोस्ट्स, X से जुड़ी हर चीज़ के मूलभूत निर्माण खंड हैं। पोस्ट्स लौटाने वाले सभी X APIs यह डेटा JavaScript Object Notation (JSON) में एन्कोड करके प्रदान करते हैं। JSON, कुंजी-मूल्य युग्मों पर आधारित होता है, जिनमें नामित एट्रिब्यूट्स और उनसे जुड़े values होते हैं। API से प्राप्त पोस्ट ऑब्जेक्ट्स में किसी X User का “status update” शामिल होता है, लेकिन Retweets, replies और quote Tweets भी पोस्ट ऑब्जेक्ट्स ही होते हैं।  यदि कोई पोस्ट किसी दूसरे पोस्ट से संबंधित है, जैसे Retweet, reply या quote Tweet के रूप में, तो उसे पोस्ट ऑब्जेक्ट में पहचाना या एम्बेड किया जाता है।  X के मूल डेटा फ़ॉर्मैट में सबसे सरल पोस्ट में भी, पोस्ट के अन्य एट्रिब्यूट्स, जैसे author, उल्लिखित users, टैग की गई place location, hashtags, cashtag symbols, media या URL links को दर्शाने के लिए nested JSON ऑब्जेक्ट्स होते हैं।  X डेटा के साथ काम करते समय यह एक महत्वपूर्ण अवधारणा है, जिसे समझना ज़रूरी है। X API से आपको मिलने वाले पोस्ट डेटा का फ़ॉर्मैट, प्राप्त पोस्ट के type, आपके द्वारा उपयोग किए जा रहे X API, और फ़ॉर्मैट settings पर निर्भर करता है। पोस्ट ऑब्जेक्ट्स लौटाने वाले Enterprise endpoints को इस तरह अपडेट किया गया है कि वे पोस्ट की edit history को समझने के लिए आवश्यक metadata प्रदान करें। इस metadata के बारे में अधिक जानने के लिए “Edit Posts” fundamentals पृष्ठ देखें।
X के मूल फ़ॉर्मैट में, JSON payload में ‘root-level’ एट्रिब्यूट्स और नेस्टेड JSON objects शामिल होंगे (जिन्हें यहाँ {} notation में दिखाया गया है):

उपलब्ध डेटा फ़ॉर्मैट

कृपया ध्यान दें: एंटरप्राइज़ डेटा APIs के लिए Enriched Native फ़ॉर्मैट का उपयोग करना अत्यधिक अनुशंसित है। 
  • Enriched Native फ़ॉर्मैट में 2017 से जोड़ा गया सभी नया मेटाडेटा शामिल है, जैसे poll metadata, साथ ही reply_count और quote_count जैसे अतिरिक्त मेट्रिक्स।
  • 2017 में हुए character update के बाद से Activity Streams फ़ॉर्मैट को नए मेटाडेटा या enrichment के साथ अपडेट नहीं किया गया है।
Enterprise data APIs डेटा को दो अलग-अलग फ़ॉर्मैट में उपलब्ध कराते हैं। मानक v1.1 native फ़ॉर्मैट के सबसे निकट का एंटरप्राइज़ फ़ॉर्मैट Native Enriched है। पुराना एंटरप्राइज़ डेटा फ़ॉर्मैट Activity Streams है, जिसे मूल रूप से उस समय X और अन्य सोशल मीडिया डेटा प्रदाताओं के बीच एक सामान्यीकृत फ़ॉर्मैट के रूप में Gnip ने लागू किया था और इस्तेमाल किया था। हालांकि यह फ़ॉर्मैट अभी भी उपलब्ध है, X ने 2017 से केवल native enriched फ़ॉर्मैट में ही नई सुविधाओं और विकास पर निवेश किया है। Enriched native फ़ॉर्मैट ठीक वैसा ही है जैसा इसका नाम दर्शाता है; इसमें native X objects के साथ-साथ एंटरप्राइज़ डेटा उत्पादों के लिए उपलब्ध अतिरिक्त enrichment भी शामिल हैं, जैसे URL unwinding metadata, profile geo, poll metadata, और अतिरिक्त engagement metrics।  

डेटा फ़ॉर्मैट के अनुसार ऑब्जेक्ट की तुलना

X पर आपका उपयोग-मामला चाहे जो भी हो, इन JSON-encoded पोस्ट ऑब्जेक्ट्स और एट्रिब्यूट्स क्या दर्शाते हैं, यह समझना आपकी रुचि के डेटा सिग्नल्स को सफलतापूर्वक खोजने के लिए बेहद महत्वपूर्ण है। इस प्रयास में मदद के लिए, हर डेटा फ़ॉर्मैट में हर ऑब्जेक्ट के लिए समर्पित पृष्ठों का एक सेट उपलब्ध है_।_ ऊपर दी गई JSON hierarchy को दर्शाते हुए, यहाँ इन प्रत्येक ऑब्जेक्ट के लिंक दिए गए हैं:

पार्सिंग के लिए सर्वोत्तम प्रथाएँ

  • X JSON को UTF-8 वर्णों का उपयोग करके एन्कोड किया जाता है।
  • पार्सर को फ़ील्ड्स के क्रम में होने वाले बदलावों को आसानी से संभालने में सक्षम होना चाहिए। यह मानकर चलना चाहिए कि पोस्ट JSON, डेटा के एक अनक्रमित hash के रूप में दिया जाता है।
  • पार्सर को ‘नए’ फ़ील्ड्स जोड़े जाने को भी सहन करना चाहिए। 
  • JSON पार्सर को ‘अनुपस्थित’ फ़ील्ड्स के प्रति सहनशील होना चाहिए, क्योंकि सभी फ़ील्ड्स हर संदर्भ में दिखाई नहीं देते।
  • सामान्यतः, null फ़ील्ड, खाली set, और किसी फ़ील्ड की अनुपस्थिति को एक ही बात मानना सुरक्षित है

Enterprise Native Enriched डेटा ऑब्जेक्ट्स

Native Enriched Tweet ऑब्जेक्ट

क्या आप यह और विस्तार से जानना चाहते हैं कि Native Enriched डेटा फ़ॉर्मैट, X API v2 फ़ॉर्मैट से कैसे मैप होता है? हमारी तुलना गाइड देखें: Native Enriched की X API v2 से तुलना

पोस्ट ऑब्जेक्ट

Enterprise data products का उपयोग करते समय, आप देखेंगे कि डेटा डिक्शनरी का बड़ा हिस्सा पोस्ट data के native format के समान है, जिसमें कुछ अतिरिक्त enriched metadata भी शामिल हैं।  Native enriched format का base level X API v1.1 data format जैसे कई object names का उपयोग करता है।  पोस्ट ऑब्जेक्ट में ‘root-level’ एट्रिब्यूट्स की एक लंबी सूची होती है, जिसमें id, created_at, और text जैसे मूलभूत एट्रिब्यूट्स शामिल हैं। पोस्ट ऑब्जेक्ट्स में user, entities, और extended_entities को शामिल करने वाले nested objects भी होते हैं। पोस्ट ऑब्जेक्ट्स में retweeted_status, quoted_status, और extended_tweet जैसे अन्य nested पोस्ट objects भी होते हैं।  Native enriched format में अतिरिक्त रूप से एक matching_rules object भी होता है।
X डेटा डिक्शनरी
नीचे आपको इन ‘रूट-लेवल’ एट्रिब्यूट्स के लिए डेटा डिक्शनरी मिलेगा, साथ ही चाइल्ड ऑब्जेक्ट्स के डेटा डिक्शनरी के लिंक भी मिलेंगे।
अतिरिक्त पोस्ट एट्रिब्यूट्स
वे X APIs जो पोस्ट्स प्रदान करते हैं (जैसे, GET statuses/lookup endpoint) इनमें पोस्ट की ये अतिरिक्त एट्रिब्यूट्स शामिल हो सकती हैं:
अप्रचलित एट्रिब्यूट

Nested पोस्ट ऑब्जेक्ट्स

कई मामलों में, एक पोस्ट ऑब्जेक्ट में अन्य nested ऑब्जेक्ट्स शामिल होते हैं। यदि आप nested ऑब्जेक्ट्स के साथ काम कर रहे हैं, तो उस JSON payload में कई पोस्ट ऑब्जेक्ट्स होंगे, और हर पोस्ट ऑब्जेक्ट में अपने अलग ऑब्जेक्ट्स हो सकते हैं। Root-level ऑब्जेक्ट में की गई कार्रवाई के प्रकार की जानकारी होगी, यानी यह Retweet है या Quote Tweet, और इसमें वह ऑब्जेक्ट भी हो सकता है जो साझा की जा रही ‘original’ पोस्ट का वर्णन करता है। Extended Posts में एक nested extended ऑब्जेक्ट शामिल होता है, जो 140 characters से आगे तक की सामग्री को समेटता है; इसका उपयोग 2017 में अपडेट किए जाने पर breaking changes को रोकने के लिए किया गया था। हर nested object dictionary का वर्णन नीचे किया गया है। Retweets Retweets में हमेशा दो पोस्ट ऑब्जेक्ट्स होते हैं। Retweet की जा रही ‘original’ पोस्ट एक “retweeted_status” ऑब्जेक्ट में दी जाती है। Root-level ऑब्जेक्ट, Retweet को ही encapsulate करता है, जिसमें Retweet करने वाले account का User ऑब्जेक्ट और Retweet का समय शामिल होता है। Retweet करना, अपने followers के साथ किसी पोस्ट को साझा करने की एक कार्रवाई है, और इसमें कोई नई सामग्री नहीं जोड़ी जा सकती। साथ ही, किसी Retweet के साथ कोई (नई) location नहीं दी जा सकती। भले ही ‘original’ पोस्ट geo-tagged हो, Retweet के “geo” और “place” ऑब्जेक्ट्स हमेशा null होंगे। Extended Posts की शुरुआत से पहले भी, root-level “entities” ऑब्जेक्ट कुछ मामलों में truncate हो जाता था और अधूरा रह जाता था, क्योंकि Retweet की जा रही पोस्ट के message में “RT @username ” string जोड़ दी जाती थी। ध्यान दें कि अगर किसी Retweet को फिर से Retweet किया जाता है, तो “retweet_status” फिर भी original पोस्ट की ओर ही संकेत करेगा, यानी बीच वाला Retweet शामिल नहीं होगा। ऐसा ही व्यवहार x.com का उपयोग करके किसी Retweet को ‘display’ करने पर भी देखा जाता है। अगर आप Retweet ‘action’ को दिया गया unique पोस्ट ID कॉपी करते हैं, तो original पोस्ट प्रदर्शित होती है।  नीचे Retweet के लिए एक example structure दिया गया है। फिर से, Retweets को parse करते समय, पूरा (original) पोस्ट message और entity metadata पाने के लिए “retweeted_status” ऑब्जेक्ट को parse करना महत्वपूर्ण है।
कोट ट्वीट्स
कोट ट्वीट्स, रीट्वीट्स की तरह ही होते हैं, लेकिन इनमें एक नया पोस्ट संदेश भी शामिल होता है। इन नए संदेशों में हैशटैग, लिंक और अन्य “entities” मेटाडेटा का अपना सेट हो सकता है। कोट ट्वीट्स में, कोट ट्वीट पोस्ट करने वाले उपयोगकर्ता द्वारा साझा की गई लोकेशन जानकारी भी शामिल हो सकती है, साथ ही GIFs, वीडियो और फ़ोटो जैसे मीडिया भी। कोट ट्वीट्स में कम-से-कम दो पोस्ट ऑब्जेक्ट होते हैं, और कुछ मामलों में तीन भी। उद्धृत किया जा रहा पोस्ट, जो स्वयं भी एक कोट ट्वीट हो सकता है, “quoted_status” ऑब्जेक्ट में दिया जाता है। रूट-स्तरीय ऑब्जेक्ट, साझा करने की कार्रवाई करने वाले खाते के लिए एक User ऑब्जेक्ट और कोट ट्वीट का समय सहित, स्वयं कोट ट्वीट को समाहित करता है। ध्यान दें कि अब कोट ट्वीट्स में ‘Post’ यूज़र-इंटरफ़ेस का उपयोग करके फ़ोटो, GIFs या वीडियो भी जोड़े जा सकते हैं। जब कोट ट्वीट संदेश में बाहरी रूप से होस्ट किए गए मीडिया के लिंक शामिल होते हैं, तो रूट-स्तरीय “entities.urls” उनका विवरण देता है। कोट ट्वीट्स के साथ संलग्न मीडिया रूट-स्तरीय “extended_entities” मेटाडेटा में दिखाई देगा। जब कोट ट्वीट्स पहली बार लॉन्च किए गए थे, तब एक छोटा किया गया लिंक (t.co URL) ‘original’ पोस्ट संदेश के अंत में जोड़ दिया जाता था और रूट-स्तरीय “text” फ़ील्ड में दिया जाता था। इसके अलावा, उस t.co URL का मेटाडेटा रूट-स्तरीय ‘entities.urls’ array में शामिल होता था। मई 2018 में, हमने इसे बदल दिया, ताकि उद्धृत Tweet का छोटा किया गया t.co URL रूट-स्तरीय “text” फ़ील्ड में शामिल नहीं होगा। दूसरा, उद्धृत Tweet का मेटाडेटा* “entities.urls” मेटाडेटा में शामिल नहीं होगा। इसके बजाय, उद्धृत Tweet के लिए URL मेटाडेटा रूट-स्तरीय (या शीर्ष-स्तरीय) पर एक नए “quoted_status_permalink” ऑब्जेक्ट में होगा, यानी “quoted_status” ऑब्जेक्ट के उसी स्तर पर। नीचे इस मूल फ़ॉर्मैटिंग का उपयोग करते हुए एक कोट ट्वीट की उदाहरण संरचना दी गई है। 
विस्तारित पोस्ट्स
Extended Posts का वर्णन करने वाला JSON नवंबर 2017 में 280-वर्ण वाले पोस्ट्स के लॉन्च के साथ पेश किया गया था। लंबे संदेशों को समाहित करने के लिए पोस्ट JSON का विस्तार किया गया, लेकिन साथ ही इन मूलभूत X ऑब्जेक्ट्स को पार्स करने वाले हज़ारों ऐप्स की संगतता भी बनी रही। पूर्ण बैकवर्ड संगतता देने के लिए, मूल 140-वर्ण वाला ‘text’ फ़ील्ड और उससे पार्स किए गए entity ऑब्जेक्ट्स को बरकरार रखा गया। 140 वर्णों से लंबे पोस्ट्स में यह रूट-लेवल ‘text’ फ़ील्ड ट्रंकेट हो जाता था, इसलिए वह पूरा नहीं रहता था। चूँकि रूट-लेवल ‘entities’ ऑब्जेक्ट्स में ‘text’ संदेश से पार्स किए गए मुख्य मेटाडेटा की arrays होती हैं, जैसे शामिल hashtags और links, इसलिए ये collections भी अपूर्ण रहती थीं। उदाहरण के लिए, अगर कोई पोस्ट संदेश 200 वर्ण लंबा हो और उसके अंत में एक hashtag शामिल हो, तो legacy रूट-लेवल ‘entities.hashtags’ array में वह शामिल नहीं होगा।  लंबे पोस्ट संदेशों और पूर्ण entity मेटाडेटा को रखने के लिए एक नया ‘extended_tweet’ फ़ील्ड पेश किया गया। “extended_tweet” ऑब्जेक्ट “full_text” फ़ील्ड देता है, जिसमें 140 वर्णों से लंबे पोस्ट का पूरा, बिना ट्रंकेट किया हुआ संदेश होता है। “extended_tweet” ऑब्जेक्ट में एक “entities” ऑब्जेक्ट भी होता है, जिसमें hashtags, links, mentions आदि की पूरी arrays होती हैं। विस्तारित पोस्ट्स की पहचान रूट-लेवल “truncated” boolean से होती है। जब इसका मान true हो (“truncated”: true), तो रूट-लेवल फ़ील्ड्स के बजाय “extended_tweet” फ़ील्ड्स को पार्स किया जाना चाहिए। नीचे दिए गए JSON उदाहरण में ध्यान दें कि रूट-लेवल “text” फ़ील्ड ट्रंकेट है और रूट-लेवल “entities.hashtags” array खाली है, जबकि पोस्ट संदेश में तीन hashtags शामिल हैं। चूँकि यह एक Extended Post है, “truncated” फ़ील्ड true पर सेट है, और “extended_tweet” ऑब्जेक्ट पूरा “full_text” और “entities” पोस्ट मेटाडेटा प्रदान करता है।

Native Enriched User ऑब्जेक्ट

User ऑब्जेक्ट में संदर्भित X User का वर्णन करने वाला X User अकाउंट मेटाडेटा शामिल होता है। 

उपयोगकर्ता डेटा शब्दकोश

अब समर्थित नहीं (deprecated) एट्रिब्यूट

उदाहरण उपयोगकर्ता ऑब्जेक्ट:

Native Enriched Geo ऑब्जेक्ट्स

पोस्ट्स को किसी स्थान से संबद्ध किया जा सकता है, जिससे ऐसा पोस्ट बनता है जिसे ‘geo-tagged’ किया गया हो। पोस्ट के स्थान X user-interface का उपयोग करके या API के जरिए पोस्ट करते समय असाइन किए जा सकते हैं। पोस्ट का स्थान एक सटीक ‘point’ location हो सकता है, या एक X Place हो सकता है, जिसमें एक ‘bounding box’ होता है जो किसी venue से लेकर पूरे region तक के बड़े क्षेत्र का वर्णन करता है। किसी पोस्ट से संबद्ध स्थान का वर्णन करने के लिए तीन ‘root-level’ JSON ऑब्जेक्ट्स का उपयोग किया जाता है: place, geo और coordinates इसके अतिरिक्त, Native enriched format में user object के भीतर profile geo enrichment’s derived location भी शामिल होती है। जब किसी पोस्ट को किसी place के साथ geo-tag किया जाता है, तो place ऑब्जेक्ट हमेशा मौजूद रहता है। Places विशिष्ट, नामित स्थान होते हैं, जिनसे संबंधित geo coordinates जुड़े होते हैं। जब उपयोगकर्ता अपने पोस्ट को कोई स्थान असाइन करने का निर्णय लेते हैं, तो उन्हें संभावित X Places की एक सूची दिखाई जाती है। API का उपयोग करके पोस्ट करते समय, place_id निर्दिष्ट करके एक X Place अटैच किया जा सकता है। Places से संबद्ध पोस्ट्स का यह आवश्यक नहीं है कि वे उसी स्थान से जारी किए गए हों; वे उस स्थान के बारे में भी हो सकते हैं। geo और coordinates ऑब्जेक्ट्स केवल तभी मौजूद (non-null) होते हैं, जब पोस्ट को एक सटीक स्थान असाइन किया गया हो। यदि एक सटीक स्थान प्रदान किया गया है, तो coordinates ऑब्जेक्ट भौगोलिक निर्देशांकों के साथ एक [long, lat] array प्रदान करेगा, और उस स्थान से संबंधित एक X Place असाइन किया जाएगा।

Place डेटा शब्दकोश

बाउंडिंग बॉक्स

Geo ऑब्जेक्ट डेटा शब्दकोश

Coordinates ऑब्जेक्ट डेटा शब्दकोश

व्युत्पन्न लोकेशन

उदाहरण:

डेटा शब्दकोश: एंटरप्राइज़

X एंटिटीज़

इस पेज पर सीधे जाएँ परिचय एंटिटीज़ ऑब्जेक्ट   - हैशटैग ऑब्जेक्ट   - मीडिया ऑब्जेक्ट   - मीडिया साइज़ ऑब्जेक्ट   - URL ऑब्जेक्ट   - यूज़र मेंशन ऑब्जेक्ट   - सिम्बल ऑब्जेक्ट   - पोल ऑब्जेक्ट रीट्वीट और कोट ट्वीट का विवरण यूज़र ऑब्जेक्ट्स में एंटिटीज़ डायरेक्ट मैसेज में एंटिटीज़ अगले चरण

परिचय

एंटिटीज़, X पर पोस्ट की गई सामग्री के बारे में metadata और अतिरिक्त प्रासंगिक जानकारी प्रदान करते हैं। entities सेक्शन में पोस्ट्स में शामिल सामान्य तत्वों की arrays होती हैं: hashtags, user mentions, links, stock tickers (symbols), X polls, और संलग्न media। पोस्ट्स को ingest करते समय ये arrays developers के लिए सुविधाजनक होती हैं, क्योंकि X ने मूल रूप से text body को पहले ही process, या parse, कर दिया होता है। पोस्ट body में इन entities को अलग से खोजने की आवश्यकता के बजाय, आपका parser सीधे इस JSON सेक्शन में जा सकता है, और वे वहीं मिल जाती हैं। Parsing को आसान बनाने के अलावा, entities सेक्शन उपयोगी ‘value-add’ metadata भी प्रदान करता है। उदाहरण के लिए, अगर आप Enhanced URLs enrichment का उपयोग कर रहे हैं, तो URL metadata में पूरी तरह expanded URLs के साथ-साथ संबंधित website titles और descriptions भी शामिल होते हैं। एक और उदाहरण यह है कि जब user mentions होते हैं, तो entities metadata में numeric user ID भी शामिल होती है, जो कई X APIs को requests करते समय उपयोगी होती है। हर पोस्ट JSON payload में entities सेक्शन शामिल होता है, जिसमें कम-से-कम hashtags, urls, user_mentions, और symbols attributes का सेट होता है, भले ही इनमें से कोई भी entity पोस्ट message का हिस्सा न हो। उदाहरण के लिए, अगर आप “Hello World!” body वाली और बिना किसी संलग्न media की किसी पोस्ट का JSON देखते हैं, तो पोस्ट के JSON में निम्नलिखित सामग्री शामिल होगी, जिसमें entity arrays में शून्य items होंगे:
नोट्स:
  • media और polls एंटिटी केवल तभी दिखाई देंगी, जब उस प्रकार का कॉन्टेंट पोस्ट का हिस्सा हो।
  • यदि आप native media (फ़ोटो, वीडियो या GIFs) के साथ काम कर रहे हैं, तो Extended एंटिटीज़ object का उपयोग करना बेहतर है।

Entities ऑब्जेक्ट

entities और extended_entities सेक्शन, दोनों entity objects की arrays से मिलकर बने हैं। नीचे आपको इनमें से प्रत्येक entity object का विवरण मिलेगा, जिसमें data dictionaries भी शामिल हैं, जो object के attribute names, types, और संक्षिप्त विवरण बताती हैं। हम यह भी बताएँगे कि कौन से PowerTrack Operators इन attributes से मेल खाते हैं, और कुछ sample JSON payloads भी शामिल करेंगे। पोस्ट्स में मिलने वाली सामान्य entities का एक संग्रह, जिसमें hashtags, links, और user mentions शामिल हैं। इस entities object में media attribute शामिल होता है, लेकिन entiites सेक्शन में इसका implementation केवल उन पोस्ट्स के लिए पूरी तरह सटीक है जिनमें एक ही photo हो। जिन सभी पोस्ट्स में एक से अधिक photo, video, या animated GIF हो, उनके लिए पाठक को extended_entities सेक्शन देखने का निर्देश दिया जाता है।

Entities डेटा शब्दकोश

entities ऑब्जेक्ट, अन्य entity उप-ऑब्जेक्ट्स के arrays को रखने वाला एक कंटेनर है। entities संरचना, इन उप-ऑब्जेक्ट्स के डेटा शब्दकोश, और उनसे मेल खाने वाले Operators को समझाने के बाद, उन्हें प्रदान किया जाएगा।

हैशटैग ऑब्जेक्ट

entities सेक्शन में एक hashtags array होता है, जिसमें पोस्ट बॉडी में शामिल हर हैशटैग के लिए एक ऑब्जेक्ट होता है। अगर कोई हैशटैग मौजूद नहीं है, तो इसमें एक खाली array शामिल होता है। PowerTrack # Operator का उपयोग text attribute पर match करने के लिए किया जाता है। has:hashtags Operator तब match करेगा, जब array में कम से कम एक item मौजूद हो।

मीडिया ऑब्जेक्ट

यदि किसी मीडिया ऑब्जेक्ट को पोस्ट से ‘संलग्न’ किया गया है, तो entities सेक्शन में एक media array होगा, जिसमें एक ही मीडिया ऑब्जेक्ट शामिल होगा। यदि कोई नेटिव मीडिया संलग्न नहीं किया गया है, तो entities में media array नहीं होगा। निम्न कारणों से पोस्ट के नेटिव मीडिया को प्रोसेस करने के लिए extended_entities सेक्शन का उपयोग किया जाना चाहिए:
  • मीडिया type हमेशा ‘photo’ दिखाएगा, यहाँ तक कि उन मामलों में भी जहाँ पोस्ट के साथ वीडियो या GIF संलग्न हो।
  • हालांकि अधिकतम चार फ़ोटो संलग्न की जा सकती हैं, entities सेक्शन में केवल पहली ही सूचीबद्ध होगी।
यदि यह array populated है, तो has:media Operator मैच करेगा।

मीडिया आकार ऑब्जेक्ट्स

नेटिव मीडिया (फ़ोटो, वीडियो और GIFs) वाले सभी पोस्ट्स में ऊँचाई और चौड़ाई के पिक्सेल आयामों के साथ ‘thumb’, ‘small’, ‘medium’ और ‘large’ आकारों का एक सेट शामिल होगा।  फ़ोटो और प्रीव्यू इमेज मीडिया URLs के लिए, फ़ोटो मीडिया URL फ़ॉर्मैटिंग यह बताता है कि अलग-अलग आकार के फ़ोटो मीडिया लोड करने के लिए अलग-अलग URLs कैसे बनाए जाएँ।

आकारों का ऑब्जेक्ट

Size ऑब्जेक्ट

फ़ोटो मीडिया URL फ़ॉर्मैटिंग

X पर फ़ोटो मीडिया को अलग-अलग आकारों में लोड किया जा सकता है।  किसी विशेष इमेज viewport में फ़िट होने के लिए, इतना बड़ा लेकिन यथासंभव सबसे छोटा चित्र लोड करना सबसे अच्छा रहता है।  अलग-अलग आकार लोड करने के लिए, आकार ऑब्जेक्ट और media_url (या media_url_https) को एक विशेष फ़ॉर्मैट में संयोजित करना होता है।  फ़ोटो मीडिया URL बनाने के उदाहरण के लिए, हम पहले से दिए गए media entity उदाहरण ऑब्जेक्ट का उपयोग करेंगे। media_url या media_url_https को अपने-आप भी लोड किया जा सकता है, जिससे डिफ़ॉल्ट रूप से medium वैरिएंट लोड होता है।  हालाँकि, जहाँ संभव हो, पूरी तरह फ़ॉर्मैट किया गया फ़ोटो मीडिया URL देना बेहतर है। फ़ोटो मीडिया URL के तीन भाग होते हैं: हम इन तीन भागों (base URL, format, और name) को मिलाकर लोड किया जाने वाला फ़ोटो मीडिया URL बनाते हैं।  इस तरीके से इमेज लोड करने के 2 फ़ॉर्मैट हैं, legacy और modern।  सभी इमेज लोड में legacy फ़ॉर्मैट का उपयोग बंद कर देना चाहिए और modern फ़ॉर्मैट का उपयोग करना चाहिए।  modern फ़ॉर्मैट का उपयोग करने से कॉलर के लिए बेहतर CDN hit rate मिलता है, जिससे लोड latency बेहतर होती है, क्योंकि Data Center से मीडिया जनरेट और लोड करने की आवश्यकता पड़ने की संभावना कम हो जाती है।

URL ऑब्जेक्ट

entities सेक्शन में एक urls array होगा, जिसमें पोस्ट बॉडी में शामिल हर लिंक के लिए एक ऑब्जेक्ट होगा। अगर कोई लिंक मौजूद नहीं है, तो इसमें एक खाली array शामिल होगा। अगर array में कम से कम एक आइटम है, तो has:links Operator मैच करेगा। url: Operator का उपयोग expanded_url attribute पर मैच करने के लिए किया जाता है। अगर आप Expanded URL enrichment का उपयोग कर रहे हैं, तो url: Operator का उपयोग unwound.url (पूरी तरह unwound URL) attribute पर मैच करने के लिए किया जाता है। अगर आप Exhanced URL enrichment का उपयोग कर रहे हैं, तो url_title: और url_decription: Operators का उपयोग unwound.title और unwound.description attributes पर मैच करने के लिए किया जाता है। अगर आप Expanded और/या Enhanced URL enrichments का उपयोग कर रहे हैं, तो निम्न metadata unwound attribute के अंतर्गत उपलब्ध है:

उपयोगकर्ता उल्लेख ऑब्जेक्ट

entities सेक्शन में एक user_mentions array होता है, जिसमें पोस्ट के मुख्य पाठ में शामिल प्रत्येक उपयोगकर्ता उल्लेख के लिए एक ऑब्जेक्ट शामिल होता है। यदि कोई उपयोगकर्ता उल्लेख मौजूद नहीं है, तो इसमें एक खाली array शामिल होता है। PowerTrack @ Operator का उपयोग screen_name attribute पर मिलान करने के लिए किया जाता है। has:mentions Operator तब मिलान करेगा, जब array में कम-से-कम एक आइटम मौजूद हो।

सिंबल ऑब्जेक्ट

entities सेक्शन में symbols array होता है, जिसमें पोस्ट बॉडी में शामिल हर $cashtag के लिए एक ऑब्जेक्ट शामिल होता है। अगर कोई symbol मौजूद न हो, तो इसमें एक खाली array शामिल होगा। PowerTrack $ Operator का उपयोग text attribute पर match करने के लिए किया जाता है। has:symbols Operator तब match करेगा, जब array में कम-से-कम एक item मौजूद हो।

पोल ऑब्जेक्ट

अगर पोस्ट में पोल शामिल है, तो entities सेक्शन में polls array होगा, जिसमें एक poll ऑब्जेक्ट शामिल होगा। अगर पोल शामिल नहीं है, तो entities सेक्शन में polls array नहीं होगा। ध्यान दें कि यह पोल मेटाडेटा केवल निम्नलिखित Enterprise APIs के साथ उपलब्ध है:

Retweet और Quote Tweet का विवरण

X API के दृष्टिकोण से, Retweet और Quote Tweet पोस्ट्स के विशेष प्रकार हैं, जिनमें मूल पोस्ट एक एम्बेडेड ऑब्जेक्ट के रूप में शामिल होता है। इसलिए Retweet और Quote Tweet ऑब्जेक्ट्स में एक चाइल्ड ‘original’ पोस्ट होता है (और इस वजह से उनका आकार दोगुना हो जाता है)। रीट्वीट में टॉप-लेवल “retweeted_status” ऑब्जेक्ट होता है, और Quote Tweets में “quoted_status” ऑब्जेक्ट होता है। एकरूपता बनाए रखने के लिए, इन टॉप-लेवल Retweet और Quote Tweet ऑब्जेक्ट्स में भी एक text प्रॉपर्टी और उससे संबंधित entities होती हैं। हालांकि, टॉप-लेवल पर मौजूद entities, एम्बेडेड ‘original’ entities से अलग हो सकती हैं। रीट्वीट के मामले में, मूल पोस्ट बॉडी के पहले नया टेक्स्ट जोड़ा जाता है। Quoted Posts के मामले में, नया टेक्स्ट पोस्ट बॉडी के अंत में जोड़ा जाता है। सामान्य तौर पर, सर्वोत्तम अभ्यास यह है कि जब भी retweeted_status मौजूद हो, तब टेक्स्ट, entities, मूल लेखक और तारीख उसी में मौजूद मूल पोस्ट से प्राप्त किए जाएँ। इसका एक अपवाद उन X entities का है जो अतिरिक्त Quote का हिस्सा होती हैं। अधिक जानकारी और सुझावों के लिए नीचे देखें।

रीट्वीट्स

रीट्वीट्स के बारे में एक महत्वपूर्ण बात यह है कि पोस्ट में कोई अतिरिक्त X entities नहीं जोड़ी जा सकतीं। उपयोगकर्ता रीट्वीट करते समय हैशटैग, URL या अन्य विवरण नहीं जोड़ सकते। हालांकि, रीट्वीट का (टॉप-लेवल) text attribute मूल पोस्ट के टेक्स्ट से बनता है, जिसके आगे “RT @username: ” जोड़ा जाता है।   कुछ मामलों में, खासकर लंबे उपयोगकर्ता नाम वाले खातों में, इन नए अक्षरों और मूल पोस्ट बॉडी का संयोजन आसानी से 140 अक्षरों की मूल पोस्ट टेक्स्ट-लंबाई सीमा से अधिक हो सकता है। 140-अक्षर आधारित प्रदर्शन और संग्रहण के समर्थन को बनाए रखने के लिए, टॉप-लेवल बॉडी पोस्ट बॉडी के अंत को ट्रंकेट कर देती है और एक एलिप्सिस (“…”) जोड़ देती है। नतीजतन, मूल पोस्ट के अंत में स्थित कुछ टॉप-लेवल entities गलत हो सकती हैं या गायब हो सकती हैं, उदाहरण के लिए किसी ट्रंकेट किए गए हैशटैग या URL entry के मामले में। यह पोस्ट,  https://x.com/FloodSocial/status/907974220298125312, का पोस्ट टेक्स्ट इस प्रकार है:                बस एक और टेस्ट पोस्ट, जिसे ठीक 140 अक्षरों का होना चाहिए, और जिसके अंत में URL तथा हैशटैग हो http://wapo.st/2w8iwPQ #Testing ऊपर दिए गए उदाहरण में, URL और हैशटैग दोनों प्रभावित हुए थे। चूंकि हैशटैग पूरी तरह ट्रंकेट हो गया था और URL आंशिक रूप से ट्रंकेट हुआ था, इसलिए ये टॉप-लेवल entities में मौजूद नहीं हैं। आप text field पर “RT @floodsocial: ” prefix से आने वाली अतिरिक्त user_mentions टॉप-लेवल entity को भी देखेंगे। हालांकि, retweeted_status में पोस्ट का टेक्स्ट और entities मूल पोस्ट को बिना किसी truncation या गलत entities के पूरी तरह दर्शाते हैं, इसलिए हमारी सिफारिश है कि रीट्वीट्स के लिए nested _retweeted_status _object पर भरोसा करें।

Quote Tweets

Quote Tweets को 2016 में पेश किया गया था, और ये Retweets से इस मायने में अलग हैं कि जब आप किसी पोस्ट को “quote” करते हैं, तो आप साझा किए गए पोस्ट के “ऊपर” नई सामग्री जोड़ते हैं। इस नई सामग्री में लगभग वह सब कुछ शामिल हो सकता है जो किसी मूल पोस्ट में हो सकता है, जैसे नया टेक्स्ट, हैशटैग, मेंशन और URL। Quote Tweets में मूल मीडिया (फ़ोटो, वीडियो और GIFs) शामिल हो सकते हैं, और वे entities object के अंतर्गत दिखाई देंगे। चूंकि X entities जोड़ी जा सकती हैं, इसलिए Quote entities मूल entities से अलग होने की संभावना है। इस उदाहरण में, Quote Tweet के अंत में एक नया URL और हैशटैग जोड़ा गया था। यह पोस्ट, https://x.com/FloodSocial/status/907983973225160704, निम्नलिखित पोस्ट टेक्स्ट रखता है:                   strange and equally tragic when islands flood… trans-atlantic testing of quote tweets | @thisuser @thatuserhttp://bit.ly/2vMMDuu #testing इस मामले में, शीर्ष-स्तरीय entities, Quote के विवरण नहीं दर्शाती हैं।  हालांकि, extended_tweet में पोस्ट text और entities, Quote Tweet को बिना किसी truncation या गलत entities के पूरी तरह दर्शाते हैं, इसलिए हमारी अनुशंसा है कि Quote Tweets के लिए nested _extended_tweet _object पर भरोसा करें।

उपयोगकर्ता ऑब्जेक्ट के लिए एंटिटीज़

User Objects के लिए एंटिटीज़ उन URLs का वर्णन करती हैं जो उपयोगकर्ता-परिभाषित प्रोफ़ाइल URL और description फ़ील्ड्स में दिखाई देते हैं। वे hashtags या user_mentions का वर्णन नहीं करती हैं। Post एंटिटीज़ के विपरीत, उपयोगकर्ता एंटिटीज़ अपने पैरेंट ऑब्जेक्ट के भीतर कई फ़ील्ड्स पर लागू हो सकती हैं — इस अस्पष्टता को दूर करने के लिए, आपको url और description नाम के पैरेंट नोड्स मिलेंगे, जो यह बताते हैं कि किस फ़ील्ड में एंटिटाइज़ किया गया URL मौजूद है। इस उदाहरण में, उपयोगकर्ता के url फ़ील्ड में एक t.co लिंक है, जो रिस्पॉन्स के entities/url/urls[0] नोड में पूरी तरह expanded रूप में मौजूद है। उपयोगकर्ता के description में कोई wrapped URL नहीं है।

JSON उदाहरण

X विस्तारित एंटिटीज़

इस पेज पर जाएँ परिचय विस्तारित एंटिटीज़ ऑब्जेक्ट उदाहरण Tweet और JSON पेलोड   - चार नेटिव फ़ोटो वाला Tweet   - नेटिव वीडियो वाला Tweet   - एक एनिमेटेड GIF वाला Tweet अगले चरण

परिचय

यदि किसी पोस्ट में नेटिव मीडिया हो (यानी किसी अन्य स्थान के लिंक के ज़रिए नहीं, बल्कि सीधे पोस्ट के यूज़र इंटरफ़ेस में साझा किया गया हो), तो उसमें एक extended_entities सेक्शन भी होगा। किसी भी नेटिव मीडिया (फ़ोटो, वीडियो, या GIF) के लिए, कई कारणों से extended_entities पसंदीदा मेटाडेटा स्रोत है। वर्तमान में, एक पोस्ट के साथ अधिकतम चार फ़ोटो संलग्न की जा सकती हैं। entities मेटाडेटा में केवल पहली फ़ोटो शामिल होगी (2014 तक केवल एक फ़ोटो शामिल की जा सकती थी), जबकि extended_entities सेक्शन में सभी संलग्न फ़ोटो शामिल होंगी। नेटिव मीडिया के साथ, entities.media मेटाडेटा की एक और कमी यह है कि मीडिया type हमेशा ‘photo’ ही दिखाएगा, यहाँ तक कि उन मामलों में भी जहाँ संलग्न मीडिया वीडियो या animated GIF हो। मीडिया का वास्तविक type, extended_entities.media[].type एट्रिब्यूट में निर्दिष्ट होता है और इसे photovideo, या animated_gif में से किसी एक पर सेट किया जाता है। इन कारणों से, यदि आप नेटिव मीडिया के साथ काम कर रहे हैं, तो extended_entities मेटाडेटा ही सबसे बेहतर विकल्प है। संलग्न फ़ोटो, वीडियो और animated GIFs वाले सभी पोस्ट्स में एक extended_entities JSON ऑब्जेक्ट शामिल होगा। extended_entities ऑब्जेक्ट में media ऑब्जेक्ट्स का एक media ऐरे होता है (इसके डेटा शब्दकोश के लिए entities सेक्शन देखें)। extended_entities सेक्शन में hashtags और links जैसे अन्य किसी भी entity प्रकार को शामिल नहीं किया जाता। extended_entities सेक्शन में मौजूद media ऑब्जेक्ट, संरचना के हिसाब से entities सेक्शन में शामिल media ऑब्जेक्ट के समान है। पोस्ट्स के साथ केवल एक ही प्रकार का मीडिया संलग्न किया जा सकता है। फ़ोटो के लिए अधिकतम चार फ़ोटो संलग्न की जा सकती हैं। वीडियो और GIFs के लिए, केवल एक संलग्न किया जा सकता है। चूँकि extended_entities सेक्शन में मीडिया type मेटाडेटा मीडिया प्रकार (‘photo’, ‘video’ या ‘animated_gif’) को सही रूप से दर्शाता है, और अधिकतम 4 फ़ोटो का समर्थन करता है, इसलिए यह नेटिव मीडिया के लिए पसंदीदा मेटाडेटा स्रोत है।

उदाहरण पोस्ट्स और JSON पेलोड

नीचे कुछ उदाहरण पोस्ट्स और उनसे संबंधित entities मेटाडेटा दिए गए हैं। चार नेटिव फ़ोटो वाला पोस्ट हैशटैग, यूज़र मेंशन, कैशटैग, URL और चार नेटिव फ़ोटो वाला पोस्ट:
इस पोस्ट का entities अनुभाग यहाँ दिया गया है:
नीचे दिए गए इस ‘extended’ पेलोड में ही आपको चार (अधिकतम) मूल फ़ोटो मिलेंगी। ध्यान दें कि array में पहली फ़ोटो वही है, जो non-extended X entities सेक्शन में शामिल एकल फ़ोटो के समान है। फ़ोटो के लिए media मेटाडेटा की संरचना entities और extended_entities दोनों सेक्शनों में एक जैसी है। यहाँ इस पोस्ट के लिए extented_entities सेक्शन दिया गया है:

नेटिव वीडियो वाली पोस्ट

नीचे वीडियो वाली इस पोस्ट के लिए विस्तारित एंटिटीज़ मेटाडेटा दिया गया है:
जब कोई विज्ञापनदाता वीडियो प्लेबैक को केवल X के स्वामित्व और संचालन वाले प्लेटफ़ॉर्म तक सीमित करने का विकल्प चुनता है, तो video_info ऑब्जेक्ट को additional_media_info ऑब्जेक्ट से बदल दिया जाएगा। additional_media_info में प्रकाशक द्वारा दी गई अतिरिक्त मीडिया जानकारी होगी, जैसे title, description और embeddable flag। जब embeddable=false होता है, तो वीडियो सामग्री केवल X के आधिकारिक क्लाइंट्स पर उपलब्ध होती है। इस स्थिति में, payload में दिए गए सभी वीडियो URL X-आधारित होंगे, ताकि उपयोगकर्ता लिंक पर क्लिक करके वीडियो को X के स्वामित्व वाले प्लेटफ़ॉर्म पर खोल सके। यहाँ एक उदाहरण दिया गया है कि इस स्थिति में विस्तारित एंटिटीज़ ऑब्जेक्ट कैसा दिखेगा:
जैसा कि ऊपर बताया गया है, यहाँ entities अनुभाग है, जिसमें type ग़लती से ‘photo’ पर सेट है। फिर भी, ‘video’ और ‘animated_gif’ सहित सभी मूल मीडिया प्रकारों के लिए extended_entities अनुभाग को प्राथमिकता दी जाती है।

एक एनिमेटेड GIF वाला पोस्ट

नीचे एक एनिमेटेड GIF वाले इस पोस्ट के लिए विस्तारित एंटिटीज़ metadata दिया गया है:

Native Enriched उदाहरण पेलोड्स

पोस्ट

पोस्ट का जवाब

विस्तृत पोस्ट

extended_entitites सहित पोस्ट

रीट्वीट

Quote Tweet

रीट्वीट किया हुआ Quote Tweet

Enterprise Activity Streams डेटा ऑब्जेक्ट्स

क्या आप यह जानना चाहते हैं कि Activity Streams डेटा फ़ॉर्मैट, X API v2 फ़ॉर्मैट से कैसे मैप होता है?
हमारी तुलना मार्गदर्शिका देखें: Activity Streams की X API v2 से तुलना
कृपया ध्यान दें: enterprise data APIs के लिए Enriched Native फ़ॉर्मैट का उपयोग करने की कड़ी अनुशंसा की जाती है। 
  • Enriched Native फ़ॉर्मैट में 2017 से जोड़ा गया सारा नया मेटाडेटा शामिल है, जैसे poll metadata, और reply_count तथा quote_count जैसे अतिरिक्त मेट्रिक्स।
  • Activity Streams फ़ॉर्मैट को 2017 के character update के बाद से नए मेटाडेटा या enrichments के साथ अपडेट नहीं किया गया है।

Activity ऑब्जेक्ट

Activity Streams, Gnip द्वारा बनाया गया X के मूल डेटा फ़ॉर्मैट का एक ऑब्जेक्ट स्कीमा रूपांतरण है, जिसे तीसरे पक्ष के यहाँ वर्णित Activity Base Schema का उपयोग करके पोस्ट डेटा और अन्य सोशल मीडिया डेटा के ‘फ़ॉर्मैट को सामान्यीकृत’ करने के लिए बनाया गया था। पोस्ट्स को activity streams schema में सामान्यीकृत किया जाता है, जिसमें note, person, place और service ऑब्जेक्ट type nested objects के रूप में शामिल होते हैं।  पोस्ट्स में Retweets के लिए, या twitter_quoted_status, long_object सहित अन्य nested पोस्ट activity ऑब्जेक्ट्स भी हो सकते हैं। बेस-लेवल ऑब्जेक्ट type “activity”, native enriched format के पोस्ट बेस-लेवल ऑब्जेक्ट के समान है।  activity streams फ़ॉर्मैट में उदाहरण payloads यहाँ मिल सकते हैं।

डेटा शब्दकोश

नीचे इन ‘root-level’ “activity” विशेषताओं के लिए डेटा शब्दकोश दिया गया है, साथ ही चाइल्ड ऑब्जेक्ट डेटा शब्दकोशों के लिंक भी दिए गए हैं.

अतिरिक्त पोस्ट विशेषताएँ

अप्रचलित विशेषताएँ

नेस्टेड पोस्ट activity obejcts

कई मामलों में, किसी पोस्ट ऑब्जेक्ट में अन्य नेस्टेड पोस्ट्स शामिल होते हैं। यदि आप नेस्टेड ऑब्जेक्ट्स के साथ काम कर रहे हैं, तो उस JSON payload में कई ऑब्जेक्ट्स होंगे, और प्रत्येक पोस्ट ऑब्जेक्ट में अपने ऑब्जेक्ट्स भी हो सकते हैं। रूट-लेवल ऑब्जेक्ट में की गई कार्रवाई के type की जानकारी होगी, यानी यह रीट्वीट है या Quote Tweet, और इसमें साझा की जा रही ‘original’ पोस्ट का वर्णन करने वाला एक ऑब्जेक्ट भी हो सकता है। Extended Posts में एक नेस्टेड extended ऑब्जेक्ट शामिल होगा, जो 140 वर्णों से अधिक सामग्री को समाहित करता है; इसका उपयोग 2017 में अपडेट किए जाने पर breaking changes को रोकने के लिए किया गया था। प्रत्येक नेस्टेड ऑब्जेक्ट dictionary का वर्णन नीचे किया गया है। रीट्वीट्स रीट्वीट्स के Activity Streams प्रारूप में type “activity” और verb “note” वाला एक नेस्टेड ऑब्जेक्ट शामिल होता है, जो रीट्वीट की जा रही मूल पोस्ट को दर्शाता है।
X उद्धृत स्टेटस Activity Streams प्रारूप में एम्बेड किए गए Quote Tweets { "id": "tag:search.x.com,2005:222222222222", "objectType": "activity", "verb": "post", "body": "Quoting a Tweet: https://t.co/mxiFJ59FlB", "actor": { "displayName": "TheQuoter2" }, "object": { "objectType": "note", "id": "object:search.x.com,2005:111111111", "summary": "https://t.co/mxiFJ59FlB" }, "twitter_entities": {}, "twitter_extended_entities": {}, "gnip": {}, "twitter_quoted_status": { "id": "tag:search.x.com,2005:111111111", "objectType": "activity", "verb": "post", "body": "console.log('Happy birthday, JavaScript!');", "actor": { "displayName": "TheOriginalTweeter" }, "object": { "objectType": "note", "id": "object:search.x.com,2005:111111111" }, "twitter_entities": {} } } रीट्वीट किया गया Quote Tweet:

Long ऑब्जेक्ट

extended_tweet का Activity Streams प्रारूप

Actor ऑब्जेक्ट

Actor ऑब्जेक्ट में X User खाते का metadata शामिल होता है, जो उस activity को बनाने वाले X User का वर्णन करता है।

डेटा शब्दकोश

अब समर्थित नहीं रहने वाली (deprecated) विशेषताएँ

उदाहरण:

Location ऑब्जेक्ट

Location ऑब्जेक्ट, X अकाउंट स्तर पर सेट किए गए actor ऑब्जेक्ट के भीतर या gnip object के profileLocations ऑब्जेक्ट के भीतर मौजूद हो सकते हैं। Location ऑब्जेक्ट का place ऑब्जेक्ट type होता है और इनमें नाम, पता या geo निर्देशांक हो सकते हैं। Location ऑब्जेक्ट, native enriched format में Geo के समान होते हैं।

स्थान डेटा शब्दकोश

profileLocations व्युत्पन्न ऑब्जेक्ट्स

उदाहरण

X entities object

Activity Streams प्रारूप के लिए, twitter_entities वही प्रारूप और डेटा शब्दकोश है जो नेटिव enriched प्रारूप में यहाँ entities object में दिखाया गया है।

उदाहरण:

X विस्तारित entities ऑब्जेक्ट

Activity streams प्रारूप के लिए, twitter_extended_entities का प्रारूप और डेटा शब्दकोश वही है जो मूल enriched प्रारूप में extended_entities ऑब्जेक्ट यहाँ दिखाया गया है।

उदाहरण:

Gnip ऑब्जेक्ट

Activity Streams प्रारूप में gnip ऑब्जेक्ट में सक्रिय enrichments द्वारा जोड़ा गया metadata होता है, साथ ही activity के लिए लागू matching rules का संकेत भी शामिल होता है।

डेटा शब्दकोश

उदाहरण:

Activity Streams पेलोड के उदाहरण

पोस्ट गतिविधि
रिप्लाई पोस्ट की गतिविधि
long_object सहित पोस्ट गतिविधि
twitter_extended_entities सहित पोस्ट गतिविधि
रीट्वीट गतिविधि
Quote Tweet गतिविधि
रीट्वीट किए गए Quote Tweet की गतिविधि

Tweet मेटाडेटा टाइमलाइन

इस पेज पर जाएं परिचय मुख्य अवधारणाएँ X समयरेखा फ़िल्टरिंग के सुझाव अगले चरण

परिचय**

मूल रूप से, X एक सार्वजनिक, रीयल-टाइम और वैश्विक संचार नेटवर्क है। 2006 से, X का विकास उपयोगकर्ताओं के इस्तेमाल के पैटर्न और प्रचलनों, साथ ही नए प्रोडक्ट फीचर्स और सुधारों, दोनों से प्रेरित रहा है। यदि आप ऐतिहासिक शोध के लिए X डेटा का उपयोग कर रहे हैं, तो इस विकास-क्रम की समयरेखा को समझना डेटा आर्काइव से रुचिकर पोस्ट्स खोजने के लिए महत्वपूर्ण है। X की शुरुआत एक सरल SMS मोबाइल ऐप के रूप में हुई थी, और समय के साथ यह एक व्यापक संचार प्लेटफ़ॉर्म बन गया। ऐसा प्लेटफ़ॉर्म जिसमें APIs का पूरा सेट उपलब्ध है। APIs हमेशा से X नेटवर्क का एक प्रमुख स्तंभ रही हैं। पहली API, X के लॉन्च होने के तुरंत बाद ही सार्वजनिक कर दी गई थी। जब 2009 में पहली बार पोस्ट्स में geo-tagging पेश की गई, तो इसे एक Geo API के माध्यम से उपलब्ध कराया गया (और बाद में किसी पोस्ट को ‘geo-tag’ करने की सुविधा X.com user-interface में एकीकृत कर दी गई)। आज, X की APIs उस दो-तरफ़ा संचार नेटवर्क को शक्ति देती हैं, जो ब्रेकिंग समाचार और जानकारी साझा करने का एक प्रमुख स्रोत बन चुका है। इस वैश्विक, रीयल-टाइम संचार चैनल के ऊपर निर्माण करने की संभावनाएँ अनंत हैं। X दो ऐतिहासिक APIs उपलब्ध कराता है जो सार्वजनिक रूप से उपलब्ध हर पोस्ट तक पहुँच प्रदान करती हैं: Historical PowerTrack और Full-Archive Search API। दोनों APIs operators का एक सेट उपलब्ध कराती हैं, जिनका उपयोग रुचिकर पोस्ट्स को query करने और एकत्र करने के लिए किया जाता है। ये operators हर पोस्ट से जुड़े कई तरह के attributes पर match करते हैं—ऐसे सैकड़ों attributes पर, जैसे पोस्ट का text content, author का account name, और पोस्ट में साझा किए गए links। पोस्ट्स और उनके attributes को JSON में encode किया जाता है, जो text-based data interchange का एक सामान्य format है। इसलिए, जैसे-जैसे नए फीचर्स जोड़े गए, नए JSON attributes भी सामने आए, और आम तौर पर उन attributes पर match करने के लिए नए API operators भी पेश किए गए। यदि आपके use-case में X पर दुनिया ने क्या कहा है, इसे सुनने की आवश्यकता शामिल है, तो आप जितना बेहतर यह समझेंगे कि operators के लिए match करने योग्य JSON metadata कब उपलब्ध होना शुरू हुआ, आपके historical PowerTrack filters उतने ही अधिक प्रभावी होंगे। अब, हम कुछ प्रमुख अवधारणाओं का परिचय देंगे, जो यह समझने की पृष्ठभूमि तैयार करती हैं कि पोस्ट metadata में हुए updates आपकी रुचि के data signal को खोजने को कैसे प्रभावित करते हैं।

मुख्य अवधारणाएँ**

उपयोगकर्ता-परंपराओं से X फर्स्ट-क्लास ऑब्जेक्ट्स तक

X उपयोगकर्ताओं ने स्वाभाविक रूप से X नेटवर्क पर संचार के नए पैटर्न विकसित किए, जो अब बुनियादी बन चुके हैं। इसका एक प्रमुख उदाहरण है हैशटैग, जिसका अब लगभग सभी सोशल नेटवर्क्स पर व्यापक रूप से उपयोग होता है। हैशटैग बातचीतों और विषयों को व्यवस्थित करने के एक तरीके के रूप में सामने आए। ऐसे नेटवर्क पर जहाँ हर दिन सैकड़ों मिलियन संदेश होते हैं, रुचिकर पोस्ट्स खोजने के लिए टूल्स बहुत महत्वपूर्ण होते हैं, और हैशटैग एक बुनियादी तरीका बन गए। जल्द ही, जैसे-जैसे हैशटैग का उपयोग बढ़ा, उन्हें X से आधिकारिक मान्यता और समर्थन भी मिल गया। जब हैशटैग एक ‘फर्स्ट-क्लास’ ऑब्जेक्ट बन गए, तो इसका कई स्तरों पर असर पड़ा। इसका मतलब था कि X.com उपयोगकर्ता इंटरफ़ेस में हैशटैग क्लिक करने योग्य और खोजने योग्य हो गए। इसका यह भी मतलब था कि हैशटैग, @mentions, संलग्न मीडिया, स्टॉक सिंबल्स, और साझा लिंक के साथ X entities परिवार का हिस्सा बन गए। इन entities को सुविधाजनक रूप से पहले से पार्स किए गए JSON array में encode किया जाता है, जिससे डेवलपर्स के लिए उन्हें process, scan, और store करना आसान हो जाता है। रीट्वीट, उपयोगकर्ता-आधारित परंपराओं के आधिकारिक ऑब्जेक्ट्स में बदलने का एक और उदाहरण हैं। Retweeting, सामग्री को दूसरों तक ‘forward’ करने के एक तरीके के रूप में उभरा। इसकी शुरुआत किसी पोस्ट को मैन्युअली copy/paste करके और उसके आगे “RT @” pattern जोड़ने से हुई। बाद में इस प्रक्रिया को एक नए रीट्वीट button के ज़रिए automated कर दिया गया, जो नए JSON metadata के साथ आया। इसी तरह ‘आधिकारिक’ रीट्वीट का जन्म हुआ। अन्य उदाहरणों में ‘mentions’, media और web links साझा करना, और अपनी पोस्ट के साथ location साझा करना शामिल हैं। इन प्रत्येक उपयोग-पैटर्न के परिणामस्वरूप x.com पर नए उपयोगकर्ता-इंटरफ़ेस features, नया supporting JSON, और इस तरह पोस्ट्स पर match करने के नए तरीके सामने आए। पोस्ट के इन सभी बुनियादी attributes के आधार पर match करने के लिए PowerTrack Operators विकसित किए गए।

पोस्ट मेटाडेटा, परिवर्तनशीलता, अपडेट, और वर्तमानता

हालाँकि पोस्ट संदेशों की लंबाई वर्णों की एक निश्चित सीमा तक हो सकती है, किसी पोस्ट का JSON विवरण 100 से अधिक एट्रिब्यूट्स से मिलकर बना होता है। इनमें यह जानकारी शामिल होती है कि पोस्ट किसने किया, किस समय किया, क्या यह एक मूल पोस्ट है या रीट्वीट, और हैशटैग, मेंशन्स, तथा साझा किए गए लिंक जैसे प्रथम-श्रेणी ऑब्जेक्ट्स की एक सरणी। पोस्ट करने वाले खाते के लिए एक User (या Actor) ऑब्जेक्ट होता है, जिसमें कई एट्रिब्यूट्स होते हैं जो उपयोगकर्ता की Profile और खाते से जुड़े अन्य मेटाडेटा प्रदान करते हैं। प्रोफ़ाइल में एक संक्षिप्त जीवनी-विवरण, home location (मुक्त-रूप टेक्स्ट), पसंदीदा भाषा, और एक वैकल्पिक वेबसाइट लिंक शामिल होते हैं। कुछ खाता मेटाडेटा कभी नहीं बदलते (उदा. संख्यात्मक user ID और created date), कुछ समय के साथ धीरे-धीरे बदलते हैं, जबकि अन्य एट्रिब्यूट्स अधिक बार बदलते हैं। लोग नौकरी बदलते हैं और स्थानांतरित होते हैं। कंपनियाँ अपनी जानकारी अपडेट करती हैं। जब आप ऐतिहासिक पोस्ट्स एकत्र कर रहे हों, तो यह समझना महत्वपूर्ण है कि कुछ मेटाडेटा पोस्ट किए जाने के समय जैसा था, जबकि अन्य मेटाडेटा क्वेरी सबमिट किए जाने के समय जैसा होता है।  सभी ऐतिहासिक APIs में, उपयोगकर्ता की प्रोफ़ाइल विवरण, डिस्प्ले नेम, और प्रोफ़ाइल ‘home’ एट्रिब्यूट्स क्वेरी के समय के मानों के अनुसार अपडेट हो जाते हैं।

“नेटिव” मीडिया

X.com और X के मोबाइल ऐप्स में, एक बटन पर क्लिक करके और अपनी फ़ोटो गैलरी ब्राउज़ करके पोस्ट में फ़ोटो और वीडियो जोड़े जा सकते हैं। अब जब इन्हें मूलभूत कार्रवाइयों के रूप में एकीकृत कर दिया गया है, तो इस तरह साझा किए गए वीडियो और फ़ोटो को ‘नेटिव’ मीडिया कहा जाता है। कई क्वेरी Operators इन ‘नेटिव’ संसाधनों के साथ काम करते हैं, जिनमें has:videos, has:images, और has:media शामिल हैं। ये केवल उस मीडिया सामग्री से मेल खाते हैं जिसे X की सुविधाओं के माध्यम से साझा किया गया हो। X प्लेटफ़ॉर्म के बाहर होस्ट किए गए अन्य मीडिया से मिलान करने के लिए, आपको ऐसे Operators का उपयोग करना होगा जो URL metadata पर मिलान करते हैं। इसलिए, Historical PowerTrack और Full-Archive Search के उत्पाद विवरणों में जाने से पहले, आइए देखें कि X एक उत्पाद और प्लेटफ़ॉर्म के रूप में समय के साथ कैसे विकसित हुआ। X समयरेखा नीचे आपको X की एक चुनी हुई समयरेखा मिलेगी। इनमें से अधिकांश X अपडेट्स ने किसी न किसी रूप में उपयोगकर्ता व्यवहार, पोस्ट JSON सामग्री, क्वेरी Operators, या इन तीनों को मूल रूप से प्रभावित किया। API प्लेटफ़ॉर्म के रूप में X को देखें, तो निम्नलिखित घटनाओं ने किसी न किसी तरह उन JSON payloads को प्रभावित किया जिनका उपयोग पोस्ट्स को encode करने के लिए किया जाता है। बदले में, यही JSON विवरण इस बात को प्रभावित करते हैं कि X के historical APIs उनका मिलान कैसे करते हैं। ध्यान दें कि यह समयरेखा सामान्यतः सटीक है, लेकिन संपूर्ण नहीं है।

2006

  • अक्टूबर
    • @replies एक प्रचलित परंपरा बन जाता है।
    • cashtagsपहलीबारसामनेआतेहैं,लेकिनस्टॉकटिकरउल्लेखोंकेलिएइनकाउपयोग2009कीशुरुआततकआमनहींहोता।cashtags पहली बार सामने आते हैं, लेकिन स्टॉक टिकर उल्लेखों के लिए इनका उपयोग 2009 की शुरुआत तक आम नहीं होता। Cashtags जून 2012 में क्लिक किए जा सकने वाले/खोजे जा सकने वाले लिंक बन गए।
  • नवंबर - Favorites पेश किए गए।

2007

  • जनवरी - in_reply_to मेटाडेटा और UI reply button के साथ @replies एक प्रथम-श्रेणी ऑब्जेक्ट बन जाते हैं।
  • अप्रैल - रीट्वीट एक प्रचलित परंपरा बन जाते हैं।
  • अगस्त - #hashtags पोस्ट्स को खोजने और व्यवस्थित करने के लिए एक प्रमुख साधन के रूप में उभरते हैं।

2009

  • फ़रवरी - स्टॉक टिकर प्रतीकों पर चर्चा के लिए $cashtags एक आम प्रचलन बन गए।
  • मई - पोस्ट बॉडी के आगे “Via @” जोड़कर रीट्वीट ‘beta’ पेश किया गया।
  • जून - सत्यापित खाते शुरू किए गए।
  • अगस्त - “RT @” पैटर्न और नए retweet_status मेटाडेटा के साथ रीट्वीट एक प्रथम-श्रेणी ऑब्जेक्ट बन गए।
  • अक्टूबर - सूची सुविधा लॉन्च की गई।
  • नवंबर - Post Geotagging API लॉन्च किया गया, जिससे उपयोगकर्ताओं को तृतीय-पक्ष ऐप्स के ज़रिए स्थान साझा करने का पहला तरीका मिला।

2010

  • जून - पोस्ट्स की जियो-टैगिंग के लिए X Places पेश किया गया।
  • अगस्त - वेबसाइटों के लिए पोस्ट बटन लॉन्च किया गया। इससे लिंक शेयर करना आसान हो गया।

2011

  • मई - Follow बटन पेश किया गया, जिससे वेबसाइटों से जुड़े अकाउंट्स को फ़ॉलो करना आसान हो गया।
  • अगस्त - नेटिव फ़ोटो पेश की गईं।

2012

  • जून - $Cashtags क्लिक करने और खोजने योग्य लिंक बन जाते हैं।

2014

2015

  • अप्रैल - X के ‘पोस्ट’ यूज़र-इंटरफ़ेस डिज़ाइन में बदलाव के कारण कम पोस्ट्स जियो-टैग की गईं।
  • अक्टूबर - X Polls पेश किए गए. शुरुआत में, Polls में 24 घंटे की मतदान अवधि के साथ दो विकल्प समर्थित थे। नवंबर में, Polls ने 5 मिनट से सात दिनों तक की मतदान अवधि के साथ चार विकल्पों का समर्थन करना शुरू किया। Poll metadata फ़रवरी 2017 में उपलब्ध कराया गया (केवल enriched native format में)।

2016

2017

  • फ़रवरी - पोस्ट मेटाडेटा में X Poll मेटाडेटा शामिल किया गया (केवल enriched native format में)।
  • अप्रैल - ‘Simplified Replies’ पेश किया गया, जिसमें replied-to-accounts को 140 अक्षरों की सीमा में नहीं गिना जाता था (“dmw140, part 2”)।
2018
  • मई - GDPR updates user.time_zone को null पर सेट किया गया, user.utc_offset को null पर सेट किया गया, user.profile_background_image_url को default value पर सेट किया गया
  • जून - quoteTweet formatting changes के फ़ॉर्मैटिंग बदलावों को अपडेट करना
2022
  • 29 सितंबर - पोस्ट्स को संपादित करने की सुविधा एक छोटे परीक्षण समूह के लिए जारी की गई। जहाँ प्रासंगिक हो, संपादित पोस्ट मेटाडेटा को पोस्ट ऑब्जेक्ट में जोड़ा गया। इसमें edit_history और edit_controls ऑब्जेक्ट्स शामिल हैं। यह मेटाडेटा उन पोस्ट्स के लिए वापस नहीं किया जाएगा जो editable functionality जोड़े जाने से पहले बनाए गए थे। इन मेटाडेटा के लिए कोई संबंधित Operators नहीं हैं। पोस्ट संपादन कैसे काम करता है, इसके बारे में अधिक जानने के लिए Edit Posts fundamentals देखें
फ़िल्टरिंग सुझाव X की उस समयरेखा से परिचित होना, जिसमें यह बताया गया है कि नई सुविधाएँ कब और कैसे जोड़ी गईं, आपको अधिक प्रभावी queries बनाने में मदद कर सकता है। यहाँ query से आशय एक filter या rule है, जिसे X historical APIs द्वारा पोस्ट archive पर लागू किया जाता है, और पोस्ट JSON पर मिलान करने के लिए PowerTrack Operators का उपयोग किया जाता है। इसका एक उदाहरण lang: Operator है, जिसका उपयोग किसी निर्दिष्ट भाषा में पोस्ट्स का मिलान करने के लिए किया जाता है। X एक language classification service प्रदान करता है (जो 50 से अधिक भाषाओं का समर्थन करती है), और X APIs हर पोस्ट के लिए जनरेट किए गए JSON में यह मेटाडेटा उपलब्ध कराते हैं। इसलिए, यदि कोई पोस्ट Spanish में लिखी गई है, तो “lang” JSON attribute को “es” पर सेट किया जाता है। इसलिए, यदि आप lang:es clause के साथ एक filter बनाते हैं, तो वह केवल उन पोस्ट संदेशों से मेल खाएगा जिन्हें Spanish के रूप में वर्गीकृत किया गया है। यह समयरेखा जानकारी प्राप्त पोस्ट डेटा की बेहतर व्याख्या करने में भी मदद कर सकती है। मान लीजिए आप 2008 और 2012 Summer Olympics के बारे में सामग्री साझा किए जाने का अध्ययन कर रहे थे। यदि आप केवल is:retweet Operator लागू करते, तो 2008 में कोई डेटा मेल नहीं खाता। हालांकि, 2012 के लिए संभवतः लाखों रीट्वीट होते। इससे आप संभावित रूप से गलत निष्कर्ष निकाल सकते थे कि 2008 में रीट्वीट उपयोगकर्ताओं की प्रचलित पद्धति नहीं थे, या बस किसी ने उन Olympics के बारे में Retweet नहीं किया। चूँकि रीट्वीट 2009 में first-class object बन गए, इसलिए 2008 में उनकी पहचान करने में मदद के लिए आपको ”RT @” rule clause जोड़ना होगा। रीट्वीट और पोस्ट language classification, दोनों ही पोस्ट attributes के उदाहरण हैं जिनका लंबा इतिहास है और जिनसे जुड़ी कई product details हैं। नीचे हम इनके साथ-साथ अन्य attribute classes के बारे में भी अधिक विस्तार से चर्चा करेंगे, जो X Data का मिलान करने और उसे समझने के लिए महत्वपूर्ण हैं।

गलत नेगेटिव की पहचान

फ़िल्टर लिखते समय एक महत्वपूर्ण बात यह समझना है कि जिन metadata पर Operators match करते हैं, उन सभी की “born on” तारीखें होती हैं। अगर आप किसी ऐसे Operator के साथ फ़िल्टर बनाते हैं जो उस metadata पर काम करता है जिसे पोस्ट किए जाने के बाद जोड़ा गया था, तो false negative मिलेगा। उदाहरण के लिए, मान लें कि आप उन सभी पोस्ट्स में रुचि रखते हैं जिनमें ‘snow’ का उल्लेख हो और जिनमें कोई वीडियो साझा किया गया हो। अगर आप has:videos Operator के साथ एक rule बनाते हैं, जो native वीडियो वाले पोस्ट्स पर match करता है, तो वह clause 2015 से पहले के किसी भी पोस्ट्स पर match नहीं करेगा। हालाँकि, X पर वीडियो साझा करना 2015 से बहुत पहले से आम था। उससे पहले, उपयोगकर्ता कहीं और host किए गए वीडियो के links साझा करते थे, लेकिन 2015 में X ने वीडियो शेयरिंग की नई सुविधाएँ सीधे platform में जोड़ दीं। अपनी रुचि के इन पुराने पोस्ट्स को खोजने के लिए, आप url:”youtube.com” जैसा कोई rule clause शामिल कर सकते हैं। ध्यान दें, Search APIs में metadata के ‘backfilled’ होने के कुछ उदाहरण हैं, जब उसका index फिर से बनाया गया। इसका एक अच्छा उदाहरण cashtagsहैं,जिनकाइस्तेमाल2009मेंstocksymbolsपरचर्चाकेलिएव्यापकरूपसेहोनेलगा।2015मेंcashtags हैं, जिनका इस्तेमाल 2009 में stock symbols पर चर्चा के लिए व्यापक रूप से होने लगा। 2015 में cashtag operator शुरू होने के बाद Search index फिर से बनाया गया, और इस प्रक्रिया में 2006 की शुरुआती Post bodies सहित सभी Post bodies से symbol entity निकाली गई, जबकि उस समय $ का उपयोग मुख्य रूप से slang के लिए होता था; “I hope it nownow $oon!”.

आपके उपयोग-प्रकरण के लिए महत्वपूर्ण पोस्ट विशेषताओं की पहचान करना और उन पर फ़िल्टर करना

कुछ मेटाडेटा, जैसे X खाते की संख्यात्मक ID, शुरू से ही मौजूद रहे हैं (और ऐसे खाता मेटाडेटा का उदाहरण हैं जो कभी नहीं बदलते)। अन्य मेटाडेटा 2006 में X की शुरुआत के काफी समय बाद जोड़े गए। नए मेटाडेटा के उदाहरणों में Retweets मेटाडेटा, पोस्ट लोकेशन, URL शीर्षक और विवरण, तथा ‘native’ मीडिया शामिल हैं। नीचे पोस्ट विशेषताओं के कुछ सबसे सामान्य प्रकार दिए गए हैं, जो X प्लेटफ़ॉर्म के इन अपडेट से बुनियादी रूप से प्रभावित हुए हैं। इनके लिए फ़िल्टरिंग/मैचिंग व्यवहार, अधिकांश मामलों में, इस बात पर निर्भर करता है कि कौन-सा ऐतिहासिक Post API इस्तेमाल किया जाता है। यह तय करने में मदद के लिए कि आपके शोध और उपयोग-प्रकरण के लिए कौन-सा उत्पाद सबसे उपयुक्त है, नीचे दिए गए विशेषता-विवरणों में उच्च-स्तरीय उत्पाद जानकारी शामिल है।

X प्रोफ़ाइलें

चूंकि X मूल रूप से एक वैश्विक, रीयल-टाइम संचार चैनल है, इसलिए पोस्ट डेटा पर शोध में अक्सर इस बात पर ज़ोर होता है कि संवाद कौन कर रहा है। अक्सर यह जानना उपयोगी होता है कि कोई X उपयोगकर्ता किस स्थान को अपना घर बताता है। कई बार किसी खाते की बायो में रुचियों और शौकों का उल्लेख आपको दिलचस्प पोस्ट्स तक पहुँचा सकता है। रुचि वाले खातों से आने वाली पोस्ट्स पर नज़र रखना भी बहुत आम है। इन सभी उपयोग-मामलों में प्रोफ़ाइल विशेषताएँ अहम होती हैं। X पर हर खाते की एक प्रोफ़ाइल होती है, जिसमें X @handle, डिस्प्ले नाम, एक छोटी बायो, गृह स्थान (उपयोगकर्ता द्वारा दर्ज किया गया मुक्त-रूप पाठ), फ़ॉलोअर्स की संख्या और कई अन्य प्रकार का मेटाडेटा शामिल होता है। कुछ विशेषताएँ कभी नहीं बदलतीं, जैसे संख्यात्मक उपयोगकर्ता ID और खाता कब बनाया गया था। अन्य विशेषताएँ आमतौर पर दिन-प्रतिदिन, सप्ताह-दर-सप्ताह, या महीने-दर-महीने बदलती रहती हैं, जैसे किए गए पोस्ट्स की संख्या, फ़ॉलो किए जा रहे खातों की संख्या, और फ़ॉलोअर्स की संख्या। खाते की कुछ अन्य विशेषताएँ भी किसी भी समय बदल सकती हैं, लेकिन वे अपेक्षाकृत कम बार बदलती हैं: डिस्प्ले नाम, गृह स्थान, और बायो। हर पोस्ट के JSON payload में पोस्ट के लेखक का खाता प्रोफ़ाइल मेटाडेटा शामिल होता है। यदि वह एक Retweet है, तो उसमें उस खाते का प्रोफ़ाइल मेटाडेटा भी शामिल होता है जिसने मूल पोस्ट किया था। किसी पोस्ट के प्रोफ़ाइल मेटाडेटा की परिवर्तनशीलता पूरी तरह इस बात पर निर्भर करती है कि कौन-सा ऐतिहासिक प्रोडक्ट उपयोग किया गया है। Search APIs ऐतिहासिक पोस्ट्स को पुनर्प्राप्ति के समय जैसी प्रोफ़ाइल सेटिंग्स होती हैं उनके साथ प्रस्तुत करती हैं। Historical PowerTrack में, प्रोफ़ाइल वैसी होती है जैसी पोस्ट किए जाने के समय थी, सिवाय 2011 से पहले के डेटा के। 2011 से पुरानी पोस्ट्स के लिए, प्रोफ़ाइल मेटाडेटा सितंबर 2011 की प्रोफ़ाइल स्थिति को दर्शाता है।

मूल पोस्ट और रीट्वीट

रीट्वीट इस बात का एक और उदाहरण हैं कि कैसे उपयोगकर्ताओं द्वारा अपनाई गई परंपराएँ आगे चलकर आधिकारिक ऑब्जेक्ट बन गईं। रीट्वीट करना, सामग्री को दूसरों तक ‘forward’ करने के एक तरीके के रूप में उभरा। इसकी शुरुआत एक मैन्युअल प्रक्रिया के रूप में हुई, जिसमें एक पोस्ट को कॉपी/पेस्ट किया जाता था और उसके आगे “RT @” पैटर्न जोड़ा जाता था। आखिरकार, इस प्रक्रिया को नए रीट्वीट बटन के ज़रिए स्वचालित कर दिया गया, साथ ही नया JSON मेटाडेटा भी जोड़ा गया। इस तरह ‘आधिकारिक’ रीट्वीट अस्तित्व में आया और रीट्वीट करने की क्रिया एक प्रथम-श्रेणी पोस्ट इवेंट बन गई। नए रीट्वीट बटन के साथ, नया मेटाडेटा भी पेश किया गया, जैसे मूल पोस्ट का पूरा payload। कोई पोस्ट मूल है या साझा की गई है, यह फ़िल्टरिंग के लिए एक सामान्य ‘switch’ है। कुछ मामलों में, केवल मूल सामग्री की ज़रूरत होती है। अन्य मामलों में, पोस्ट एंगेजमेंट सबसे महत्वपूर्ण होता है, इसलिए रीट्वीट अहम होते हैं। PowerTrack is:retweet Operator उपयोगकर्ताओं को रीट्वीट शामिल करने या बाहर रखने, दोनों की सुविधा देता है। अगर अगस्त 2009 से पहले का डेटा निकाला जा रहा है, तो उपयोगकर्ताओं को रीट्वीट मिलान (या गैर-मिलान) के लिए दो रणनीतियाँ अपनानी होंगी। अगस्त 2009 से पहले की अवधि के लिए, “@RT ” पैटर्न से मेल खाने की जाँच हेतु, पोस्ट संदेश की exact phrase matching के साथ जाँच करनी होती है। अगस्त 2009 के बाद की अवधि के लिए, is:retweet Operator उपलब्ध है।

पोस्ट भाषा वर्गीकरण

किसी पोस्ट को किस भाषा में लिखा गया है, यह आम रुचि का विषय है। पोस्ट की भाषा से उसके स्थान का अनुमान लगाने में मदद मिल सकती है, और विश्लेषण या प्रदर्शन के लिए अक्सर केवल एक विशिष्ट भाषा की आवश्यकता होती है। (X प्रोफ़ाइल्स में पसंदीदा भाषा की सेटिंग भी होती है।) किसी पोस्ट के भाषा वर्गीकरण के आधार पर फ़िल्टर करने के लिए, X के ऐतिहासिक प्रोडक्ट्स (Search API और Historical PowerTrack) काफ़ी अलग हैं। जब Search archive बनाया गया था, तब सभी पोस्ट्स में X का भाषा वर्गीकरण बैकफ़िल किया गया था। इसलिए lang: Operator पूरे पोस्ट archive के लिए उपलब्ध है। Historical PowerTrack में, X का भाषा वर्गीकरण मेटाडेटा archive में 26 मार्च 2013 से उपलब्ध है। 

पोस्ट्स का भू-संदर्भन

यह पता लगा पाना कि कोई पोस्ट कहाँ पोस्ट की गई थी (अर्थात, उसका भू-संदर्भन करना) कई उपयोग के मामलों में महत्वपूर्ण है। पोस्ट्स का भू-संदर्भन करने के तीन मुख्य तरीके हैं:
  • किसी पोस्ट के संदेश में भौगोलिक संदर्भ
  • उपयोगकर्ता द्वारा भू-टैग की गई पोस्ट्स
  • उपयोगकर्ता द्वारा सेट की गई अकाउंट प्रोफ़ाइल की ‘होम’ लोकेशन
पोस्ट संदेश में भौगोलिक संदर्भ
पोस्ट संदेश में भौगोलिक संदर्भों के आधार पर मिलान करना, हालांकि यह अक्सर सबसे चुनौतीपूर्ण तरीका होता है क्योंकि यह स्थानीय जानकारी पर निर्भर करता है, पूरे पोस्ट आर्काइव के लिए एक विकल्प है। यहाँ 2006 का एक भौगोलिक-संदर्भित मिलान उदाहरण दिया गया है, जो San Francisco क्षेत्र के लिए ‘golden gate’ फ़िल्टर पर आधारित है: https://x.com/biz/statuses/28311
उपयोगकर्ता द्वारा जियो-टैग की गई पोस्ट्स
नवंबर 2009 में X ने अपना Post Geotagging API पेश किया, जिससे पोस्ट्स को सटीक स्थान के साथ जियो-टैग करना संभव हुआ। जून 2010 में X ने X Places पेश किया, जो किसी स्थल, पड़ोस या शहर के स्तर के भौगोलिक क्षेत्र को दर्शाता है। लगभग 1-2% पोस्ट्स इनमें से किसी एक तरीके का उपयोग करके जियो-टैग की जाती हैं। उपलब्ध जियो-टैगिंग इतिहास इस बात पर निर्भर करता है कि आप कौन-सा Historical API उपयोग कर रहे हैं। Search APIs के साथ, कुछ Geo Operators का उपयोग करके पोस्ट्स का मिलान शुरू करने की क्षमता मार्च 2010 में उपलब्ध हुई, और अन्य के लिए फरवरी 2015 में। यदि आप Historical PowerTrack का उपयोग कर रहे हैं, तो जियो-रेफ़रेंसिंग 1 सितंबर 2011 से शुरू होती है। Historical PowerTrack archive बनाए जाने पर, इस तिथि से पहले की सभी जियो-टैगिंग को इसमें शामिल नहीं किया गया था।
उपयोगकर्ता द्वारा सेट किया गया अकाउंट प्रोफ़ाइल ‘home’ स्थान
सभी X उपयोगकर्ताओं के पास अपना प्रोफ़ाइल स्थान सेट करने का विकल्प होता है, जो उनके निवास स्थान को दर्शाता है। लाखों X उपयोगकर्ता यह जानकारी देते हैं, और इससे X Firehose में जियोडेटा की मात्रा काफ़ी बढ़ जाती है। यह स्थान मेटाडेटा एक गैर-मानकीकृत, उपयोगकर्ता-जनित, फ़्री-फ़ॉर्म स्ट्रिंग होता है। लगभग 30% अकाउंट्स में Profile Geo मेटाडेटा होता है, जिसे देश-स्तर तक रिज़ॉल्व किया जा सकता है। पोस्ट जियो की तरह, मिलान की विधियाँ और उपलब्ध समय-अवधियाँ इस बात पर निर्भर करती हैं कि आप कौन-सा Historical API उपयोग कर रहे हैं। Historical PowerTrack उपयोगकर्ताओं को इन फ़्री-फ़ॉर्म स्ट्रिंग्स पर अपना कस्टम मिलान आज़माने की सुविधा देता है। इस प्रक्रिया को आसान बनाने के लिए, X एक प्रोफ़ाइल जियो एनरिचमेंट भी प्रदान करता है, जो जहाँ संभव हो वहाँ जियोकोडिंग करता है और मानकीकृत मेटाडेटा तथा संबंधित Operators उपलब्ध कराता है। Profile Geo Operators, Historical PowerTrack और Search APIs दोनों में उपलब्ध हैं। Historical PowerTrack के साथ, यह Profile Geo मेटाडेटा जून 2014 से उपलब्ध है। Search APIs के साथ, यह मेटाडेटा फ़रवरी 2015 से उपलब्ध है। वेब पेज लिंक, फ़ोटो और वीडियो साझा करना हमेशा से X का एक बुनियादी उपयोग-मामला रहा है। अपने शुरुआती दौर में, इन सभी कार्रवाइयों के लिए पोस्ट संदेश में ही एक URL लिंक शामिल करना पड़ता था। 2011 में X ने अपने यूज़र इंटरफ़ेस में सीधे फ़ोटो साझा करने की सुविधा एकीकृत की। 2016 में नेटिव वीडियो जोड़े गए। इस इतिहास को देखते हुए, इस सामग्री के मिलान के लिए कई तरह के फ़िल्टरिंग Operators इस्तेमाल किए जाते हैं। कुछ Operators इस आधार पर मिलान करते हैं कि पोस्ट्स में साझा किए गए लिंक, फ़ोटो और वीडियो हैं या नहीं। साथ ही, क्योंकि X पर साझा किए जाने वाले ज़्यादातर URLs को पोस्ट के कम वर्ण इस्तेमाल करने के लिए छोटा कर दिया जाता है (उदाहरण के लिए, bitly या tinyurl जैसी सेवा द्वारा जनरेट किए गए), X ऐसे data enrichments उपलब्ध कराता है जो एक पूरा, expanded URL जनरेट करते हैं, जिस पर मिलान किया जा सकता है। उदाहरण के लिए, अगर आप उन पोस्ट्स का मिलान करना चाहते हैं जिनमें X और प्रारंभिक चेतावनी प्रणालियों पर चर्चा करने वाले लिंक हों, तो ‘severe weather communication’ का संदर्भ देने वाला फ़िल्टर इस http://bit.ly/1XV1tG4 URL वाले पोस्ट से मेल खाएगा। मार्च 2012 में, expanded URL enrichment पेश किया गया। इससे पहले, पोस्ट payloads में केवल वही URL शामिल होता था जो उपयोगकर्ता ने दिया हो। इसलिए, अगर उपयोगकर्ता ने छोटा किया हुआ URL शामिल किया हो, तो रुचि के (expanded) URLs पर मिलान करना मुश्किल हो सकता है। Historical PowerTrack और Search APIs, दोनों में, ये metadata मार्च 2012 से उपलब्ध हैं। जुलाई 2016 में, enhanced URL enrichment पेश किया गया। यह उन्नत संस्करण पोस्ट payload में वेबसाइट का HTML title और description देता है, साथ ही उन पर मिलान करने के लिए Operators भी उपलब्ध कराता है। Historical PowerTrack के साथ, ये metadata जुलाई 2016 से उपलब्ध होने लगते हैं। Search APIs के साथ, ये metadata दिसंबर 2014 से दिखने लगते हैं। सितंबर 2016 में X ने ‘native attachments’ पेश किए, जिनमें अंत में जोड़ा गया साझा लिंक 140 पोस्ट वर्ण सीमा में नहीं गिना जाता। दोनों URL enrichments अब भी इन साझा लिंक पर लागू होते हैं। URL filtering से जुड़े अन्य product-specific विवरणों के लिए, अधिक जानकारी हेतु संबंधित लेख देखें।