NIP-32: describe use of Wikidata properties in labeling

[darashi]

Summary

This PR expands NIP-32 to include a standard method for using Wikidata properties within l and L tags.

Motivation

Currently, when tagging external entities, it is often necessary to clarify what the entity is (e.g., a "communication protocol" vs. a "location"). Wikidata provides a robust ontology for this via properties like P31 (instance of).

This proposal was conceived as an extension for implementing applications on top of Thingstr (See #2150). I would appreciate your feedback on this approach.

Details

Explains how to format the tags using RDF-style prefixes (e.g., wdt:P31).

Provides a concrete example of a Kind 17 event reacting to the Nostr entity (Q116423243) and classifying it (P31) as a communication protocol (Q132364).

[vitorpamplona]

I am not liking this overload of kind: 17 with a bunch of things. Why not just do a kind 17 event for the reaction and a separate kind 1985 for the label?

[darashi]

Thank you for your feedback. I was simply looking for a quick and easy way to get reactions about a specific theme. But I also had concerns that if Wikidata's data updates, the kind:17 event would become stale. As you mentioned, it might be better to label with another event.

[vitorpamplona]

hum.. is the reaction itself specific to the theme or the post? Meaning, is the goal to do a Like for "travel" and a dislike for "bitcoin"?

[darashi]

Reactions are made towards entities in Wikidata. Yes, so, we can react to

travel https://thingstr.pages.dev/things/Q61509 and
bitcoin https://thingstr.pages.dev/things/Q131723

and I think this is somewhat interesting.

The labeling proposed here is particularly useful when building more specific applications, such as anime information sites, book sites, movie sites, or music sites, etc.

Here, I reacted + to two anime series:

https://thingstr.pages.dev/things/Q662
https://thingstr.pages.dev/things/Q57390937

These have separate IDs: Q662 and Q57390937. While Wikidata contains information that both are instances of (P31) anime television series (Q63952888; this classification, too, is an entity), this information is not present in Nostr events (unless additionally stored).

If someone wants to retrieve all reactions I've made for any anime series, without some kind of clue, they would have to fetch all my reactions and then search for the anime works from there. (It is possible to scope kind:17 with “#k”: [“wikidata”])

This is when labels become necessary. Am I explaining this well?

[vitorpamplona]

I was trying to understand if the label is rating the reaction itself OR the post/content. If the label is "labeling" the reaction itself, then this might make sense, but if the label is towards the content you are reacting to, I think two events are better.

[darashi]

Labels are directed at the content being reacted, not at reaction itself.

Even if kind:1985 is used, “e”-tag should refer to the reaction event, so this should be interpreted as a label directed at the reaction, right? Does this mean we don't have a way to assign labels of this nature?

[staab]

Yeah, I agree with @vitorpamplona, NIP 32 specifies that labels applied to non-1985 are self-labels, not labels of the target. This was probably overly-prescriptive, so it might make sense to change it, but see if splitting labeling and reacting up makes sense first. To pull reactions for a given topic, you would first fetch labels, then fetch reactions for specific topics. But I could see how this wouldn't be performant.

[darashi]

Thank you for your comments. I haven't implemented it yet, but I've revised the spec to separate reactions from the labeling of reaction targets. I also added mentioned to explicitly indicate that the labeling target is the event's target, not the event itself referenced by e. What do you think? To be honest, I don't think it's a great idea...