RE: More History comments

> Tansley, Robert wrote:
> 
> >This looks fine, until you actually try and change something.  Say I 
> >add a new bitstream, BITS2, to BND1.  I've shown this in that nasty 
> >orange colour.  This obviously consistutes a change in BND1; 
> you can't 
> >just draw another hasPart arc between BND1:1 and BITS2:1, since you 
> >would never be able to tell that BND1 in one situation 
> contained only 
> >BITS1.  So, you create a new situation for BND1, called BND1:2, and 
> >have hasPart arcs between that and BITS1:1 and BITS2:1.  
> (This assumes 
> >that the situation of BITS1 is not changed by virtue of the 
> fact that 
> >the Bundle it is in has changed.)
> >
> 
> This is only a problem for content based identifiers (see my rambling 
> answer to Mark).  When using resource identifiers the two 
> instances of 
> BND1:1 are distinct, so there is no confusion between the two chains.
> 
> Collapsing all nodes that have the same contents by using 
> content based 
> identifiers is an invalid optimization, as this use case shows (among 
> others.)


Hi Kevin,

I'm afraid I really don't understand what you've said here.  Which response to Mark are you talking about?  BND1:1 is a single node in the graph.  So you might have in two separate parts of the History data,

BND1:1  -- hasPart -->  BITS1:1

BND1:1  -- hasPart -->  BITS2:1

By definition, aren't the two BND1:1's the same node?  Do I have some serious misunderstanding about the basics of RDF here?

 Robert Tansley / Hewlett-Packard Laboratories / (+1) 617 551 7624