駅へのアクセスと住宅。そのつながりを文章から読む

二つの話題を結ぶ問いから始める

駅への行きやすさと周辺の住宅は、urbanplanningの文章でどのように結び付けられているでしょうか。コミュニティを調べる担当者は、このような具体的な問いから読み始められます。Subreddit DataはRedditの独立した過去アーカイブAPIです。公式サービスでもリアルタイム配信でもありません。検索件数で全参加者の関心を順位付けするのではなく、取得できた文章の論点と選ばれた理由を説明するために使います。

例は https://api.subredditdata.com/v1/search?q=transit&subreddit=urbanplanning&limit=3 です。qは検索文、subredditは対象コミュニティ、limitは最大三件という上限を表します。三件の該当記録が必ずあるという意味ではありません。実際の返答を読み、駅への疑問、路線の提案、ニュースの引用を同じ種類の発言として扱ってよいか確認します。

投稿とコメント、どちらを比べるか

投稿は計画全体を説明し、コメントはその一部への返答だけを含むことがあります。投稿、コメント、両方を含む集合のどれを読むか先に決めます。必要ならkind=postまたはkind=commentを指定し、二つの検索でそろえてください。種類の違いが話題の違いに見えてしまうのを避けるためです。

手元の表に、検索ごとの条件を一行ずつ記録します。コミュニティ、検索語、記録の種類、UTCの日付、スコアの下限、ページの大きさ、読んだページ、取得時刻と結果を残すと、何を変えたか説明できます。同じコミュニティで別の話題を調べる際は検索語以外の条件をそろえます。ただし、条件の一致は代表性や網羅性を保証しません。

qはtitleとtextを検索します。複数の解析済み語は一致するフィールド内でAND条件となり、どれか一語だけの一致では足りません。一方、すべての語が両方のフィールドにある必要はありません。完全なフレーズ一致の保証でもありません。語を増やして結果が減っても、コミュニティの関心が低いと結論づけないでください。

駅周辺の住宅を二重に数えない

駅周辺の住宅についての文章は、交通と住宅の両方の検索に入るかもしれません。表ではこの重なりを示し、二人の独立した意見として数えないようにします。話題のラベルと判断理由は利用者が手元で付けるものです。APIが話題の割合、感情スコア、人口属性や統計的結論を提供するわけではありません。

記録はフラットな形式で、完全な会話ツリーではありません。parent_idやlink_idがあれば手元で関連付けられますが、親の記録や会話全体が取得できる保証はありません。元の文章、読み手の解釈、不明な文脈を分けて残します。情報が足りない場合は無理に分類せず、不明とする選択肢を用意してください。

次の一回を使う理由を決める

fromとtoはYYYY-MM-DD形式で、created_utcをUTC基準で絞り込みます。toは指定日の一日全体を含み、今日を選んだ場合も送信時刻で切りません。その日の記録がすべてあるという保証ではありません。_doc順は日時順、関連度順、スコア順ではなく、min_scoreも数値の下限を指定するだけです。

一回で最大100件、一つの検索条件で最大100ページという制限があります。許されたページをすべて読んでも、全履歴を取得した証明にはなりません。同じページ数は同じ読書量のルールであって、同じ収録率ではありません。保存した返答で実際の根拠を確認できますが、再検索して同じ記録が返るとは限りません。

transitの小さな返答を読んだ後は、housingを検索するか、次のページを見るか、保存済みの文章を読み直すか選びます。成功した取得は空でも一クレジット、手元のファイルの再読には新しいAPI呼び出しが不要です。キーのページでアクセスを準備し、ガイドで二つの検索を比較表にまとめてください。最後に、まだ答えられない問いを残すことも作業の成果です。