Hash-URI resources fragments do not have well-defined semantics. In HTML, they are typically used to take the user to a particular point on the page, and are also sometimes used to record application state. In XML and semantic web use, they are used as identifiers that are distinct from the base resource (i.e., without the hash URI fragment), but often contained in the same document (e.g., an RDF/XML element with the corresponding id attribute). In Fedora, they are intended to be resources descriptions that are distinct are distinct from, but dependent on, the base resource.
Current implementation - as JCR Nodes
In the current implementation, hash URI fragments are stored on JCR nodes under a special node named #. So properties about the hash URI fragment /foo#bar would be attached to the node /foo/#/bar.
- Properties on hash URI resources fragments can be added and deleted by updating the base resource (POSTing/PUTting RDF, SPARQL Update).
- References to hash URI resources fragments are treated the same as references to base resources: they can only be made to existing resourcesfragments, and they are automatically removed when the resource fragment is deleted.
- When a resource is updated to include properties on hash URI resourcesfragments, they are automatically created.
- The only way to delete a hash URI resource fragment is to delete its base resource – though there is a proposal to address this by automatically deleting them if they have no properties and/or inbound references.
...
An alternate implementation would be to store hash URI fragment properties in a JCR property. So the properties about all hash URI fragments would be stored as serialized RDF in the value of a property 
.
- Properties on hash URI resources fragments would still be added and deleted by updating the base resource.
- References to hash URI resources fragments would not be subject to the same restrictions as references to nodes, and would not be automatically removed when they were deleted.
- Hash URI resources fragments would not have any persistence other than triples in the serialized RDF, so adding triples would effectively create them, and deleting the triples would effectively delete them.
...