...
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 fragments can be added and deleted by updating the base resource (POSTing/PUTting RDF, SPARQL Update).
- References to hash URI fragments are treated the same as references to base resources: they can only be made to existing fragments, and they are automatically removed when the fragment is deleted.
- When a resource is updated to include properties on hash URI fragments, they are automatically created.
- The only way to delete a hash URI 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.
- hash URIs also may not contain the "/" character, which is different than what RFC 3986 describes as possible with fragment URIs. The current behavior generates a stacktrace with this message: Hash URI resource created with too much hierarchy
Alternate implementation - as Property/Properties
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 fragments would still be added and deleted by updating the base resource.
- References to hash URI 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 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.
- As properties, hashURIs could contain the "/" character, as described by RFC 3986.
Questions
- One of the driving use cases for hash fragments is proxies and ordering. What, if any, impact would a properties-based implementation have on that use case?
- Would properties stored in a properties-based implementation continue to have all the restrictions placed on properties on nodes? E.g., could a property refer to a non-existent repository resource? Would a property that referred to a repository resource be deleted when that resource was deleted?
...