Here's perhaps another way to come at the topic (which we touched on in our brief hallway convo).
The OAuth group, in designing its scope capability, struggled with how much formality to give to that capability. Ultimately, the group kept it extremely informal, so that there are no semantics at the spec level.
We in the UMA group have given some formality to scopes so far: They can optionally have description documents (or they can be just strings), and they must be attached to specific resource sets.
I listed three options below in the thread. What Justin has done in his implementation, as I understand it, is to leave the "class-to-instance" mapping implicit at the spec level -- effectively leaving it up to API documentation, exactly the way scope and protected-resource semantics are left to API documentation in OAuth now. So he's exercising "option #3", that is, doing nothing in the spec, while letting the set math flow unimpeded.
(Even if we choose to use this option, I still wonder if some nonnormative explanatory language would be valuable to explain the class-to-instance connection, particularly since UMA has a different approach to protected resources -- that is, they're named and RO-specific compared to OAuth.)
(Another thought: Would it be friendlier if we were to use the name "protected resource" vs. "resource set"? I trip up on "resource set" all the time.)
Though Justin indicated he may not be awake at the appointed BOF hour (I admit I will struggle with it myself!), it feels like this thread is on its way to giving us a better and better basis for discussion and decision-making, tomorrow and in subsequent WG calls.