https://github.com/staab/nips/blob/ratings/56.md

I see you kept quality between 0 to 1, do you want to include a seperate tag like [negative, true/false] that could be better queried?

The meaning of the fields in a tag has not depended on the event kind before. Here we have an 'e' tag where the meaning of the fields is different then every other e tag in every other kind. This complicates my code lots. So I'm against unless this can be changed.

That isn't new, it's how kind 1984 is already described.

It may be better to eschew kind 1984 for a different structure, but it's been kept this way for backwards compatability.
I'm starting to think it would be better to just use a new kind and do it right as 1984 seems mostly unimplemented (rightfully so.)

Yes, the intention was for backwards compatibility, but I agree that the structure used in 1984 is abhorrent. I'll draft a new PR this week with a cleaner implementation.

I see you kept quality between 0 to 1, do you want to include a seperate tag like [negative, true/false] that could be better queried?

As I was putting this PR together, I came to the conclusion that negation isn't necessary if you think in terms of a venn diagram rather than vectors to/away from a target. In the former metaphor, a negative match makes no sense, since 0 indicates no overlap, IOW a total negation. The latter might indicate toward (+1) or away from (-1) some target or standard, but that metaphor only applies to some concepts (you might be able to justify negative quality, but not negative confidence). So my preference is now a spectrum of 0 to 1, I think it's much cleaner.

Querying the tag is another question, I'll think about how that might be accomplished.

Here's what I'm thinking so far; single reference, multiple labels.

{
  kind: ???
  tags: [
    ["p", <pubkey>],
    ["t", "label"],
    ["t", "label2"]
  ]
}

Any tags attached to the event besides tags in the spec like e/p/r could be interpreted as applying to what's referenced.
So you could apply a description tag to a relay for instance, or even an updated relay url to an event.

I see two ways in which l tags extend t tags, namespaces and quality. I say we make namespace the third field and quality the fourth, assuming the default namespace: topic and quality: 1. I think simply extending t tags seems like the right way to go instead of introducing a new, strict superset, tag and it seems you agree. I want to include quality on the label-level so that different labels in the same event can have different qualities.

Keeping confidence as a special tag for labeling events is fine as confidence doesn't make much sense when tagging your own event, and in this case the downside of applying to all labels in the event is acceptable IMO.

Other thoughts:
I think we should keep the context tag you introduced, I like it.
With my described changes, you would lose the ability to specify the quality of a reference without a label, but you could use a blank label to achieve something similar.

Closed in favor of #532

@Gruruya I don't mind any suggestions you made above, but I went a slightly different direction with the new PR. There is a trade-off between being able to apply multiple labels to a single entity vs applying a single label to multiple entities, I went with the latter in the new PR. I removed context, since that was mostly to support NIP 56, which I've decided not to touch for now. I do think namespace is helpful, I'm ambivalent as to whether it should be included in a label, except that defining fewer tags keeps things simple, and a slash is trivial to parse.

There is a trade-off between being able to apply multiple labels to a single entity vs applying a single label to multiple entities

I'll write something, I want multiple labels for one reference as I expect to be doing a lot of mass-tagging. It seems two seperate implementations may be necessary.

Ok, I can take another look. I suppose we could just support multiple labels and multiple targets, with the implication being that all labels are applied to all entities.