From wsbjzy at gmail.com Mon Sep 1 01:09:29 2008 From: wsbjzy at gmail.com (zhang yu) Date: Mon, 1 Sep 2008 13:09:29 +0800 Subject: [Dspace-general] one translation question Message-ID: <357eb8940808312209h7f3c8017q3853a3ba66710730@mail.gmail.com> Hi All: I am a chinese librarian.I am trying to translat DSpace 1.5.1Beta1 Manual into simplified chinese. So i have a question about translation,if I publish the manual which have been translated into simplified Chinese(eg:book,paper..),do I need some license or permission or signing contract? Waiting for your reply! thanks a lot Zhang Yu Beijing,China 2008,9,1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080901/11962e6e/attachment.htm From rcastro at alerta.cl Mon Sep 1 15:24:51 2008 From: rcastro at alerta.cl (Rodrigo Castro Artigas) Date: Mon, 1 Sep 2008 15:24:51 -0400 Subject: [Dspace-general] Carga de Registros Dspace In-Reply-To: References: Message-ID: <001501c90c68$67ca40d0$375ec270$@cl> Hi, i am loading Items a Dspace, and follow the next message: [root at SDSPACE bin]# ./dsrun org.dspace.app.itemimport.ItemImport -a -e ajasmen at alerta.cl -c "10" -s "/alerta/dspace/LIBROS" -m "100" Destination collections: Owning Collection: Libros por Cap??tulos (prueba) Adding items from directory: /alerta/dspace/LIBROS Generating mapfile: 100 Adding item from directory 1 [Fatal Error] dublin_core.xml:9:88: The reference to entity "request" must end with the ';' delimiter. org.xml.sax.SAXParseException: The reference to entity "request" must end with the ';' delimiter. at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:151) at org.dspace.app.itemimport.ItemImport.loadXML(ItemImport.java:1277) at org.dspace.app.itemimport.ItemImport.loadDublinCore(ItemImport.java:803) at org.dspace.app.itemimport.ItemImport.loadMetadata(ItemImport.java:788) at org.dspace.app.itemimport.ItemImport.addItem(ItemImport.java:634) at org.dspace.app.itemimport.ItemImport.addItems(ItemImport.java:506) at org.dspace.app.itemimport.ItemImport.main(ItemImport.java:415) org.xml.sax.SAXParseException: The reference to entity "request" must end with the ';' delimiter. In file Attach XML for load. -------------- next part -------------- A non-text attachment was scrubbed... Name: dublin_core.xml Type: text/xml Size: 943 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080901/c0f085cd/attachment.xml From Claudia.Juergen at ub.uni-dortmund.de Mon Sep 1 15:57:15 2008 From: Claudia.Juergen at ub.uni-dortmund.de (Claudia Juergen) Date: Mon, 1 Sep 2008 21:57:15 +0200 (CEST) Subject: [Dspace-general] Carga de Registros Dspace In-Reply-To: <001501c90c68$67ca40d0$375ec270$@cl> References: <001501c90c68$67ca40d0$375ec270$@cl> Message-ID: Hola Rodrigo, it's the value of the URI that renders the xml unvalid. Hope that helps Claudia > Hi, i am loading Items a Dspace, and follow the next message: > > > [root at SDSPACE bin]# ./dsrun org.dspace.app.itemimport.ItemImport -a -e > ajasmen at alerta.cl -c "10" -s "/alerta/dspace/LIBROS" -m "100" > Destination collections: > Owning Collection: Libros por Cap??tulos (prueba) > Adding items from directory: /alerta/dspace/LIBROS > Generating mapfile: 100 > Adding item from directory 1 > [Fatal Error] dublin_core.xml:9:88: The reference to entity "request" must > end with the ';' delimiter. > org.xml.sax.SAXParseException: The reference to entity "request" must end > with the ';' delimiter. > at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) > at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown > Source) > at > javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:151) > at > org.dspace.app.itemimport.ItemImport.loadXML(ItemImport.java:1277) > at > org.dspace.app.itemimport.ItemImport.loadDublinCore(ItemImport.java:803) > at > org.dspace.app.itemimport.ItemImport.loadMetadata(ItemImport.java:788) > at > org.dspace.app.itemimport.ItemImport.addItem(ItemImport.java:634) > at > org.dspace.app.itemimport.ItemImport.addItems(ItemImport.java:506) > at org.dspace.app.itemimport.ItemImport.main(ItemImport.java:415) > org.xml.sax.SAXParseException: The reference to entity "request" must end > with the ';' delimiter. > > In file Attach XML for load. > _______________________________________________ > Dspace-general mailing list > Dspace-general at mit.edu > http://mailman.mit.edu/mailman/listinfo/dspace-general > From rcastro at alerta.cl Mon Sep 1 16:04:07 2008 From: rcastro at alerta.cl (Rodrigo Castro Artigas) Date: Mon, 1 Sep 2008 16:04:07 -0400 Subject: [Dspace-general] Carga de Registros Dspace In-Reply-To: References: <001501c90c68$67ca40d0$375ec270$@cl> Message-ID: <003a01c90c6d$e415eae0$ac41c0a0$@cl> The url is: http://146.155.39.20:8991/F?func=find-b&request=9783540715825&find_code=ISBN &adjacent=N&local_base=SIBUC&filter_code_4=WFT&filter_request_4=&filter_code _5=WSL&filter_request_5=&filter_code_1=WLN&filter_request_1=&filter_code_2=W YR&filter_request_2=&filter_code_3=WYR&filter_request_3=&x=37&y=9 -----Mensaje original----- De: Claudia Juergen [mailto:Claudia.Juergen at ub.uni-dortmund.de] Enviado el: Lunes, 01 de Septiembre de 2008 15:57 Para: Rodrigo Castro Artigas CC: dspace-general at mit.edu Asunto: Re: [Dspace-general] Carga de Registros Dspace Hola Rodrigo, it's the value of the URI that renders the xml unvalid. Hope that helps Claudia > Hi, i am loading Items a Dspace, and follow the next message: > > > [root at SDSPACE bin]# ./dsrun org.dspace.app.itemimport.ItemImport -a -e > ajasmen at alerta.cl -c "10" -s "/alerta/dspace/LIBROS" -m "100" > Destination collections: > Owning Collection: Libros por Cap??tulos (prueba) > Adding items from directory: /alerta/dspace/LIBROS > Generating mapfile: 100 > Adding item from directory 1 > [Fatal Error] dublin_core.xml:9:88: The reference to entity "request" must > end with the ';' delimiter. > org.xml.sax.SAXParseException: The reference to entity "request" must end > with the ';' delimiter. > at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) > at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown > Source) > at > javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:151) > at > org.dspace.app.itemimport.ItemImport.loadXML(ItemImport.java:1277) > at > org.dspace.app.itemimport.ItemImport.loadDublinCore(ItemImport.java:803) > at > org.dspace.app.itemimport.ItemImport.loadMetadata(ItemImport.java:788) > at > org.dspace.app.itemimport.ItemImport.addItem(ItemImport.java:634) > at > org.dspace.app.itemimport.ItemImport.addItems(ItemImport.java:506) > at org.dspace.app.itemimport.ItemImport.main(ItemImport.java:415) > org.xml.sax.SAXParseException: The reference to entity "request" must end > with the ';' delimiter. > > In file Attach XML for load. > _______________________________________________ > Dspace-general mailing list > Dspace-general at mit.edu > http://mailman.mit.edu/mailman/listinfo/dspace-general > From Claudia.Juergen at ub.uni-dortmund.de Mon Sep 1 16:21:39 2008 From: Claudia.Juergen at ub.uni-dortmund.de (Claudia Juergen) Date: Mon, 1 Sep 2008 22:21:39 +0200 (CEST) Subject: [Dspace-general] Carga de Registros Dspace In-Reply-To: <003a01c90c6d$e415eae0$ac41c0a0$@cl> References: <001501c90c68$67ca40d0$375ec270$@cl> <003a01c90c6d$e415eae0$ac41c0a0$@cl> Message-ID: <7494825f5ba7a4e5c2e0a256ecc35e9f.squirrel@mail.ub.uni-dortmund.de> Hi Rodriguo, the URL renders the dublin_core.xml invalid. & > < ' " are reservered signs in xml. Try replacing it with http://146.155.39.20:8991/F?func=find-b&request=9783540715825;&find_code=ISBN&adjacent=N&local_base=SIBUC&filter_code_4=WFT&filter_request_4=&filter_code_5=WSL&filter_request_5=&filter_code_1=WLN&filter_request_1=&filter_code_2=WYR&filter_request_2=&filter_code_3=WYR&filter_request_3=&x=37&y=9 Claudia > The url is: > > http://146.155.39.20:8991/F?func=find-b&request=9783540715825&find_code=ISBN > &adjacent=N&local_base=SIBUC&filter_code_4=WFT&filter_request_4=&filter_code > _5=WSL&filter_request_5=&filter_code_1=WLN&filter_request_1=&filter_code_2=W > YR&filter_request_2=&filter_code_3=WYR&filter_request_3=&x=37&y=9 > > > > -----Mensaje original----- > De: Claudia Juergen [mailto:Claudia.Juergen at ub.uni-dortmund.de] > Enviado el: Lunes, 01 de Septiembre de 2008 15:57 > Para: Rodrigo Castro Artigas > CC: dspace-general at mit.edu > Asunto: Re: [Dspace-general] Carga de Registros Dspace > > Hola Rodrigo, > > it's the value of the URI that renders the xml unvalid. > > Hope that helps > > Claudia > >> Hi, i am loading Items a Dspace, and follow the next message: >> >> >> [root at SDSPACE bin]# ./dsrun org.dspace.app.itemimport.ItemImport -a -e >> ajasmen at alerta.cl -c "10" -s "/alerta/dspace/LIBROS" -m "100" >> Destination collections: >> Owning Collection: Libros por Cap??tulos (prueba) >> Adding items from directory: /alerta/dspace/LIBROS >> Generating mapfile: 100 >> Adding item from directory 1 >> [Fatal Error] dublin_core.xml:9:88: The reference to entity "request" >> must >> end with the ';' delimiter. >> org.xml.sax.SAXParseException: The reference to entity "request" must >> end >> with the ';' delimiter. >> at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) >> at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown >> Source) >> at >> javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:151) >> at >> org.dspace.app.itemimport.ItemImport.loadXML(ItemImport.java:1277) >> at >> org.dspace.app.itemimport.ItemImport.loadDublinCore(ItemImport.java:803) >> at >> org.dspace.app.itemimport.ItemImport.loadMetadata(ItemImport.java:788) >> at >> org.dspace.app.itemimport.ItemImport.addItem(ItemImport.java:634) >> at >> org.dspace.app.itemimport.ItemImport.addItems(ItemImport.java:506) >> at >> org.dspace.app.itemimport.ItemImport.main(ItemImport.java:415) >> org.xml.sax.SAXParseException: The reference to entity "request" must >> end >> with the ';' delimiter. >> >> In file Attach XML for load. >> _______________________________________________ >> Dspace-general mailing list >> Dspace-general at mit.edu >> http://mailman.mit.edu/mailman/listinfo/dspace-general >> > > From rcastro at alerta.cl Mon Sep 1 16:26:23 2008 From: rcastro at alerta.cl (Rodrigo Castro Artigas) Date: Mon, 1 Sep 2008 16:26:23 -0400 Subject: [Dspace-general] Carga de Registros Dspace In-Reply-To: <7494825f5ba7a4e5c2e0a256ecc35e9f.squirrel@mail.ub.uni-dortmund.de> References: <001501c90c68$67ca40d0$375ec270$@cl> <003a01c90c6d$e415eae0$ac41c0a0$@cl> <7494825f5ba7a4e5c2e0a256ecc35e9f.squirrel@mail.ub.uni-dortmund.de> Message-ID: <004701c90c71$00df9420$029ebc60$@cl> Thanks you, it?s very good!!! -----Mensaje original----- De: Claudia Juergen [mailto:Claudia.Juergen at ub.uni-dortmund.de] Enviado el: Lunes, 01 de Septiembre de 2008 16:22 Para: Rodrigo Castro Artigas CC: dspace-general at mit.edu Asunto: RE: [Dspace-general] Carga de Registros Dspace Hi Rodriguo, the URL renders the dublin_core.xml invalid. & > < ' " are reservered signs in xml. Try replacing it with http://146.155.39.20:8991/F?func=find-b&request=9783540 715825;&find_code=ISBN&adjacent=N&local_base=SIBUC&filter_co de_4=WFT&filter_request_4=&filter_code_5=WSL&filter_request_5=&a mp;filter_code_1=WLN&filter_request_1=&filter_code_2=WYR&filter_ request_2=&filter_code_3=WYR&filter_request_3=&x=37&y=9 Claudia > The url is: > > http://146.155.39.20:8991/F?func=find-b&request=9783540715825&find_code=ISBN > &adjacent=N&local_base=SIBUC&filter_code_4=WFT&filter_request_4=&filter_code > _5=WSL&filter_request_5=&filter_code_1=WLN&filter_request_1=&filter_code_2=W > YR&filter_request_2=&filter_code_3=WYR&filter_request_3=&x=37&y=9 > > > > -----Mensaje original----- > De: Claudia Juergen [mailto:Claudia.Juergen at ub.uni-dortmund.de] > Enviado el: Lunes, 01 de Septiembre de 2008 15:57 > Para: Rodrigo Castro Artigas > CC: dspace-general at mit.edu > Asunto: Re: [Dspace-general] Carga de Registros Dspace > > Hola Rodrigo, > > it's the value of the URI that renders the xml unvalid. > > Hope that helps > > Claudia > >> Hi, i am loading Items a Dspace, and follow the next message: >> >> >> [root at SDSPACE bin]# ./dsrun org.dspace.app.itemimport.ItemImport -a -e >> ajasmen at alerta.cl -c "10" -s "/alerta/dspace/LIBROS" -m "100" >> Destination collections: >> Owning Collection: Libros por Cap??tulos (prueba) >> Adding items from directory: /alerta/dspace/LIBROS >> Generating mapfile: 100 >> Adding item from directory 1 >> [Fatal Error] dublin_core.xml:9:88: The reference to entity "request" >> must >> end with the ';' delimiter. >> org.xml.sax.SAXParseException: The reference to entity "request" must >> end >> with the ';' delimiter. >> at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) >> at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown >> Source) >> at >> javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:151) >> at >> org.dspace.app.itemimport.ItemImport.loadXML(ItemImport.java:1277) >> at >> org.dspace.app.itemimport.ItemImport.loadDublinCore(ItemImport.java:803) >> at >> org.dspace.app.itemimport.ItemImport.loadMetadata(ItemImport.java:788) >> at >> org.dspace.app.itemimport.ItemImport.addItem(ItemImport.java:634) >> at >> org.dspace.app.itemimport.ItemImport.addItems(ItemImport.java:506) >> at >> org.dspace.app.itemimport.ItemImport.main(ItemImport.java:415) >> org.xml.sax.SAXParseException: The reference to entity "request" must >> end >> with the ';' delimiter. >> >> In file Attach XML for load. >> _______________________________________________ >> Dspace-general mailing list >> Dspace-general at mit.edu >> http://mailman.mit.edu/mailman/listinfo/dspace-general >> > > From dsalo at library.wisc.edu Mon Sep 1 18:04:48 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Mon, 1 Sep 2008 17:04:48 -0500 Subject: [Dspace-general] Week 3: Good Repository Software Message-ID: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> Sorry, all, I was on holiday and didn't think to set up this week's question in advance. (Also, since the statistics discussion is still ongoing, I'm waiting to summarize to the wiki until talk dies down. By all means keep talking!) This week's question sounds simple but isn't. What is good repository software? What does it allow us to do (both macro- and micro-level)? What do we accomplish with it? I'm going to ask that respondents please write their own answers before reading those of others! I would like to see some diversity of response. Feel free to respond directly to me if you feel uncomfortable answering on the list. I will moderate a chat on this topic in the DSpace IRC room (#dspace on irc.freenode.net) on Wednesday at 10 am Central, 11 Eastern, 4 pm GMT. Have at it! Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From bram at mire.be Tue Sep 2 04:03:14 2008 From: bram at mire.be (Bram Luyten) Date: Tue, 2 Sep 2008 10:03:14 +0200 Subject: [Dspace-general] [Dspace-tech] Week 3: Good Repository Software In-Reply-To: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> Message-ID: Hello Dorothea, another excellent topic. Because the question is so broad, I'd like to narrow my response down to two areas: good repository functionality and good software. Although the areas I describe might have some low-baseline definition of what's good or bad, it's often a case of "what's good enough, to reach the intended purpose of the system". Stated differently "What's good enough to address the needs and requiremens of my institution". 1. Good Repository Functionality 1.1 Flexibility to "properly" ingest and support all the types of data and information that the system claims it can ingest and support. If the system claims it can ingest any bitstream, together with a series of descriptive metadata fields, it should be really able to do so. However, this might not be the detailed definition of "properly" that your institution has in mind. For example: * If there is a need to ingest and properly support an item, and keep the relation between that item and it's different versions, additional functionality is required. * Special collections often have a need for special purpose functionality: "properly" ingesting video files and supporting them, might mean they should be converted on ingest and being streamed instead of downloaded when someone clicks the files. A good general purpose repository can be configured or customized in order to get as close to this required definition of "properly". It should state which kinds of special purpose functionality it supports. An open interface should be available for institutions or third parties to create additional special purpose functionality for ingesting and properly supporting special formats. 1.2 Future-proof: ensuring that all stored data or information can be migrated or exported in a lossless way. Although many (database) systems claim that they can stand time, the average lifespan of information storage systems are still around 10 years. A good repository platform offers functionality to both migrate metadata and bitstreams, to newer formats, or has at least an open API that allows you to plug other migration or export software. 2. Good Software 2.1 Continuity: Active community, open source, reliable vendors Good software doesn't imply that it is free of defects or bugs. That's why continuous improvement is a hard requirement when you decide to integrate a repository platform as a strategic system within your institution. A lively community of developers and users is a good base to start from, whether commercial or open source: if the software is widely used or sold, it demonstrates that support will probably be around for a while. If the code of the system is open source, your institution can always modify the code itself, if no other help is available. Nowadays, commercial vendors often have escrow agreements that offer clients the code as well, once the company ceases to exist or stops offering support for certain products. In either case, if you want to assess continuity: the number of developpers, number of deployed installations, release cycle history or the future release roadmap are good indicators to look at. 2.2 Scalability The software should make a clear statement what magnitudes of users, stored objects, ... can be handled. If this is a fuzzy area, a range of examples should be available to demonstrate which combinations of the software, and server configurations work to serve a certain load, and which don't. It would be great if you could state this requirement as "the system should support an infinite number of users, and an infinite amount of stored data", but I'm afraid that's a bit far-fetched for any system. 2.3 Compatibility If the software heavily relies on other software components (java, apache, databases, ...), the software should be compatible with recent versions of these components, mainly for performance and security reasons. If there is no such compatibility yet, someone should be able to estimate when it will be. 2.4 Usability Good software should be user friendly. It's difficult to make sure that all types of users will be able to figure out in a short time-span how they can do the actions they want. I think a baseline for usability is the presence of meaningful error messages for administrators. The person who achieved to install and run the repository, should first of all receive an error message when something goes wrong. Based on that error message, a community or other third party should be able to help this person. Concerning usability of interfaces: I believe there's nothing wrong with having an "administrator" or "expert user" interface, where you can actually damage the system infrastructure through wrong usage ... But every one of these administrator interfaces should be properly documented. with kindest regards, Bram Luyten -- @mire NV Romeinse Straat 18 3001 Heverlee Belgium +32 2 888 29 56 http://www.atmire.com - Institutional Repository Solutions http://www.togather.eu - Before getting together, get Tog at ther On Tue, Sep 2, 2008 at 12:04 AM, Dorothea Salo wrote: > Sorry, all, I was on holiday and didn't think to set up this week's > question in advance. (Also, since the statistics discussion is still > ongoing, I'm waiting to summarize to the wiki until talk dies down. By > all means keep talking!) > > This week's question sounds simple but isn't. What is good repository > software? What does it allow us to do (both macro- and micro-level)? > What do we accomplish with it? > > I'm going to ask that respondents please write their own answers > before reading those of others! I would like to see some diversity of > response. Feel free to respond directly to me if you feel > uncomfortable answering on the list. > > I will moderate a chat on this topic in the DSpace IRC room (#dspace > on irc.freenode.net) on Wednesday at 10 am Central, 11 Eastern, 4 pm > GMT. > > Have at it! > > Dorothea > > -- > Dorothea Salo dsalo at library.wisc.edu > Digital Repository Librarian AIM: mindsatuw > University of Wisconsin > Rm 218, Memorial Library > (608) 262-5493 > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > DSpace-tech mailing list > DSpace-tech at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080902/526e1835/attachment.htm From dsalo at library.wisc.edu Tue Sep 2 11:27:39 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Tue, 2 Sep 2008 10:27:39 -0500 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> Message-ID: <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> BLUNTNESS ALERT. This is not a happy email. I have tried to make it a reasonably diplomatic one, but I may well have failed, in which case I apologize in advance. I'm going to tip my hand here. I am speaking from the perspective of a repository manager, not a software architect or developer. From that perspective, I don't think DSpace is good repository software. From where I'm sitting -- on top of a repository that has not met its library system's hopes and expectations *and is currently being called to account for that* -- it's pretty terrible repository software. Let's start from two axioms: Axiom 1. The most elegant, stable, reliable, preservation-ready, standards-compliant, easy-to-install, easy-to-maintain repository software package in the WORLD is completely useless -- worse, indefensible -- if it does not attract deposits. Do not tell me "that's a political problem" or "that's a marketing/outreach problem." In part it is, but the politics at my institutions are not lining up behind it, and marketing and outreach are useless without a compelling value proposition. It certainly doesn't help matters that the repository I run has been an albatross thus far, in considerable part due to DSpace's limitations (usage reports, anyone?). My local credibility and my ability to argue convincingly for resources and support for the repository have been heavily tarnished by that. The conclusion is simple: DSpace software must present a compelling value proposition *all by itself* -- without hacks, without outside software, without local developer support, without guarantee of deposit support -- if the repository I run is to survive at all. I do not believe that this repository is alone in that respect; far from it. I believe that most people in my shoes in the United States are living professional lives of (too-)quiet desperation. Axiom 2. The abovementioned ideal repository software package will not attract deposits if it does not solve a problem that depositors (not libraries, not IT, not administrators, DEPOSITORS) perceive that they have. Ergo my answer to this week's question is: Good repository software solves depositors' data- and publication-management problems. Let me point out, because I've seen this consistently missed, that if I don't or can't solve data- and publication-management problems as they come to me, the people with those problems won't come to me with their other problems *even if I can actually solve them*, nor will they recommend the repository to their colleagues. This has happened to me over and over and *over* again in the three years I've been running DSpace repositories. I am Sisyphus, and that infernal stone keeps rolling down the mountain. This answer, of course, begs a question: what *are* faculty's data- and publication-management problems? Here are some problems that faculty at the institutions I serve have admitted to: - collaborating on unfinished work across institutional boundaries, securely and easily - storing and maintaining substantial amounts of data (in highly heterogeneous forms) and writing, both while projects are underway and afterwards - safely storing data that cannot be shown or even hinted at (for a wide variety of reasons) to people outside a certain group (often the campus or the university system, but sometimes an ad-hoc group) - loading their data from their software and their servers into a safe storage place, with as little manual intervention as possible, preferably none - (in some disciplines) coming up with a sustainable data-management plan to satisfy grant requirements - dealing with electronic works that they want to save, often works by third parties such as students; ETDs, of course, but also honors projects, graduate/undergraduate research journals, and local publications such as newsletters and working-papers series - managing their publication record, irrespective of whether they are permitted to self-archive some or all of it; use cases include annual reviews, tenure-and-promotion packages, and online presence - (in some disciplines) coping with funder-mandated requirements for open access to published work arising from a grant - dealing with electronic materials requiring preservation arising from faculty retirements None of this should be surprising; the data-curation literature is full of these and similar problems. I am leaving digitization support out of the picture, not because it isn't important (it is!), but because it's a problem DSpace can't feasibly solve -- it's *genuinely* a political problem. Still and all, it's worlds harder to solve this political problem when DSpace's limitations leave me with a credibility deficit to overcome. The problem that DSpace was designed for -- self-archiving of peer-reviewed journal articles in an institution-based repository for purposes of open access -- does not appear on the above list. Bluntly, this is because faculty do not perceive self-archiving as a problem they have or wish to solve. At the moment, there are two institutions in the United States that are entitled to say that some of their faculty think otherwise: Harvard and Stanford. DSpace presumably wishes to appeal to more than two institutions! DSpace can go on being an elegant solution to a nonexistent problem, in which case I believe it is doomed, or it can solve problems that potential depositors have. Those are its only two choices from where I'm sitting. Continuing to proclaim "problems that people actually have are out of scope!" is not a viable option. The agreed-upon scope has heretofore been hopelessly misdefined. This is not DSpace developers' fault, I hasten to say; developers didn't come up with the open-access "build it and they will come" ideology which has foundered on the rock of faculty apathy. This has led to the vast majority of DSpace repositories in the United States becoming white elephants. (Wikipedia definition of a white elephant: "a valuable possession which its owner cannot dispose of and whose cost [particularly cost of upkeep] exceeds its usefulness." Right on, Wikipedia. Right on.) I'm sorry if that's unwelcome news. It's my daily reality. My career and the repository's continuance are riding on me being able to turn that around, and frankly, the odds are not presently in my favor -- and I own a lot of that, I willingly grant, but DSpace owns some of it too. It's worth noting that solving some of the above problems would create fertile ground for acquiring appropriate versions of the eventual published literature based on the research projects served. Even those who are unilaterally committed to open access should support an expansion of DSpace's problem-space, because open access gained as a byproduct of other solved problems *is still open access*. In short, I believe DSpace could do far worse than take on "solving depositors' data- and publication-management problems" as its new scope, since remaining committed to the old one will mire DSpace in irrelevance. So. There are a few relatively easy changes that would help me a great deal in answering some of the above challenges: - True dark archiving: fix the OAI-PMH hole, please! Some collection owners do not *want* or *cannot legally leave* collection metadata hanging in the breeze. They need to have the option of hiding it *completely*, or they walk away from the repository. - Embargoes. - Bitstream-less items. Somewhat more difficult fixes that would have great impact: - File versioning. - User- and depositor-facing usage reports, as discussed last week. - Elimination of per-item licensing, replaced with a single Terms of Service click-through. (I can elaborate on this if desired.) - Streamlining and simplification of the deposit process, including accepting incomplete deposits (even just a file!) for later inspection/revision/management by a third party. - Better display options for a broader variety of content. I need a page-turner, an image browser, and a journal browser that behaves like a journal browser -- and that's just for the content I *currently have*, not the content I foresee wanting to cope with in future. - Easier machine-to-machine deposit. SWORD is good, but frankly, it's too hard or out-of-reach for most of the data sources I can imagine. I need DSpace to deal with crappy RSS feeds, because crappy RSS feeds are what by-author searches of literature databases can produce, and local IT folks can usually hack together crappy RSS feeds. I also need DSpace to cope with watch folders, because "put it here on the server and I'll deal with it" is a value proposition I can sell. So is "DSpace will watch your page and ingest any new issues of your publication automagically." So is "DSpace can serve as the preservation datastore for your OJS/OCS/Omeka/ContentDM/Greenstone/Kete/whatever installation." - Better hooks for transcluding metadata in other contexts. I want one- or no-click publication histories by author, in HTML and RTF at a minimum. I want prettily-formatted, logically-organized lists of publications in a given collection via a single line of Javascript. I want Researcher Pages. (One of the campuses I serve is seriously threatening to defect to BePress because of the Selected Works feature. This is what I mean when I say that value propositions for depositors are *not optional*, *not frills*, in DSpace.) I want COinS and RefWorks export. I do believe that technological integration with Fedora Commons will go a considerable distance toward escaping the shackles bolted on by DSpace's too-narrow conception of its mission, and I wholeheartedly endorse motion in that direction. Whew. Sorry about this; it's a bit of a broadside. All I can say in my own defense is that I wouldn't bother if I didn't care as deeply as I do. I whinge because I love! Repository managers: If any of this rings a bell with you, I need you to stand up and say so publicly. "The lurkers support me in email" (see ) is no more going to get these problems solved in future than it has in the past. Dorothea From denials at gmail.com Tue Sep 2 22:45:23 2008 From: denials at gmail.com (Dan Scott) Date: Tue, 2 Sep 2008 22:45:23 -0400 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> Message-ID: 2008/9/2 Dorothea Salo : > BLUNTNESS ALERT. This is not a happy email. I have tried to make it a > reasonably diplomatic one, but I may well have failed, in which case I > apologize in advance. > Repository managers: If any of this rings a bell with you, I need you > to stand up and say so publicly. "The lurkers support me in email" > (see ) > is no more going to get these problems solved in future than it has in > the past. Ding ding ding. I cheated and just read your response. I could definitely get behind your vision for repository software. I'll apologize up front if I'm behind the times - I've been trying to avoid doing anything with DSpace since managing to get a 1.4.2 + various i18n patch version up and running last year. I would add "thorough internationalization support" to the list. The interfaces are translatable but the metadata needs to be translatable and equally searchable too. Our collection and community names are a prime example; we're a bilingual university, yet the lack of support for collection and community names in multiple languages forced us (in 1.4.2) to choose to use either "English / French" or "French / English" for the names - and either choice has both usability and political ramifications. Is there support yet for ordering bitstreams for a given item in user-dictated fashion? One of our first enthusiastic adopters published a full book in our 1.4.2-based repository, but the base hack that we used to get his chapters to appear in the desired order was to name the chapters A.pdf, B.pdf, C.pdf... sigh. -- Dan Scott Laurentian University From Claudia.Juergen at ub.uni-dortmund.de Wed Sep 3 06:39:52 2008 From: Claudia.Juergen at ub.uni-dortmund.de (=?ISO-8859-1?Q?Claudia_J=FCrgen?=) Date: Wed, 03 Sep 2008 12:39:52 +0200 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> Message-ID: <48BE6978.1000902@ub.uni-dortmund.de> Hi all, just some general thought, as I can't participate in the weekly chat meeting. A good repository should have a defined scope and concentrate on it's core tasks i.e. to "capture, index, preserve and distribute" the material of it's institution and perform these well. Furthermore it should integrate with it's "natural habitat". In my opinion (a repo do-it-all) it might be dangerous to try to convert it to an all-in-one device suitable for every purpose. Taking a university as a use case (the most common one for DSpace) there are many business processes (elearning, research evaluation, collaborative work, informatione management ...) for which appropriate tools exist and form part of the institutions working environment. With these a repository should be able to interact and thus form a part of the institutions infrastructure. Sunny greetings Claudia J?rgen Dorothea Salo schrieb: > BLUNTNESS ALERT. This is not a happy email. I have tried to make it a > reasonably diplomatic one, but I may well have failed, in which case I > apologize in advance. > > I'm going to tip my hand here. I am speaking from the perspective of a > repository manager, not a software architect or developer. From that > perspective, I don't think DSpace is good repository software. From > where I'm sitting -- on top of a repository that has not met its > library system's hopes and expectations *and is currently being called > to account for that* -- it's pretty terrible repository software. > > Let's start from two axioms: > > Axiom 1. The most elegant, stable, reliable, preservation-ready, > standards-compliant, easy-to-install, easy-to-maintain repository > software package in the WORLD is completely useless -- worse, > indefensible -- if it does not attract deposits. > > Do not tell me "that's a political problem" or "that's a > marketing/outreach problem." In part it is, but the politics at my > institutions are not lining up behind it, and marketing and outreach > are useless without a compelling value proposition. It certainly > doesn't help matters that the repository I run has been an albatross > thus far, in considerable part due to DSpace's limitations (usage > reports, anyone?). My local credibility and my ability to argue > convincingly for resources and support for the repository have been > heavily tarnished by that. The conclusion is simple: DSpace software > must present a compelling value proposition *all by itself* -- without > hacks, without outside software, without local developer support, > without guarantee of deposit support -- if the repository I run is to > survive at all. I do not believe that this repository is alone in that > respect; far from it. I believe that most people in my shoes in the > United States are living professional lives of (too-)quiet > desperation. > > Axiom 2. The abovementioned ideal repository software package will not > attract deposits if it does not solve a problem that depositors (not > libraries, not IT, not administrators, DEPOSITORS) perceive that they > have. > > Ergo my answer to this week's question is: Good repository software > solves depositors' data- and publication-management problems. Let me > point out, because I've seen this consistently missed, that if I don't > or can't solve data- and publication-management problems as they come > to me, the people with those problems won't come to me with their > other problems *even if I can actually solve them*, nor will they > recommend the repository to their colleagues. This has happened to me > over and over and *over* again in the three years I've been running > DSpace repositories. I am Sisyphus, and that infernal stone keeps > rolling down the mountain. > > This answer, of course, begs a question: what *are* faculty's data- > and publication-management problems? Here are some problems that > faculty at the institutions I serve have admitted to: > > - collaborating on unfinished work across institutional boundaries, > securely and easily > > - storing and maintaining substantial amounts of data (in highly > heterogeneous forms) and writing, both while projects are underway and > afterwards > > - safely storing data that cannot be shown or even hinted at (for a > wide variety of reasons) to people outside a certain group (often the > campus or the university system, but sometimes an ad-hoc group) > > - loading their data from their software and their servers into a safe > storage place, with as little manual intervention as possible, > preferably none > > - (in some disciplines) coming up with a sustainable data-management > plan to satisfy grant requirements > > - dealing with electronic works that they want to save, often works by > third parties such as students; ETDs, of course, but also honors > projects, graduate/undergraduate research journals, and local > publications such as newsletters and working-papers series > > - managing their publication record, irrespective of whether they are > permitted to self-archive some or all of it; use cases include annual > reviews, tenure-and-promotion packages, and online presence > > - (in some disciplines) coping with funder-mandated requirements for > open access to published work arising from a grant > > - dealing with electronic materials requiring preservation arising > from faculty retirements > > None of this should be surprising; the data-curation literature is > full of these and similar problems. I am leaving digitization support > out of the picture, not because it isn't important (it is!), but > because it's a problem DSpace can't feasibly solve -- it's *genuinely* > a political problem. Still and all, it's worlds harder to solve this > political problem when DSpace's limitations leave me with a > credibility deficit to overcome. > > The problem that DSpace was designed for -- self-archiving of > peer-reviewed journal articles in an institution-based repository for > purposes of open access -- does not appear on the above list. Bluntly, > this is because faculty do not perceive self-archiving as a problem > they have or wish to solve. At the moment, there are two institutions > in the United States that are entitled to say that some of their > faculty think otherwise: Harvard and Stanford. DSpace presumably > wishes to appeal to more than two institutions! > > DSpace can go on being an elegant solution to a nonexistent problem, > in which case I believe it is doomed, or it can solve problems that > potential depositors have. Those are its only two choices from where > I'm sitting. Continuing to proclaim "problems that people actually > have are out of scope!" is not a viable option. The agreed-upon scope > has heretofore been hopelessly misdefined. This is not DSpace > developers' fault, I hasten to say; developers didn't come up with the > open-access "build it and they will come" ideology which has foundered > on the rock of faculty apathy. > > This has led to the vast majority of DSpace repositories in the United > States becoming white elephants. (Wikipedia definition of a white > elephant: "a valuable possession which its owner cannot dispose of and > whose cost [particularly cost of upkeep] exceeds its usefulness." > Right on, Wikipedia. Right on.) I'm sorry if that's unwelcome news. > It's my daily reality. My career and the repository's continuance are > riding on me being able to turn that around, and frankly, the odds are > not presently in my favor -- and I own a lot of that, I willingly > grant, but DSpace owns some of it too. > > It's worth noting that solving some of the above problems would create > fertile ground for acquiring appropriate versions of the eventual > published literature based on the research projects served. Even those > who are unilaterally committed to open access should support an > expansion of DSpace's problem-space, because open access gained as a > byproduct of other solved problems *is still open access*. > > In short, I believe DSpace could do far worse than take on "solving > depositors' data- and publication-management problems" as its new > scope, since remaining committed to the old one will mire DSpace in > irrelevance. > > So. There are a few relatively easy changes that would help me a great > deal in answering some of the above challenges: > > - True dark archiving: fix the OAI-PMH hole, please! Some collection > owners do not *want* or *cannot legally leave* collection metadata > hanging in the breeze. They need to have the option of hiding it > *completely*, or they walk away from the repository. > - Embargoes. > - Bitstream-less items. > > Somewhat more difficult fixes that would have great impact: > > - File versioning. > > - User- and depositor-facing usage reports, as discussed last week. > > - Elimination of per-item licensing, replaced with a single Terms of > Service click-through. (I can elaborate on this if desired.) > > - Streamlining and simplification of the deposit process, including > accepting incomplete deposits (even just a file!) for later > inspection/revision/management by a third party. > > - Better display options for a broader variety of content. I need a > page-turner, an image browser, and a journal browser that behaves like > a journal browser -- and that's just for the content I *currently > have*, not the content I foresee wanting to cope with in future. > > - Easier machine-to-machine deposit. SWORD is good, but frankly, it's > too hard or out-of-reach for most of the data sources I can imagine. I > need DSpace to deal with crappy RSS feeds, because crappy RSS feeds > are what by-author searches of literature databases can produce, and > local IT folks can usually hack together crappy RSS feeds. I also need > DSpace to cope with watch folders, because "put it here on the server > and I'll deal with it" is a value proposition I can sell. So is > "DSpace will watch your page and ingest any new issues of your > publication automagically." So is "DSpace can serve as the > preservation datastore for your > OJS/OCS/Omeka/ContentDM/Greenstone/Kete/whatever installation." > > - Better hooks for transcluding metadata in other contexts. I want > one- or no-click publication histories by author, in HTML and RTF at a > minimum. I want prettily-formatted, logically-organized lists of > publications in a given collection via a single line of Javascript. I > want Researcher Pages. (One of the campuses I serve is seriously > threatening to defect to BePress because of the Selected Works > feature. This is what I mean when I say that value propositions for > depositors are *not optional*, *not frills*, in DSpace.) I want COinS > and RefWorks export. > > I do believe that technological integration with Fedora Commons will > go a considerable distance toward escaping the shackles bolted on by > DSpace's too-narrow conception of its mission, and I wholeheartedly > endorse motion in that direction. > > Whew. Sorry about this; it's a bit of a broadside. All I can say in my > own defense is that I wouldn't bother if I didn't care as deeply as I > do. I whinge because I love! > > Repository managers: If any of this rings a bell with you, I need you > to stand up and say so publicly. "The lurkers support me in email" > (see ) > is no more going to get these problems solved in future than it has in > the past. > > Dorothea > _______________________________________________ > Dspace-general mailing list > Dspace-general at mit.edu > http://mailman.mit.edu/mailman/listinfo/dspace-general From mwood at IUPUI.Edu Wed Sep 3 09:24:04 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Wed, 3 Sep 2008 09:24:04 -0400 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> Message-ID: <20080903132404.GG24559@IUPUI.Edu> Lots of folks are better positioned than I to describe excellence in document repository software from the end-user or content-administrator or organizational-administrator POV, so I'll confine my comments to the operational and information-architecture POV. o Leverages the organization's existing authentication and identity systems. DSpace has been getting better at the former, still shows room for improvement in the latter. (Example: when registering a user authenticated through LDAP, there's no need to store locator info. such as a phone number or email address, because we can just fetch those from the directory when asked, and if we *do* store them then the data become stale over time.) o Instrumented for monitoring and maintenance. This goes beyond statistics. Example: I want to build an application-level backup system under DSpace so that we can fan out several dead-storage copies of new acquisitions *once* rather than backing up terabytes of static files every week forever. To do that, my gadget needs to know when a new item comes in and how to identify it. o Configurable without rebuilding. I think the current setup process knows too much about deployment issues. DSpace is atypically good in this respect among the Java app.s I've seen, but I'd like to see even better decoupling between build time and runtime. (I haven't yet spent enough time with 1.5 to say how much the situation has improved there.) o Routine operational procedures should be completely automatable. Any operation which requires a sysadmin. to sit at a console and click buttons is a manual process. There should be no manual processes required for any repetitive task. (This isn't speaking about content ingestion, which is a creative activity and *should* be hands-on.) DSpace is good here -- I just want to keep it that way. o User functions exposed programmatically. The repository should be usable by machines, not just humans. Someone is going to come up with a use for our pool of documents which is quite unlike anything we've imagined, and he should be able to just use the documents and/or metadata without going up to his elbows into DSpace code. Abstracting a bit, I think a repo. should be well fitted to serve as a component in the organization's information architecture, not just an isolated tool. It should use other components which are useful and strive to be useful to other components. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080903/ce815f3c/attachment.bin From grotophorst at mac.com Wed Sep 3 10:03:37 2008 From: grotophorst at mac.com (wally grotophorst) Date: Wed, 03 Sep 2008 10:03:37 -0400 Subject: [Dspace-general] Week 3: Good Repository Software Message-ID: <48BE9939.3060605@mac.com> I cheated too...and Dorothea's right. DSpace, for all the many things it does well, really isn't yet a great end-to-end solution if you're actually running a digital repository. Stretch the system to store digital objects other than open-access offprints and it begins to feel unnecessarily cramped. I first got a copy of DSpace up and running in 2003. At the time I thought it was a lot more trouble than it should have been but understood that I didn't know all that much about Tomcat, JSPs or Postgres. Here in 2008, I still don't know a lot about Java and JSPs but I now realize that not all that many other people around the library world do either. When I see how little actual "work" DSpace does (I mean, we're not talking about a transaction-based, real-time processing sort of system), why such a complex codebase? Sure, a certain amount of over-engineering seems to accompany software projects that begin life in the library but on some level it does seem to end up strangling innovation... I suspect that if the original development team had decided to code the thing in PHP with a MySQL database, we'd be much further along in terms of user-contributed code enhancement (think WordPress). Of course, if like my toaster it did everything I asked, I wouldn't much care what the code looked like or why/how it worked. So complaining about the platform's code is my way of saying there are things that I'd like to fix if I could. Absent a rewrite of the code, I think these specific things would help: -- a way to address an individual bitstream--one that used the handle to resolve the hostname. I'd really like to be able to use other systems for display and have DSpace focus on maintaining the bitstreams. -- a quicker way to add content. The simple "upload your stuff' way that Flickr takes in a digital image and offers a few fields for user-supplied metadata could be a big help in getting faculty/researchers to add content. This content could go into some sort of "holding area" for review and post-upload editing, of course. The design goal would be to help end users bypass the current click-happy series of add-an-item pages. -- in the absence of deleting content, some way to handle versioning of documents -- a way to "hide" content (and associated metadata) on both the item level and the collection level. Wally Wally Grotophorst Associate University Librarian Digital Programs and Systems University Libraries George Mason University Fairfax, Virginia 22030 (703) 993-9005 From dsalo at library.wisc.edu Wed Sep 3 10:05:01 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Wed, 3 Sep 2008 09:05:01 -0500 Subject: [Dspace-general] Chat in one hour Message-ID: <356cf3980809030705xfe012bfg2edbc514017d6e5f@mail.gmail.com> By now you know the drill: irc.freenode.net, #dspace, one hour from now, to last one hour. I want to emphasize that there are no right or wrong answers to this week's question -- just different answers, and it's worthwhile to surface as many as we can. Thanks, all! Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From mwood at IUPUI.Edu Wed Sep 3 10:08:27 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Wed, 3 Sep 2008 10:08:27 -0400 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <20080903132404.GG24559@IUPUI.Edu> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <20080903132404.GG24559@IUPUI.Edu> Message-ID: <20080903140827.GH24559@IUPUI.Edu> *sigh* following up my own post. *sigh* I feel that good software should try not to do too much outside of its core competencies. This is why I keep whining about components. The more unrelated features you try to bind together, the fewer users will find your "solution" a good fit to their problems. A good solution to a large complex problem often boils down to a collection of solutions to small, organic problems, a collection well-chosen by the user or the organization, and different for different users/organizations. Components which each handle one agreed-upon problem well and which are easy to bind together make this approach workable. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080903/696bd6cb/attachment.bin From mwood at IUPUI.Edu Wed Sep 3 11:06:52 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Wed, 3 Sep 2008 11:06:52 -0400 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> Message-ID: <20080903150652.GI24559@IUPUI.Edu> On Tue, Sep 02, 2008 at 10:27:39AM -0500, Dorothea Salo wrote: > The problem that DSpace was designed for -- self-archiving of > peer-reviewed journal articles in an institution-based repository for > purposes of open access -- does not appear on the above list. Bluntly, > this is because faculty do not perceive self-archiving as a problem > they have or wish to solve. Nor should they. This is in large part a political problem precisely because the people who want an IR and the people who fill it are disjoint sets. It's the institution that (sometimes) perceives value in an IR. If the institution makes non-contribution a problem for faculty then faculty will want a solution. Perhaps not a happy situation. I'd like to hear of better ways. Faculty who want anything other than the status quo probably want disciplinary repositories, as has been pointed out before. The scope of the individual repository is probably irrelevant to the design of the tool, at least within the academic sphere. (The scope of the content surely is relevant, but that is another matter.) There's no reason that policies cannot permit, and encourage, deposit in both kinds of repositories as well as commercial publication. They just don't. Policy isn't properly part of the tool unless the tool's purpose is to enforce policy. Is there something special about IRs as opposed to any other kind of Rs which requires us to choose a path when designing the support tools? > - True dark archiving: fix the OAI-PMH hole, please! Some collection > owners do not *want* or *cannot legally leave* collection metadata > hanging in the breeze. They need to have the option of hiding it > *completely*, or they walk away from the repository. If DSpace is going to represent access permissions, then the access model should extend throughout the product. The PMH server should respect the access model. This still allows a site to set anonymous read access on all objects if it choose. > - Embargoes. A proper part of the document data model IMHO. It's been done, but we need it incorporated and configured on/off rather than patched in. > - Elimination of per-item licensing, replaced with a single Terms of > Service click-through. (I can elaborate on this if desired.) We've done that here in specialized circumstances. The hack is that every registered user of one of our DSpaces is automagically made a member of the depositors group of the single collection in that repo. and the registration form extended to require acceptance of the deposit license at registration time. It could be done better. > - Better display options for a broader variety of content. I need a > page-turner, an image browser, and a journal browser that behaves like > a journal browser -- and that's just for the content I *currently > have*, not the content I foresee wanting to cope with in future. Those are tools which address more than just DSpace. Can we find a way to separate them from the repo. across a well-defined interface which can be used by other services too? > - Easier machine-to-machine deposit. SWORD is good, but frankly, it's > too hard or out-of-reach for most of the data sources I can imagine. I > need DSpace to deal with crappy RSS feeds, because crappy RSS feeds > are what by-author searches of literature databases can produce, and > local IT folks can usually hack together crappy RSS feeds. I also need > DSpace to cope with watch folders, because "put it here on the server > and I'll deal with it" is a value proposition I can sell. So is > "DSpace will watch your page and ingest any new issues of your > publication automagically." So is "DSpace can serve as the > preservation datastore for your > OJS/OCS/Omeka/ContentDM/Greenstone/Kete/whatever installation." I think that SWORD or something like it is exactly what you need, but you shouldn't have to deal with it directly. DSpace won't solve this problem, but the DSpace community can! Those who can build tools to do this, please share them; those who cannot, please share ideas. It's likely that one site's solution will be useful at other sites, though not all. A collection of several solutions, available to the community, should serve most needs. > - Better hooks for transcluding metadata in other contexts. I want > one- or no-click publication histories by author, in HTML and RTF at a > minimum. I want prettily-formatted, logically-organized lists of > publications in a given collection via a single line of Javascript. I > want Researcher Pages. (One of the campuses I serve is seriously > threatening to defect to BePress because of the Selected Works > feature. This is what I mean when I say that value propositions for > depositors are *not optional*, *not frills*, in DSpace.) I want COinS > and RefWorks export. How do authors manage their records of their own work? Would they prefer Yet Another List, or a way to suck the information out into a mechanical bibliography compiler of some sort? Thinking of our own contributors: we run several DSpaces, ContentDM, OJS, and we're tooling up our second attempt at a "blog hotel". And authors also still deal with dead-tree publishers, which relationship is out of our hands. How do they acquire and collate all of that information? how would they *like* to do it? I think that helping DSpace users become more a community and less an audience will help a lot in addressing these "non-optional peripheral" issues, which typically need a basket of solutions in differing styles in order to please everybody. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080903/74a8701a/attachment.bin From mwood at IUPUI.Edu Wed Sep 3 12:12:59 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Wed, 3 Sep 2008 12:12:59 -0400 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <48BE9939.3060605@mac.com> References: <48BE9939.3060605@mac.com> Message-ID: <20080903161259.GJ24559@IUPUI.Edu> On Wed, Sep 03, 2008 at 10:03:37AM -0400, wally grotophorst wrote: > -- a way to address an individual bitstream--one that used the handle to > resolve the hostname. I'd really like to be able to use other systems > for display and have DSpace focus on maintaining the bitstreams. Yes! No matter how nice we make the DSpace UI, it should be thought of as the default. What makes information powerful is linking it together, and there are lots of ways to do that. HTML is good at linking, not so good (in practice) at capturing the many dimensions of knowledge. Repo.s are good at capturing metadata but haven't been so good at linking. Can we do better? > -- a quicker way to add content. The simple "upload your stuff' way > that Flickr takes in a digital image and offers a few fields for > user-supplied metadata could be a big help in getting > faculty/researchers to add content. This content could go into some > sort of "holding area" for review and post-upload editing, of course. > The design goal would be to help end users bypass the current > click-happy series of add-an-item pages. What about making a subset of available fields part of the user profile? "I'm willing to supply these fields." Of course, if people uncheck everything, then submission is easy, but OTOH why not just use WebDAV and forget about metadata? I suppose this means configuring what can be unchecked. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080903/d62028ef/attachment.bin From dsalo at library.wisc.edu Wed Sep 3 14:23:23 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Wed, 3 Sep 2008 13:23:23 -0500 Subject: [Dspace-general] Fwd: [SOAF] Statistics survey for repository users - Synergies Canada In-Reply-To: References: Message-ID: <356cf3980809031123y17110253pb1bc71df1836eda9@mail.gmail.com> In light of our discussion last week, I wanted to point this out to people! Dorothea -----Original Message----- From: akosavic at yorku.ca [mailto:akosavic at yorku.ca] Sent: 02 September 2008 21:06 To: eprints at erpanet.org Subject: Statistics survey for repository users - Synergies Canada Greetings! The Synergies Canada Statistics Working group is asking for your help in completing a short survey. Many repository users have expressed their dissatisfaction with the statistics gathering capabilities of repositories. For some, the frequency of gathering and the display of statistics are not adequate, for others the breadth of data being captured falls short of meeting granting agency guidelines. We want to hear your concerns! By sharing your thoughts about statistics with us, we hope to be able to identify core needs and build tools to share with the community that will improve statistics gathering for all. Please follow the link below to access the survey: http://www.surveymonkey.com/s.aspx?sm=4qiY0wPvxH4hSCCUamQ1wA_3d_3d Thanks for your participation, your help is most appreciated. Synergies Technical Committee http://www.synergiescanada.org Click this link to opt out of the survey: http://www.surveymonkey.com/optout.aspx?sm=4qiY0wPvxH4hSCCUamQ1wA_3d_3d ========== This message is sent to you because you are subscribed to The SPARC Open Access Forum. To post, send your message to . To unsubscribe, email to . To switch to digest mode, email to . To switch to index mode, email to . Send administrative queries to . -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From graham at biomedcentral.com Thu Sep 4 11:33:14 2008 From: graham at biomedcentral.com (Graham Triggs) Date: Thu, 04 Sep 2008 16:33:14 +0100 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> Message-ID: <48BFFFBA.7050804@biomedcentral.com> Dorothea Salo wrote: > BLUNTNESS ALERT. This is not a happy email. I have tried to make it a > reasonably diplomatic one, but I may well have failed, At least I know it's going to be entertaining! Well, my warning shall be that this isn't intended to be a rebuttal, more counterpoint. It's great that all this has been said, but if you take [another] step back, does it still look the same? > Axiom 1. The most elegant, stable, reliable, preservation-ready, > standards-compliant, easy-to-install, easy-to-maintain repository > software package in the WORLD is completely useless -- worse, > indefensible -- if it does not attract deposits. > > Do not tell me "that's a political problem" or "that's a > marketing/outreach problem." In part it is, but the politics at my > institutions are not lining up behind it, and marketing and outreach > are useless without a compelling value proposition. It certainly > doesn't help matters that the repository I run has been an albatross > thus far, in considerable part due to DSpace's limitations (usage > reports, anyone?). I'm going to bite on this one, as I want to ask a serious question - should usage reports play a part in encouraging deposits? Would seeing low usage reports DIScourage people that would otherwise choose to submit? If you are looking at counts of accesses and downloads, how reliable can they ever be? My personal opinion is that usage reports at an item/bitstream level is something of an itch you can't scratch - if you try, it might ease an initial sore point, only for it to recur in another guise later on. Those kinds of usage reports are better suited at a high level 'is this repository wanted' question, and things like Google Analytics answer that far better than anything we could ever build in. Value at a finer level would (again, imho) be better accounted for in MESURes like citation counts. Is that really something that can or should be built in to DSpace? (it could just as easily be an entirely separate system that a DSpace installation could query to obtain the relevant information for display). As I say, the above is just a personal take, so people are free to disagree. I just want to shake things up a little and see if people have thought about the problem from different angles [than just saying 'statistics in DSpace']. > This answer, of course, begs a question: what *are* faculty's data- > and publication-management problems? Here are some problems that > faculty at the institutions I serve have admitted to: > > - collaborating on unfinished work across institutional boundaries, > securely and easily An interesting use case, but not necessarily one that can be solved by an institutional repository, or ever should be solved by something that is set up for preservation. (I'm deliberately leaving that point for further exapnsion later). If you are wanting to collaboratively edit a document, for example, would the better answer be to use Google Docs? *That* level of collaborative ability is way off the scope for what we could ever hope to put in to a repository. Rather, the question should be how can we better support external collaboration tools - ie. easy ingesting of a Google Doc into a repository. > - storing and maintaining substantial amounts of data (in highly > heterogeneous forms) and writing, both while projects are underway and > afterwards I rather covered the editing side above, but there may be a lot of [relatively] static data that is associated with a paper. It may not need to be updated, but it does need to be stored somewhere - and if it is eventually going to be in the repository, why not have it there from the start rather than managing it until the point of submission? It's an interesting point. > - loading their data from their software and their servers into a safe > storage place, with as little manual intervention as possible, > preferably none I see that as being quite related to the above - as much of a users output should be captured [seamlessly] as part of their ongoing work. > None of this should be surprising; the data-curation literature is > full of these and similar problems. I am leaving digitization support > out of the picture, not because it isn't important (it is!), but > because it's a problem DSpace can't feasibly solve -- it's *genuinely* > a political problem. Still and all, it's worlds harder to solve this > political problem when DSpace's limitations leave me with a > credibility deficit to overcome. > > The problem that DSpace was designed for -- self-archiving of > peer-reviewed journal articles in an institution-based repository for > purposes of open access -- does not appear on the above list. Bluntly, > this is because faculty do not perceive self-archiving as a problem > they have or wish to solve. At the moment, there are two institutions > in the United States that are entitled to say that some of their > faculty think otherwise: Harvard and Stanford. DSpace presumably > wishes to appeal to more than two institutions! I have sympathy for your plight. But I think (not necessarily in you, I hasten to add ;) that there may be some element of not accepting problems as political ones, because frankly their are only so many of these battles that we can take on (and win), and because we can point to their possibly being a technical solution to a limited selection of cases that have been encountered to date. I'm not saying that to have an argument, but from the other side there are only so many technical problems that can be taken on and solved in a certain period of time. If one of these problems could be tackled politically, would that mean our time would be better spent solving other issues? > - Bitstream-less items. that's already been done ;) (all developers down the pub then, right?) > Somewhat more difficult fixes that would have great impact: > > - File versioning. I agree about it being difficult. There was GSoC code for this that will make it into a future release. Although I'll make my obligatory statement about the need for this may be exaggerated - there are practises a repository can adopt for managing it's items that would alleviate a number of potential cases, and in relation to the points above about collaboration - there are better ways to address the problem *before* hitting the repository. > - Elimination of per-item licensing, replaced with a single Terms of > Service click-through. (I can elaborate on this if desired.) I agree with the sentiment. Lot's of issues to think about though in the wider scope - ie. how do you deal with updating the Terms of Service. > - Streamlining and simplification of the deposit process, including > accepting incomplete deposits (even just a file!) for later > inspection/revision/management by a third party. A lot of this could already be achieved solely through the configuration files - and maybe this could be aided by one or two 'non-interactive' submission steps being provided in the default DSpace, ready for configuring. > - Better display options for a broader variety of content. I need a > page-turner, an image browser, and a journal browser that behaves like > a journal browser -- and that's just for the content I *currently > have*, not the content I foresee wanting to cope with in future. Isn't this about 90% outside of the scope of DSpace. A page turner? - that could just be a flash object that you give the url of a PDF to. If there is something out there already that offers that, it's fairly minimal effort for someone to customise their interface to use it - you don't need to get 'inside' DSpace. I can see why visualizations are useful, but that isn't a reason for DSpace itself to do anything more than make it possible to easily integrate third party objects. If someone finds or wants to provide such objects that can be redistributed with DSpace, that's a bonus. G This email has been scanned by Postini. For more information please visit http://www.postini.com From tdm27 at cam.ac.uk Thu Sep 4 11:46:32 2008 From: tdm27 at cam.ac.uk (Tom De Mulder) Date: Thu, 4 Sep 2008 16:46:32 +0100 (BST) Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> Message-ID: On Tue, 2 Sep 2008, Dorothea Salo wrote: > Repository managers: If any of this rings a bell with you, I need you > to stand up and say so publicly. "The lurkers support me in email" > (see ) > is no more going to get these problems solved in future than it has in > the past. While I'm not a repository manager, I've looked after a big DSpace instance for over 5 years, and I've worn that hat. I agree with Dorothea. We have serious issues with scalability and stability, and the fact that the existing codebase is very hard to modify (but I'll leave it to my colleague who has to do the development to elaborate). It would be better if the project had a strong technical lead who could steer development and take responsability, rather than what looks like a random group of committers who often only have time to work on what their institution wants them to work on. Maybe it would also be more easy to follow if communication wasn't so fragmented between various forums, and more concentrated on the[se] existing mailing lists? -- Tom De Mulder - Cambridge University Computing Service +44 1223 3 31843 - New Museums Site, Pembroke Street, Cambridge CB2 3QH -> 03/09/2008 : The Moon is Waxing Crescent (16% of Full) From dsalo at library.wisc.edu Thu Sep 4 12:42:06 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Thu, 4 Sep 2008 11:42:06 -0500 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <48BFFFBA.7050804@biomedcentral.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> <48BFFFBA.7050804@biomedcentral.com> Message-ID: <356cf3980809040942wff926cave57a9be21f844e61@mail.gmail.com> > I'm going to bite on this one, as I want to ask a serious question - > should usage reports play a part in encouraging deposits? Well, in the sense of "they're a feature depositors both potential and actual want/need," absolutely. I personally think it's incredibly stupid that scholars are using SSRN download counts in tenure-and-promotion packages -- BUT THEY ARE. That puts the repository I run at a feature disadvantage. I also can't argue with the (several!) people who have come to me asking for this. They want it. I am their mouthpiece. We also need to look at the repository-software market. EPrints does this already. I'm pretty sure ContentDM and BePress do as well. How long does DSpace remain the solution of choice if it doesn't? Sure, a lot of counts are going to be low. That doesn't bother me. Some won't be -- and just *one* case of "look! fifteen hundred downloads in a month!" will make faculty heads pop up. (That's not an unreasonable number; it's about what Roach Motel did.) Why would I fight that? > Would seeing low usage reports DIScourage people that would otherwise > choose to submit? If you are looking at counts of accesses and > downloads, how reliable can they ever be? They can't -- but see all the ongoing arguments about journal impact factors. Numbers are stupid, inaccurate, and deceptive. Granted. That doesn't stop people wanting numbers, and not just any numbers, not just whole-repository numbers, but THEIR numbers. > If you are wanting to collaboratively edit a document, for example, > would the better answer be to use Google Docs? *That* level of > collaborative ability is way off the scope for what we could ever hope > to put in to a repository. Read the Google Chrome ToS lately? No, we can't recreate Google Docs, but we might be able to do something closer to SVN-for-documents. I could sell that... and then I'd have access to preprints and postprints that I don't now. Rather, the question should be how can we > better support external collaboration tools - ie. easy ingesting of a > Google Doc into a repository. Agree. > I see that as being quite related to the above - as much of a users > output should be captured [seamlessly] as part of their ongoing work. That's the overarching theme I was trying to get at, yes. Thanks for putting it so succinctly! > I have sympathy for your plight. But I think (not necessarily in you, I > hasten to add ;) that there may be some element of not accepting > problems as political ones, Oh, I know. But then our institutions start chasing their tails. "Why hasn't the repository succeeded?" "Because it's under-resourced." "What resources do you need?" "Well, a developer would help, because the software is bare-bones and its developers won't address the needs I have identified." "What? Why would we throw a developer at an unsuccessful project?" and 'round the circle goes. And that's in institutions *that have developers*. I'm sorry to belabor this point, because I know I've said this before, but DSpace's market position is "out-of-the-box solution," which means it's in use at a lot of places with serious, serious resource constraints. If you're saying they're plain old out of luck, okay, but I would want to hear that said at a pretty high level before I'd be willing to shut up about it. >> - Bitstream-less items. > > that's already been done ;) (all developers down the pub then, right?) Bleh. My bad! > Although I'll make my obligatory statement about the need for this may > be exaggerated - there are practises a repository can adopt for managing > it's items that would alleviate a number of potential cases, and in > relation to the points above about collaboration - there are better ways > to address the problem *before* hitting the repository. Maybe, but those ways tend to *bypass* the repository with the final product. If we can address *that* problem -- and I agree that part of it is non-technical -- I'm happy. If we can't, then I need something to compete with other collaboration solutions, or I'm just written out of the landscape. > I agree with the sentiment. Lot's of issues to think about though in the > wider scope - ie. how do you deal with updating the Terms of Service. Definitely. I wouldn't be looking forward to going to Legal Services to make this happen... but I would, because the reduction in deposit annoyance, the vast expansion of material I could grab without tediously negotiating with individual faculty every single time, the destruction of the paper-based license workflow... it would be worth it. >> - Streamlining and simplification of the deposit process, including >> accepting incomplete deposits (even just a file!) for later >> inspection/revision/management by a third party. > > A lot of this could already be achieved solely through the configuration > files - and maybe this could be aided by one or two 'non-interactive' > submission steps being provided in the default DSpace, ready for > configuring. We're getting there, I agree... but we're a long way from sensible defaults and sufficient flexibility still. Mediated deposit is a pain in the posterior (especially as regards licensing), and it needs badly not to be, because it's the standard case (not the edge!) in most repositories. > Isn't this about 90% outside of the scope of DSpace. Building the individual pieces, yes, probably. But in my opinion it needs to be easier to embed these gizmos in DSpace. This is partly a communication problem, I think; we in the community simply don't document what we do so that we can be emulated. We may be talking about this next week, so I'll let it go for now, noting only that one of the things on my Manakin to-do list is a better thumbnail browser for image collections... and if I get something halfway decent, yes, I'll throw it over the fence. Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From stb28 at cam.ac.uk Thu Sep 4 12:49:04 2008 From: stb28 at cam.ac.uk (Simon Brown) Date: Thu, 4 Sep 2008 17:49:04 +0100 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> Message-ID: On 4 Sep 2008, at 16:46, Tom De Mulder wrote: > On Tue, 2 Sep 2008, Dorothea Salo wrote: > >> Repository managers: If any of this rings a bell with you, I need you >> to stand up and say so publicly. "The lurkers support me in email" >> (see > >) >> is no more going to get these problems solved in future than it has >> in >> the past. > > While I'm not a repository manager, I've looked after a big DSpace > instance for over 5 years, and I've worn that hat. I agree with > Dorothea. > > We have serious issues with scalability and stability, and the fact > that > the existing codebase is very hard to modify (but I'll leave it to my > colleague who has to do the development to elaborate). That would be me. I cannot speak to the 1.5 codebase but from what I've seen of it so far I don't think there have been many sweeping changes, so most of this probably applies. I refer specifically to 1.4.2. It's a BigBallOfMud. The boundaries between architectural layers vary from blurred to nonexistent - for example, there is SQL code scattered throughout the codebase, rather than down in an database access layer where it should be. This has several unpleasant effects, the first of which is that if you plan on running on a database other than Postgres or Oracle, you have to hunt down every single piece of SQL throughout the entire codebase and add another "else if" to it. Better hope you get them all. Supposing that you do, and you want to release your additional database support as a patch to assist the community at large, you've got a monster patch touching a large number of files in the codebase rather than one or two additional classes whose presence won't affect anyone who doesn't use them. That's not good design. It also manifests itself in other ways. Patching the system for properly darkening items is, as Dorothea has already noted, fraught with potential failures. We have a dark items patch which hides items from browse, RSS, and OAI-PMH, and we *think* we've caught everything, but as the only way to do it in the codebase as it stands is - once again - hunt down every instance of access to items and patch in an authz check, we're still not completely certain. We patched OAI-PMH in something of a hurry not long ago when we realised metadata was leaking through it. This kind of access control should, once again, be applied at a very low level - any calls to get lists of items for browsing etc. should include the user access context and shouldn't even return items the user should not be able to see. This kind of thing is difficult enough to implement on a well-defined architecture and an unholy nightmare on a bad one. Now, in a way, I can understand why fixing these things hasn't been high on anyone's list - my institution has things it would rather I do with our system in the same way that anyone else's does. What I'm less sure of is why a better architecture (which would benefit everyone who works with the codebase and therefore, indirectly, everyone else who uses DSpace) hasn't been more of a priority for the federation. I don't really want to address what makes an institutional repository good or bad because it's really not my area of expertise; I do feel that addressing the quality of the code itself will make it much easier for everyone who uses DSpace to bend it towards their particular needs. Regards, -- Simon Brown - Cambridge University Computing Service +44 1223 3 34714 - New Museums Site, Pembroke Street, Cambridge CB2 3QH From sbeers at gmu.edu Thu Sep 4 17:02:13 2008 From: sbeers at gmu.edu (Shane Beers) Date: Thu, 04 Sep 2008 17:02:13 -0400 Subject: [Dspace-general] [Dspace-tech] Week 3: Good Repository Software In-Reply-To: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> Message-ID: <8D654DA5-420A-431D-AFDD-4391929B7FDB@gmu.edu> In order to follow your directions and answer before reading other answers. Hopefully I have not duplicated many other responses: In my view, good repository software should allow: - Individuals to deposit materials in a straightforward and efficient manner, as to encourage the use of the repository to the widest possible audience. This requires more than just a customizable deposit process, as issues such as user permissions and security come into play. In my opinion, there should be some "dropbox" functionality so the repository manager does not have to go through a cumbersome account creation/approval process every time someone wishes to simply start using the repository. - The repository manager to easily manage the data being deposited into the system. The manager should be able to do things such as: * See a list of the last # deposits and the individual who deposited the item * Perform long-term data management to support the life of the data in the repository, including viewing/sorting items based on their file format (and version) to determine if data migration needs to take place * Modify the metadata of a large number of items at once, or the logical location of items within the repository without resorting to working directly with the database - The repository manager to be able to easily manage the users of the system, by granting permissions to individual users that are both understandable (instead of confusing terms such as "COLLECTION_64_SUBMIT") and functional (for example, why can a collection admin not replace bitstreams?) - The repository manager to easily view a wide array of data on the repository: * unique visitors on a repository wide, collection/community wide, or individual item basis, while being able to collect results on a day/ week/month/year/etc * downloads of items with the same granularity as visitors * which users deposited which items and when - The repository manager to modify the look and feel of the repository in a fairly straightforward manner, by having the ability to, for example, easily: * Change header/footer graphics * Change things like text/box colors * Modify which metadata fields are displayed in which layouts (I understand much of this is possible by modifying code, but not within the repository software front-end) - Multiple types of data to be equally at home - audio, video, textual, etc. For example, audio and video could be streamed and playable from the repository directly, while textual materials could be browsed page-by-page from the repository. - Users to find what they are looking for with search results that make sense and explain why their search resulted in the returned items. Fundamentally, a repository should encourage users to deposit materials and help them easily locate materials they are looking for. It should allow the repository manager to easily manage data, users, view information about the repository, and modify the look and feel of the front-end. It should also be suited for the long-term storage and accessibility of the information that is deposited. I feel that a repository software should fulfill many (if not most/all) of the requirements in the OCLC's Digital Repository Certification program. Certainly I'm asking for a perfect solution, but that's what you were hoping for, right? Shane Beers Digital Repository Services Librarian George Mason University sbeers at gmu.edu http://mars.gmu.edu 703-993-3742 On Sep 1, 2008, at 6:04 PM, Dorothea Salo wrote: > Sorry, all, I was on holiday and didn't think to set up this week's > question in advance. (Also, since the statistics discussion is still > ongoing, I'm waiting to summarize to the wiki until talk dies down. By > all means keep talking!) > > This week's question sounds simple but isn't. What is good repository > software? What does it allow us to do (both macro- and micro-level)? > What do we accomplish with it? > > I'm going to ask that respondents please write their own answers > before reading those of others! I would like to see some diversity of > response. Feel free to respond directly to me if you feel > uncomfortable answering on the list. > > I will moderate a chat on this topic in the DSpace IRC room (#dspace > on irc.freenode.net) on Wednesday at 10 am Central, 11 Eastern, 4 pm > GMT. > > Have at it! > > Dorothea > > -- > Dorothea Salo dsalo at library.wisc.edu > Digital Repository Librarian AIM: mindsatuw > University of Wisconsin > Rm 218, Memorial Library > (608) 262-5493 > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > DSpace-tech mailing list > DSpace-tech at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech From l.hayes at auckland.ac.nz Thu Sep 4 22:16:00 2008 From: l.hayes at auckland.ac.nz (Leonie Hayes) Date: Fri, 5 Sep 2008 14:16:00 +1200 Subject: [Dspace-general] Good repository software Message-ID: Good Repository Software I am taking the pragmatic line ... I have worked with some really really bad software (not repository software) so this has probably coloured my experience. 1. Good repository software should not crash, create errors, fall over or become corrupted, 3-4 times a year is ok. DSpace works like a charm here. 2. Good repository software should be able to be installed and supported (given adequate resources) in a wide variety of institutions ranging from small <50 people outfits, to large 1000 + institutions. DSpace fits this mix. 3. Good repository software should without any customisation do the basics of storing metadata and objects, apart from my issue with statistics, DSpace performs that job. 4. Good repository software should be affordable, an although we don't need to purchase software the cost of support staff is comparable to other products. 5. Good repository software should be able to identify bugs, present fixes, and provide a mechanism for technical problems to be solved. Most of the problems we identify have been raised already by the community, are mentioned very soon on the tech lists, and either we or someone else usually comes up with the solution eventually. 6. Good repository software should not pretend to be better than what it is, and bamboozle you with such complex configurations that you end up at the mercy of your clients bending over to their every whim. Supporting it becomes a nightmare and moving onward, upgrading or migrating out of it is impossible because of the huge investment you have made in the product. DSpace is honest software. Leonie Hayes Research Repository Librarian http://www.library.auckland.ac.nz/contacts/?firstname=&lastname=hayes http://researchspace.auckland.ac.nz From john at ohiolink.edu Fri Sep 5 11:36:58 2008 From: john at ohiolink.edu (John Davison) Date: Fri, 5 Sep 2008 11:36:58 -0400 Subject: [Dspace-general] Position Announcement: OhioLINK Systems Developer (DSpace) Message-ID: <002e01c90f6d$3bd05250$6c1e99c0@black> Cross-posted. Apologies for any duplication. Position Announcement: OhioLINK Systems Developer The Ohio Library and Information Network (OhioLINK) is seeking a hard-working, analytical individual to participate in the creation and maintenance of our internationally recognized set of online library information services, with special focus on the Ohio Digital Resource Commons. OhioLINK serves the higher education population in the State of Ohio with over 85 college and university member institutions. The position requires a four-year degree in Computer Science, or a graduate degree in Information or Library Science, or equivalent technical experience. The candidate should have strong programming skills in languages such as Java, and should be comfortable working in a Unix/Linux environment with open source software. Experience with the following is highly valued: Digital Repositories, Cocoon, Apache Tomcat, XML/XSLT, PostgreSQL. Experience with the following is desirable: DSpace/Manakin, HTML/CSS site design, metadata, Subversion, Perl, shell scripting. Salary: $49,000 minimum If you are interested in this position, please send a resume, a summary statement of experience, and an indication of your salary expectations to resume at ohiolink.edu. Thank you, John Davison Assistant Director, Digital Resources Development OhioLINK -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080905/5629145f/attachment.htm From graham at biomedcentral.com Fri Sep 5 12:34:55 2008 From: graham at biomedcentral.com (Graham Triggs) Date: Fri, 05 Sep 2008 17:34:55 +0100 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <356cf3980809040942wff926cave57a9be21f844e61@mail.gmail.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> <48BFFFBA.7050804@biomedcentral.com> <356cf3980809040942wff926cave57a9be21f844e61@mail.gmail.com> Message-ID: <48C15FAF.5040306@biomedcentral.com> Dorothea Salo wrote: > We also need to look at the repository-software market. EPrints does > this already. I'm pretty sure ContentDM and BePress do as well. How > long does DSpace remain the solution of choice if it doesn't? That's a good question. You could also ask how long it would be the solution of choice if we simply chase other implementations? And I mean that in the sense of could we be leapfrogging other solutions, rather than simply following what they've done? > Sure, a lot of counts are going to be low. That doesn't bother me. > Some won't be -- and just *one* case of "look! fifteen hundred > downloads in a month!" will make faculty heads pop up. (That's not an > unreasonable number; it's about what Roach Motel did.) Why would I > fight that? Dorothea, you can't simply go around uploading inflammatory material into your repositories to get the numbers up ;) > They can't -- but see all the ongoing arguments about journal impact > factors. Numbers are stupid, inaccurate, and deceptive. Granted. That > doesn't stop people wanting numbers, and not just any numbers, not > just whole-repository numbers, but THEIR numbers. Numbers that we know are wrong. That probably can't even be compared across DSpace implementations, let alone across different platforms. Which don't take into account that the same material may be available in multiple places. And what's worse, numbers that can't be verified. If they want these numbers in anything approaching a formal capacity, I think we both realise that we might as well just put a random number generator in there rather than bother trying to actually count anything!! At least if they could get those numbers from something like a Google Analytics report, there would be some kind of independent validity to them. That's not entirely unfeasible, and there is also an upcoming competitor - Woopra - that will have an API, potentially allowing for integration of those numbers into the repository itself. I'm not against statistics, but I'm interested to find out if we can / should be spending our time on delivering something with less flaws. > No, we can't recreate Google Docs, but we might be able to do > something closer to SVN-for-documents. I could sell that... and then > I'd have access to preprints and postprints that I don't now. Or you could just use SVN ;) Having all of this inside your 'preservation' repository is rather sub-optimal - both for the purposes of the workspace, and for the long term sustainability of the repository. Maybe a neater solution would be a workspace / collaboration type service that enables all of the gathering of data and people working together, with the end result a SWORD submission to the final repository. (One advantage of that route is that such a service can be applicable to EPrints, Fedora, etc. - not just DSpace. Which means you've got a potentially wider pool of interested parties to make it happen) Yes, it's a selling point of DSpace that it's a 'out-of-the-box' solution - but that doesn't mean it (or anyone's customised implementation of it) should incorporate every aspect of anything that touches on the content finding it's way into the repository. The repository has a job to do, and there is nothing wrong - in fact, there is quite a lot of right - in having a suite of distinct, but integrated, services. > We're getting there, I agree... but we're a long way from sensible > defaults and sufficient flexibility still. Mediated deposit is a pain > in the posterior (especially as regards licensing), and it needs badly > not to be, because it's the standard case (not the edge!) in most > repositories. Ahh... the sensible defaults argument. Oh, I quite agree that we could come up with something that is more suitable for the 80% case. Right now, we're kind of limited in actioning such a change - we have a general rule to keep the default configurations as much as possible the same, which is really meant to aid with upgrading. For example, although the submission code has changed dramatically to be more flexible in 1.5, the defaults provided mimic the 'out-of-the-box' experience of 1.4 as much as possible. Now, can any one of the developers / committers unilaterally decide - actually, let's have the submission process look like this? If there was a consensus as to what the sensible defaults should be, then there could be a commitment to delivering them in future release(s). G This e-mail is confidential and should not be used by anyone who is not the original intended recipient. BioMed Central Limited does not accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of BioMed Central Limited. No contracts may be concluded on behalf of BioMed Central Limited by means of e-mail communication. BioMed Central Limited Registered in England and Wales with registered number 3680030 Registered Office Middlesex House, 34-42 Cleveland Street, London W1T 4LB From dsalo at library.wisc.edu Fri Sep 5 14:08:34 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Fri, 5 Sep 2008 13:08:34 -0500 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <48C15FAF.5040306@biomedcentral.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> <48BFFFBA.7050804@biomedcentral.com> <356cf3980809040942wff926cave57a9be21f844e61@mail.gmail.com> <48C15FAF.5040306@biomedcentral.com> Message-ID: <356cf3980809051108r2d2ae39flf88ba27e062fce0f@mail.gmail.com> On Fri, Sep 5, 2008 at 11:34 AM, Graham Triggs wrote: > That's a good question. You could also ask how long it would be the > solution of choice if we simply chase other implementations? > > And I mean that in the sense of could we be leapfrogging other > solutions, rather than simply following what they've done? That's a question I can get behind! > Dorothea, you can't simply go around uploading inflammatory material > into your repositories to get the numbers up ;) +1 -- and you owe me a Diet Coke and a new keyboard. :) Roach Motel isn't the only item in MINDS at UW that's done those kinds of numbers. I'd love to know what's inflammatory about an undergraduate kinesiology journal -- I've been wondering! > If they want these numbers in anything approaching a formal capacity, I > think we both realise that we might as well just put a random number > generator in there rather than bother trying to actually count anything!! I got an excellent, excellent private email from Robert Roggenbuck (which I strongly encourage him to post back to the list!) pointing out that the serials world already has a standard called COUNTER that addresses this question (see and ). I think as much COUNTER compliance as we can claim (some of it, such as independent audits, we can't) would be a big win, and an example for other software and services. > Or you could just use SVN ;) Yeah, I can, but can my faculty? Having all of this inside your > 'preservation' repository is rather sub-optimal - both for the purposes > of the workspace, and for the long term sustainability of the repository. Is it? I've been saying all along that a repository viewed as *useful* is going to be a lot more sustainable! > Maybe a neater solution would be a workspace / collaboration type > service that enables all of the gathering of data and people working > together, with the end result a SWORD submission to the final repository. No argument. Show it to me such that John Q. Librarian can install and manage it as simply as he currently does DSpace. > Yes, it's a selling point of DSpace that it's a 'out-of-the-box' > solution - but that doesn't mean it (or anyone's customised > implementation of it) should incorporate every aspect of anything that > touches on the content finding it's way into the repository. It should if we want something other than empty repositories. The > repository has a job to do, and there is nothing wrong - in fact, there > is quite a lot of right - in having a suite of distinct, but integrated, > services. And there's quite a lot of wrong, too, in that institutions have committed to DSpace, not such a suite. I can argue until I'm blue in the face (and have done!) that they *ought* to have so committed, but they didn't, and now we're stuck. The more I can make DSpace do along those lines, then, the more wins I win, and the more leverage I have to win still more wins. Maybe the answer is finding another group of implementers to build and document that suite. That would be a super-interesting project. Likely? I dunno. I think I may get more mileage out of what I'm doing now, honestly. Here's another thing to think about. Resolved: it makes more sense to build that suite on top of Fedora Commons than on top of DSpace. Corollary: insofar as institutions decide they want such a suite (and I definitely see motion in that direction from where I am), they will abandon DSpace for Fedora. > Now, can any one of the developers / committers unilaterally decide - > actually, let's have the submission process look like this? Probably not... but I'm giving my little all here to building enough of a vocal userbase that the devs can make that decision and blame it on us. :) Maybe I won't get there -- I know full well I haven't yet -- but we'll see. > If there was a consensus as to what the sensible defaults should be, > then there could be a commitment to delivering them in future release(s). Putting on my Alan-Cooper-fan hat, I would say that design-by-consensus piled atop some initial poor decisions landed us in the usability mess we're currently in. I don't think more of the same will haul us out, especially given the Ronco-Spray-On-Usability approach we've taken heretofore. (See the brilliant and hilarious for the origin of that phrase.) I would be all for us throwing a real usability expert (which I'm not; I just read a lot about it and understand the low-level basics) at DSpace, and if the DSpace Foundation were to canvass the membership, I wouldn't be surprised if an institution containing such an expert proved willing to contribute his or her services. (I know I'd be knocking on a few doors at MPOW.) Maybe for 2.0? Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From mwood at IUPUI.Edu Fri Sep 5 15:33:27 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Fri, 5 Sep 2008 15:33:27 -0400 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <356cf3980809051108r2d2ae39flf88ba27e062fce0f@mail.gmail.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> <48BFFFBA.7050804@biomedcentral.com> <356cf3980809040942wff926cave57a9be21f844e61@mail.gmail.com> <48C15FAF.5040306@biomedcentral.com> <356cf3980809051108r2d2ae39flf88ba27e062fce0f@mail.gmail.com> Message-ID: <20080905193327.GA27097@IUPUI.Edu> On Fri, Sep 05, 2008 at 01:08:34PM -0500, Dorothea Salo wrote: > On Fri, Sep 5, 2008 at 11:34 AM, Graham Triggs wrote: > > Having all of this inside your > > 'preservation' repository is rather sub-optimal - both for the purposes > > of the workspace, and for the long term sustainability of the repository. > > Is it? I've been saying all along that a repository viewed as *useful* > is going to be a lot more sustainable! Are we having a communication problem here? I think I see two different uses of the word "inside". If "inside" means "designed and built and maintained as part of DSpace" then I have to say I think we should not do that. If "inside" means "can easily be made to appear as part of a system which also includes DSpace" then that makes a lot of sense. I see the same people seeming to argue both yea and nay, and that makes me think I haven't understood all of their words. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080905/1270c357/attachment.bin From es444 at cam.ac.uk Mon Sep 8 05:29:28 2008 From: es444 at cam.ac.uk (Elin Stangeland) Date: Mon, 08 Sep 2008 10:29:28 +0100 Subject: [Dspace-general] [Fwd: Re: Week 3: Good Repository Software] Message-ID: <48C4F078.2060000@cam.ac.uk> Hi everyone, A belated addition to last week?s discussion, I hope that?s ok. First of all can I just start by saying thank you Dorothea for taking the responsibility of managing this process? Very useful for me in a little exercise I'm doing here in Cambridge, secondly you seem to succeed in getting at least some of our Repository manager colleagues out there to speak, which is great! Also Dorothea, many of the issues you describe are problems we struggle with here in Cambridge as well. You ask me to define what I think is good repository software. Here are some of the things that would be on the top of my list of what I would like to see in good repository software (and which DSpace doesn't yet do): - Flexibility in managing and describing objects in the repository (an object can be a community, collection, item or bitstream) and in expressing the relationships between these. For example I would like to be able to define on ingest (and later on as well) which collections an item should belong to (and yes I have used the mapping tool, but it is rather clunky), or whether a collection related to one community also should be listed as part of another. If the content I deposit is ?related? to another item somehow I would like to be able to express this as well. - The option to (easily) plug in to whatever external sources of content and or metadata I can find which would then let me pull this content to DSpace at Cambridge. For example it would be great if a researcher wanting to deposit an article could pull the content and the author?s final version from Nature or indeed push it from Nature?s own author interface (as suggested recently by Nature publishing). If I on top of that were able to integrate easy access to for example the Sherpa tools giving advice on copyright and funder mandates I?d be very happy. Or perhaps we need to make external interfaces for doing all of this and use SWORD or similar technologies to make sure that the content ends up in the IR? - Also (and this is where I become DSpace specific) I would like to be able to manage submission forms, make decisions on what metadata is being indexed, what browse indexes to generate etc. from the DSpace front end administration not various text files that my technical staff would then have to spend time on deploying for me. That's all for now! Best regards, Elin ____________________________________________________ Elin Stangeland DSpace at Cambridge Repository Manager Cambridge University Library West Road, Cambridge CB3 9DR tel. 01223 333 130 e-mail: es444 at cam.ac.uk http://www.dspace.cam.ac.uk ____________________________________________________ -- ____________________________________________________ Elin Stangeland DSpace at Cambridge Repository Manager Cambridge University Library West Road, Cambridge CB3 9DR tel. 01223 333 130 e-mail: es444 at cam.ac.uk http://www.dspace.cam.ac.uk ____________________________________________________ From joseph.greene at ucd.ie Mon Sep 8 07:26:32 2008 From: joseph.greene at ucd.ie (Joseph Greene) Date: Mon, 08 Sep 2008 12:26:32 +0100 Subject: [Dspace-general] Cost/benefit of upgrading to 1.5 Message-ID: <00a901c911a5$c0a0ced0$ba5f2b89@D64NZ32J> I'm just wondering if there is anyone out there who has done a cost/benefit analysis of upgrading to 1.5.x (currently 1.4.2 here) that would be willing to share; I'm not too concerned about format or polish, just the information. I am currently doing just that and would be very interested in seeing what others see as important or not. I have recently encountered some scepticism from repository developers in the EU, (perhaps it's more accurate to say 'platform agnosticism') which makes me want to be that much more sure before we decide to upgrade. Thanks for your help, Joseph Greene Institutional Repository Project Manager University College Dublin Belfield, Dublin 4 353 (0)1 716 7398 joseph.greene at ucd.ie http://irserver.ucd.ie/dspace/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080908/256ea717/attachment.htm From dsalo at library.wisc.edu Mon Sep 8 09:24:30 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Mon, 8 Sep 2008 08:24:30 -0500 Subject: [Dspace-general] Week 4: Bitstream types Message-ID: <356cf3980809080624u42c7b1ddh571b1db281257515@mail.gmail.com> I know I'm seriously late on last week's chat summary; it's on my to-do list for today. Sorry about that! This week's question has to do with bitstreams. DSpace is designed around discrete papers contained within single bitstreams, and it also handles websites reasonably well. The question is: what else do you have, what have you done with/to DSpace to accommodate it, and what else do you need from DSpace? Bram de Luyten asks: "Would you recommend DSpace to an organization with needs to use it as a repository for very specific filetypes, different from standard documents (for example, audio or video repository ...) ? Why (not) ? And what if they want to store "many different things" ?" I'm feeling laissez-faire this week, and this is something of an additive question, so go ahead and read other folks' answers before adding your own. Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From mwood at IUPUI.Edu Mon Sep 8 10:05:45 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Mon, 8 Sep 2008 10:05:45 -0400 Subject: [Dspace-general] Week 4: Bitstream types In-Reply-To: <356cf3980809080624u42c7b1ddh571b1db281257515@mail.gmail.com> References: <356cf3980809080624u42c7b1ddh571b1db281257515@mail.gmail.com> Message-ID: <20080908140545.GB3865@IUPUI.Edu> Two challenges we've run into here are isochronous media (audio, video) and multimedia presentation packages. Audio and video are difficult for a couple of reasons. One problem is that they tend to be LARGE documents, which makes downloading tedious, yet the only way to get one out of DSpace is to download and then present. A suitably designed application *could* pull byte-range chunks out of the document and present them more quickly, but then there is the other problem: unlike text or drawings which just sit on the screen and can be delivered at any reasonable rate, audio and video evolve in time and must be presented at a constant (high) rate of delivery. One of the fundamental design decisions on which the Internet is based is that timing and even ordering of packet delivery are not critical. Both of these problems point to the use of a streaming service. Streaming clients expect to pull the material a bit at a time, and streaming protocols are designed to minimize timing problems. What we've tried is to deposit a SMIL wrapper as the DSpace bitstream and have that point to the actual presentation over on a streaming service. It works on some browsers, but SMIL is not yet as widely deployed as we might wish. One could do the same thing using e.g. RealMedia RAM pointer files, but that ties one down to a single vendor. We really ought to support open standards as they become available. Multimedia presentations take us to the next level of challenge, because they include a user interface program which lets the user control the delivery of the presentation. All the MM creator packages I've seen seem to assume that the result will be stamped on CDROMs and physically delivered. SMIL should eventually be the answer to this problem, since this is what it was really designed for: it's a language for defining buttons, projection areas, timing and synchronization for access to multiple streams of content. That's when the MM package makers get on board and leave their proprietary non-networkable baggage behind. We haven't come up with a satisfactory way to deal with such content until the dawning of that glorious day; our best response right now is to dump .iso images into the repo., and that's not at all what the user expects. DSpace can't do much about these problems, but the DSpace community can push the makers of producer and consumer software to build standards-based products. DSpace might be able to coordinate more closely with a streaming service by making it simple for that service to access bitstreams stored in DSpace. People who operate institutional streamers tend to see the content as ephemeral, which means that we wind up setting up our own streamer to ensure long-term availability. ++++++++++++++++++ There's one other problem I've noted with AV material: production values. We are often presented with horrors such as an AV recording made by pointing a camera at a projection screen while the presenter talks his way through a PowerPoint slideshow, and meetings that start with 10-15 minutes of unintelligible hubbub before the meeting comes to order. Technology can do nothing about this. We need to get the word out that people should think about preservation in advance and plan their capture of presentations. Simply editing down to something presentable will help in some cases, while in others the presentation would benefit from being designed over again with network delivery in mind (transcript+slides instead of chalk-talk recording, maybe packaged with SMIL to make a neat whole of it). This is really an extension of what we do in advising depositors about file formats that work well for long-term preservation. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080908/11625575/attachment.bin From mwood at IUPUI.Edu Mon Sep 8 10:07:39 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Mon, 8 Sep 2008 10:07:39 -0400 Subject: [Dspace-general] Week 4: Bitstream types In-Reply-To: <356cf3980809080624u42c7b1ddh571b1db281257515@mail.gmail.com> References: <356cf3980809080624u42c7b1ddh571b1db281257515@mail.gmail.com> Message-ID: <20080908140739.GC3865@IUPUI.Edu> Following myself up again, I don't know what I *would* recommend as a repository for AV files. Maybe we have an opportunity here. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080908/63c2d464/attachment.bin From bram at mire.be Mon Sep 8 10:28:33 2008 From: bram at mire.be (Bram Luyten) Date: Mon, 8 Sep 2008 16:28:33 +0200 Subject: [Dspace-general] Cost/benefit of upgrading to 1.5 In-Reply-To: <00a901c911a5$c0a0ced0$ba5f2b89@D64NZ32J> References: <00a901c911a5$c0a0ced0$ba5f2b89@D64NZ32J> Message-ID: Dear Joseph, although we have not conducted a formal cost/benefit analysis for upgrading, following benefits, costs and possible risks might make sense in your context. Benefits (some copied from http://www.dspace.org/index.php?option=com_content&task=blogcategory&id=23&Itemid=63) * By following the latest (non-beta) releases, you can benefit from the latest bugfixes and optimalisation. * (feature) Submission steps can be configured more easily * (feature) You can configure different browse indices Costs * If you intend to customize the user interface, there is a learning curve for the new Manakin XML UI (with the exception of very very basic customizations). One of our JSP developers needed around three weeks fulltime to get really into Manakin development. * Likewise, if you intend to do custom development, you will need to learn a thing or two about Maven. Risks * Some of the patches you applied or inhouse customizations might not work anymore and might be difficult to port. * (very unclear at the moment:) if you intend to perform customizations on 1.5.x, there's a possible risk that these customizations might not be compatible with the future 2.0 release. If anyone has more information regarding this, please elaborate. Your current situation is very important in the equation: for example, we do conversions of standard 1.4.2 DSpace installations, to standard 1.5.x jsp-ui DSpace in one day (which basically means following these instructions: http://dspace.svn.sourceforge.net/viewvc/dspace/trunk/dspace/docs/update.html#142_15with a few checks here and there). Although I fear this is probably a very general answer, I do hope it helps to some extent (or maybe opens up discussion). with best regards, Bram Luyten -- @mire NV Romeinse Straat 18 3001 Heverlee Belgium +32 2 888 29 56 http://www.atmire.com - Institutional Repository Solutions http://www.togather.eu - Before getting together, get Tog at ther 2008/9/8 Joseph Greene > I'm just wondering if there is anyone out there who has done a > cost/benefit analysis of upgrading to 1.5.x (currently 1.4.2 here) that > would be willing to share; I'm not too concerned about format or polish, > just the information. I am currently doing just that and would be very > interested in seeing what others see as important or not. I have recently > encountered some scepticism from repository developers in the EU, (perhaps > it's more accurate to say 'platform agnosticism') which makes me want to be > that much more sure before we decide to upgrade. > > > > Thanks for your help, > > > > Joseph Greene > > Institutional Repository Project Manager > > University College Dublin > > Belfield, Dublin 4 > > > > 353 (0)1 716 7398 > > joseph.greene at ucd.ie > > http://irserver.ucd.ie/dspace/ > > > > _______________________________________________ > Dspace-general mailing list > Dspace-general at mit.edu > http://mailman.mit.edu/mailman/listinfo/dspace-general > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080908/99ec380f/attachment.htm From graham at biomedcentral.com Mon Sep 8 10:51:10 2008 From: graham at biomedcentral.com (Graham Triggs) Date: Mon, 08 Sep 2008 15:51:10 +0100 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <356cf3980809051108r2d2ae39flf88ba27e062fce0f@mail.gmail.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> <48BFFFBA.7050804@biomedcentral.com> <356cf3980809040942wff926cave57a9be21f844e61@mail.gmail.com> <48C15FAF.5040306@biomedcentral.com> <356cf3980809051108r2d2ae39flf88ba27e062fce0f@mail.gmail.com> Message-ID: <48C53BDE.7030106@biomedcentral.com> Dorothea Salo wrote: > +1 -- and you owe me a Diet Coke and a new keyboard. :) remind me at the next conference we're both at! > I got an excellent, excellent private email from Robert Roggenbuck > (which I strongly encourage him to post back to the list!) pointing > out that the serials world already has a standard called COUNTER that > addresses this question (see > and > ). I think as > much COUNTER compliance as we can claim (some of it, such as > independent audits, we can't) would be a big win, and an example for > other software and services. COUNTER compliance would be better than nothing. >> Or you could just use SVN ;) > > Yeah, I can, but can my faculty? I didn't say directly! Just think how many people have been developing SVN, and for how long. If there is a need for versioning that goes beyond the most basic of requirements - as would be the case for some kind of collaborative environment - then there is so much more mileage (and efficiency) in building that part of the solution around something that already does it. Especially as you probably wouldn't be looking to capture and preserve the frequent minor revisions for the long term. > Having all of this inside your >> 'preservation' repository is rather sub-optimal - both for the purposes >> of the workspace, and for the long term sustainability of the repository. > > Is it? I've been saying all along that a repository viewed as *useful* > is going to be a lot more sustainable! Political vs technical argument, and you have to have a balance of both. You may have the most useful and used repository in the world, but there is still going to be a limit which if the cost of technical sustainability exceeds, the plug will be pulled. You are right in saying that DSpace does not adequately fulfil either criteria (then again, neither does anyone else or we wouldn't all still be doing this). But we do have to ensure that the technical side stays within bounds whilst improving it's political sustainability. >> Maybe a neater solution would be a workspace / collaboration type >> service that enables all of the gathering of data and people working >> together, with the end result a SWORD submission to the final repository. > > No argument. Show it to me such that John Q. Librarian can install and > manage it as simply as he currently does DSpace. Funny you should say that, because it just so happens... that I can't. But that's not a problem, it's an opportunity ;) > Maybe the answer is finding another group of implementers to build and > document that suite. That would be a super-interesting project. > Likely? I dunno. I think I may get more mileage out of what I'm doing > now, honestly. That's essentially where I'm pointing. Everybody has to deal with having limited sets of resources - the EPrints and Fedora communities are no different in that regard... we can't solve all the world's problems and have it done in time for dinner! Not only are some of these pre-ingest [collaboration?] services distinct enough from the main function of the repository that they can and should be implemented as a separate service (*). As a separate application, not only do you have three times the number of interested parties, three times the number of potential resources, you can also put together a funding bid. A collaboration service that enables researchers to work together across multiple locations, and collates their output for submission to a repository via SWORD (using SWAP profile) might be of interest to JISC for example - certainly more so than a similar project that extends DSpace internally and is therefore only applicable to that one platform. (* and when I say that, remember that out-of-the-box things like OAI-PMH, SWORD and LNI are delivered as separate applications in DSpace - which could even be installed on distinctly separate machines, etc. even though nobody would know that from outside) > Here's another thing to think about. Resolved: it makes more sense to > build that suite on top of Fedora Commons than on top of DSpace. > Corollary: insofar as institutions decide they want such a suite (and > I definitely see motion in that direction from where I am), they will > abandon DSpace for Fedora. If you need to do 'deep' integration with the repository, then Fedora is in a better place to build from. For what would effectively be a pre-ingest service, then you possibly don't need anything more for integration than SWORD. Of course, a suite means having administration and dissemination of the repository contents, something that DSpace provides for less work. You may be right that some people will abandon DSpace for Fedora if/when they realise they've made some incorrect assumptions about DSpace. I don't see that as problem though. We aren't trying to crush Fedora or EPrints, we just want to provide a good solution that serves a need. > Putting on my Alan-Cooper-fan hat, I would say that > design-by-consensus piled atop some initial poor decisions landed us > in the usability mess we're currently in. I don't think more of the > same will haul us out, especially given the Ronco-Spray-On-Usability > approach we've taken heretofore. (See the brilliant and hilarious > for the origin > of that phrase.) I would be all for us throwing a real usability > expert (which I'm not; I just read a lot about it and understand the > low-level basics) at DSpace, and if the DSpace Foundation were to > canvass the membership, I wouldn't be surprised if an institution > containing such an expert proved willing to contribute his or her > services. (I know I'd be knocking on a few doors at MPOW.) Maybe for > 2.0? I'm not saying design-by-consensus - but there has to be a design, and there has to be a consensus that supports it. Developers randomly changing the interface in any number of different ways every release until we hit on something that people like isn't going to do anyone much of a service! G This email has been scanned by Postini. For more information please visit http://www.postini.com From graham at biomedcentral.com Mon Sep 8 11:02:27 2008 From: graham at biomedcentral.com (Graham Triggs) Date: Mon, 08 Sep 2008 16:02:27 +0100 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <20080905193327.GA27097@IUPUI.Edu> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> <48BFFFBA.7050804@biomedcentral.com> <356cf3980809040942wff926cave57a9be21f844e61@mail.gmail.com> <48C15FAF.5040306@biomedcentral.com> <356cf3980809051108r2d2ae39flf88ba27e062fce0f@mail.gmail.com> <20080905193327.GA27097@IUPUI.Edu> Message-ID: <48C53E83.9000705@biomedcentral.com> Mark H. Wood wrote: > Are we having a communication problem here? I think I see two > different uses of the word "inside". If "inside" means "designed and > built and maintained as part of DSpace" then I have to say I think we > should not do that. If "inside" means "can easily be made to appear > as part of a system which also includes DSpace" then that makes a lot > of sense. That's what I'm basically getting at - integrated services [should] mean that people don't see the boundaries, even if the provision of those services is distinctly separate. As something of an illustration of the point, take a look at the BioMed Central website - that's running across half a dozen machines, some especially provisioned to do certain tasks. Even where different parts of the website are running on the same machine, it is actually implemented using a variety of different technologies and [computer] languages. But as a user - or author submitting a manuscript to one of the journals - you wouldn't know what machine, what application server, what language was used at any point during your interaction. It all just looks like one continuous site. And that's where a suite of applications should sit - a faculty member should be able to access the 'library services' website, and within that single url space there could be a CMS, a blog, a DSpace repository, a collaboration service, and regardless of how many applications, languages, servers, etc. are involved in delivering that, the experience would be seamless and feel like there is just one application sitting behind it. G This e-mail is confidential and should not be used by anyone who is not the original intended recipient. BioMed Central Limited does not accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of BioMed Central Limited. No contracts may be concluded on behalf of BioMed Central Limited by means of e-mail communication. BioMed Central Limited Registered in England and Wales with registered number 3680030 Registered Office Middlesex House, 34-42 Cleveland Street, London W1T 4LB This email has been scanned by Postini. For more information please visit http://www.postini.com From graham at biomedcentral.com Mon Sep 8 11:46:58 2008 From: graham at biomedcentral.com (Graham Triggs) Date: Mon, 08 Sep 2008 16:46:58 +0100 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> Message-ID: <48C548F2.5000301@biomedcentral.com> Simon Brown wrote: > Now, in a way, I can understand why fixing these things hasn't been > high on anyone's list - my institution has things it would rather I do > with our system in the same way that anyone else's does. What I'm less > sure of is why a better architecture (which would benefit everyone who > works with the codebase and therefore, indirectly, everyone else who > uses DSpace) hasn't been more of a priority for the federation. This isn't intended to be rude, but I think this deserves a response and the only way I can see to do so is simply state the facts. Two years ago, the foundation didn't even exist, and HP and MIT were only starting that process around mid-to-late 2006 (as far as I recall). The first thing that that process did was to get funding to gather a group of committers and interested parties for a week-long discussion on the architecture, with a number of suggestions and things to investigate (the output of this meeting was documented on the Wiki) That was October 2006. The foundation didn't exist in any real sense though until after Michele Kimpton came on board (the press release announcing the formation of the foundation is dated July 2007). The foundation was immediately seeking funding for important development work. By October 2007, potential funding had been found and some resources earmarked. Although this funding wasn't confirmed, some resources for the project had still not been found, and there was no technical director for the foundation. All of that wasn't finally resolved for another six or so months. That brings us up to two months ago, which is where the work to define the scope and priorities of the funded development has begun. As you say, without the foundation doing all the above, there are very few people that are in a position to address even part of the architectural problem. But even with the best will in the world, those are the timescales to making it a practical reality. This e-mail is confidential and should not be used by anyone who is not the original intended recipient. BioMed Central Limited does not accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of BioMed Central Limited. No contracts may be concluded on behalf of BioMed Central Limited by means of e-mail communication. BioMed Central Limited Registered in England and Wales with registered number 3680030 Registered Office Middlesex House, 34-42 Cleveland Street, London W1T 4LB This email has been scanned by Postini. For more information please visit http://www.postini.com From dsalo at library.wisc.edu Mon Sep 8 12:24:31 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Mon, 8 Sep 2008 11:24:31 -0500 Subject: [Dspace-general] [Dspace-tech] Week 4: Bitstream types In-Reply-To: <20080908140739.GC3865@IUPUI.Edu> References: <356cf3980809080624u42c7b1ddh571b1db281257515@mail.gmail.com> <20080908140739.GC3865@IUPUI.Edu> Message-ID: <356cf3980809080924x412dd0f8p27a2e260a97dc269@mail.gmail.com> I have all the same A/V problems Mark Woods talked about. What makes me unhappy about the SMIL/stream solution is that (if I understand things correctly, which I may not) I don't actually have the video file under DSpace's control for checksumming and so forth. There are ways around this (the file can live in two places!), but they seem cumbersome and they increase storage-space requirements heavily. Multimedia is also a problem just as Mark said, but let me toss into that mix compound objects like Flash learning objects. As I understand the structure of those benighted things, they act a little bit like HTML files, calling out to external resources like images and movies and whatever. *Unlike* HTML files, they're troublesome to rewrite, so to ingest them usably, we'd have to be *extra*-careful to maintain their directory structures... and I don't even want to *think* about ones that access resources by URL/URI, ugh. Here's a question I've never had an authoritative answer to: Suppose I put a mess of audio files in their own collection. Is the RSS feed from that collection podcast-friendly? If it isn't, how much work would it take (especially in XMLUI) to make it so? Other problems I've run into, along with potential solutions: - Individual page-scans. Not only do these look unconscionably messy on a DSpace item page, DSpace has no innate sense of bitstream order, which makes it *really* hard to tie in an outside page-turner app. What I've historically done is squish the scans into a (somewhat lower-quality) PDF via ImageMagick and ps2pdf, and throw that in along with the scans. This is -- okay, it's a gross hack, but it does well enough for the purpose, I guess. The display-messiness problem might be solvable with a Manakin theme, but again, there aren't really any hooks in DSpace to make this easy (though hm, *maybe* the "primary bitstream" notion could be repurposed), meaning any "solution" is going to be an ugly kludge. - Image collections. DSpace's usual browses are pretty grotty UI for this purpose. I'm looking at doing some kind of thumbnail browse in Manakin; it shouldn't be *that* hard. (Famous last words.) We might also want to look at what third-party whizbangs like PicLens/Cooliris need to do their magic. - We've run into problems in 1.4.x opening large PDFs in-browser. We *think* this was partly because of our bitstream-handle hack, and we also think the rewrite we did of that for 1.5 will solve the problem, so stay tuned. - Specialty metadata and persistent bitstream URLs for mashups. GIS metadata is a pain-point here. My colleagues on the digital-library side of the fence have done super-cool things with local collections and Google Maps. I know Manakin makes some of this possible because I've seen the demos, but I'm not smart enough to figure out how to make it work on my own. I think those are our big pain-points. I may think of more as the week goes on. Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From hellpop at umich.edu Mon Sep 8 12:28:39 2008 From: hellpop at umich.edu (Jim Ottaviani) Date: Mon, 08 Sep 2008 12:28:39 -0400 Subject: [Dspace-general] Week 4: Bitstream types (Dorothea Salo) In-Reply-To: Message-ID: > This week's question has to do with bitstreams. DSpace is designed > around discrete papers contained within single bitstreams, and it also > handles websites reasonably well. The question is: what else do you > have, what have you done with/to DSpace to accommodate it, and what > else do you need from DSpace? Audio and Video As others have said, audio and video are challenges because of file size, preservation standards (or lack thereof), and typical user needs. We have deposited enough video, and enough interest in preserving and presenting it, to see a few things repeat: (1) Deposit almost always has to be mediated, since users either don't have the tools to convert what they have into something they can deposit, or don't want to wait while a very large file transfers via the web form. (2) If we didn't have a partnership with a streaming service on campus, people wouldn't deposit audio and video in Deep Blue. Full stop. Preservation is a secondary concern for most -- they want to be sure others have access, and they don't have the server space to provide it. And access via "download the whole thing to the desktop" doesn't work for two reasons: it's too slow and depending on the encoding the downloaded file might not work anyway. We're measured against the convenience and usability of YouTube...and yes, that's not fair, and no, pointing out that we're more reliable than YouTube doesn't matter. (See above re. preservation as a secondary concern.) (3) Depositors often don't have the option -- or don't know how -- to choose how they capture video, so you get what they produce and live with it. We've created best practices for creating high quality text, image, and audio files, but we're stuck on defining what a best practice would be for digital video. If others have settled on best practices I'd love to hear how they've decided to define preservation quality video. Not that users will deliver preservation quality even if you tell them what it is, but it would be nice to know what we mean by it. Websites and XML-based complex objects In the realm of complex objects, those wrapped in HTML and XML are easy enough to preserve and present, though I disagree about handling them reasonably well. Once they're in DSpace all's well, but getting them in is tedious (or more accurately, incredibly tedious). Handling (a) nested directory structures without having to "flatten out" a website completely by rewriting internal links and renaming files (b) being able to upload directories, nested or not, would be fantastic features to have. Complex Objects We get relatively few requests for things like lecture objects and things that require complex interactions between files, but when we do I'm usually able to help their producers understand how platform/operating system/software specific objects are inherently difficult to preserve in the long term. (A few examples of ubiquitous but now dead programs and companies usually suffice. Heck, just reminding people of how you can lose functionality between one version of PowerPoint to the next will usually suffice.) So I'm not too worried that DSpace doesn't handle these things seamlessly, since most of my depositors don't expect it to, yet. Bitstreams in general I think DSpace's biggest weakness is its trusting nature: If the depositor says it's a PDF, DSpace believes it. We've just begun to look into how we might go one small step further by using JHOVE to at least identify the format. If the depositor says it's a PDF, does that appear to be true? Never mind validating and characterizing, at least for now. Sticking with PDF, the next step would be to differentiate between PDF and PDF/A...though as mentioned above, for those of us that embrace an unmediated, self-deposit mode, we can lead our users to best practices but we can't make them use them. So we'd have to think hard about whether we'd want to reject a sub-optimal (but still understandable and usable) file, or even alert depositors to it. ____________________________________ Jim Ottaviani +1 734-763-4835 Coordinator, Deep Blue http://deepblue.lib.umich.edu University of Michigan Library Quis custodiet ipsos custodes --Juvenal, Satires VI, 347 From sands at MIT.EDU Mon Sep 8 12:56:48 2008 From: sands at MIT.EDU (Sands Fish) Date: Mon, 8 Sep 2008 12:56:48 -0400 Subject: [Dspace-general] [Dspace-tech] Week 4: Bitstream types In-Reply-To: <356cf3980809080624u42c7b1ddh571b1db281257515@mail.gmail.com> References: <356cf3980809080624u42c7b1ddh571b1db281257515@mail.gmail.com> Message-ID: Dorothea, Concerning current work in the Bitstream type area of DSpace development, I presented at Open Repositories 08 ( http:// pubs.or08.ecs.soton.ac.uk/127/ ) on Larry Stone's (lcs at mit.edu) work, which greatly enhances DSpace's ability to handle and potentially disseminate file-types of various non-standard form. For more information on this work, see the extensive documentation here: http://wiki.dspace.org/index.php/BitstreamFormat_Renovation -- sands fish Software Engineer MIT Libraries Technology Research & Development sands at MIT.EDU E25-131 On Sep 8, 2008, at 9:24 AM, Dorothea Salo wrote: > I know I'm seriously late on last week's chat summary; it's on my > to-do list for today. Sorry about that! > > This week's question has to do with bitstreams. DSpace is designed > around discrete papers contained within single bitstreams, and it also > handles websites reasonably well. The question is: what else do you > have, what have you done with/to DSpace to accommodate it, and what > else do you need from DSpace? > > Bram de Luyten asks: "Would you recommend DSpace to an organization > with needs to use it as a repository for very specific filetypes, > different from standard documents (for example, audio or video > repository ...) ? Why (not) ? And what if they want to store "many > different things" ?" > > I'm feeling laissez-faire this week, and this is something of an > additive question, so go ahead and read other folks' answers before > adding your own. > > Dorothea > > -- > Dorothea Salo dsalo at library.wisc.edu > Digital Repository Librarian AIM: mindsatuw > University of Wisconsin > Rm 218, Memorial Library > (608) 262-5493 > > ---------------------------------------------------------------------- > --- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > DSpace-tech mailing list > DSpace-tech at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech From gbunton at odu.edu Mon Sep 8 13:20:00 2008 From: gbunton at odu.edu (Bunton, Glenn A.) Date: Mon, 8 Sep 2008 13:20:00 -0400 Subject: [Dspace-general] [Dspace-tech] Week 4: Bitstream types In-Reply-To: <356cf3980809080924x412dd0f8p27a2e260a97dc269@mail.gmail.com> References: <356cf3980809080624u42c7b1ddh571b1db281257515@mail.gmail.com> <20080908140739.GC3865@IUPUI.Edu> <356cf3980809080924x412dd0f8p27a2e260a97dc269@mail.gmail.com> Message-ID: <995598B9C975CB4682261F55BB321EF23706F4C7AE@MUFASA.ts.odu.edu> Just a quick comment from a very novice Dspace admin. In regards to multiple file types my impression has always been that Fedora (the repository, not the Red Hat version) was much more adept at handling various content types than Dspace. Is this impression incorrect? -----Original Message----- From: dspace-general-bounces at mit.edu [mailto:dspace-general-bounces at mit.edu] On Behalf Of Dorothea Salo Sent: Monday, September 08, 2008 12:25 PM To: dspace-general at mit.edu Subject: Re: [Dspace-general] [Dspace-tech] Week 4: Bitstream types I have all the same A/V problems Mark Woods talked about. What makes me unhappy about the SMIL/stream solution is that (if I understand things correctly, which I may not) I don't actually have the video file under DSpace's control for checksumming and so forth. There are ways around this (the file can live in two places!), but they seem cumbersome and they increase storage-space requirements heavily. Multimedia is also a problem just as Mark said, but let me toss into that mix compound objects like Flash learning objects. As I understand the structure of those benighted things, they act a little bit like HTML files, calling out to external resources like images and movies and whatever. *Unlike* HTML files, they're troublesome to rewrite, so to ingest them usably, we'd have to be *extra*-careful to maintain their directory structures... and I don't even want to *think* about ones that access resources by URL/URI, ugh. Here's a question I've never had an authoritative answer to: Suppose I put a mess of audio files in their own collection. Is the RSS feed from that collection podcast-friendly? If it isn't, how much work would it take (especially in XMLUI) to make it so? Other problems I've run into, along with potential solutions: - Individual page-scans. Not only do these look unconscionably messy on a DSpace item page, DSpace has no innate sense of bitstream order, which makes it *really* hard to tie in an outside page-turner app. What I've historically done is squish the scans into a (somewhat lower-quality) PDF via ImageMagick and ps2pdf, and throw that in along with the scans. This is -- okay, it's a gross hack, but it does well enough for the purpose, I guess. The display-messiness problem might be solvable with a Manakin theme, but again, there aren't really any hooks in DSpace to make this easy (though hm, *maybe* the "primary bitstream" notion could be repurposed), meaning any "solution" is going to be an ugly kludge. - Image collections. DSpace's usual browses are pretty grotty UI for this purpose. I'm looking at doing some kind of thumbnail browse in Manakin; it shouldn't be *that* hard. (Famous last words.) We might also want to look at what third-party whizbangs like PicLens/Cooliris need to do their magic. - We've run into problems in 1.4.x opening large PDFs in-browser. We *think* this was partly because of our bitstream-handle hack, and we also think the rewrite we did of that for 1.5 will solve the problem, so stay tuned. - Specialty metadata and persistent bitstream URLs for mashups. GIS metadata is a pain-point here. My colleagues on the digital-library side of the fence have done super-cool things with local collections and Google Maps. I know Manakin makes some of this possible because I've seen the demos, but I'm not smart enough to figure out how to make it work on my own. I think those are our big pain-points. I may think of more as the week goes on. Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 _______________________________________________ Dspace-general mailing list Dspace-general at mit.edu http://mailman.mit.edu/mailman/listinfo/dspace-general From mwood at IUPUI.Edu Mon Sep 8 13:37:54 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Mon, 8 Sep 2008 13:37:54 -0400 Subject: [Dspace-general] Week 4: Bitstream types (Dorothea Salo) In-Reply-To: References: Message-ID: <20080908173754.GA29222@IUPUI.Edu> If an organization has people whose focus is A/V production, then a little help from them could go a long way. And they probably also wince at some of the stuff that people bring to us, and might like the opportunity to help spiff it up. For those who don't have a media department or can't call on it, maybe the best DSpace can do is some ancillary scripts that package the operations required to render such bitstreams in formats best suited to wide use and long-term preservation. I don't think we want it to be automatic. Some of us have a desire to archive both (say) the raw MPEG-2 data for the sake of never losing anything, and a properly edited, well-engineered, scaled and compressed version for daily use. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080908/50fa39df/attachment.bin From dsalo at library.wisc.edu Mon Sep 8 13:46:28 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Mon, 8 Sep 2008 12:46:28 -0500 Subject: [Dspace-general] Week 4: Bitstream types (Dorothea Salo) In-Reply-To: <20080908173754.GA29222@IUPUI.Edu> References: <20080908173754.GA29222@IUPUI.Edu> Message-ID: <356cf3980809081046xf1d1de7o874a920be3f3738f@mail.gmail.com> > I don't think we want it to > be automatic. Some of us have a desire to archive both (say) the raw > MPEG-2 data for the sake of never losing anything, and a properly edited, > well-engineered, scaled and compressed version for daily use. As a rule, I would want anything that changes a bitstream without human intervention to be non-destructive. I can see where that might become obnoxious from a storage standpoint, though, especially with video. Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From sbeers at gmu.edu Mon Sep 8 16:42:06 2008 From: sbeers at gmu.edu (Shane Beers) Date: Mon, 08 Sep 2008 16:42:06 -0400 Subject: [Dspace-general] [Dspace-tech] Week 4: Bitstream types In-Reply-To: <356cf3980809080624u42c7b1ddh571b1db281257515@mail.gmail.com> References: <356cf3980809080624u42c7b1ddh571b1db281257515@mail.gmail.com> Message-ID: <915964A0-1BDB-4FB3-8A24-C04BA869D502@gmu.edu> DSpace is, honestly, not good at doing anything regarding audiovisual data types besides doing what it does with textual data - storing them, providing basic metadata, and allowing users to download them. While this is often good enough for textual data (combined with the indexing of the textual content), it's essentially useless for an a/v archive. There are a number of archival products both open source and commercial that handle image data (I know less about moving image data) in a far, far superior way to DSpace. I do have to say that I don't necessarily look at this as a failure of DSpace in some way, as I don't think working with image data was even really considered in the design phase. However, no one working with a large collection of digital images would even begin to consider using DSpace as an archival platform unless they wanted to be continually frustrated and have none of the features that one desires when working with images, such as panning/zooming, photography-specific metadata, lightboxes, and so on. I don't know if developers are at all interested in providing better support for a/v materials, as they would more-or-less have to duplicate the features of existing, successful (and frequently commercial) products (see ContentDM) to make me interested. I think it would certainly be an advantage and an improvement to DSpace, but I think there are certainly some higher priority improvements that need to take place on the textual document end. Shane Beers Digital Repository Services Librarian George Mason University sbeers at gmu.edu http://mars.gmu.edu 703-993-3742 On Sep 8, 2008, at 9:24 AM, Dorothea Salo wrote: > I know I'm seriously late on last week's chat summary; it's on my > to-do list for today. Sorry about that! > > This week's question has to do with bitstreams. DSpace is designed > around discrete papers contained within single bitstreams, and it also > handles websites reasonably well. The question is: what else do you > have, what have you done with/to DSpace to accommodate it, and what > else do you need from DSpace? > > Bram de Luyten asks: "Would you recommend DSpace to an organization > with needs to use it as a repository for very specific filetypes, > different from standard documents (for example, audio or video > repository ...) ? Why (not) ? And what if they want to store "many > different things" ?" > > I'm feeling laissez-faire this week, and this is something of an > additive question, so go ahead and read other folks' answers before > adding your own. > > Dorothea > > -- > Dorothea Salo dsalo at library.wisc.edu > Digital Repository Librarian AIM: mindsatuw > University of Wisconsin > Rm 218, Memorial Library > (608) 262-5493 > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > DSpace-tech mailing list > DSpace-tech at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech From peterwalgemoed at carelliance.com Mon Sep 8 19:53:06 2008 From: peterwalgemoed at carelliance.com (Peter Walgemoed) Date: Tue, 09 Sep 2008 01:53:06 +0200 Subject: [Dspace-general] Week 4: Bitstream types (Dorothea Salo) In-Reply-To: <20080908173754.GA29222@IUPUI.Edu> References: <20080908173754.GA29222@IUPUI.Edu> Message-ID: <48C5BAE2.9000408@carelliance.com> An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080909/269de127/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: peterwalgemoed.vcf Type: text/x-vcard Size: 291 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080909/269de127/attachment.vcf From liucong315 at yahoo.com.cn Tue Sep 9 03:00:12 2008 From: liucong315 at yahoo.com.cn (=?gb2312?B?wfW0zw==?=) Date: Tue, 9 Sep 2008 15:00:12 +0800 Subject: [Dspace-general] Which version of SRB does Dspace support? Message-ID: <200809091500047033149@yahoo.com.cn> Hi£º Now we are using dspace to build a library system. In this system we need to use SRB( The SDSC Storage Resource Broker) to stroe the files.But we don't konw which version SRB is supported? Looking forward your reply.Thanks a lot. Cong Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080909/0c38d3e1/attachment.htm From liucong315 at yahoo.com.cn Tue Sep 9 03:05:05 2008 From: liucong315 at yahoo.com.cn (=?gb2312?B?wfW0zw==?=) Date: Tue, 9 Sep 2008 15:05:05 +0800 Subject: [Dspace-general] Which version of SRB does Dspace support? Message-ID: <200809091505003757357@yahoo.com.cn> Hi£º Now we are using dspace to build a library system. In this system we need to use SRB( The SDSC Storage Resource Broker) to stroe the files.But we don't konw which version SRB is supported? Looking forward your reply.Thanks a lot. Cong Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080909/b4db3e8b/attachment.htm From dsalo at library.wisc.edu Tue Sep 9 09:00:50 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Tue, 9 Sep 2008 08:00:50 -0500 Subject: [Dspace-general] Week 4: Bitstream types (Dorothea Salo) In-Reply-To: <48C5BAE2.9000408@carelliance.com> References: <20080908173754.GA29222@IUPUI.Edu> <48C5BAE2.9000408@carelliance.com> Message-ID: <356cf3980809090600u487a1376rc95005b31d08a2ed@mail.gmail.com> 2008/9/8 Peter Walgemoed : > I fully agree with Mark's suggestion. A/V as well as Medical Imaging is not > something you would like to deal with as a generic repository service. Assuredly true. That doesn't mean I don't have to. Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From mwood at IUPUI.Edu Tue Sep 9 10:00:12 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Tue, 9 Sep 2008 10:00:12 -0400 Subject: [Dspace-general] Week 4: Bitstream types (Dorothea Salo) In-Reply-To: <356cf3980809090600u487a1376rc95005b31d08a2ed@mail.gmail.com> References: <20080908173754.GA29222@IUPUI.Edu> <48C5BAE2.9000408@carelliance.com> <356cf3980809090600u487a1376rc95005b31d08a2ed@mail.gmail.com> Message-ID: <20080909140012.GB11751@IUPUI.Edu> On Tue, Sep 09, 2008 at 08:00:50AM -0500, Dorothea Salo wrote: > 2008/9/8 Peter Walgemoed : > > I fully agree with Mark's suggestion. A/V as well as Medical Imaging is not > > something you would like to deal with as a generic repository service. > > Assuredly true. That doesn't mean I don't have to. But you *don't* have to. Somebody already invented RealPlayer. Somebody already invented Adobe Reader. Somebody already invented word processors, networked version control systems, text pagers, slide sorters, etc. As somebody invented DSpace. What we need is to bolt them all to a well-designed panel and invent the wiring that connects them. The panel becomes The Machine, and all the various sub-machines disappear behind it, although they still exist as discrete components that can be replaced individually as needed. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080909/7467f4c4/attachment.bin From tdm27 at cam.ac.uk Tue Sep 9 10:13:06 2008 From: tdm27 at cam.ac.uk (Tom De Mulder) Date: Tue, 9 Sep 2008 15:13:06 +0100 (BST) Subject: [Dspace-general] Week 4: Bitstream types (Dorothea Salo) In-Reply-To: <20080909140012.GB11751@IUPUI.Edu> References: <20080908173754.GA29222@IUPUI.Edu> <48C5BAE2.9000408@carelliance.com> <356cf3980809090600u487a1376rc95005b31d08a2ed@mail.gmail.com> <20080909140012.GB11751@IUPUI.Edu> Message-ID: On Tue, 9 Sep 2008, Mark H. Wood wrote: >>> I fully agree with Mark's suggestion. A/V as well as Medical Imaging is not >>> something you would like to deal with as a generic repository service. >> Assuredly true. That doesn't mean I don't have to. > But you *don't* have to. Somebody already invented RealPlayer. As far as I know, noone invented a long-term storage solution for general digital content, including images, audio, video and scientific and medical data. This generic data often ties together closely to papers also deposited in a repository. As such it makes sense to store it all together. We have quite a lot of all types of content, and have already had to bash the DSpace software hard (the thumbnails in particular were implemented in an atrociously inefficient way) to make it work. But we need it to work, because a large part of our remit is digital preservation. > sorters, etc. As somebody invented DSpace. What we need is to bolt > them all to a well-designed panel and invent the wiring that connects > them. The panel becomes The Machine, and all the various sub-machines > disappear behind it, although they still exist as discrete components > that can be replaced individually as needed. I can only assume that you haven't tried to bolt much into DSpace. -- Tom De Mulder - Cambridge University Computing Service +44 1223 3 31843 - New Museums Site, Pembroke Street, Cambridge CB2 3QH -> 09/09/2008 : The Moon is Waxing Gibbous (53% of Full) From mwood at IUPUI.Edu Tue Sep 9 10:50:45 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Tue, 9 Sep 2008 10:50:45 -0400 Subject: [Dspace-general] Week 4: Bitstream types (Dorothea Salo) In-Reply-To: References: <20080908173754.GA29222@IUPUI.Edu> <48C5BAE2.9000408@carelliance.com> <356cf3980809090600u487a1376rc95005b31d08a2ed@mail.gmail.com> <20080909140012.GB11751@IUPUI.Edu> Message-ID: <20080909145045.GA13974@IUPUI.Edu> On Tue, Sep 09, 2008 at 03:13:06PM +0100, Tom De Mulder wrote: > As far as I know, noone invented a long-term storage solution for general > digital content, including images, audio, video and scientific and medical > data. This generic data often ties together closely to papers also deposited > in a repository. As such it makes sense to store it all together. No one has invented a long-term storage solution for *anything*. When it exists, it'll exist equally for all content, because in the storage layer content is content -- it doesn't matter what is represented therein. Way up in the presentation layer, there are other considerations, such as telling the user's browser what kind of content we think this bit is, migrating formats as the winds of fashion wobble, facilitating relationships among bitstreams, and so on. > We have quite a lot of all types of content, and have already had to bash > the DSpace software hard (the thumbnails in particular were implemented in > an atrociously inefficient way) to make it work. But we need it to work, > because a large part of our remit is digital preservation. I think I don't quite understand what is meant by "preservation" here. What's the connection between thumbnails and preservation, for instance? >> sorters, etc. As somebody invented DSpace. What we need is to bolt >> them all to a well-designed panel and invent the wiring that connects >> them. The panel becomes The Machine, and all the various sub-machines >> disappear behind it, although they still exist as discrete components >> that can be replaced individually as needed. > > I can only assume that you haven't tried to bolt much into DSpace. Why do you think DSpace is the panel? I think the browser is the panel. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080909/acff8c15/attachment.bin From sil.linguist at gmail.com Tue Sep 9 12:44:48 2008 From: sil.linguist at gmail.com (Hugh Paterson III) Date: Tue, 9 Sep 2008 11:44:48 -0500 Subject: [Dspace-general] Week 4: Bitstream types (Dorothea Salo) In-Reply-To: <356cf3980809081046xf1d1de7o874a920be3f3738f@mail.gmail.com> References: <20080908173754.GA29222@IUPUI.Edu> <356cf3980809081046xf1d1de7o874a920be3f3738f@mail.gmail.com> Message-ID: <324503CB-7B2F-4742-A368-5DEFEE4B3F29@gmail.com> True, but unlike stationary (paper based) media in order for a user to "pre-view" an audio or video file they have to "see" multiple portions of the file. With traditional media I read a paragraph or an abstract and say this article is going to be worth reading let me download it. but with video I am going to want to see if it is relevant or if the quality is good enough. So I am going to want a preview function as a user. YouTube offers this feature where a user can start viewing the file from any point. For the system to load a full size preview and then for the user to not download it seems wasteful in terms of bandwidth. H.264 has a great scalable features. http://en.wikipedia.org/wiki/H.264 So why not automatically create a "preview" version when ever an audio/video file is added to the archive? Sure. There may be people who want the MPEG-2 file but there are people that will be served the file who don't want that original file. Why not serve them an h.264 preview of the file and then also serve them a link to the MPEG-2 file. Just like flikr.com gives users size options when they download pictures why not give users a size option when downloading video/audio/ pictures in d-space? - Hugh Paterson III Hugh_Paterson at sil.org On Sep 8, 2008, at 12:46 PM, Dorothea Salo wrote: >> I don't think we want it to >> be automatic. Some of us have a desire to archive both (say) the raw >> MPEG-2 data for the sake of never losing anything, and a properly >> edited, >> well-engineered, scaled and compressed version for daily use. > > As a rule, I would want anything that changes a bitstream without > human intervention to be non-destructive. I can see where that might > become obnoxious from a storage standpoint, though, especially with > video. > > Dorothea > > -- > Dorothea Salo dsalo at library.wisc.edu > Digital Repository Librarian AIM: mindsatuw > University of Wisconsin > Rm 218, Memorial Library > (608) 262-5493 > _______________________________________________ > Dspace-general mailing list > Dspace-general at mit.edu > http://mailman.mit.edu/mailman/listinfo/dspace-general From mwood at IUPUI.Edu Tue Sep 9 14:56:52 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Tue, 9 Sep 2008 14:56:52 -0400 Subject: [Dspace-general] Week 4: Bitstream types (Dorothea Salo) In-Reply-To: <324503CB-7B2F-4742-A368-5DEFEE4B3F29@gmail.com> References: <20080908173754.GA29222@IUPUI.Edu> <356cf3980809081046xf1d1de7o874a920be3f3738f@mail.gmail.com> <324503CB-7B2F-4742-A368-5DEFEE4B3F29@gmail.com> Message-ID: <20080909185652.GB18816@IUPUI.Edu> On Tue, Sep 09, 2008 at 11:44:48AM -0500, Hugh Paterson III wrote: > True, but unlike stationary (paper based) media in order for a user to > "pre-view" an audio or video file they have to "see" multiple portions > of the file. With traditional media I read a paragraph or an abstract > and say this article is going to be worth reading let me download it. > but with video I am going to want to see if it is relevant or if the > quality is good enough. So I am going to want a preview function as a > user. YouTube offers this feature where a user can start viewing the > file from any point. For the system to load a full size preview and > then for the user to not download it seems wasteful in terms of > bandwidth. H.264 has a great scalable features. http://en.wikipedia.org/wiki/H.264 I think that's a job for browser plugins, not DSpace. Writing a whole new video player in Javascript sounds daunting. And we still need to address streaming vs. download-and-then-view. > So why not automatically create a "preview" version when ever an > audio/video file is added to the archive? Sure. There may be people > who want the MPEG-2 file but there are people that will be served the > file who don't want that original file. Why not serve them an h.264 > preview of the file and then also serve them a link to the MPEG-2 > file. Just like flikr.com gives users size options when they download > pictures why not give users a size option when downloading video/audio/ > pictures in d-space? Now that sounds modest enough that we might be able to do it before 2015. A suitable XMLUI theme might pick off video bitstreams, for example, and offer them as sizes, IF it can tell that certain bitstreams are resampled versions of each other. Is there a metadata standard for marking them as such? Hmmm, how easy is it to plug new *actions* into the ingestion process? Some collections might want automatic scaling, others clipping, others still extraction, others something we can't imagine. If we accommodate every taste we're going to rile up the people who say that submission is already too complicated. By the way, we need to be careful about patents in the video area. There are a lot of them. On H.264 for example. Some things it may not be possible to build into a redistributable product. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080909/86c2d7c9/attachment.bin From Ina.Smith at up.ac.za Wed Sep 10 05:24:17 2008 From: Ina.Smith at up.ac.za (Ina Smith) Date: Wed, 10 Sep 2008 11:24:17 +0200 Subject: [Dspace-general] Please register now! Attend the African Digital Scholarship & Curation Conference 2009! Message-ID: <48C7AE61.1050.00C0.0@up.ac.za> The African Digital Scholarship & Curation Conference 12-14 May 2009 preliminary programme & registration form are now available on the Web (http://www.ais.up.ac.za/digitalscholarship.htm). Digital scholarship and curation are steadily gaining momentum internationally and on the continent. Are you and your institution a part of this dynamic process? If yes, then join colleagues at this conference to share ideas, network and strategise. If no, then you should attend to become a part of this dynamic process. Some of the exciting topics presented by African & international speakers are: e-Research & e-Science, Digital preservation, Digital data managemant & curation, Collaboration / Web 2, Repositories, Intellectual property issues, Open scholarship, e-Resources, e-Learning and Distance learning, IT infrastructure for digital scholarship, IT adoption & perceptions, Information literacy, Digital divide. Workshops are also available on: Spatial data, Web 2 for your library, Implementation of an institutional repository, Use & pitfalls of federated searching, Open access & advancement of science & research, Computer games for information literacy. Last day of payment: 31 March 2009 Full 2 day conference: R1 500 Single day of conference: R800 Each workshop: R400 Function: R50 See you there! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080910/00ea8195/attachment.htm From philip.hunter at ed.ac.uk Wed Sep 10 12:25:23 2008 From: philip.hunter at ed.ac.uk (Philip Hunter) Date: Wed, 10 Sep 2008 17:25:23 +0100 Subject: [Dspace-general] The Repository Fringe 2008 - Streamed video of the event Message-ID: <006a01c91361$d350c090$c747d781@liblap1504> Apologies for cross-posting **** Repository Fringe 2008 Those interested in the likely future development of repositories will be interested in the streamed video presentations of the event which are now available at: www.repositoryfringe.org. Many of the Powerpoint presentations are also available from the site. Repository Fringe 2008 was held on the 31st of August and the 1st of September, funded by JISC and hosted by the University of Edinburgh, and saw researchers exchange ideas on the best way this data might be collected, stored and made accessible. The keynote presentation was given by Dorothea Salo (Wisconsin) and focussed on the failure of the 'build it and they will come' approach to institutional repository provision ('Le IR, c'est mort. Vive le IR!') . Other presentations took up the theme of radically rethinking the repository idea. Posted by: ********************************* Philip Hunter Digital Library Section Edinburgh University Library George Square, Edinburgh, EH8 9LJ Tel: +44 (0)131 651 3768 ********************************* -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From mdiggory at MIT.EDU Wed Sep 10 17:36:12 2008 From: mdiggory at MIT.EDU (Mark Diggory) Date: Wed, 10 Sep 2008 14:36:12 -0700 Subject: [Dspace-general] DSpace 1.5.1 Stable Release Message-ID: <739D3D71-E09D-485C-9470-9888ECEB2599@mit.edu> Dear DSpace Community, We are pleased to announce the release of DSpace 1.5.1 stable. This release is primarily a bug fix release incorporating numerous bug fixes and enhancements. Refer to the http://wiki.dspace.org/index.php/DSpace_Release_1.5.1_Notes and SVN history for details on these modifications. http://fisheye3.atlassian.com/changelog/~date=2008-09-11T00%3A00%3A00/ dspace/branches/dspace-1_5_x Although this is a tested stable release, there is always the case that new issues may be uncovered. We request that community members interested in testing the release please download it and verify that they can complete upgrade and fresh installation. The documentation for this release is bundled within the package. DSpace 1.5.1 can be downloaded from the files area at https://sourceforge.net/project/showfiles.php? group_id=19984&package_id=64285&release_id=625291 or with SVN from http://dspace.svn.sf.net/svnroot/dspace/tags/dspace-1_5_1/ Please use the mailing lists to provide feedback on this release. Those wishing to do development work with DSpace are strongly encouraged to obtain the source code using SVN. This is very straightforward and a guide to doing this is available here: http:// wiki.dspace.org/ContributionGuidelines We would also like to take this opportunity to invite you all to take part in the DSpace development process. Extra developer hands are always welcome, but there are other ways you can help: - Test the system and report bugs - Provide documentation (for end users and institutions, as well as technical) - Provide or update language packs - Share your deployment experiences - Donate content and metadata for testing and research - Share your technical experience and ideas Please visit the DSpace Wiki to see the various resources and collaboration tools available to the DSpace community: http:// wiki.dspace.org/DspaceResources Sincerely, Mark Diggory ~~~~~~~~~~~~~ Mark R. Diggory - DSpace Developer and Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology Home Page: http://purl.org/net/mdiggory/homepage From priyadharshini.sridhar at tcs.com Thu Sep 11 01:11:05 2008 From: priyadharshini.sridhar at tcs.com (Priyadharshini Sridhar) Date: Thu, 11 Sep 2008 10:41:05 +0530 Subject: [Dspace-general] query... Message-ID: Hello, We are trying to use dspace to archive our multimedia content. We are able to install dspace successfully. But we are unable to use it as the admin user created by us is removed automatically by the software. Can you pl. help us out on this? Thanks, Priyadharshini Sridhar Tata Consultancy Services Mailto: priyadharshini.sridhar at tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Outsourcing ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080911/abbabc01/attachment.htm From stb28 at cam.ac.uk Thu Sep 11 10:24:42 2008 From: stb28 at cam.ac.uk (Simon Brown) Date: Thu, 11 Sep 2008 15:24:42 +0100 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <48C548F2.5000301@biomedcentral.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <356cf3980809020827u30def80fw4d4183d08f717949@mail.gmail.com> <48C548F2.5000301@biomedcentral.com> Message-ID: On 8 Sep 2008, at 16:46, Graham Triggs wrote: > Simon Brown wrote: >> Now, in a way, I can understand why fixing these things hasn't >> been high on anyone's list - my institution has things it would >> rather I do with our system in the same way that anyone else's >> does. What I'm less sure of is why a better architecture (which >> would benefit everyone who works with the codebase and therefore, >> indirectly, everyone else who uses DSpace) hasn't been more of a >> priority for the federation. > > This isn't intended to be rude, but I think this deserves a response > and the only way I can see to do so is simply state the facts. Not taken as such. It's information that I didn't possess, and as such I'm grateful for it. It makes a couple of things a bit clearer. > That brings us up to two months ago, which is where the work to > define the scope and priorities of the funded development has begun. Has there been any output from this yet? Is the aim that output from these processes will be fed back to these mailing lists? > As you say, without the foundation doing all the above, there are > very few people that are in a position to address even part of the > architectural problem. But even with the best will in the world, > those are the timescales to making it a practical reality. I guess my concern is that much of this effort will be focused on blue- sky "the future of DSpace"-type thinking, rather than the sort which aims to fix the real problems people are having with the software right now. The future needs to be looked to; the present shouldn't be neglected in order to do so. I will be very happy to know that this concern is unfounded. -- Simon Brown - Cambridge University Computing Service +44 1223 3 34714 - New Museums Site, Pembroke Street, Cambridge CB2 3QH From sands at MIT.EDU Thu Sep 11 10:25:51 2008 From: sands at MIT.EDU (Sands Fish) Date: Thu, 11 Sep 2008 10:25:51 -0400 Subject: [Dspace-general] query... In-Reply-To: References: Message-ID: <57538410-E2BA-4F35-A64B-D7D7294636FF@mit.edu> Priyadharshini, could you say what version of DSpace you are trying to use? You are using the ./create-administrator script to create your admin account? What indication do you have that this account is being removed? Are there any errors you can share? Cheers, -- sands fish Software Engineer MIT Libraries Technology Research & Development sands at MIT.EDU E25-131 On Sep 11, 2008, at 1:11 AM, Priyadharshini Sridhar wrote: > > Hello, > We are trying to use dspace to archive our multimedia content. We > are able to install dspace successfully. But we are unable to use > it as the admin user created by us is removed automatically by the > software. Can you pl. help us out on this? > Thanks, > Priyadharshini Sridhar > Tata Consultancy Services > Mailto: priyadharshini.sridhar at tcs.com > Website: http://www.tcs.com > ____________________________________________ > Experience certainty. IT Services > Business Solutions > Outsourcing > ____________________________________________ > =====-----=====-----===== > Notice: The information contained in this e-mail > message and/or attachments to it may contain > confidential or privileged information. If you are > not the intended recipient, any dissemination, use, > review, distribution, printing or copying of the > information contained in this e-mail message > and/or attachments to it are strictly prohibited. If > you have received this communication in error, > please notify us by reply e-mail or telephone and > immediately and permanently delete the message > and any attachments. Thank you > > > _______________________________________________ > Dspace-general mailing list > Dspace-general at mit.edu > http://mailman.mit.edu/mailman/listinfo/dspace-general -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080911/4d7f9bd5/attachment.htm From km.lib at cbs.dk Thu Sep 11 11:22:19 2008 From: km.lib at cbs.dk (Kurt Mathiesen) Date: Thu, 11 Sep 2008 17:22:19 +0200 Subject: [Dspace-general] Add-on: Add pdf cover page Message-ID: <5C265E69B914434EBD9CEAAB2DD9804E0BC8776C9F@EXCHANGE01.hhk.dk> Hi All, is there an add-on for Dspace that can add a pdf cover page to an uploaded pdf? something like http://files.eprints.org/36/ (for Eprints) I think I've seen it mentioned for Dspace a couple of months ago, but now I can't find anything about it. What we would like to do is to add a custom cover page containing university logo and address + some metadata from the archived item. Eg. Author, title, journal, doi, citation information, license etc. All the best Kurt -- Kurt Mathiesen, Research Services Librarian CBS Library, Faculty Services +45 38153764, km.lib at cbs.dk IM: MSN or Plugoo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080911/adb13a73/attachment.htm From michele at dspace.org Thu Sep 11 13:28:01 2008 From: michele at dspace.org (Michele Kimpton) Date: Thu, 11 Sep 2008 13:28:01 -0400 Subject: [Dspace-general] Speakers announced for SPARC repositories conference Message-ID: SPARC ANNOUNCES INTERNATIONAL SPEAKER ROSTER FOR NOVEMBER REPOSITORIES MEETING Early bird registration deadline is September 15, 2008 Washington, DC ? September 11, 2008 ? SPARC (the Scholarly Publishing and Academic Resources Coalition) has announced a prominent slate of speakers for the SPARC Digital Repositories Meeting 2008 in Baltimore on November 17 and 18. The gathering, organized by SPARC in cooperation with SPARC Europe and SPARC Japan (a Japan National Informatics Institute initiative), will examine how open online archives may be enhanced to further serve scholars, institutions, and the public. Leaders, innovators, and practitioners from North America, Europe, and Asia will explore new frontiers in building and supporting online open archives. Four timely discussion tracks bring together speakers with far-reaching experience: New Horizons (Monday, November 17, morning) Speakers: Norbert Lossau (Director, Goettingen State and University Library and a leader of Europe?s DRIVER Project, Germany), Jennifer Campbell-Meier (Doctoral Student, Communication and Information Sciences, University of Hawaii, USA), Shawn Martin (Scholarly Communication Librarian, University of Pennsylvania, USA). Developing Value-Added Services (Monday, November 17, afternoon) Speakers: Sayeed Chodhury (Associate Dean for Library Digital Programs, Johns Hopkins University, USA), Joan Giesecke (Dean of Libraries) and Paul Royster (Coordinator of Scholarly Communications, University of Nebraska-Lincoln, USA), Hideki UCHIJIMA (Librarian, Kanazawa University Library, Japan). The Policy Environment (Tuesday, November 18, morning) Speakers: Bernard Rentier (Rector, University of Li?ge, Belgium), Syun Tutiya (Professor of Cognitive and Information Sciences, Chiba University, Japan), Bonnie Klein (Information Collection and Copyright Specialist, Defense Technical Information Center, USA). Campus Publishing Strategies (Tuesday, November 18, morning) Speakers: Rea Devakos (T-Space Service Coordinator, University of Toronto, Canada), Catherine Mitchell (Director, eScholarship Publishing Group, California Digital Library, USA), Teresa Fishel (Library Director) and Janet Sietmann (DigitalCommons Project Manager, Macalester College, USA). Filling out the extensive program will be a marketing practicum for repository advocates, an innovation fair, and keynote talks by John Wilbanks, Vice President for Science at Creative Commons and director of the Science Commons program; Bob Witeck, CEO and co-founder of Witeck-Combs Communications, a renowned marketing communications and public relations agency in Washington, DC; and David Shulenburger, Vice President for Academic Affairs at the National Association of State University and Land-Grant Colleges (NASULGC). For program detail, see the conference Web site at http://www.arl.org/sparc/ir08 . The SPARC Digital Repositories Meeting 2008 is supported by major contributions from Microsoft (Conference Sponsor); Berkeley Electronic Press, BioMed Central, and EPrints, (Coffee Break Sponsors); and by additional contributions from: Association of College and Research Libraries (ACRL), Association of Research Libraries (ARL), CRKN (Canadian Research Knowledge Network), DSpace Foundation, Fedora Commons, Greater Western Library Alliance, HP, the Japanese Coordinating Committee for University Libraries, JISC, and NISO. This meeting is a follow up to SPARC?s popular 2004 institutional repositories conference, which drew hundreds of participants from around the globe and set the stage for some of the key developments in open access of the past four years. To register for the SPARC Digital Repositories Meeting 2008, visit the conference Web site at http://www.arl.org/sparc/ir08. Early Bird Registration is available only until midnight on Monday, September 15. # SPARC SPARC (Scholarly Publishing and Academic Resources Coalition), with SPARC Europe and SPARC Japan, is an international alliance of more than 800 academic and research libraries working to create a more open system of scholarly communication. SPARC?s advocacy, educational and publisher partnership programs encourage expanded dissemination of research. SPARC is on the Web athttp://www.arl.org/sparc. The SPARC Digital Repositories Meeting program has been developed by the members of the 2008 Program Committee: Jun Adachi (SPARC Japan), Raym Crow (SPARC), Richard Fyffe (Grinnell College), Susan Gibbons (University of Rochester), Melissa Hagemann (Open Society Institute), Karla Hahn (Association of Research Libraries), Bill Hubbard (SHERPA), Rick Johnson (SPARC), Michelle Kimpton (DSpace Foundation), Norbert Lossau (Goettingen State and University Library and DRIVER), Joyce Ogburn (University of Utah), Terry Owen (University of Maryland, College Park), Kathleen Shearer (Canadian Association of Research Libraries), Alma Swan (Key Perspectives Ltd.), Sean Thomas (Massachusetts Institute of Technology), Susan Veldsman (eIFL), and Charles Watkinson (The American School of Classical Studies at Athens). -- -------------------------- Jennifer McLennan Director of Communications SPARC (The Scholarly Publishing & Academic Resources Coalition) http://www.arl.org/sparc ************************** Save the date: The SPARC Digital Repositories Meeting 2008 November 17 18, 2008 | Baltimore, MD ************************** (202) 296-2296 ext 121 jennifer at arl.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080911/f360e7a1/attachment.htm From Gail.Truman at Sun.COM Thu Sep 11 14:16:02 2008 From: Gail.Truman at Sun.COM (Gail Truman) Date: Thu, 11 Sep 2008 11:16:02 -0700 Subject: [Dspace-general] Reg: Speakers announced for SPARC repositories conference In-Reply-To: References: Message-ID: <48C96062.4020802@sun.com> Michele and Dspace community: For those of you who attend SPARC you may want to continue your stay in Baltimore and attend the Preservation Archive Special Interest Group (which is attended by DSpace users and community, along with others). Please forgive the broad posting, but if you are interested please see below details Thanks Gail Truman, Sun Microsystems, Open Archive product manager Details: The venue for the next Sun Preservation and Archiving Special Interest Group (PASIG) has now been set. It will be at the Baltimore Hilton November 19-21. The event will start with a reception on *Tuesday, November 18th and will end midday on Friday, November 21st.* Receptions will also be held on Wednesday and Thursday evenings. 1) Location and Registration: Baltimore was chosen as the venue for November's meeting in order not to compete with the SPARC Digital Repositories Conference (http://www.arl.org/sparc/meetings/ir08) on Monday and Tuesday. We heard from Sun PASIG members that there was a conflict, so we decided to optimize both conferences by allowing cross fertilization in Baltimore. The Summer PASIG meeting in June will shift back to Europe. The Hilton hotel room rate is $194.00. We will have the registration open on the www.sun-pasig.org mid-next week. Though Sun is defraying most of the costs for the event, there will be a registration fee for the PASIG conference. Education, non-profit, and Government customers will be charged a $100.00 Early Bird Special through October 17 and $200.00 afterwards. Sun partners and commercial entities will be charged $500.00 per person and Sun employees will be charged $400.00. Partners may bring literature for distribution at the conference. 2) The Agenda: We will be maintaining the focus on previous working group topics - Enterprise Repository Architectures, Preservation, Longterm Data Management and Storage, and Data Curation. But any ideas for content, presentations, or an additional working group topic are welcome! We will be taking input from the Advisory Group and also the registration forms we receive in the first month in order to collaboratively craft the agenda with the community. So, iterations of the agenda will be sent out with the final agenda appearing mid-October. But we will keep the basic structure of plenaries, panels, working group break outs, 1-1 architectural sessions, etc. that has been successful. Michele Kimpton wrote: > SPARC ANNOUNCES INTERNATIONAL SPEAKER ROSTER > FOR NOVEMBER REPOSITORIES MEETING > > Early bird registration deadline is September 15, 2008 > > Washington, DC ? September 11, 2008 ? SPARC (the Scholarly Publishing > and Academic Resources Coalition) has announced a prominent slate of > speakers for the SPARC Digital Repositories Meeting 2008 in Baltimore > on November 17 and 18. The gathering, organized by SPARC in > cooperation with SPARC Europe and SPARC Japan (a Japan National > Informatics Institute initiative), will examine how open online > archives may be enhanced to further serve scholars, institutions, and > the public. > > Leaders, innovators, and practitioners from North America, Europe, and > Asia will explore new frontiers in building and supporting online open > archives. Four timely discussion tracks bring together speakers with > far-reaching experience: > > New Horizons (Monday, November 17, morning) > > Speakers: Norbert Lossau (Director, Goettingen State and University > Library and a leader of Europe?s DRIVER Project, Germany), Jennifer > Campbell-Meier (Doctoral Student, Communication and Information > Sciences, University of Hawaii, USA), Shawn Martin (Scholarly > Communication Librarian, University of Pennsylvania, USA). > > Developing Value-Added Services (Monday, November 17, afternoon) > > Speakers: Sayeed Chodhury (Associate Dean for Library Digital > Programs, Johns Hopkins University, USA), Joan Giesecke (Dean of > Libraries) and Paul Royster (Coordinator of Scholarly Communications, > University of Nebraska-Lincoln, USA), Hideki UCHIJIMA (Librarian, > Kanazawa University Library, Japan). > > The Policy Environment (Tuesday, November 18, morning) > > Speakers: Bernard Rentier (Rector, University of Li?ge, Belgium), Syun > Tutiya (Professor of Cognitive and Information Sciences, Chiba > University, Japan), Bonnie Klein (Information Collection and Copyright > Specialist, Defense Technical Information Center, USA). > > Campus Publishing Strategies (Tuesday, November 18, morning) > > Speakers: Rea Devakos (T-Space Service Coordinator, University of > Toronto, Canada), Catherine Mitchell (Director, eScholarship > Publishing Group, California Digital Library, USA), Teresa Fishel > (Library Director) and Janet Sietmann (DigitalCommons Project Manager, > Macalester College, USA). > > Filling out the extensive program will be a marketing practicum for > repository advocates, an innovation fair, and keynote talks by John > Wilbanks, Vice President for Science at Creative Commons and director > of the Science Commons program; Bob Witeck, CEO and co-founder of > Witeck-Combs Communications, a renowned marketing communications and > public relations agency in Washington, DC; and David Shulenburger, > Vice President for Academic Affairs at the National Association of > State University and Land-Grant Colleges (NASULGC). > > For program detail, see the conference Web site > at http://www.arl.org/sparc/ir08. > > The SPARC Digital Repositories Meeting 2008 is supported by major > contributions from Microsoft (Conference Sponsor); Berkeley Electronic > Press, BioMed Central, and EPrints, (Coffee Break Sponsors); and by > additional contributions from: Association of College and Research > Libraries (ACRL), Association of Research Libraries (ARL), CRKN > (Canadian Research Knowledge Network), DSpace Foundation, Fedora > Commons, Greater Western Library Alliance, HP, the Japanese > Coordinating Committee for University Libraries, JISC, and NISO. > > This meeting is a follow up to SPARC?s popular 2004 institutional > repositories conference, which drew hundreds of participants from > around the globe and set the stage for some of the key developments in > open access of the past four years. > > To register for the SPARC Digital Repositories Meeting 2008, visit the > conference Web site at http://www.arl.org/sparc/ir08. Early Bird > Registration is available only until midnight on Monday, September 15. > > # > > SPARC > > SPARC (Scholarly Publishing and Academic Resources Coalition), with > SPARC Europe and SPARC Japan, is an international alliance of more > than 800 academic and research libraries working to create a more open > system of scholarly communication. SPARC?s advocacy, educational and > publisher partnership programs encourage expanded dissemination of > research. SPARC is on the Web athttp://www.arl.org/sparc. > > The SPARC Digital Repositories Meeting program has been developed by > the members of the 2008 Program Committee: Jun Adachi (SPARC Japan), > Raym Crow (SPARC), Richard Fyffe (Grinnell College), Susan Gibbons > (University of Rochester), Melissa Hagemann (Open Society Institute), > Karla Hahn (Association of Research Libraries), Bill Hubbard (SHERPA), > Rick Johnson (SPARC), Michelle Kimpton (DSpace Foundation), Norbert > Lossau (Goettingen State and University Library and DRIVER), Joyce > Ogburn (University of Utah), Terry Owen (University of Maryland, > College Park), Kathleen Shearer (Canadian Association of Research > Libraries), Alma Swan (Key Perspectives Ltd.), Sean Thomas > (Massachusetts Institute of Technology), Susan Veldsman (eIFL), and > Charles Watkinson (The American School of Classical Studies at Athens). > > > > -- > -------------------------- > Jennifer McLennan > Director of Communications > SPARC > (The Scholarly Publishing & Academic Resources Coalition) > http://www.arl.org/sparc > ************************** > Save the date: The SPARC Digital Repositories Meeting 2008 > November 17 18, 2008 | Baltimore, MD > ************************** > (202) 296-2296 ext 121 > jennifer at arl.org > > ------------------------------------------------------------------------ > > _______________________________________________ > Dspace-general mailing list > Dspace-general at mit.edu > http://mailman.mit.edu/mailman/listinfo/dspace-general > -- * Gail Truman * Open Archive, Data Protection Business Development Mgr, http://www.sun.com/storagetek/disk_systems/enterprise/5800/ http://www.sun.com/openstorage/ * Join the facebook open storage community group * http://www.facebook.com/group.php?gid=12774638036/ *Sun Microsystems, Inc.* Open Storage and Open Networks Business Group San Francisco, California US Phone 510 550 7313 Mobil 510 502 6497 Email Gail.Truman at Sun.COM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080911/b3e01a89/attachment.htm From baoxuemi at shu.edu Fri Sep 12 09:56:57 2008 From: baoxuemi at shu.edu (Xueming Bao) Date: Fri, 12 Sep 2008 09:56:57 -0400 Subject: [Dspace-general] JLIS Call for Papers Message-ID: JLIS Call for Papers The Journal of Library and Information Science (JLIS) is inviting submission of papers. JLIS is a peer-reviewed and bilingual (English and Chinese) scholarly journal focusing on library and information science. It publishes twice a year in April and October. For English papers to be published in the April issue, it is preferred that you submit your manuscript by December 31; for the October issue, please submit by June 30. If you have an article on library related subjects and are interested in publishing, please submit the manuscript via email attachment to Min Chou (email: mchou at njcu.edu). More information about the Journal is available at the website . Submission Guidelines Each submission should be accompanied by a cover letter indicating that the manuscript is original and not under consideration by any other journal or book. English manuscripts should be submitted to Min Chou, Associate Editor of JLIS, c/o Congressman Frank J. Guarini Library, New Jersey City University, 2039 Kennedy Boulevard, Jersey City, New Jersey, 07305-1597, U.S.A., or email: mchou at njcu.edu. All Chinese manuscripts should be submitted to the Editorial Board of JLIS, c/o Graduate Institute of Library & Information Studies, National Taiwan Normal University, 162, Section 1, Hoping East Road, Taipei, R.O.C in Taiwan, or email: Dr.Hsiao-tien PU at htpu at ntnu.edu.tw. Books, monographs, reports, and other items for review should be submitted to Dr. Mengxiong Liu, c/c Dr. Martin Luther King Jr. Library, San Jose State University, 1 Washington Square, San Jose, California 95192-0028, U.S.A., or email: mengxiong.liu at sjsu.edu. English manuscripts must be typed in MS Word and submitted either as email attachments or on a CD. Manuscripts should not exceed 10,000 words in length, not including notes, tables, and forms of data. A manuscript must have a separate title page bearing the title of the article, the author name, title, affiliation, email address, and full postal address. Author information may not appear on the manuscript itself, as the JLIS engages in double-blind review of manuscripts. Articles presented at a conference must include the name, place, and date of the conference. The body of a manuscript must be preceded by a 100-150-word abstract and 3-8 keywords, and followed by references and bibliographies. Each illustration or table should be numbered and have a brief caption. JLIS follows the Manual of the American Psychological Association for reference and bibliography style. Consult recent issues of JLIS as a guide to format. JLIS is an online e-journal accessible at http://cms.cala-web.org/node/165 . Authors will receive one printed copy of their articles. Additional copies can be purchased at a nominal cost from Showwei Information Technology Ltd. Copyright of all articles published in JLIS is held by the publisher. JLIS English Editor and Chair of CALA JLIS Editorial Board: Min Chou, (2008-2011) Reference Librarian/Associate Professor Congressman Frank J. Guarini Library New Jersey City University mchou at njcu.edu Editorial Team: Dr. Xue-Ming Bao, (2008-2010) Librarian II (Systems/Digital Library)/Associate Professor Seton Hall University Libraries baoxuemi at shu.edu Nancy Hershoff (2008-2011) Head, Bibliographic Control Dept., Florida International University sunn at fiu.edu Manuel Urrizola (2008-2010) Head, Cataloging & Metadata Services University of California at Riverside Manuel.Urrizola at ucr.edu Dr. Mark Winston (2008-2009) Assistant Chancellor and Director Dana Library Rutgers University winstonm at andromeda.rutgers.edu Ex-officio Officers: Sha-Li Zhang (CALA President 2008-09) Assistant Dean for Collections & Technical Services University Libraries The University of North Carolina at Greensboro slzhang at uncg.edu Mengxiong Liu (JLIS Editor for Book Reviews) Engineering Librarian and Professor of Library and Information Science San Jose State University mengxiong.liu at sjsu.edu Hong Miao (Co-Chair of Publications Committee 2008-09) Public Service Librarian Maywood University Library hongm at es.marywood.edu Mia Bassham (Co-Chair of Publications Committee 2008-09) Director Luzern Couty Community College Library mbassham at luzerne.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080912/0f39014a/attachment.htm From Claudia.Juergen at ub.uni-dortmund.de Fri Sep 12 11:39:05 2008 From: Claudia.Juergen at ub.uni-dortmund.de (=?ISO-8859-15?Q?Claudia_J=FCrgen?=) Date: Fri, 12 Sep 2008 17:39:05 +0200 Subject: [Dspace-general] Call for Translations Message-ID: <48CA8D19.1020207@ub.uni-dortmund.de> Hi all, first of all thanx to all who took the time and effort and provided translations of DSpace. Now with 1.5.1 released it is a good time to call for updates on existing translations. To ease this process I've started creating lists of tags to be translated from the current version of the translations to 1.5.1 in the lists of available translations, see http://wiki.dspace.org/index.php/I18nSupport#Available_translations_of_Messages.properties_for_JSP-UI or http://tinyurl.com/5yfrb6 For the existing 1.5 translations (Czech, Portugues, Welsh) there is not much to do, just 3 new tags to be translated. Furthermore if you start working on a complex update or a new translation please spread news through the lists and add your work in progress to the wiki. Thus other can join the effort. There are still some translations lingering in the Patch Queue. Italian http://sourceforge.net/tracker/index.php?func=detail&aid=1984513&group_id=19984&atid=319984 Spanish http://sourceforge.net/tracker/index.php?func=detail&aid=1839429&group_id=19984&atid=319984 Arabic http://sourceforge.net/tracker/index.php?func=detail&aid=1776843&group_id=19984&atid=319984 We can and did check the translations formally, but native speakers are needed here for content checks. Have a nice Weekend Claudia J?rgen From dsalo at library.wisc.edu Fri Sep 12 11:48:12 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Fri, 12 Sep 2008 10:48:12 -0500 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> Message-ID: <356cf3980809120848m7d58524dn64279f936c4877cd@mail.gmail.com> Apologies for the lateness. We're finally getting 1.5 in shape to roll out, and I'm just a little stressed about that. REPOSITORY MIGRATION Work is underway to enable wholesale repository migration between platforms via OAI-ORE. The winning entry in the hackfest at Open Repositories 2008 nearly managed an entire migration between DSpace and Fedora. ONE CHANGE Asked what the one change would be that would advance DSpace furthest toward the ideal repository system, these possibilities came up (in rough rank by interest): * file versioning * embargoes * eliminating the need for server restarts * authority control * API to the repository layer * multiple instances of DSpace run from a single codebase * componentization of DSpace EMBARGOES Bram Luyten shared this video of their DSpace embargo function: Elliot Metsger shared , and its FAQ at A more nuanced implementation of OAI-PMH would be helpful to several chatters. There was general agreement that withdrawn and embargoed items should not export metadata via OAI-PMH. The ability to have OAI-PMH only disseminate items designated as "full-text" (or otherwise complete) was also desired. Embargoed items should not come up in browses or searches, of course, nor should they be crawlable by search engines. However, some items can be halfway-private: metadata can be available (including via OAI-PMH), but the files should not be downloadable. Access Control Lists were raised as one potential solution. Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From mdiggory at MIT.EDU Fri Sep 12 15:24:35 2008 From: mdiggory at MIT.EDU (Mark Diggory) Date: Fri, 12 Sep 2008 12:24:35 -0700 Subject: [Dspace-general] Week 3: Good Repository Software In-Reply-To: <356cf3980809120848m7d58524dn64279f936c4877cd@mail.gmail.com> References: <356cf3980809011504xc5f7531s5fe8c318e0e44cca@mail.gmail.com> <356cf3980809120848m7d58524dn64279f936c4877cd@mail.gmail.com> Message-ID: <2DCC4445-F556-4B9F-BDE0-2DF3DF2D2450@mit.edu> Dorothea, I'll take this as an opportunity to summarize what I know about various projects that are already happening in the community to address these topics. On Sep 12, 2008, at 8:48 AM, Dorothea Salo wrote: > Apologies for the lateness. We're finally getting 1.5 in shape to roll > out, and I'm just a little stressed about that. You should certainly be voicing any issues/concerns you may have with the community. We are glad to advise on best approaches for rolling out a 1.5 release (As you know, at MIT we just finished this rollout). > > REPOSITORY MIGRATION > > Work is underway to enable wholesale repository migration between > platforms via OAI-ORE. The winning entry in the hackfest at Open > Repositories 2008 nearly managed an entire migration between DSpace > and Fedora. I think the Fedora and DSpace communities are actually looking for something even more synergistic than "Migration" out of the ORE and other Projects. We did just finish a project in the GSoC to address the subject of using a Fedora repository as the storage layer for the DSpace Assetstore. http://wiki.dspace.org/index.php/ Google_Summer_of_Code_2008_Fedora_Integration There is certainly a strong push between both DSpace and Fedora communities to become more involved and collaborative with each-other. With the 2.0 work there is an opportunity to see even more reuse of storage between DSpace and Fedora. Allowing all DSpaceObject data (including Policies and permissions to be mapped to Fedora under the hood. Likewise, the 2.0 model rework is seeking to allow metadata to be attached to any DSpaceObject, this opens the door for a richer expression of DSpace Objects that fits better with both the ORE and Fedora storage models. While hackfests are interesting opportunities to explore ideas, without the resulting code being publicized and brought into the community, I'm wary of the outcome being anything more than just an example of the the point we all know: Given that we are storing similar content, we also ultimately have similar use-cases and underlying implementation strategies. I see this as not much different than Scott Yeadons work to present Content Interchange at OR2007. The only (albeit big) benefit being a third party expression/mapping of both tools to ORE rather than METS. > # Content Interchange and the Invisible Repository > Scott Yeadon > > The Australian National University (ANU) will be undertaking > development work for the Australian Partnership for Sustainable > Repositories (APSR) in 2007. Much of this work will be focused > around repository interoperability and the integration of a > repository service within the university?s application > infrastructure. This presentation will discuss and demonstrate some > of the prototype DSpace-related development work undertaken so far > and planned for further development in 2007. Specifically: a METS > SIP/DIP profile intended to be used as a national standard for the > meaningful exchange of digital objects between repositories; > separation of concerns at a functional level so an institution can > select best-of-breed software, with an example using Open Journal > Systems (OJS) to manage publication workflow, DSpace to manage > preservation and Manakin as an access/publication point; and a > Manakin theme incorporating Google Earth and Google Maps > functionality. > ... > ONE CHANGE > > Asked what the one change would be that would advance DSpace furthest > toward the ideal repository system, these possibilities came up (in > rough rank by interest): Thank you for instigating these responses Dorothea, I would like to Make some comments. Firstly, I would add that aligning DSpace in terms of Model and capability with lower level storage solutions (Like Fedora) is one of the important requirements in the 2.0 development roadmap and that this level of integration is of a very high priority to the Foundation and the Core 2.0 development team. Anyone who has questions about how/what is being planned for 2.0 should voice them to the team and the community at large. We are working to solidify the architectural prototype and bring together these designs. Once we have a tangible body of work, we will be opening the effort to review by the community at large. That said, I know we also have the following projects already in the works in the community: > * file versioning I mentored a GSoC project done in 2007 that address this, our intention is to merge it into the trunk at some point inthe near future http://wiki.dspace.org/index.php/Google_Summer_of_Code_2007_Versioning Likewise we have a project within the MIT Libraries initially prototyped by Larry Stone to implement the new History system for DSpace http://wiki.dspace.org/index.php/HistorySystemPrototype > * embargoes Elliot Metsinger has been hard at work on a prototype for handling embargoes that is a fork of the 1.5.x codebase, he is also working on porting this to the trunk. > * eliminating the need for server restarts Not sure about this topic? ITs not necessarily a "feature" of DSpace as much as how one deploys it in a production environment. > * authority control Authority control is an important topic and one that I've had some ideas about, but I haven't seen come to fruition yet. I'll say that theses project however relate to it. Bitstream Format Renovation (initially prototyped by Larry Stone): http://wiki.dspace.org/index.php/BitstreamFormat_Renovation This is a critical project that MIT Libraries has bee working on over the last year. It basically provides an Authority Control over the Bitstream Formats that will enable DSpace to use services like Pronom and GDFR to supply more uniform and consistent Format detection and control. By using a Global Format Registry, DSpace isntance can all share a common set of known Formats that will be updated on a regular basis to reflect the changes in digital media that occur over time. In the DSpace DAO refactoring work that James Rutherford, Richard Jones, Graham Triggs and myself participated in (which now resides in the DSpace trunk). There was a critical effort to refactor out the ability to assign and manage External Identifiers such as Handles, DOIs, PURLs, Arks, etc I'm of the opinion that what we are seeking is ultimately a more universal solution here. ExternalIdentifiers, BitstreamFormats, are really a cases of controlled Metadata fields. An that these fields are backed by services with the following levels of capability Level 1 Read - The ability to list, search or validate a specific metadata value (Literal string or Identifier) within an external service. Level 2 Write - The ability to mint new metadata value (Literal string or Identifier) within such a service We already see such "endpoints" evolving at the LoC and other leaders in the field of metadata standardization and classification. > * API to the repository layer We have an API to the repository layer. Its called "DSpace API". I'm not sure what is meant otherwise? If you are referring to a pluggable layer that will allow one to implement ones own Bitstream Assetstore solution, this is currently a project that Richard Rodgers has been spearheading at MIT Libraries and there are prototype API available, this is the intention of seeing it become part of DSpace shortly, the only question seems to be which version. If my understanding is correct, this api was also used as a critical enhancement to DSpace to support integration work with Fedora in the DSPace/Fedora GSoC project. > * multiple instances of DSpace run from a single codebase The Maven build system allows one to setup numerous separate configurations that reuse the same DSpace codebase across them all. Again, this is insufficiently vague. Are you referring to sharing jars in a tomcat server instance or JEE container? This is something that Graham Triggs has been working on cleaning up the codebase improve that capability of. > * componentization of DSpace DSpace 1.5.x was our first major reorganization to support componentization of DSpace, MAven allows you to write separate module projects for DSpace and include them into your build process. This allows not only the separation of your customizations from the original core codebase, but also the previous statement concerning multiple instances. > > EMBARGOES > > Bram Luyten shared this video of their DSpace embargo function: > Elliot Metsger shared > , and its FAQ > at > > A more nuanced implementation of OAI-PMH would be helpful to several > chatters. There was general agreement that withdrawn and embargoed > items should not export metadata via OAI-PMH. The ability to have > OAI-PMH only disseminate items designated as "full-text" (or otherwise > complete) was also desired. > > Embargoed items should not come up in browses or searches, of course, > nor should they be crawlable by search engines. However, some items > can be halfway-private: metadata can be available (including via > OAI-PMH), but the files should not be downloadable. Access Control > Lists were raised as one potential solution. Those are certainly requirements of the Embargo project the Elliot Metsger has been working very hard at. I think the Core developers embrace that unanimously as an important feature and the exposure as serious issue that needs fixing. I hope this summary of known projects assists the community in understanding where work is currently going on and what the overall "tack" is our communities informal development roadmap. I do think this discussion has been very fruitful and allows a platform for the developers within the community to clarify the work that they are doing. Sincerely, Mark Diggory ~~~~~~~~~~~~~ Mark R. Diggory - DSpace Developer and Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology Home Page: http://purl.org/net/mdiggory/homepage From mallikarjun at bmaindia.com Sat Sep 13 01:08:26 2008 From: mallikarjun at bmaindia.com (Mallikarjun) Date: Sat, 13 Sep 2008 10:38:26 +0530 Subject: [Dspace-general] Authorization Required Message-ID: <001401c9155e$c1a07f80$44e17e80$@com> Dear Dspace Team, We have installed the Dspace software and its working fine also, but we are facing the problem when the user end nobody can not access the uploaded files only the user can see the meta data of the particular item and once the user clicked the "view/open" it is asking Authorization Required. for your reference below is the screen shot for the same. We are planning to upload the faculty resources for restricted user, is it possible to give the permission to open that particular community to particular users. Please kindly needful the same. Regards, Mallikarjun M K Asst. Librarian Bangalore Management Academy # 17, Ashirwad Towers, Doddanekkundi Cross, Mahadevapura Ring Road, Marathahalli Post, Bangalore - 560 037. Phone : 080-28533006 Ext.: 127. Disclaimer Statement : This electronic message transmission contains information from Bangalore Management Academy & is confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, beware that any disclosure, copy distribution or use of the contents of this information is prohibited. If you have received the electronic transmission in error please notify us immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080913/62c24640/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 45824 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080913/62c24640/attachment.jpg From dsalo at library.wisc.edu Mon Sep 15 09:19:20 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Mon, 15 Sep 2008 08:19:20 -0500 Subject: [Dspace-general] Week 5: Submission process Message-ID: <356cf3980809150619q1c7043b6ya5fc32f844b597e3@mail.gmail.com> This week's question is about the DSpace submission and workflow process. What works? What doesn't? What do you do at your institution that the DSpace workflow doesn't account for? What would an ideal set of processes (because there's rarely just one) look like? Because the submission process changed considerably in 1.5 owing to the Configurable Submission patch, please mention which version of DSpace you are running on. I apologize for not running a chat last week -- I'm under the gun as regards our 1.5 rollout. I will run a chat on this week's question, Wednesday 17 September at 10 am CT, 11 am ET, 4 pm GMT. I will not be able to run a chat on the 24th owing to a must-attend meeting; if anyone's willing to facilitate in my place, please let me know -- feel free to suggest a question as well! Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From dsalo at library.wisc.edu Mon Sep 15 10:03:26 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Mon, 15 Sep 2008 09:03:26 -0500 Subject: [Dspace-general] Week 5: Submission process In-Reply-To: <356cf3980809150619q1c7043b6ya5fc32f844b597e3@mail.gmail.com> References: <356cf3980809150619q1c7043b6ya5fc32f844b597e3@mail.gmail.com> Message-ID: <356cf3980809150703y13ec6a1fo6c26a4c7a400c7ad@mail.gmail.com> Running on 1.4.1, with an upgrade to 1.5.1 in our too-near future... > This week's question is about the DSpace submission and workflow > process. What works? I was able to set up a new community and collection and deposit a video on the spot with the content-owner watching. There is just no way this is not cool. Curiously, I have found that would-be depositors expect the process to be much more involuted than it actually is. I'm not sure why this is or what to do about it, but it's so. (One contributor may be the sheer number of screens indicated across the top, perhaps? A percentage indicator may be friendlier.) > What doesn't? The first screen with ticky-boxes on it. Please can we slay it? With extreme prejudice? The two-titles question applies in a vanishingly small (as in, approaching zero) number of cases, the published-before question creates really nasty externalities, and the multiple-files question is simply unnecessary. The cognitive load for reading and then answering these questions is substantial, for a minuscule benefit. I am *more than pleased* to add title.alternative, date.issued, and citation fields into input-forms.xml for those collections that need them, if it gets rid of this infernal screen! I think Manakin may have fixed this, but the metadata-input screens in 1.4.x JSPUI do not indicate which fields are required. Should be an easy fix, no? Without this, the depositor leaves something out, gets slapped for it, and then justifiably feels annoyed that DSpace didn't tell him he had to put it in in the first place! In the workflow process, the "Take Task" and then "Accept Task" interaction is unnecessarily redundant. Epersons who "take task" should be taken directly to the "perform task" page; if they decide they don't want to do it, they can "return task to pool." This refinement would save me personally hundreds of clicks and page-refreshes a year (and a lot of grumbly annoyance). Suggestion: The "verify your work" page layout is confusing and (in my experience with depositors) easy to overlook. I suggest instead that the depositor be presented with the page as it will appear in DSpace after deposit, because that they *care about* and will examine carefully. If development corners need to be cut, just present the page as a logged-in user would see it, with the "Edit" button and a... hm, having label aphasia here... let's say a "Continue" button beside it. It'd be really slick to do corrections with AJAX, but I realize that presents browser-sniffing and fallback difficulties. > What do you do at your institution > that the DSpace workflow doesn't account for? Third-party deposit is a huge issue here. The big problem is licensing; DSpace assumes that because I'm pushing the buttons, I own the content, which I often don't. I'd like to be able to send "please license this deposit" email to another eperson. Other eperson clicks link in email, sees license, accepts/rejects license, done. (It's arguable whether there needs to be an authentication step here. I incline toward no -- if the eperson clicks on a link-with-unique-token, that's enough authentication for my purposes. Others may disagree. Comments?) Bonus points if the eperson can license multiple deposits at once; the use-case here is me going through their CV for deposit-able materials which are then batch-loaded. Another licensing matter is materials that don't necessarily need licenses; I've put stuff in that's public-domain, and what about materials under a blanket SHERPA/RoMEO permission? I'm not sure what the proper answer is here, honestly; I bring it up for discussion. There's more, but I have stuff to be getting on with, I'm afraid. Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From graham at biomedcentral.com Mon Sep 15 10:39:12 2008 From: graham at biomedcentral.com (Graham Triggs) Date: Mon, 15 Sep 2008 15:39:12 +0100 Subject: [Dspace-general] Week 5: Submission process In-Reply-To: <356cf3980809150703y13ec6a1fo6c26a4c7a400c7ad@mail.gmail.com> References: <356cf3980809150619q1c7043b6ya5fc32f844b597e3@mail.gmail.com> <356cf3980809150703y13ec6a1fo6c26a4c7a400c7ad@mail.gmail.com> Message-ID: <48CE7390.4090307@biomedcentral.com> Dorothea Salo wrote: > I think Manakin may have fixed this, but the metadata-input screens in > 1.4.x JSPUI do not indicate which fields are required. Should be an > easy fix, no? Without this, the depositor leaves something out, gets > slapped for it, and then justifiably feels annoyed that DSpace didn't > tell him he had to put it in in the first place! You are right, it is an easy fix - it took me minutes alter the metadata entry JSP to add little red stars next to any field marked as in input-forms.xml. I'll quite happily put it into the main codebase, but obviously it's missed 1.5.1, so it may be some time ;) > In the workflow process, the "Take Task" and then "Accept Task" > interaction is unnecessarily redundant. Epersons who "take task" > should be taken directly to the "perform task" page; if they decide > they don't want to do it, they can "return task to pool." This > refinement would save me personally hundreds of clicks and > page-refreshes a year (and a lot of grumbly annoyance). This is a tricky one - the information in the pool listing isn't necessarily enough for someone to decide if they are going to do the task. So if they take it, they have to return it to the pool or nobody else can work on it. I really wouldn't be surprised if this was a 'damned if you do, damned if you don't' scenario, and either way will cause irritation / problems for an equal number of deployments. G This e-mail is confidential and should not be used by anyone who is not the original intended recipient. BioMed Central Limited does not accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of BioMed Central Limited. No contracts may be concluded on behalf of BioMed Central Limited by means of e-mail communication. BioMed Central Limited Registered in England and Wales with registered number 3680030 Registered Office Middlesex House, 34-42 Cleveland Street, London W1T 4LB This email has been scanned by Postini. For more information please visit http://www.postini.com From dsalo at library.wisc.edu Mon Sep 15 11:09:55 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Mon, 15 Sep 2008 10:09:55 -0500 Subject: [Dspace-general] Week 5: Submission process In-Reply-To: <48CE7390.4090307@biomedcentral.com> References: <356cf3980809150619q1c7043b6ya5fc32f844b597e3@mail.gmail.com> <356cf3980809150703y13ec6a1fo6c26a4c7a400c7ad@mail.gmail.com> <48CE7390.4090307@biomedcentral.com> Message-ID: <356cf3980809150809q435b0462k4513bcf574c64602@mail.gmail.com> On Mon, Sep 15, 2008 at 9:39 AM, Graham Triggs wrote: > You are right, it is an easy fix - it took me minutes alter the metadata > entry JSP to add little red stars next to any field marked as > in input-forms.xml. Just for clarification: if input-forms.xml changes to make different fields required or not, your JSP fixes the input screens automagically? That's obviously the ideal. :) Manakin folks: how much does DRI know about what's in input-forms.xml? Is it possible for a theme to do this work, or does an Aspect have to be rewritten? > This is a tricky one - the information in the pool listing isn't > necessarily enough for someone to decide if they are going to do the > task. So if they take it, they have to return it to the pool or nobody > else can work on it. Well, yes, but look at the clickstream here. We have four cases: eperson does or doesn't want a task, crossed with "accept task" screen existing or not. If eperson DOES want task, and "accept task" screen DOES exist: Eperson takes task, eperson accepts task. Two clicks. If eperson DOES want task, and "accept task" screen DOES NOT exist: Eperson takes task. One click. If eperson DOES NOT want task, and "accept task" screen DOES exist: Eperson takes task. Eperson rejects task. Two clicks. If eperson DOES NOT want task, and "accept task" screen DOES NOT exist: Eperson takes task. Eperson clicks "return task to pool." Two clicks. In other words, keeping the "accept task" screen doesn't actually save any work for the eperson who doesn't want a given task! It also creates a whole JSP/XMLUI section to maintain for developers (and, if I understand correctly, a whole state for a task to be in: "taken but not done yet"). I'm sensitive to the scenario in which an eperson who doesn't want a task forgets to return it to the pool, but my fix for it (if possible) would be to return the task to the pool automatically once the eperson's session ends. If they want the task later, they can pick it up again from their My DSpace page... and I note that this solution would help deal with the "marooned task" problem as well. Ideally, the "return task to pool" button would be relabelled or eliminated, because the state of a task is really DSpace-internal housekeeping, not something that's important to the performer of the task. In this scenario, failure to perform the task, or navigation away from the task toward something else, would signify "return task to pool" to DSpace. I don't know how much programming hassle that would create, I'm afraid; the workflow code has made my head hurt whenever I've looked at it. Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From graham at biomedcentral.com Mon Sep 15 11:40:23 2008 From: graham at biomedcentral.com (Graham Triggs) Date: Mon, 15 Sep 2008 16:40:23 +0100 Subject: [Dspace-general] Week 5: Submission process In-Reply-To: <356cf3980809150809q435b0462k4513bcf574c64602@mail.gmail.com> References: <356cf3980809150619q1c7043b6ya5fc32f844b597e3@mail.gmail.com> <356cf3980809150703y13ec6a1fo6c26a4c7a400c7ad@mail.gmail.com> <48CE7390.4090307@biomedcentral.com> <356cf3980809150809q435b0462k4513bcf574c64602@mail.gmail.com> Message-ID: <48CE81E7.2030500@biomedcentral.com> Dorothea Salo wrote: > Just for clarification: if input-forms.xml changes to make different > fields required or not, your JSP fixes the input screens > automagically? That's obviously the ideal. :) Yes, that's exactly how it works. > Well, yes, but look at the clickstream here. We have four cases: > eperson does or doesn't want a task, crossed with "accept task" screen > existing or not. But there are other scenarios: Eperson DOES NOT want task, hits their browser's back button Eperson DOES NOT want task, and clicks on any other link in the navigation Eperson DOES NOT WANT task, closes browser and walks away etc. What happens in those cases if the 'accept task' screen doesn't exist? The task is no longer in the pool, so nobody else can choose to take the task. > In other words, keeping the "accept task" screen doesn't actually save > any work for the eperson who doesn't want a given task! Quite, but that's not what it's there for! > It also > creates a whole JSP/XMLUI section to maintain for developers (and, if > I understand correctly, a whole state for a task to be in: "taken but > not done yet"). No, until you 'perform the task', the task is still in the state that it was in before you clicked 'take task' - ie. it is still in the pool. It would be more accurate if the button said 'view task', and then the next page have 'take task'. > I'm sensitive to the scenario in which an eperson who > doesn't want a task forgets to return it to the pool, but my fix for > it (if possible) would be to return the task to the pool automatically > once the eperson's session ends. If they want the task later, they can > pick it up again from their My DSpace page... and I note that this > solution would help deal with the "marooned task" problem as well. Well, you could hook into the SessionListener, and wait for the sessionDestroyed(), but an expiring session can't really be taken to mean that an eperson does not want a task and/or that it can be returned to the pool. (There may be a very good reason why they've taken it, to prevent others from working on it). And you have all sorts of potential issues if the web server crashes, etc. > Ideally, the "return task to pool" button would be relabelled or > eliminated, because the state of a task is really DSpace-internal > housekeeping, not something that's important to the performer of the > task. In this scenario, failure to perform the task, or navigation > away from the task toward something else, would signify "return task > to pool" to DSpace. I don't know how much programming hassle that > would create, I'm afraid; the workflow code has made my head hurt > whenever I've looked at it. The state of the task isn't important to the performer, but it is important to the 5 other people that you've set up to be able to review content in that collection. They don't want to be reviewing an item that someone else is already working on. It may be important to you, if you've noticed a submission that you don't want any of them working on (but which you don't simply want to reject). The biggest headache is dealing with things that you can't possibly know - for example, how do you trap the case where a user has gone off to a different page? OK, you may be able to detect that they are looking at another page, but what's to say they aren't doing that in a different tab, and are still keeping the review task open? G This e-mail is confidential and should not be used by anyone who is not the original intended recipient. BioMed Central Limited does not accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of BioMed Central Limited. No contracts may be concluded on behalf of BioMed Central Limited by means of e-mail communication. BioMed Central Limited Registered in England and Wales with registered number 3680030 Registered Office Middlesex House, 34-42 Cleveland Street, London W1T 4LB This email has been scanned by Postini. For more information please visit http://www.postini.com From gsk5 at cornell.edu Mon Sep 15 11:50:59 2008 From: gsk5 at cornell.edu (George Kozak) Date: Mon, 15 Sep 2008 11:50:59 -0400 Subject: [Dspace-general] Week 5: Submission process In-Reply-To: <356cf3980809150703y13ec6a1fo6c26a4c7a400c7ad@mail.gmail.co m> References: <356cf3980809150619q1c7043b6ya5fc32f844b597e3@mail.gmail.com> <356cf3980809150703y13ec6a1fo6c26a4c7a400c7ad@mail.gmail.com> Message-ID: <6.2.5.6.2.20080915112429.01ec64a8@cornell.edu> Dorothea et al. Concerning this topic of submission, at Cornell University, we are running DSpace 1.4.2... What works? In general the submission process works fine, but we have had to make some local changes. The first local change was a new function called "Quick Submit". We have a "Quick Submit" button along side the regular submit. The Quick Submit is a rewrite of the original Submit. It starts with "Choose a Collection", then jumps to the License Agreement and then jumps to a one page Description Page which has a button to allow to add more files if needed. The idea was to make things easier for people to add records and if more metadata was needed, it could be added later. This was originally created for DSpace 1.2 by a Java Programmer (not me), but I have had to migrate it with each upgrade and make changes to it so that it would work. I am assuming this process will die with DSpace 1.5.1. The other change we made wasn't in DSpace, but more of a process. We have people wanting to add videos to the Physics arXiv [which my Department manages] (but the arXiv doesn't allow videos). So I set up a generic account in DSpace and then a HTML page that logs a person into DSpace (under that generic account) so they can submit their videos. Once they have a handle, they can submit a paper to the arXiv with the link to their video. The idea was to allow people to submit without having each user get a DSpace account. What doesn't work? Well, we really need a more flexible submit process per collection. I don't know how that could be programmed, but our users definitely want their own "personalized" submission process. Maybe, 1.5.1 will help here. We handle a lot of questions about what things mean on the submit pages. A lot of times, I tell people if they don't know what I field means, ignore it. All we want is Author, Title, Abstract, Keyword(s) and the item, itself. Another problem is videos. We had a user who wanted to submit flash videos. We came up a process for them which was bit complicated (and involved with us creating the auxiliary files and a viewer). In the end, the user decided not to use our process or repository. We, also, looked at providing a template for users and then using the batch process as a background job for uploading files. This really didn't go anywhere, but we have had people who would like to batch load stuff. Right now, I do most of the batch loads. At 10:03 AM 9/15/2008, Dorothea Salo wrote: >Running on 1.4.1, with an upgrade to 1.5.1 in our too-near future... > > > This week's question is about the DSpace submission and workflow > > process. What works? > >I was able to set up a new community and collection and deposit a >video on the spot with the content-owner watching. There is just no >way this is not cool. > >Curiously, I have found that would-be depositors expect the process to >be much more involuted than it actually is. I'm not sure why this is >or what to do about it, but it's so. (One contributor may be the sheer >number of screens indicated across the top, perhaps? A percentage >indicator may be friendlier.) > > > What doesn't? > >The first screen with ticky-boxes on it. Please can we slay it? With >extreme prejudice? The two-titles question applies in a vanishingly >small (as in, approaching zero) number of cases, the published-before >question creates really nasty externalities, and the multiple-files >question is simply unnecessary. The cognitive load for reading and >then answering these questions is substantial, for a minuscule >benefit. I am *more than pleased* to add title.alternative, >date.issued, and citation fields into input-forms.xml for those >collections that need them, if it gets rid of this infernal screen! > >I think Manakin may have fixed this, but the metadata-input screens in >1.4.x JSPUI do not indicate which fields are required. Should be an >easy fix, no? Without this, the depositor leaves something out, gets >slapped for it, and then justifiably feels annoyed that DSpace didn't >tell him he had to put it in in the first place! > >In the workflow process, the "Take Task" and then "Accept Task" >interaction is unnecessarily redundant. Epersons who "take task" >should be taken directly to the "perform task" page; if they decide >they don't want to do it, they can "return task to pool." This >refinement would save me personally hundreds of clicks and >page-refreshes a year (and a lot of grumbly annoyance). > >Suggestion: The "verify your work" page layout is confusing and (in my >experience with depositors) easy to overlook. I suggest instead that >the depositor be presented with the page as it will appear in DSpace >after deposit, because that they *care about* and will examine >carefully. If development corners need to be cut, just present the >page as a logged-in user would see it, with the "Edit" button and a... >hm, having label aphasia here... let's say a "Continue" button beside >it. It'd be really slick to do corrections with AJAX, but I realize >that presents browser-sniffing and fallback difficulties. > > > What do you do at your institution > > that the DSpace workflow doesn't account for? > >Third-party deposit is a huge issue here. The big problem is >licensing; DSpace assumes that because I'm pushing the buttons, I own >the content, which I often don't. I'd like to be able to send "please >license this deposit" email to another eperson. Other eperson clicks >link in email, sees license, accepts/rejects license, done. (It's >arguable whether there needs to be an authentication step here. I >incline toward no -- if the eperson clicks on a >link-with-unique-token, that's enough authentication for my purposes. >Others may disagree. Comments?) Bonus points if the eperson can >license multiple deposits at once; the use-case here is me going >through their CV for deposit-able materials which are then >batch-loaded. > >Another licensing matter is materials that don't necessarily need >licenses; I've put stuff in that's public-domain, and what about >materials under a blanket SHERPA/RoMEO permission? I'm not sure what >the proper answer is here, honestly; I bring it up for discussion. > >There's more, but I have stuff to be getting on with, I'm afraid. > >Dorothea > >-- >Dorothea Salo dsalo at library.wisc.edu >Digital Repository Librarian AIM: mindsatuw >University of Wisconsin >Rm 218, Memorial Library >(608) 262-5493 >_______________________________________________ >Dspace-general mailing list >Dspace-general at mit.edu >http://mailman.mit.edu/mailman/listinfo/dspace-general *************************** George Kozak Coordinator Web Development and Management Digital Media Group 501 Olin Library Cornell University 607-255-8924 *************************** gsk5 at cornell.edu From dsalo at library.wisc.edu Mon Sep 15 11:57:12 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Mon, 15 Sep 2008 10:57:12 -0500 Subject: [Dspace-general] Week 5: Submission process In-Reply-To: <48CE81E7.2030500@biomedcentral.com> References: <356cf3980809150619q1c7043b6ya5fc32f844b597e3@mail.gmail.com> <356cf3980809150703y13ec6a1fo6c26a4c7a400c7ad@mail.gmail.com> <48CE7390.4090307@biomedcentral.com> <356cf3980809150809q435b0462k4513bcf574c64602@mail.gmail.com> <48CE81E7.2030500@biomedcentral.com> Message-ID: <356cf3980809150857r4d2e0139i916b04068a46aeeb@mail.gmail.com> > Yes, that's exactly how it works. Beautiful! > But there are other scenarios: > > Eperson DOES NOT want task, hits their browser's back button Task returns to pool on session end. > Eperson DOES NOT want task, and clicks on any other link in the navigation Task returns to pool. > Eperson DOES NOT WANT task, closes browser and walks away Task returns to pool on session expire. > It would be more accurate if the button said 'view task', and then the > next page have 'take task'. I could go for this, as long as there's a button next to "view task" that says "do task." That still lets me skip the argh-making "accept task" screen. > Well, you could hook into the SessionListener, and wait for the > sessionDestroyed(), but an expiring session can't really be taken to > mean that an eperson does not want a task and/or that it can be returned > to the pool. (There may be a very good reason why they've taken it, to > prevent others from working on it). Open call: How often does this happen? To me, it just doesn't -- I'm usually the only reviewer on a collection. However, if this must happen, I'd prefer a "reserve task" button to there *always* being an extra click when I just want to do the gosh-darn task! > And you have all sorts of potential issues if the web server crashes, etc. Always the case. > The state of the task isn't important to the performer, but it is > important to the 5 other people that you've set up to be able to review > content in that collection. They don't want to be reviewing an item that > someone else is already working on. It may be important to you, if > you've noticed a submission that you don't want any of them working on > (but which you don't simply want to reject). Again, I'm fairly convinced these are edge cases at best, nonexistent cases at worst; I have *never* taken a task just to keep it away from somebody else. Commentary from others? > The biggest headache is dealing with things that you can't possibly know > - for example, how do you trap the case where a user has gone off to a > different page? OK, you may be able to detect that they are looking at > another page, but what's to say they aren't doing that in a different > tab, and are still keeping the review task open? Hm, yes, I see the difficulty there; I've had more than one DSpace tab open, er, more than once. I guess waiting for session end (and having some kind of cleanup mechanism in case of webserver crashes) is the only thing that will work consistently. Writing that jogged loose something else: the collection-creation tool should have an easy hook into eperson creation. I make a *lot* of collections where I have to stop in the middle because the epeople related to the collection are brand-new and I have to hit the admin interface to create them. Ideally (there's that word again), this would happen automagically -- that is, I pop in an email address, DSpace checks to see if it is a recognized eperson, and if it isn't, I am taken to the edit-eperson screen (with an added "oops, typo, I meant somebody else!" option). Added wrinkle: ideally, community admins should be able to create collections; ought they be able to add epeople as well? Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From sbeers at gmu.edu Mon Sep 15 11:55:52 2008 From: sbeers at gmu.edu (Shane Beers) Date: Mon, 15 Sep 2008 11:55:52 -0400 Subject: [Dspace-general] [Dspace-tech] Week 5: Submission process In-Reply-To: <356cf3980809150619q1c7043b6ya5fc32f844b597e3@mail.gmail.com> References: <356cf3980809150619q1c7043b6ya5fc32f844b597e3@mail.gmail.com> Message-ID: We are running on 1.4.2. Starting with pros: - It works! - It's configurable on a collection by collection basis, although the way different input forms get assigned to collections is abominable. Cons: - When one begins a submission from "My DSpace" instead of the collections page, the list of collections is completely flat and in alphabetical order. This does not reflect the organization of the collections and makes it difficult to locate the collection you wish to deposit into. - The first page with the checkboxes is essentially useless. The number of items that have translated titles or more than one file are so few that it's just another step to avoid. - I don't really understand why the metadata entry needs to be split into two screens. It should be organized into REQUIRED and OPTIONAL areas and allow users to easily see what they have to do. Perhaps I am able to do this and simply haven't dug in that deeply? - The file uploaded successfully screen, while informative to IR managers, is just another step no one else really cares about and just has to hit another "Next >" button. - Additionally, the Verify Submission page is something even I never check, as I assume I deposited it just fine. Just another step for people to click through and not actually read. - We continue to have issues with the creative commons function for some users. It works perfectly fine for me on my mac and other PCs I've used, but one user on a perfectly normal PC has issues. I have not been able to diagnose this. - Upon completion of submission, the left navigation bar disappears and could confuse users. ---- I feel that the submission process in 1.4.2 is far too clumsy for anyone who isn't truly interested in the IR, and would turn off most casual users. I'm trying to move us to a 1-page submission form that will allow faculty here to quickly enter in what I consider the essential metadata elements and upload their document. Additionally, a selection pull-down allows the user to say what part of the University they are a part of, which corresponds to a directory on the server. Their document, dublin_core.xml (which gets generated by the form through some php - thanks goes out to our web guru), contents file, and license all get filed into a new subdirectory within the correct root directory. This will allow me to more easily run the batch importer, since you can only run it for items going into a single collection. This process will also not require users to actually sign up for access to the IR, which is an obstacle as well. I'll be testing this this week and will share it as soon as I know it's working. Shane Beers Digital Repository Services Librarian George Mason University sbeers at gmu.edu http://mars.gmu.edu 703-993-3742 On Sep 15, 2008, at 9:19 AM, Dorothea Salo wrote: > This week's question is about the DSpace submission and workflow > process. What works? What doesn't? What do you do at your institution > that the DSpace workflow doesn't account for? What would an ideal set > of processes (because there's rarely just one) look like? > > Because the submission process changed considerably in 1.5 owing to > the Configurable Submission patch, please mention which version of > DSpace you are running on. > > I apologize for not running a chat last week -- I'm under the gun as > regards our 1.5 rollout. I will run a chat on this week's question, > Wednesday 17 September at 10 am CT, 11 am ET, 4 pm GMT. I will not be > able to run a chat on the 24th owing to a must-attend meeting; if > anyone's willing to facilitate in my place, please let me know -- feel > free to suggest a question as well! > > Dorothea > > -- > Dorothea Salo dsalo at library.wisc.edu > Digital Repository Librarian AIM: mindsatuw > University of Wisconsin > Rm 218, Memorial Library > (608) 262-5493 > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > DSpace-tech mailing list > DSpace-tech at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech From dsalo at library.wisc.edu Mon Sep 15 12:14:40 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Mon, 15 Sep 2008 11:14:40 -0500 Subject: [Dspace-general] [Dspace-tech] Week 5: Submission process In-Reply-To: References: <356cf3980809150619q1c7043b6ya5fc32f844b597e3@mail.gmail.com> Message-ID: <356cf3980809150914h7cdeb345w773547dca2e2956c@mail.gmail.com> > - It's configurable on a collection by collection basis, although the > way different input forms get assigned to collections is abominable. Expanding on this: When I create a collection, I usually forget to go over to input-forms.xml and put the right form on it. I have (to my shame be it spoken) confused users with thesis collections by demoing them the form customized for theses... and then they don't see it when they first try to deposit! It'd be nice if the collection-creation UI read input-forms.xml and let me assign an existing form to the collection (a single radio-button control would seem to do the trick, yes?). No, that doesn't solve the whole issue (still can't design a new form via UI, which doesn't bother me much because creating UI for that is an *evil* problem), but it's a nice 80/20 point. > - I don't really understand why the metadata entry needs to be split > into two screens. It should be organized into REQUIRED and OPTIONAL > areas and allow users to easily see what they have to do. Perhaps I am > able to do this and simply haven't dug in that deeply? This could be done with input-forms.xml -- or it could if it weren't for the published-before checkbox externalities, at least. To the best of my knowledge, nobody's done the user testing to figure out what's the most intuitive metadata-entering paradigm, though Marty and Twidale's ASIST demo last year showed pretty conclusively that the out-of-the-box DSpace one is substantially broken. I do know of several efforts to strip down deposit to the absolute bare minimum for later correction (usually by a third party): upload plus citation plus license, end of story. This strikes me as a common enough workflow to be worth baking in to DSpace proper. > - The file uploaded successfully screen, while informative to IR > managers, is just another step no one else really cares about and just > has to hit another "Next >" button. Oof. Agreed. Sorry I forgot to mention this! Okay, closing out GMail now to reboot the test 1.5 instance with a new dspace.cfg and xmlui.xconf. I expect much breakage to ensue, with associated wailing and gnashing of teeth... Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From res20 at duke.edu Mon Sep 15 14:11:41 2008 From: res20 at duke.edu (Ryan Scherle) Date: Mon, 15 Sep 2008 14:11:41 -0400 Subject: [Dspace-general] Week 5: Submission process In-Reply-To: <356cf3980809150619q1c7043b6ya5fc32f844b597e3@mail.gmail.com> References: <356cf3980809150619q1c7043b6ya5fc32f844b597e3@mail.gmail.com> Message-ID: <48481091-A46A-46AD-8FEF-D85799E7604D@duke.edu> We're currently running on 1.4.2, but we're busy building our own custom submission system for 1.5.x. What works: * Account creation. * Basic management of the workflow for "standard" items. What doesn't work: * Creating relationships between submitted items. * Allowing users to submit multiple items with similar metadata. * Marking items for embargo or restricted access. * Submitting items without associated bitstreams. * Authority control (or "my usual list of coauthors") * Applying terms from controlled vocabularies. * Too many pages are displayed and too many button clicks are required. What do we do that DSpace doesn't handle? We're collecting data files associated with articles. This means we need to establish a relationship between the article and each data file. No, it doesn't work to simply add the data files as bitstreams on the article record; the data files need their own metadata. But the metadata can be repetitive, which provides a burden to the depositor if there is not an easy way to say "create a new record based on this one". What would an ideal set of processes look like? Check back with me in a few months. We're in various stages of fixing everything I listed under "what doesn't work". When we're done, the code will be available, although it is unclear how many people will be interested in the type of workflow we're building... --- Ryan Scherle --- Data Repository Architect --- National Evolutionary Synthesis Center From FCampbell at groupwise.swin.edu.au Tue Sep 16 01:33:21 2008 From: FCampbell at groupwise.swin.edu.au (Fiona Campbell) Date: Tue, 16 Sep 2008 15:33:21 +1000 Subject: [Dspace-general] Subscription email used default handle URL instead of our local URL Message-ID: <48CFD1C1.57CB.00AE.0@groupwise.swin.edu.au> Swinburne does not use CNRI handles. Instead, we use our local URL eg http://images.swinburne.edu.au/handle/1111.1/590. The handles we use are referenced in the dspace.cfg & by the HandleManager.java variable getCanonicalForm. This generally works. It works in the web interface and in our submission emails. The one place it does not work is in the subscription emails sent out to users who have subscribed to get email updates for new entries. Instead of having http://images.swinburne.edu.au it has http://hdl.handle.net Subscription emails (WRONG!) Title: Test for Fiona and Susan ID: http://hdl.handle.net/1111.1/3732 INVESTIGATION AND POSSIBLE SOLUTION The simple wording of emails is changed by adjusting the email templates in [dspace-source]/config/emails. We've done that - that is not the problem. To change the argument passed to the template you must change [dspace-source]/org/dspace/eperson/Subscribe.java in sendEmail change This appears correct as it uses our getCanonicalForm that is used elsewhere quite successfully. emailText.append("\n ID: ").append( HandleManager.getCanonicalForm(hii.handle)).append( "\n\n"); However, one recommendation I have found was to use this form instead: emailText.append("\n ID: ").append( ConfigurationManager.getProperty("dspace.url")).append( "/handle/").append( hii.handle).append( "\n\n"); This will use the property dspace.url as defined in [dspace-source]/config/dspace.cfg to build the ID which is used in the subscription email. QUESTION Does anyone else recommend changing the [dspace-source]/org/dspace/eperson/Subscribe.java? What solutions have other people come up with? Regards, Fiona -- Fiona Campbell Systems Librarian ITS Information Systems Swinburne University of Technology Melbourne, Victoria, Australia Email: fcampbell at swin.edu.au Phone:+ 61 03 9214 8279 ----- Swinburne University of Technology CRICOS Provider Code: 00111D NOTICE This e-mail and any attachments are confidential and intended only for the use of the addressee. They may contain information that is privileged or protected by copyright. If you are not the intended recipient, any dissemination, distribution, printing, copying or use is strictly prohibited. The University does not warrant that this e-mail and any attachments are secure and there is also a risk that it may be corrupted in transmission. It is your responsibility to check any attachments for viruses or defects before opening them. If you have received this transmission in error, please contact us on +61 3 9214 8000 and delete it immediately from your system. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. Please consider the environment before printing this email. From rcastro at alerta.cl Tue Sep 16 10:03:31 2008 From: rcastro at alerta.cl (Rodrigo Castro Artigas) Date: Tue, 16 Sep 2008 10:03:31 -0400 Subject: [Dspace-general] Dspace Item description (default) In-Reply-To: References: Message-ID: <004301c91805$001be120$0053a360$@cl> Hi. I need help for set ?tem description default. For example add cita -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080916/5b3108b6/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 30850 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080916/5b3108b6/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 268 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080916/5b3108b6/attachment-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 13057 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080916/5b3108b6/attachment-0002.png From dsalo at library.wisc.edu Wed Sep 17 10:08:01 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Wed, 17 Sep 2008 09:08:01 -0500 Subject: [Dspace-general] Chat in an hour Message-ID: <356cf3980809170708p62ead15co51852654026a2b6a@mail.gmail.com> Greetings, DSpace community, I'll be firing up a chat in the #dspace IRC chatroom in a little less than an hour. This week's topic is the DSpace submission process. I hope to see many of you there! Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From christophe.dupriez at destin.be Thu Sep 18 04:38:00 2008 From: christophe.dupriez at destin.be (Christophe Dupriez) Date: Thu, 18 Sep 2008 10:38:00 +0200 Subject: [Dspace-general] Week 5: Submission process In-Reply-To: <356cf3980809150619q1c7043b6ya5fc32f844b597e3@mail.gmail.com> References: <356cf3980809150619q1c7043b6ya5fc32f844b597e3@mail.gmail.com> Message-ID: <48D21368.6080608@destin.be> Hi Dorothea! (copy to the General list) My 2 cents on submission: 1) Submission should be named Contribution (more positive, more Web 2 minded!) 2) Librarians do not understand why record update should be different from submission! They would appreciate to be "helped" (menus, validations) when updating the same way contributors are helped during submission. (Current update form can be retained for more extraordinary updates) 3) Submission is not multilingual now (I had to modify it locally in depth for this): some fields (like title) must be entered in multiple languages in Quebec, Belgium, etc. 4) Dynamic Authority lists are essentials (collections, subjects, authors, etc.): this mean some way to manage authority lists is needed. I am working on this by using dedicated collections for each Authority list we have to manage. The trick is to store only the handle of the linked item (entry in the authority list) but to index and display the dc.titles of the linked item (the name of the subject, authors, etc. and its synonyms: dc.title.alternative) Have a nice day! Christophe Dorothea Salo a ?crit : > This week's question is about the DSpace submission and workflow > process. What works? What doesn't? What do you do at your institution > that the DSpace workflow doesn't account for? What would an ideal set > of processes (because there's rarely just one) look like? > > Because the submission process changed considerably in 1.5 owing to > the Configurable Submission patch, please mention which version of > DSpace you are running on. > > I apologize for not running a chat last week -- I'm under the gun as > regards our 1.5 rollout. I will run a chat on this week's question, > Wednesday 17 September at 10 am CT, 11 am ET, 4 pm GMT. I will not be > able to run a chat on the 24th owing to a must-attend meeting; if > anyone's willing to facilitate in my place, please let me know -- feel > free to suggest a question as well! > > Dorothea > > -------------- next part -------------- A non-text attachment was scrubbed... Name: christophe_dupriez.vcf Type: text/x-vcard Size: 454 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080918/d2c54330/attachment.vcf From dsalo at library.wisc.edu Fri Sep 19 12:23:28 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Fri, 19 Sep 2008 11:23:28 -0500 Subject: [Dspace-general] Chat summary: 17 September 2008 Message-ID: <356cf3980809190923w3a63fa99yd9ef0c2b86bcffe6@mail.gmail.com> We held a requirements chat on the topic of the DSpace deposit process on 17 September in the DSpace IRC channel. BATCH IMPORT The commonest use-case for the batch import mechanism is receipt of a great many items at once. HTML items are another use-case. Most chatters had written custom code (outside DSpace altogether) to make batch-importing easier. It was suggested that a DSpace-blessed way to share, discover, and reuse some of this code would be helpful, as would translators from common metadata formats such as MARC and MODS to a format compatible with SWORD-based deposit. It might be possible to distribute third-party code in /contrib, which by convention does not warrant any particular code quality. Other suggestions: * a validator (or better error-handling) for batch imports; the -t flag does not catch many metadata errors, which can cause a batch import to die in the middle. * a web interface to handle batch imports DEPOSIT INTERFACE Suggestions included: * a web interface for altering input-forms.xml * being able to select an input form "on the fly" based on the type of item being deposited * a web interface to the Configurable Submission System * eliminating the need to restart the server after changes to input-forms.xml and the Configurable Submission System * allowing more configuration (e.g. input-forms.xml, Configurable Submission) and command-line actions (e.g. batch imports) to be pushed down to community and collection administrators * allowing metadata specific to an eperson (e.g. name, metadata fields to exclude) to be stored in that eperson's profile It was noted that the lack of a web interface to many DSpace configuration files means that repository managers who are not also systems administrators may not be able to configure their installations fully. Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From mwood at IUPUI.Edu Fri Sep 19 13:28:32 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Fri, 19 Sep 2008 13:28:32 -0400 Subject: [Dspace-general] Chat summary: 17 September 2008 In-Reply-To: <356cf3980809190923w3a63fa99yd9ef0c2b86bcffe6@mail.gmail.com> References: <356cf3980809190923w3a63fa99yd9ef0c2b86bcffe6@mail.gmail.com> Message-ID: <20080919172832.GA29151@IUPUI.Edu> On Fri, Sep 19, 2008 at 11:23:28AM -0500, Dorothea Salo wrote: > Other suggestions: > > * a validator (or better error-handling) for batch imports; the -t > flag does not catch many metadata errors, which can cause a batch > import to die in the middle. I must have been unclear. -t *does* catch errors; the problem is that the first error still kills the run even in test mode. Making most errors nonfatal when -t is true might be helpful. Right now what I do is to throw a batch at the loader in -t mode, fix the error reported at the end of the output, throw the batch again, fix the next error (which was uncovered by fixing the previous error), perhaps many times until a run completes cleanly. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080919/000ce58c/attachment.bin From dsalo at library.wisc.edu Fri Sep 19 13:40:53 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Fri, 19 Sep 2008 12:40:53 -0500 Subject: [Dspace-general] Chat summary: 17 September 2008 In-Reply-To: <20080919172832.GA29151@IUPUI.Edu> References: <356cf3980809190923w3a63fa99yd9ef0c2b86bcffe6@mail.gmail.com> <20080919172832.GA29151@IUPUI.Edu> Message-ID: <356cf3980809191040j1afc7696ld9e1f7ce1cab1b98@mail.gmail.com> 2008/9/19 Mark H. Wood : > I must have been unclear. -t *does* catch errors; the problem is that > the first error still kills the run even in test mode. I think we're both right. I've run into errors that didn't stop the program in -t mode, but killed the actual import. Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From lcs at MIT.EDU Fri Sep 19 18:27:40 2008 From: lcs at MIT.EDU (Larry Stone) Date: Fri, 19 Sep 2008 18:27:40 EDT Subject: [Dspace-general] Chat summary: 17 September 2008 In-Reply-To: Your message of Fri, 19 Sep 2008 11:23:28 -0500 Message-ID: > Other suggestions: > > * a web interface to handle batch imports After acknowledging the irony of a request for an interactive interface to a batch procedure, I'd like to respond that this sounds like they want a way to run the batch importer on a separate machine. This is already available in the form of the LNI (Lightweight Network Interface) with the simple LNI client -- see the wiki page http://wiki.dspace.org/index.php/Simple_LNI_Client It needs a "DSpace SIP" package, which you can create with a utility like the SIP toolkit, see: http://wiki.dspace.org/index.php/DSpace_SIP_Toolkit Combining those tools effectively gives you a remote batch ingester. It's also worth looking at SWORD as a solution, too. -- Larry From mdiggory at MIT.EDU Fri Sep 19 19:20:49 2008 From: mdiggory at MIT.EDU (Mark Diggory) Date: Fri, 19 Sep 2008 16:20:49 -0700 Subject: [Dspace-general] Chat summary: 17 September 2008 In-Reply-To: References: Message-ID: <14EF25B4-6655-42A0-BBEC-6335C2AB22DB@mit.edu> On Sep 19, 2008, at 3:27 PM, Larry Stone wrote: >> Other suggestions: >> >> * a web interface to handle batch imports > > After acknowledging the irony of a request for an interactive > interface to a batch procedure, I'd like to respond that this > sounds like they want a way to run the batch importer on a separate > machine. > > This is already available in the form of the LNI (Lightweight Network > Interface) with the simple LNI client -- see the wiki page > http://wiki.dspace.org/index.php/Simple_LNI_Client > > It needs a "DSpace SIP" package, which you can create with a utility > like the SIP toolkit, see: > http://wiki.dspace.org/index.php/DSpace_SIP_Toolkit > > Combining those tools effectively gives you a remote batch ingester. > > It's also worth looking at SWORD as a solution, too. > > -- Larry I'll toss in the GSoC project as well, but my understanding is that actually produces Item-Importer directories? http://wiki.dspace.org/index.php/Google_Summer_of_Code_2008_Batch_Import -Mark From nsarr at library.rochester.edu Sat Sep 20 07:09:14 2008 From: nsarr at library.rochester.edu (Sarr, Nathan) Date: Sat, 20 Sep 2008 07:09:14 -0400 Subject: [Dspace-general] Enhancing Repositories for the Next Generation of Academics Message-ID: Hello DSpace Community, The University of Rochester just completed a public report on the user research portion of "Enhancing Repositories for the Next Generation of Academics". I thought this may be interesting to many of you on the list. You can download a copy of the report from here: http://hdl.handle.net/1802/6053 Best, -Nate Nathan Sarr Senior Software Engineer River Campus Libraries University of Rochester Rochester, NY 14627 (585) 275-0692 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080920/e703a4ee/attachment.htm From dsalo at library.wisc.edu Wed Sep 24 08:40:03 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Wed, 24 Sep 2008 07:40:03 -0500 Subject: [Dspace-general] Educational materials list on the Open Access Directory Message-ID: <356cf3980809240540te9320b1ka5def5058dec184@mail.gmail.com> Greetings, DSpace community, I know I'm MIA this week, and I apologize for that, but I broke Manakin badly yesterday and I have to get it back together... and so it goes. I do want to emerge from self-imposed exile to ask those of you who are also active in the open access movement to consider adding to the page I just seeded on the Open Access Directory. The page lists educational materials about open access, paying special attention to those that are legally and practically editable and mashuppable. If you have developed such materials, please add them to the page! My very sincere thanks. Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From michele at dspace.org Wed Sep 24 09:45:28 2008 From: michele at dspace.org (Michele Kimpton) Date: Wed, 24 Sep 2008 09:45:28 -0400 Subject: [Dspace-general] DSpace Repository Mgr mtg post SPARC Message-ID: <79EA28E2-81C3-4A6F-8F64-8FC0CEC04A66@dspace.org> To Repository Managers and Administrators of DSpace, The DSpace Foundation, with the help and support of the DSpace global outreach committee are looking into organizing a 1/2 day DSpace Repository Mgr. meeting Wed Nov 19th following the SPARC repository meeting in Baltimore. The global outreach committee has come up with a list of interesting topics for the 1/2 day session. Valorie, our community outreach manager will be sending out a short 4 question survey next week to see if there is enough interest in the community to put together this 1/2 day session and get your input on what topics would be of most interest. If this sounds at all appealing please block space in your calendar. If we have a minimum of 25 people interested we will definitely run the session. If you have questions please do not hesitate to contact myself or Val in the meantime. best, Michele and Val Michele at dspace.org, Val at dspace.org From mitcheet at wfu.edu Wed Sep 24 17:17:38 2008 From: mitcheet at wfu.edu (Mitchell, Erik T.) Date: Wed, 24 Sep 2008 17:17:38 -0400 Subject: [Dspace-general] Position Announcement - Systems Librarian Wake Forest University In-Reply-To: <5f4ba2340710220517h776020e3g40d959de81fe0db7@mail.gmail.com> References: <5f4ba2340710220517h776020e3g40d959de81fe0db7@mail.gmail.com> Message-ID: Apologies for Cross posting. . . SYSTEMS LIBRARIAN zsr.wfu.edu Wake Forest University seeks a collaborative, innovative and service-oriented Librarian with strong programming skills to serve as the Systems Librarian for the Z. Smith Reynolds Library. This position will be central in the development and implementation of next generation information systems to accomplish the library's goal of migrating to open source environments. The Systems Librarian will design, implement, and manage software to extend and integrate commercial, open source, and locally developed software; perform system analysis and application development to facilitate the use of technology in the library; manage the Integrated Library System and consult and collaborate with faculty and staff on library information technology initiatives. This Librarian will also provide support to faculty, staff and students on library-related systems, software, and hardware; provide user instruction for the students, faculty, and University community and serve as the library liaison and subject specialist for departments as needed. The Z. Smith Reynolds Library, with a collection of over 1.9 million volumes, materials expenditures of $3.5 million, and operating budget over $7 million, serves over 4,000 students in the undergraduate College, the Calloway School of Business and Accountancy, the Graduate School of Arts and Sciences, and the Divinity School of Wake Forest University. Wake Forest University is a private, coeducational institution dedicated to academic excellence in the liberal arts, graduate and professional education. Founded in 1834, the University is ranked among the top thirty national universities. Wake Forest is a collegiate university offering a vibrant intellectual community with a rich cultural life, an impressive array of facilities and an active athletics community. From its founding, the university adopted the motto "pro humanitate" which is exemplified by a deep institutional commitment to public service and engagement with the world. For quick facts about the University, go to www.wfu.edu/visitors/quickfacts.html Qualifications: Master's degree in Library Science from an ALA accredited program plus, two years of progressively responsible experience in an academic library, managing and providing library services. Significant software development experience using advanced techniques. Experience with database design, reporting, and management including SQL, Oracle, & client reporting applications required. An equivalent combination of education and experience may be accepted. Salary: Commensurate with qualifications and experience. Review of applicants will begin September 29th and continue until filled. For full position description and application instructions, visit www.wfu.edu/hr/careers Wake Forest University does not discriminate on the basis of race, color, religion, sex, age, national origin, disability, sexual orientation, marital or veteran status. Wake Forest University is an Affirmative Action/Equal Opportunity Employer. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080924/65231dd1/attachment.htm From dsalo at library.wisc.edu Mon Sep 29 09:28:35 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Mon, 29 Sep 2008 08:28:35 -0500 Subject: [Dspace-general] Week 6: Documentation Message-ID: <356cf3980809290628i292d2701l14f725a97c6e80fd@mail.gmail.com> Greetings, DSpace community, My apologies for last week's discussion hiatus; I still had several showstopper bugs in Manakin themes and an uncomfortably close go-live date. The showstoppers are fixed (with many thanks to the community), and my headspace is just that much clearer. This week's topic is documentation, something the survey asked about previously. When you face a DSpace difficulty, where is the first place you turn? The second? Third? When all else fails, where do you go? On a scale of 1 to 5, where 1 is "never find anything useful" and 5 is "always solves my problem," how would you rate the resources you just listed? What would a 5 resource look like and contain? Finally, what would you be willing and able to contribute to DSpace documentation? I will facilitate a chat discussion of these questions this Wednesday 1 October at 11 am ET (10 am CT, 4 pm GMT) in the #dspace IRC channel on irc.freenode.net. Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From dsalo at library.wisc.edu Mon Sep 29 10:08:31 2008 From: dsalo at library.wisc.edu (Dorothea Salo) Date: Mon, 29 Sep 2008 09:08:31 -0500 Subject: [Dspace-general] Week 6: Documentation In-Reply-To: <356cf3980809290628i292d2701l14f725a97c6e80fd@mail.gmail.com> References: <356cf3980809290628i292d2701l14f725a97c6e80fd@mail.gmail.com> Message-ID: <356cf3980809290708x4cc23cft746b34f62d034d07@mail.gmail.com> On Mon, Sep 29, 2008 at 8:28 AM, Dorothea Salo wrote: > When you face a DSpace difficulty, where is the first place you turn? > The second? Third? When all else fails, where do you go? It depends on the problem, honestly. Often, the problem is "I can't remember the syntax of a command-line operation." In that case, I usually know whether it's something I've documented on my blog, and if I have, that's where I go. If not, I hit up the DSpace docs, which are a 4 for this purpose -- not a 5 because they're a pain to scan and search. Sometimes the problem has to do with the incomprehensible DSpace authorization and permissions system. I don't even BOTHER with the DSpace documentation for this; it is a solid 1. I resolve these by trial and error. For design problems involving JSP and Manakin, I check the HOWTOs on the wiki. For JSP, these are somewhere around a high 3 or low 4; for Manakin, they're about a 2. The Manakin documentation, unfortunately, is also a 2 for design problems. It's aimed more at people who want to understand the underpinnings of the system than at the hapless souls who want to do something with it. Comments in the Manakin stylesheets are a 3; they often contain vital clues to resolving design problems. Let me say this again, louder: doing a Manakin design that's any more than a CSS refresh is a *hard development problem*, and there is practically *no* documentation aimed at those of us interested in it. I'm not quite ready to write the documentation I would want to see, because some aspects of Manakin (notably making DRI and METS play nicely together) still break my brain. (Though I think moving to a call-template design pattern with a lot of with-params instead of apply-templates might solve the specific problem I'm having. I need to force myself over the scared-to-try hump before I'll know.) Ask me again in six months. The wiki is not an ideal solution, honestly. I wikified the Donohue/Phillips/Salo customization guides a while ago; doing so was a fair bit of work, it didn't turn out perfectly, and I freely admit I haven't kept them up to date. I seriously doubt I'm the only person who's created local documentation, but it sure looks as though I'm nearly the only person putting it on the wiki. If we mean to continue crowdsourcing our documentation, we need to acknowledge and accept that people use the tools they use. I want to give a shout out to the community, because a year or so ago, asking the -tech or -devel mailing lists for help was somewhere around a 2, and now I think it's a 4. We are doing a *lot* better at resolving questions than we used to, and we should be proud of that. The number, type, and repetitiveness of questions we get, however, indicates pretty clearly that our documentation lacks a lot, particularly for new DSpace sysadmins. I also want to point out some documentation and training examples I think worth following. The Fedora Commons tutorials () are absolutely brilliant; I went through them last week, and while I'm still a little shaky on the content-model architecture, I'm happy with my understanding of the object model. We have nothing comparable in DSpace, although something like that would be a beautiful thing to have on the DSpace-on-a-CD distribution. As for EPrints, it is so far ahead of DSpace () that as someone who's done a little DSpace training, I'm *embarrassed*. I particularly like the breakdown of concerns on the EPrints page (enduser/config/customization). Dorothea -- Dorothea Salo dsalo at library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 From mwood at IUPUI.Edu Tue Sep 30 12:41:32 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Tue, 30 Sep 2008 12:41:32 -0400 Subject: [Dspace-general] Authoring tools and repositories -- anybody looked at PKP? Message-ID: <20080930164132.GB14891@IUPUI.Edu> There's been discussion here of improving the interface between authoring and publication. There's a new development under way at the Public Knowledge Project: Open Monograph Press, which may be of interest, especially since they are explicitly aiming to link it to repository software. http://pkp.sfu.ca/omp We're reasonably well pleased with PKP's Open Journal Systems product. http://journals.iupui.edu/ -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080930/bd41f8ff/attachment.bin