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.
Therefore the augmentation of section 3.2 need be little more than to
emphasize this now obvious fact. More specifically, in the case of
multiple URIs as a result of belonging to multiple hierarchies, this
fully models the general DAG case as well. i.e. given a single
hierarchy (one root), it is obvious that a URI scheme can be used to
apply identifiers to the members of that hierarchy. Furthermore, given
a DAG, because the DAG can be transformed into a set of independent
hierarchies, a separate URI scheme can be applied to each hierarchy
there, and when transformed back into the DAG, the nodes that appear in
multiple hierarchies will simply have multiple URIs and the problem is
fully defined.
Thanks,
Rich
Daniel Engovatov wrote:
However, I do not understand precisely what you are recommending:
I do not understand how {"PC", "DEPT", "FACILITIES"} relates to the
scenario I have described. I have specific PCs, in the example they
have serial numbers r5, r6. One of these PCs, r5, is identified in the
"dept" as /a1/b1/c1. In the facilities org the same pc is identified as
/a2/b2/c2.
No, PC is identified by "r5". The fact that a PC is governed by a
policy of the "dept" does not change that fact. The only purpose of
hierarchy is to determine an applicable set of rules for a particular
evaluation. That is it. Constructing a hierarchical identifier is
beyond the scope of that task.
So in my example access to a "PC" is governed by rules applied to both
"DEPT" and "FACILITIES". Very simple.
It is also uniquely defined by a URI if a
URI scheme has been applied to the same resources, since all the ance
URIs do not represent bags of strings. Possibly one might choose to
represent a URI as a bag of strings, however, one loses the ordering in
the process. If one wants to identify the specific set of nodes
represented by a URI, it is a simple matter to sequentially strip one
component at a time off the URI, and at each step one has the normative
identity of the next node up the chain until one reaches the root.
For the purposes of defining a hierarchical policy in this model all
you need is a bag of strings. Using URI for that is not needed. Use
cases that can be represented that way are a subset of use cases that
can be represented wit "ancestors" approach. Ordering is not important
in this model, just like for the rest of our rules.
At this point I fail to understand the
purpose of specifically not using a hierarchical naming scheme in order
to identify a set of resources that will be managed as a hierarchy. I
understand that there may be cases where for some reason it may not be
possible or practical to use such a naming scheme, but in those cases
where it is possible and practical, I do not understand why it would
not be a good idea to use it.
The purpose is that a hierarchical naming scheme is not generic
enough. For those cases when it is possible, it is still easier to
use, as it does not require one to introduce a superfluous naming
scheme and preserves the ability to change the structure of the
inheritance graph if needed.
Daniel;
