I think the source of confusion was this. Daniel's point was that the initial representation of each hierarchy could be a DAG, since it is a generalization of a tree. Rich's point was that if you start out with all the hierarchies in whatever form, and you include defined hierarchies which do not include the Resource in question as a member, even though ancestors of the Resource are members of the hierarchy, if you combine all the hierarchies you lose the information about the original hierarchies necessary to be able to distinguish whether the nodes above the Resource are true ancestors or not.
My comments on the call and below on the DAG were based on the premise that we started out with one or more hierarchies merged them into a DAG and then determined the parents and ancestors. Under this premise, the use of a DAG seemed like a intermediate step of no particular interest. I now see that Daniel was trying to say that at the very beginning, any of the distinct hierarchies may be multi-rooted and thus represented as a DAG.
My feeling now is to make minimal changes to the document. I think if we make it clear that the starting point is one or more hierarchy each of which may be singly or multiply rooted, but only hierarchies which contain the resource. I don't object to the individual hierarchies or their union as being described as a DAG, but the ancestors could also be computed by examining each hierarchy in turn.
I have some concerns about the URI part, which I will put in a separate email.
Hal
