I tend to agree with Graham: 1. That can of worm may have already been opened as soon as people approach the persistent identifier issue. Items are relatively stable so we don't have much of a problem on assigning handles to them but the same can't said about the files. At least for now the admin is free to delete/add files at will. To add the versioning helps but may not completely eliminate the problem.
2. It would be nice to have a sensitive tool/solution accompanying assigning handles to files, at least to help most of the admin usecases when the identifier needs to be changed/re-assigned. I remember someone has written a note for W3C arguing that the persistent identifier issue is purely an adminnistrative problem. I think he's right to some extent. To administer well the admin needs tools. With the tools in hand then perhaps it's up to the admin to use it wisely. BTW I think the admin can always mess up if s/he wants to. Zhiwu On 7/20/07, Graham Triggs <[EMAIL PROTECTED]> wrote: > 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 DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
