1 files changed, 7 insertions, 70 deletions

diff --git a/32.md b/32.md
index b147385..ddd364a 100644
--- a/32.md
+++ b/32.md
@@ -6,11 +6,7 @@ Labeling
 
 `draft` `optional` `author:staab` `author:gruruya` `author:s3x-jay`
 
-A label is a `kind 1985` event that is used to label other entities. This supports a number of use cases:
-
-- Distributed moderation and content recommendations
-- Reviews and ratings
-- Definition of edges in a graph structure
+A label is a `kind 1985` event that is used to label other entities. This supports a number of use cases, from distributed moderation and content recommendations to reviews and ratings.
 
 Label Target
 ----
@@ -26,18 +22,17 @@ Label Tag
 This NIP introduces a new tag `l` which denotes a label, and a new `L` tag which denotes a label namespace.
 A label MUST include a mark matching an `L` tag. `L` tags refer to a tag type within nostr, or a nomenclature
 external to nostr defined either formally or by convention. Any string can be a namespace, but publishers SHOULD
-ensure they are unambiguous by using a well-defined namespace (such as an ISO standard) or reverse domain name notation. Some examples:
+ensure they are unambiguous by using a well-defined namespace (such as an ISO standard) or reverse domain name notation.
 
 Namespaces starting with `#` indicate that the label target should be associated with the label's value.
 This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, etc.
 
+Some examples:
+
 - `["l", "footstr", "#t"]` - the publisher thinks the given entity should have the `footstr` topic applied.
 - `["l", "<pubkey>", "#p"]` - the publisher thinks the given entity is related to `<pubkey>`
-- `["l", "D005528", "MeSH"]` - ["Foot"](https://meshb.nlm.nih.gov/record/ui?ui=D005528) from NIH's Medical Subject Headings vocabulary
-- `["l", "3173435", "GeoNames"]` - [Milan, Italy](https://www.geonames.org/3173435/milan.html) using the GeoNames coding system
 - `["l", "IT-MI", "ISO-3166-2"]` - Milano, Italy using ISO 3166-2.
 - `["l", "VI-hum", "com.example.ontology"]` - Violence toward a human being as defined by ontology.example.com.
-- `["l", "relay/review", "com.example.ontology"]` - the publisher is leaving a review about a relay, as defined by ontology.example.com.
 
 `L` tags containing the label namespaces MUST be included in order to support searching by
 namespace rather than by a specific tag. The special `ugc` ("user generated content") namespace
@@ -65,30 +60,6 @@ explanation of why something was labeled the way it was, should go in the event'
 Example events
 --------------
 
-A single event can apply multiple labels to multiple targets to support mass-tagging. Multiple
-namespaces may be used at the same time.
-
-```json
-{
-  "kind": 1985,
-  "tags": [
-    ["e", <id>, <relay_url>],
-    ["p", <id>, <relay_url>],
-    ["t", "chickens"],
-    ["L", "#t"]
-    ["L", "ugc"]
-    ["L", "com.example.labels"]
-    ["l", "chickens", "#t"],
-    ["l", "user generated content", "ugc"],
-    ["l", "permaculture", "com.example.labels"],
-    ["l", "permies", "com.example.labels"],
-    ["l", "farming", "com.example.labels"],
-  ],
-  "content": "",
-  ...
-}
-```
-
 A suggestion that multiple pubkeys be associated with the `permies` topic.
 
 ```json
@@ -105,24 +76,7 @@ A suggestion that multiple pubkeys be associated with the `permies` topic.
 }
 ```
 
-A review of a relay, as relates to certain topics, including additional dimensions. The author
-is indicating here that `relay_url` is related to the bitcoin topic, but they're not very sure
-that's the case.
-
-```json
-{
-  "kind": 1985,
-  "tags": [
-    ["L", "#t"],
-    ["l", "bitcoin", "#t", "{\"quality\": 0.7, \"confidence\": 0.2}"],
-    ["r", <relay_url>]
-  ],
-  "content": "I think this relay is mostly just bitcoiners.",
-  ...
-}
-```
-
-A plain review of a relay.
+A review of a relay.
 
 ```json
 {
@@ -137,24 +91,6 @@ A plain review of a relay.
 }
 ```
 
-A more abstract use case: defining an edge in a graph structure, in this case identifying
-a lightning channel that is open between two pubkeys. This just demonstrates the flexibility
-this spec provides for overlaying structured metadata on top of nostr.
-
-```json
-{
-  "kind": 1985,
-  "tags": [
-    ["L", "my-lightning-nomenclature"],
-    ["l", "channel", "my-lightning-nomenclature"],
-    ["p", <pubkey1>, <relay_url>],
-    ["p", <pubkey2>, <relay_url>]
-  ],
-  "content": "<channel_id>",
-  ...
-}
-```
-
 Publishers can self-label by adding `l` tags to their own non-1985 events.
 
 ```json
@@ -174,7 +110,8 @@ Other Notes
 
 When using this NIP to bulk-label many targets at once, events may be deleted and a replacement
 may be published. We have opted not to use parameterizable/replaceable events for this due to the
-complexity in coming up with a standard `d` tag.
+complexity in coming up with a standard `d` tag. In order to avoid ambiguity when querying,
+publishers SHOULD limit labeling events to a single namespace.
 
 Before creating a vocabulary, explore how your use case may have already been designed and
 imitate that design if possible. Reverse domain name notation is encouraged to avoid