Thanks Rich,
If you put it this way, then it's "Way A".
With Way B I meant that there exists multiple hierarchies which are
defined independently from each other. Maybe the relation to naming was
confusing, and I'm not sure I understand that myself yet clearly.
As a (contrived) example of Way B, think of an organization which has,
among others, two units: "IT-services" and "Budgeting".
There exists a hierarchy for a budgeting process in which the budgeting
department is superior to IT-services, so Budgeting is an ancestor to
IT-services.
There also exists a hierarchy for management of IT infrastructure, in
which the IT-services department controls the IT-resources of the
budgeting department, so in this hierarchy the IT-services department is
an ancestor of Budgeting.
If we would combine these two hierarchies, the result won't be consistent.
The point I am trying to make is that if there are multiple hierarchies,
it is not guaranteed that their combination is even a DAG. It can be
entirely inconsistent (a graph which contains cycles).
So I think we have to assume that there exists a consistent hierarchy,
before we can say anything. The above counterexample proves that there
cannot exist an algorithm which turns any set of hierarchies into a
joint DAG.
With the discussion on naming I meant that if you do have a consistent
hierarchy, it is no problem that the nodes may have multiple "normative
descriptions" (names). You seemed to indicate in an earlier email that
multiple "normative descriptions" (which it says in the 2.0 profile) is
a problem.
Best regarsd,
Erik
Rich.Levinson wrote:
