My first tendency is towards "pick anything", but if there is to be discussion I'll happily throw in a couple of cents.
Isn't the question: what is this thing we're naming? Using atom:uri/atom:iri is only marginally better than saying atom:string - it describes how the identifier is put together, it tells you nothing about what's being identified. I don't think we want atom:id (or similar) because the URI/IRI is only related to the construct, it isn't an identifier for it. I've pasted the relevant bits of the spec below. One is an IRI "associated with" a person, the other an IRI "relevant" to the generator. Shouldn't the name of the attribute reflect the relationship between the Atom construct and the resource being identified? But both atom:associated and atom:relevant seem pretty clunky. So why not atom:related? Cheers, Danny. 3.2.2 The "atom:uri" Element The "atom:uri" element's content conveys an IRI associated with the person. Person constructs MAY contain an atom:uri element, but MUST NOT contain more than one. The content of atom:uri in a Person construct MUST be an IRI reference [RFC3987]. 4.2.5 The "atom:generator" Element The atom:generator element MAY have a "uri" attribute whose value MUST be an IRI reference [RFC3987]. When dereferenced, that IRI SHOULD produce a representation that is relevant to that agent. -- http://dannyayers.com
