- 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