From: "James Rutherford" <[EMAIL PROTECTED]> >> I absolutely agree. But how can you guarantee that it resolves to what it >> is meant to be identifying if you completely disallow the possibility to >> reassign it? > > I'd flip this around and say how can you guarantee that it resolves to > what it is meant to be identifying if you *do* allow the possibility to > reassign it. Oh, what a can of worms!
You can't. But that isn't the issue. If you are going to have the situation where an id may not resolve correctly, then you have to have the tools to be able to correct - even if that can create problems through misuse. >> I was tempted to say that you shouldn't be allowed to delete a file that >> has an external identifier (or at least that the default implementation >> shouldn't). As soon as I realised that wouldn't be possible, you have to >> consider the possibility of reassigning the handle. > > This isn't actually strictly true. Once we have versioning, it could > well be impossible (presumably at the discretion of the repository > curator) to delete *anything*, only to be able to create a new "head" > version of the container that doesn't hold any reference to the file you > wanted to delete. As nice as that would be in theory, and even if it is the likely 'normal operation', you will always have to cater for being able to completely erase a file or item (ie. legal issues). > Remember that in systems with versioning, deletion is > a very different concept to systems where versioning isn't supported. > The points I have made so far assume we are working with a system that > supports versioning. Yes, the external id could refer - and continue to refer - to a 'deleted' but still accessible file. But bear in mind that we should make no assumption of what external id system(s) are used for the assignment, and that system may not be providing a persistent identifier. So we can't assume what the appropriate behaviour of handling that id is on file / item deletion. >> Remember, that such a reassignment is (or rather should only be used for) >> altering the resolution of the identifier - which doesn't automatically >> mean that you are conceptually changing what it identifies. > > Danger danger! Surely we would just be giving our adopters enough rope > with which to hang themselves by doing this. It is pretty obvious that > people will never use things the way we've decided that they should, no > matter how much we jump up and down and tell them that it's the wrong > thing to do. True - but I could argue that by even having the ability to assign external / persistent identifiers to anything you are giving adopters enough rope to hang themselves. But having them is also a fundamental part of preservation, and they are likely hanging themselves if they don't use them (appropriately). There are so many issues that I don't think it's possible to ever write a system where it would be impossible for adopters to not hang themselves (with enough functionality to sustain a diverse community). The best we can do is minimize the potential for these problems in 'normal' operation, and provide extra (separate) functionality that can try to correct problems that do arise. G This email has been scanned by Postini. For more information please visit http://www.postini.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
