You are right, the human-readable flag applies to the data, not the name.
I'll add in what you wanted, to make it clearer.
As for the name -- well, I have no idea.
I have an intuitive sense of what human readable means for the value. For
example, "I have read this document, but do not agree with much of its
content, call or email for long-winded details" is a fine human-readable
notation, and one of the purposes it's there for. I can even understand
that the semantic content of that note can be put in any arbitrary language
and encoded in whatever alphabets in unicode, and it's still "human
readable" even if that human better speak Esperanto.
But is "method://whatever/goes/in/a/uri" human-readable? Tim Berners-Lee
thinks not. Or thought not. The protocol we describe in 2440bis for names
doesn't make them human readable in some sense of the word, and in fact
clucks its tongue at a name like "Statement about what my signature means"
which is a *fine* human readable name to go along with the human readable
value.
My opinion is this: Pick your names with a small amount of wisdom. No
matter what you do, someone will be sure to tell you that you did the wrong
thing. A notation means what its creator wants it to mean. Unlike most
data, since this is contained in a signature, there's a known creator of
that data. Consequently, the disambiguation we have in the standard is
really overkill. However, the reason for a notation is communication, and
there are two parties in communication. If you pick a name tag that someone
else will interpret differently than what you mean, then you have a
problem. That's why a small amount of wisdom is needed, and if you pick
some scheme like the one in 2440bis, or the backwards-domain scheme that
Java uses, fewer people will cluck their tongues at you than would if you
used a name like "a". And yet a name like "ReadMe" is pretty obvious, even
if squishy and non-standard. You're a bright guy, there are lots of
reasonable things to do. Pick one.
Jon