>Do you actually oppose assigning them, or just making them visible to > the user? in some sense "invisible to the users" identifiers are assigned to all files even now in the form handle/sequence_id/filename and I don't think it is possible to build a repository where you will not assign them. However if I understand correctly, you were talking about something else e.g. about generating URIs for each file which will have to be unique, permanent and system independent. That implies additional maintenance costs for the repository.
> Naturally the "citation link" would be exactly as it is now > (ie: pointing to an Item). Personally, I can't see any reason why having > this information available would be harmful, so I'm interested to > understand why you might think it was a bad idea (I'm very open to input > here). > For our Preservation repository we use external handle server. Handles for items are generated using NOID on pre-ingest stage and are registered when item is ingested (we modified your handle server patch a bit).Most of our items have a rather complex structure and might include thousands of files in various formats which come from different sources. If we would have to support URIs on file level it would mean additional workflow steps and a more complicated pre-ingest process. On the other hand, it will not give us any additional functionality because our repository services are based on item not on file level. I don't think it's necessarily a bad idea, but I think it can have some serious consequences which might be bad for us. The decision on what level to support URIs determines, at least to some extent, what is the basic element in a repository. It's rather important decision, which might impact the repository architecture as a whole. I am concerned that if we (at NYU) do not support individual file's URIs while most other Dspace repositories do, then we might have problems with data compatibility and, in the long run, even with Dspace version upgrades. Regards. Kate Ekaterina Pechekhonova Digital Library Programmer/Analyst New York University Libraries email: [EMAIL PROTECTED] phone: 212-992-9993 ----- Original Message ----- From: James Rutherford <[EMAIL PROTECTED]> Date: Friday, July 20, 2007 4:32 am Subject: Re: [Dspace-tech] [vote] Do we want to assign external identifiers (Handles) to files? To: Ekaterina Pechekhonova <[EMAIL PROTECTED]> Cc: DSpace Tech <[email protected]> > On Thu, Jul 19, 2007 at 01:47:19PM -0400, Ekaterina Pechekhonova wrote: > > +1 as it usually better to have more options then less. > > However, in our repository we keep identifiers on item level as we > > see item as a repository "atomic" structure, and we think it's pretty > > important that file identifiers will be an option not a default. > > Do you actually oppose assigning them, or just making them visible to > the user? Naturally the "citation link" would be exactly as it is now > (ie: pointing to an Item). Personally, I can't see any reason why having > this information available would be harmful, so I'm interested to > understand why you might think it was a bad idea (I'm very open to input > here). > > cheers, > > Jim > > -- > James Rutherford | Hewlett-Packard Limited registered Office: > Research Engineer | Cain Road, > HP Labs | Bracknell, > Bristol, UK | Berks > +44 117 312 7066 | RG12 1HN. > [EMAIL PROTECTED] | Registered No: 690597 England > > The contents of this message and any attachments to it are > confidential and > may be legally privileged. If you have received this message in error, > you > should delete it from your system immediately and advise the sender. > To any > recipient of this message within HP, unless otherwise stated you should > consider this message and attachments as "HP CONFIDENTIAL". > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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
