Hi Daniel,

If you would care to elaborate on the use case of 'access to a "PC" is governed by rules applied to both "DEPT" and "FACILITIES" ', I would be interested, however, with the info you have given, I simply do not see a hierarchy represented there. I am truly interested, because when I do not understand something, I generally assume that there is information of which I am not yet fully cognizant, as was the case when Erik responded with his example that showed usage of the ancestors capability.

My experience with hierarchies includes the following as a common use case: A manager conceptualizes a project, large as a whole company or govt or small as a simple team leader scoped project, and creates a hierarchical structure within which resources: people, equipment, facilities, etc. are deployed. As such, for one example, the manager creates a hierarchical org chart of the people in the project and defines responsibilities etc wrt to that org chart. When the project commences, individuals are assigned their places within the hierarchy and they have the hierarchical identifier added to their identity properties. Such is the case with the /a*/ b*/c* that I used in my example. "r5" was the serial number on the PC that doesn't change, however, the hierarchies that PC participates in will generally vary over time, which is reflected by the identifiers from the various org structures that it is assigned. One additional realization that has occurred to me after last night's email is that when resources are assigned URIs for the purpose of being within a particular organization, that set of URIs satisfies the requirements of the algorithms ("corrected" or not) in section 3.2. This is because, as I pointed out, without being fully cognizant of the implications at that point, the URI, itself, implicitly contains the normative identity of "self", "parent", and all "ancestors" by nature of its construction.