- From: Bass, Mick <mick.bass@hp.com>
- Date: Thu, 22 May 2003 13:30:14 -0700
- To: "Tansley, Robert" <robert.tansley@hp.com>, Kevin Smathers <kevin.smathers@hp.com>
- Cc: "(www-rdf-dspace@w3.org)" <www-rdf-dspace@w3.org>
> This could prove to be a > scalability issue; if every minor change in the archive > results in a lot of things having a different situation, then > the history system will rapidly become an enormous corpus of > data. Maybe that's OK. My point is that as far as I'm aware > this vital issue hasn't been looked at even vaguely in the > original or current work of the History system. The original History System work did indeed consider this, as well as some of the issues raised here regarding hash-based naming and differences among situations. For example see [1]. I am encouraged, though, by the vigor of review that we are seeing in this discussion, which complements that prior work. [1] History Requirements http://lists.w3.org/Archives/Public/www-rdf-dspace/2003May/0099.html > -----Original Message----- > From: Tansley, Robert [mailto:robert.tansley@hp.com] > Sent: Thursday, May 22, 2003 3:54 PM > To: Kevin Smathers; Tansley, Robert > Cc: (www-rdf-dspace@w3.org) > Subject: RE: More History comments > > > > > The question is why you decided to use BND1:1 rather than > BND1:2. If > > the choice of BND1:1 was required because the resource at > > that node is > > identified by a content based identifier, then information > > has been lost > > about the distinct nature of the two instances. The graph > > looks wrong; > > the second chain is logically independent of the first, yet you've > > combined the nodes early in the chain, dividing them only where the > > content has changed. I think you instead should consider the > > instance > > chain to be independent of the content (see attachment.) > > Hi Kevin, > > Your attachment shows the logical conclusion of following the > logic I was trying to describe; that basically, if you change > anything in the archive, since things in the archive are > related changing one thing changes the situation that > everything related to that changes. This could prove to be a > scalability issue; if every minor change in the archive > results in a lot of things having a different situation, then > the history system will rapidly become an enormous corpus of > data. Maybe that's OK. My point is that as far as I'm aware > this vital issue hasn't been looked at even vaguely in the > original or current work of the History system. > > Robert Tansley / Hewlett-Packard Laboratories / (+1) 617 551 7624 >
Received on Thursday, 22 May 2003 16:30:20 UTC