Y'all I searched and the NIPs repo doesn't formally define the `d` tag anywhere.

That means no one can tell us we can't extend it lol.

I was thinking we use positional values to extend the `d` tag array.  Something like:

```json
"tags": [
  ["d", "war-and-peace", "leo-tolstoy", "penguin-classics-edition"]
]
```

The general format would be `["d", <title>, <author>, <edition>]` where edition is a human-readable edition name (as opposed to just a number).

The event _should_ still be addressable by `#d` and the title, just like other event kinds' d tags, but we can increase address specificity for the Nostr Knowledge Base use case.  Then we can bake this specificity into wikilinks (see NIP-54 for an existing wikilinks specification).  A document might contain `[[War and Peace. Leo Tolstoy. Penguin Classics Edition.]]` and we can specify that clients should split that at the periods and normalize it into a d tag array reference, so it becomes `["#d", "war-and-peace", "leo-tolstoy", "penguin-classics-edition"]`.  The client can then use this tag array to search its relays, find the closest match, and display to the user a hyperlink to the referenced event.

Basically, we define a citation format for NKB events.

Since the event ID is derived from a serialization of the whole event, including tags, increasing identifier specificity will always generate a unique event ID.

We'll have to experiment with how relays index events by d tag, and how they respond to queries for such events.  Maybe Stella's PHP utilities can help us with that.  Worst case, relays only support searching by the first `d` tag value and return a bunch of matching results, and then we have Alexandria walk through the results and find matches by author and edition.