@ darashi

Japanese follows. 日本語はあとで。 This article is for the 14th day of [Nostr Advent Calendar 2024](https://adventar.org/calendars/10004) (relay blogging). The article for the 13th day was "[Open Sats 申請編](https://zenn.dev/konemono/articles/cb39fb7f302551)" (Applying for Open Sats) by mono-san. The article for the 14th day will be "[Nostrはじめました。](https://bewith.bz/?p=121)" (I started Nostr) by bro-san. # Thinking of Thingstr I've come up with an idea for Other Staff that I think is interesting (at least, for me), so I'm going to write about it. I actually wanted to show you the implementation and brag about it, but it's not solid enough to be implemented yet. The key idea is just “add a reaction to the WikiData ID”. ## WikiData There is a service called [WikiData](https://www.wikidata.org/). It is a knowledge base that provides structured data. You may be wondering what it is, but the important thing to understand here is that WikiData assigns identifiers to a fairly wide range of “objects” and “things”. So, if you can react to this, you can think of various applications just by thinking of it for a moment, right? For example, the anime series “There are too many losing heroines!” is assigned the ID `Q123819103`. The corresponding page is https://www.wikidata.org/wiki/Q123819103 . (NOTE: The canonical URI for entities on Wikidata is http://www.wikidata.org/entity/Q1142841. This is in accordance with Semantic Web conventions, and is not https, but http. Also, this URI does not necessarily match the actual address of the correspnding web page. Just an identifier. In most cases, it will redirect). ## What can wd do? For example, what about a website that records your anime viewing history? You can record what you want to watch with 👀, what you've already watched with ✅, and your favorites with ☆. You can also express your “likes” for production companies, staff, voice actors, etc. In this way, you can see what a particular user likes. This could be a movie, a book, a comic, an author, music, an idol group, a place, or food (Someone likes pork cutlet `Q1142841`). The fact that you can record everything in the same framework is what makes it interesting. ## What form of event should it be recorded as? There is probably room for discussion about how to record this information in a concrete way. The simplest way would be to use NIP-25's "Reactions to a website" kind:17 (a.k.a. Makibishi). How about something like this? ```json [ ["i", "wd:Q123819103", "http://www.wikidata.org/entity/Q123819103"], ] ``` Since NIP-73 has External Content IDs, it would be good if we could include WikiData here so that we could write `wd:Q123819103`. Actually, `isbn:` and other identifiers have already been defined, so it is possible to use the current NIP range to describe books (however, the authors do not have IDs. If we use WikiData as an ID, we can also describe reactions related to the author). Of course, it is not a matter of choosing one or the other, and it is also fine to add the ISBN tag at the same time as the WikiData tag for books. ## Search for recorded reactions So far, this is all very simple, but it would be inconvenient if we didn't include tags to mark subsets of reactions (for example, only those related to anime) so that we can query them together. When we try to create a site that is specialized for a certain purpose, we need to be able to extract the reactions that are necessary. On Wikidata, the predicate `wdt:P31` (instance of) is used to group together concepts that represent the same thing. For example, how about including this in the `l` tag? "There are too many losing heroines!" is a "Japanese television anime series (`Q63952888`)", so: ```json [ ["i", "wd:Q1142841", "http://www.wikidata.org/entity/Q1142841"], ["l", "wdt:P31 wd:Q63952888"] ] ``` UPDATE(2024-12-15): rnurachue-san suggested that `#l` or `#L` might be better for labeling (the first version used `#a`). I think that's a good idea, so I've updated the article. nostr:nevent1qgswamu0rsela0kwhj87p24ueapxdp04vzz7ar0pp6lfyq923t3l02cqyr9786635s60ra0f973nwv2sln2l74lqx4twdlgxfz2jgevpvsgtc9zwn6d However, when you think about creating an anime website, you may want to query both TV anime and anime films. This makes things more complicated. "Japanese TV anime series (`Q63952888`)" is a subclass (subclass of; `wdt:P279`) of "Anime series (`Q117467261`)", which is in turn a subclass of "Anime (`Q1107`)". However, if you were to embed this hierarchy in each reaction, it would waste a lot of space. The following query will get all the superclasses of "Japanese TV anime series (`Q63952888`)", but there are 54 of them. https://query.wikidata.org/#%23%20Subclass%20hierarchy%20traversal%20for%20Q63952888%0ASELECT%20%3Fitem%20%3FitemLabel%20%3Fsuperclass%20%3FsuperclassLabel%0AWHERE%20%7B%0A%20%20%23%20Starting%20class%0A%20%20wd%3AQ63952888%20wdt%3AP279%2a%20%3Fsuperclass%20.%0A%20%20BIND%28wd%3AQ63952888%20AS%20%3Fitem%29%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%7D%0AORDER%20BY%20%3Fsuperclass%0A So, I think it should be okay for practical purposes to embed `P31`s of the reaction target. In other words, if you search for "anime series `Q63952888`" and "anime movie `Q20650540`", that should be enough. Fortunately, the conditions for single-character tags work with OR, so you can query multiple tags at once. we'll have to try it to see how well it works in practice, though. ## Discussion: Which kind should I use? So far we have considered using kind:17, but we have not yet decided whether it is a good idea to mix Thingstr events with reactions to web pages. Also, there may be a debate over whether to record regular events or addressable events, depending on the purpose of use. For example, if you want to record the transition of viewing results and impressions on an anime viewing site, you should use regular events, and if you want to maintain the viewing status, you should use addressable events. What do you think? ## Other ideas If we can react to Nodes on [OpenStreetMap](https://www.openstreetmap.org/) using the same framework, we might be able to create something like [Swarm](https://swarmapp.com/). Since the views you want to see will differ depending on the purpose, it would be good to create various sites while having a consistent way of recording. Wouldn't that be the most Nostr-like thing? ## Summary I discussed how to use WikiData and OpenStreetMap as an ID infrastructure and realize various check-in and review services with a unified data model by using them on Nostr. Please let us know if you have any feedback. Or why not try implementing it? ---- この記事は [Nostr Advent Calendar 2024](https://adventar.org/calendars/10004) の14日目の記事です。13日目の記事はmonoさんによる「[Open Sats 申請編](https://zenn.dev/konemono/articles/cb39fb7f302551)」でした。15日目の記事はbroさんによる「[Nostrはじめました。](https://bewith.bz/?p=121)」です。 # Thingstrについて考えた 面白そうな（と勝手に思ってる） Other Staff のアイディアを思いついたので、書いてみます。 本当は実装を持ってきて自慢したかったのですが、まだふわっとしていて実装に落ちていません。 コアになるアイディアは「WikiData の ID に対して、Reactionをつける」これだけです。 ## WikiData [WikiData](https://www.wikidata.org/) というサービスがあります。構造化データを提供する知識ベースです。 なにそれ？という感じですが、ここで大事なのはWikiDataはかなり広範な「もの」「こと」に識別子(Identifier)を付与している、ということです。 だから、これにリアクションできれば、ぱっと思いつくだけでもいろいろな応用ができそうじゃないですか。 例えば、アニメシリーズ「負けヒロインが多すぎる！」には `Q123819103` というIDが振られています。これに対応するページとして https://www.wikidata.org/wiki/Q123819103 があります。 （ただし、WikiData のエンティティに対する canonical な URI は http://www.wikidata.org/entity/Q1142841 であることには注意が必要です。セマンティックウェブの作法で https ではなく http になっています。そして、このURIは必ずしもWebページのアドレス一致しません。大抵の場合はリダイレクトされます）。 ## なにができるの たとえば、アニメの視聴記録サイトはどうでしょう。👀は見たい作品、✅は視聴済み、☆はお気に入り、みたいに記録していく。制作会社、スタッフ、声優、...に対してLikeを表明したりできそうです。そうすると、あるユーザが何にLikeしているかわかります。 これが映画でもいいし、書籍、漫画、作家でもいいし、音楽でもいいし、アイドルグループでもいいし、場所でもいいし、食べ物でもいい（とんかつ `Q1142841` が好き、とか）。全部同じ枠組みで記録できるのが面白そうなところです。 ## どういうNostrイベントで記録する？ 具体的な記録の仕方には議論の余地があるでしょう。一番単純なのは、NIP-25の "Reactions to a website" kind:17 (Makibishi) を使う方法でしょうか。こんなのはどうでしょう。 ```json [ ["i", "wd:Q123819103", "http://www.wikidata.org/entity/Q123819103"], ] ``` NIP-73にExternal Content IDsがあるので、ここにWikiDataを入れられるようにして `wd:Q123819103` と書けるとよさそうです。実は `isbn:` などはすでに定義されているので、書籍に関しては現行のNIPの範囲でもうまいことできます（ただ、著者にはIDが振られていません。WikiDataをIDに使うと著者に関するリアクションも記述できます）。もちろん、どちらか一方を選ぶというものでもなくて、書籍にはWikiDataのタグと当時にISBNのタグを付与しておいてもいいと思います。 ## 記録されたリアクションを検索する ここまではシンプルでよいのですが、リアクションの部分集合（たとえばアニメに関連するものだけ、とか）をまとめてクエリできるように、目印となるタグを入れておかないと不便です。ある目的に特化したサイトを作ろうとしたとき、必要になるリアクションが抽出できるようにしておかないといけません。 WikiData では `wdt:P31` (instance of) という述語で、ある概念が何を表しているかをグルーピングしてくれています。例えばこれを`l`タグとかに含めておくのはどうでしょうか。 負けヒロインが多すぎる！は「日本のテレビアニメシリーズ(`Q63952888`)」なので、 ```json [ ["i", "wd:Q1142841", "http://www.wikidata.org/entity/Q1142841"], ["l", "wdt:P31 wd:Q63952888"] ] ``` みたいな感じで付与します。 UPDATE(2024-12-15): rnurachueさんからラベル付けには `#l` または `#L` のほうがよいかもという提案をいただきました。最初のバージョンでは `#a` を使用していました。そのとおりだと思ったので更新しました。 nostr:nevent1qgswamu0rsela0kwhj87p24ueapxdp04vzz7ar0pp6lfyq923t3l02cqyr9786635s60ra0f973nwv2sln2l74lqx4twdlgxfz2jgevpvsgtc9zwn6d ただ、アニメサイトを作ることを考えると、テレビアニメも劇場版アニメも両方クエリしたいこともありそうですよね。そうなると話が複雑になってきます。 「日本のテレビアニメシリーズ(`Q63952888`)」は「アニメシリーズ(`Q117467261`)」のサブクラス(subclass of; `wdt:P279`)で、それがさらに「アニメ(`Q1107`)」 のサブクラスになっています。ただ、この階層をいちいちリアクションに埋め込むのと大変なことになります。以下のようなクエリで「日本のテレビアニメシリーズ(`Q63952888`)」のすべての上位クラスが取れるのですが、54件もあります。 https://query.wikidata.org/#%23%20Subclass%20hierarchy%20traversal%20for%20Q63952888%0ASELECT%20%3Fitem%20%3FitemLabel%20%3Fsuperclass%20%3FsuperclassLabel%0AWHERE%20%7B%0A%20%20%23%20Starting%20class%0A%20%20wd%3AQ63952888%20wdt%3AP279%2a%20%3Fsuperclass%20.%0A%20%20BIND%28wd%3AQ63952888%20AS%20%3Fitem%29%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%7D%0AORDER%20BY%20%3Fsuperclass%0A なので、リアクション対象の`P31`を埋め込む、くらいで実用上は問題ないような気がします。つまり、検索するときに 「アニメシリーズ `Q63952888`」と「アニメ映画 `Q20650540`」を対象にすれば、十分では、ということです。幸い、一文字タグの条件はORで効くので、複数を並べて一度にクエリできます。実際にどのくらいうまく行くかはやってみないとわからないですが。 ## 議論: どの kind を使うべきか？ 一旦 kind 17 を使うことを考えてきましたが、Thingstr のイベントが Web ページに対するリアクションと混ざるのが良いことなのか、いまいち判断がついていません。 また、用途によって regular event で記録するべきか、それとも addressable event で記録すべきか、という議論もありそうです。 アニメ視聴サイトを例にあげるなら、視聴実績とか感想の変遷を記録したいならば regular event でしょうし、視聴の状態を保持したいならば addressable とするのがよさそうです。 どう思いますか？ ## 他のアイディア これと同じ枠組みで [OpenStreetMap](https://www.openstreetmap.org/) の Node に対してリアクションできるようにすれば [Swarm](https://swarmapp.com/) のようなものも実現できるかもしれません。 用途ごとに見たいビューは違うだろうから、一貫した記録の仕方を持ちつつ、色々なサイトを作ったらいいんじゃないでしょうか。それって最高にNostrっぽくないですか？ ## まとめ WikiDataやOpenStreetMapをID基盤として活用し、Nostr上でreactすることで、様々なチェックインサービス、レビューサービスを統一的なデータモデルで実現する方法について議論しました。フィードバックがあったら教えてください。むしろ実装してみてください。