eRDF re-uses HTML's @id to establish resource identifiers, so it mixes document identifiers with non-doc ones, and this is an ambiguity problem indeed. RDFa, however, is a layer on top of HTML that introduces a dedicated mechanism for resource identification, the @about attribute (, and that's why it unfortunately needs an own DTD, but that's another story). From a WebArch POV, the design is clean, content-type-specific identifiers don't get mixed. I can unambiguously describe what "..ben#self" is meant to identify without the representation format playing a role. RDFa can re-purpose HTML's text nodes for RDF literals, and anchors for resource URIs, but apart from that, the HTML document is not much more than a (human-friendly) container.
I agree with his point that RDFa has a much better design than eRDF for this. But the purpose of my series of posts is to point out that this is ever so much more complicated than it needs to be. URIs with fragment identifiers are inherently ambiguous because their meaning can change due to a network operation, not simply due to the semantic declarations in RDF or RDFa documents. Performing a GET on a URI can cause my graph to become inconsistent if I was banking on it denoting a train but I got an HTML document telling me it denotes a fragment of a document.
Also, there's a difference between getting a description of something and getting its representation. Danny touched on this in his blog recently. If I use a URI with a fragment to denote a resource then there's no predictable way in the web architecture to get a representation of that resource. I have to get the unhashed version and hope for the best. This implies the issue isn't just about RDF descriptions, but about using HTTP URIs to denote things other than documents in a way that is integral to the current Web.