From rrodgers at MIT.EDU Fri Sep 5 11:49:59 2003 From: rrodgers at MIT.EDU (Richard Rodgers) Date: 05 Sep 2003 11:49:59 -0400 Subject: [Dspace-general] Preview of next release of DSpace Message-ID: <1062776999.25377.91.camel@dspace-03.mit.edu> An Early Look at DSpace 1.2 We would like to share our plans for the next release of DSpace in order to open up the development process and let adopters and evaluators know where we are putting our efforts. Here is a 'short list' of major features we propose to include in this release, reflecting our assessment of the most desired and widely useful enhancements to the system. These have been gathered from the SourceForge request list, discussions on the 'dspace-tech' mailing list, and input from others using the DSpace system. Given thousands of downloads and over a hundred known deployments, it is difficult to come up with an optimal list of enhancements that is both small and gives maximum benefit to the DSpace community - if you feel strongly about a feature that is not on this list, please let us know. It is a 'short-list' in the sense that while we will concentrate our efforts on the list items for the next release, we may not be able to implement all of the items in the list. It is also our short list - DSpace 1.2 will also likely contain other contributed work from third parties, which will be announced separately. The item descriptions are rather brief, but we wanted to offer at least a general picture of the release as early as we could. We will be sending out calls for discussion on several of the features, and more detailed descriptions of the others, to insure that the community has good opportunity to offer input. DSpace 1.2 Enhancement Short List (1) Support for sub-communities. The current simple and flat implementation of communities is not powerful enough for users who would like to express more complex organizational structures. (2) Allow delegated administration of communities and collections. It is time to offload administration tasks to the users. A 'collection-editor' role will be able to edit item metadata within a collection after items have been submitted, and a'community-administrator' role will have the ability to manage a community. (3) Import/Export items with METS metadata. DSpace currently uses a custom XML schema to import and export item metadata and associated digital files (or 'bitstreams'). With the emergence of the METS standard for digital object encoding http://www.loc.gov/standards/mets/, and in particular its application as an Open Archival Information Systems Archival Information Package, we are in the process of defining a METS profile for DSpace items. Once that profile is complete, we will add support in the batch import and export routines for METS encoding of DSpace items, as well as storing METS packages internally as AIPs. When the METS profile is ready, we will distribute it (in advance of the release). (4) Tools for adding and managing items in multiple collections. (5) Analyze need for persistent identifiers (e.g. Handles) for bitstreams in addition to item metadata records. Implement if appropriate. (6) Support for thumbnails of bitstreams in the item display (for appropriate content). (7) Several enhancements to the administration UI centered around ease-of-use and robustness. (8) Support for indexing and search of the full-text of item documents. (9) Better support for web page (HTML document) item display. MIT and HP's role in future DSpace development The DSpace developers at MIT and HP would also like to take this opportunity to share with the community of DSpace adopters what we feel our role should be in the continuing development and support of the DSpace system. DSpace was released as open source system in the hope that our work at HP and MIT would benefit other institutions with similar problems. We are delighted by the interest in and adoption of the DSpace system so far, but we have very limited resources to enhance and maintain the system... Remember that as an open source system DSpace does not generate any revenue, and we are maintaining the system for non-MIT use gratis, because we need it too. Today we see the HP/MIT team as having two main roles, to: -- make changes that are needed by MIT to meet its service goals -- coordinate changes made by other institutions or individuals back into the main codebase We will focus our energy on changes required by MIT. We acknowledge that some changes (e.g. digital publishing tools, or support for non-Roman character sets), while not at the top of MIT's list, are priorities elsewhere. We welcome contributions to the system from those for whom these changes are a priority. We have posted guidelines for those who wish to contribute code at the new dspace.org website (Choose the 'DSpace Technology' link, and look for 'Development Guidelines'), and encourage participation in advancing the DSpace platform. From j.krizack at neu.edu Fri Sep 5 12:40:06 2003 From: j.krizack at neu.edu (j.krizack@neu.edu) Date: Fri, 5 Sep 2003 12:40:06 -0400 Subject: [Dspace-general] Re: Margaret Branschofsky's paper Message-ID: The text didn't come through on my email. Is there another way I can get a copy of the paper? Thanks. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Joan D. Krizack University Archivist and Head, Special Collections Department 92 Snell Library Northeastern University 360 Huntington Avenue Boston, MA 02115-5000 (v) 617.373.8318 (f) 617.373.8132 j.krizack at neu.edu http://www.lib.neu.edu/archives/ From chodge5 at utk.edu Fri Sep 5 13:39:44 2003 From: chodge5 at utk.edu (chodge5@utk.edu) Date: Fri, 5 Sep 2003 13:39:44 -0400 (EDT) Subject: [Dspace-general] Preview of next release of DSpace] Message-ID: This is great news! With regard to future development, I think the real challenge is going to be for the DSpace community to find some way to organize itself and facilitate the development of collaborative projects around specific issues. I think a number of people are willing to devote some resources in this area -- I know we are -- but there needs to be some structure and coordination to make sure the work gets channelled back into the community as a whole. Chris Hodge UNiversity of Tennessee -------- Original Message -------- Subject: [Dspace-general] Preview of next release of DSpace Date: Fri, 05 Sep 2003 11:49:59 -0400 From: Richard Rodgers To: dspace-general at mit.edu, dspace-tech at lists.sourceforge.net An Early Look at DSpace 1.2 We would like to share our plans for the next release of DSpace in order to open up the development process and let adopters and evaluators know where we are putting our efforts. Here is a 'short list' of major features we propose to include in this release, reflecting our assessment of the most desired and widely useful enhancements to the system. These have been gathered from the SourceForge request list, discussions on the 'dspace-tech' mailing list, and input from others using the DSpace system. Given thousands of downloads and over a hundred known deployments, it is difficult to come up with an optimal list of enhancements that is both small and gives maximum benefit to the DSpace community - if you feel strongly about a feature that is not on this list, please let us know. It is a 'short-list' in the sense that while we will concentrate our efforts on the list items for the next release, we may not be able to implement all of the items in the list. It is also our short list - DSpace 1.2 will also likely contain other contributed work from third parties, which will be announced separately. The item descriptions are rather brief, but we wanted to offer at least a general picture of the release as early as we could. We will be sending out calls for discussion on several of the features, and more detailed descriptions of the others, to insure that the community has good opportunity to offer input. DSpace 1.2 Enhancement Short List (1) Support for sub-communities. The current simple and flat implementation of communities is not powerful enough for users who would like to express more complex organizational structures. (2) Allow delegated administration of communities and collections. It is time to offload administration tasks to the users. A 'collection-editor' role will be able to edit item metadata within a collection after items have been submitted, and a'community-administrator' role will have the ability to manage a community. (3) Import/Export items with METS metadata. DSpace currently uses a custom XML schema to import and export item metadata and associated digital files (or 'bitstreams'). With the emergence of the METS standard for digital object encoding http://www.loc.gov/standards/mets/, and in particular its application as an Open Archival Information Systems Archival Information Package, we are in the process of defining a METS profile for DSpace items. Once that profile is complete, we will add support in the batch import and export routines for METS encoding of DSpace items, as well as storing METS packages internally as AIPs. When the METS profile is ready, we will distribute it (in advance of the release). (4) Tools for adding and managing items in multiple collections. (5) Analyze need for persistent identifiers (e.g. Handles) for bitstreams in addition to item metadata records. Implement if appropriate. (6) Support for thumbnails of bitstreams in the item display (for appropriate content). (7) Several enhancements to the administration UI centered around ease-of-use and robustness. (8) Support for indexing and search of the full-text of item documents. (9) Better support for web page (HTML document) item display. MIT and HP's role in future DSpace development The DSpace developers at MIT and HP would also like to take this opportunity to share with the community of DSpace adopters what we feel our role should be in the continuing development and support of the DSpace system. DSpace was released as open source system in the hope that our work at HP and MIT would benefit other institutions with similar problems. We are delighted by the interest in and adoption of the DSpace system so far, but we have very limited resources to enhance and maintain the system... Remember that as an open source system DSpace does not generate any revenue, and we are maintaining the system for non-MIT use gratis, because we need it too. Today we see the HP/MIT team as having two main roles, to: -- make changes that are needed by MIT to meet its service goals -- coordinate changes made by other institutions or individuals back into the main codebase We will focus our energy on changes required by MIT. We acknowledge that some changes (e.g. digital publishing tools, or support for non-Roman character sets), while not at the top of MIT's list, are priorities elsewhere. We welcome contributions to the system from those for whom these changes are a priority. We have posted guidelines for those who wish to contribute code at the new dspace.org website (Choose the 'DSpace Technology' link, and look for 'Development Guidelines'), and encourage participation in advancing the DSpace platform. _______________________________________________ Dspace-general mailing list Dspace-general at mit.edu http://mailman.mit.edu/mailman/listinfo/dspace-general From margretb at MIT.EDU Tue Sep 16 14:38:04 2003 From: margretb at MIT.EDU (Margret Branschofsky) Date: Tue, 16 Sep 2003 14:38:04 -0400 Subject: [Dspace-general] Theses in DSpace Message-ID: <5.2.1.1.2.20030916142738.01de45c0@po10.mit.edu> Hi all, I'm wondering if any other institutions are planning to use DSpace for theses. I know that the Theses Alive! project in the UK is doing this, and we at MIT are also planning an implementation. I'm thinking that it would be very useful if we could all agree to use the same metadata standard to accommodate theses in DSpace. Margret Margret Branschofsky DSpace User Support Manager Digital Library Research Group Bldg. 14S-M24 (617)253-1293 margretb at mit.edu http://dspace.mit.edu From ellermann at ubib.eur.nl Tue Sep 16 15:47:06 2003 From: ellermann at ubib.eur.nl (Henk Ellermann) Date: Tue, 16 Sep 2003 21:47:06 +0200 Subject: [Dspace-general] Theses in DSpace In-Reply-To: <5.2.1.1.2.20030916142738.01de45c0@po10.mit.edu> References: <5.2.1.1.2.20030916142738.01de45c0@po10.mit.edu> Message-ID: <3F6768BA.6070404@ubib.eur.nl> Hi Margret, > I'm wondering if any other institutions are planning to use DSpace for > theses. I know that the Theses Alive! project in the UK is doing this, > and we at MIT are also planning an implementation. I'm thinking that it > would be very useful if we could all agree to use the same metadata > standard to accommodate theses in DSpace. We use DSpace as an Institutional Repository and have included a number of dissertations. It will not be long before we will put all (well, except the obvious few) dissertations of the Erasmus University in DSpace. So far we have not given dissertations any special treatment in terms of metadata. We do use aQDC field description.sponsorship for the names of the promotores (is that an English word too?). We have adapted DSpace to expert qualified dublin core too, so we can use this field for localized services (web display) in the near future. However, we sure would like it if there were some kind of (exportable) metadataset, standardized across DSpace users, for dissertations. If you can initiate something, we are willing to co-operate and spend some quality time on it. Regards, Henk Ellermann -- -- ------------------------------------------------------------------------------- - Henk Ellermann - Erasmus Electronic Publishing Initiative - University Library, Erasmus University Rotterdam - P.O. Box 1738, 3000 DR, Rotterdam, The Netherlands - ellermann at ubib.eur.nl - weblog: http://eepi.ubib.eur.nl/iliit/index.html - tel: +31 (0) 10 4081284/81208 - cell: +31 (0) 6 41 50 2002 ------------------------------------------------------------------------------- -- From margretb at MIT.EDU Wed Sep 17 10:09:45 2003 From: margretb at MIT.EDU (Margret Branschofsky) Date: Wed, 17 Sep 2003 10:09:45 -0400 Subject: [Dspace-general] Theses in DSpace In-Reply-To: <3F6768BA.6070404@ubib.eur.nl> References: <5.2.1.1.2.20030916142738.01de45c0@po10.mit.edu> <5.2.1.1.2.20030916142738.01de45c0@po10.mit.edu> Message-ID: <5.2.1.1.2.20030917093545.01e8ba90@po10.mit.edu> Hello Henk and JQ, Thanks for responding to my question. We are planning to use the existing qualified DC in DSpace for our theses, but we would like to add a few fields for the thesis-specific information, such as thesis department and degree granted. We were originally planning to put the thesis advisor (or sponsor or supervisor) under Contributor.advisor and the department and degree under Description.department and Description.degree. But now we are exploring alternatives and seeing what others are using before making a decision. The NDLTD schema, for example, uses (simple) Dublin Core with the addition of a Degree element and 4: thesis.degree.name Name of degree (Masters in Operations Research) thesis.degree.level Level of education (masters, doctoral) thesis.degree.discipline Area of study (name of department or program) thesis.degree.grantor Institution granting the degree I believe that the Thesis Alive! project is seriously considering using this. I am also in communication with Ed Fox (NDLTD) and Thom Hickey(OCLC) to find out how likely it is that the NDLTD standard will be brought into the Dublin Core. And I'm also trying to find out if the electronic thesis/dissertation OAI Union Catalog will ever adopt those fields (So far it uses simple DC.) I have one question for Henk: >We have adapted DSpace to expert qualified dublin core too, so we can use >this field for localized services (web display) in the near future. I'm assuming you meant "export" in this sentence? Have you created an XML Schema of the DSpace metadata? Best regards, Margret Margret Branschofsky DSpace User Support Manager Digital Library Research Group Bldg. 14S-M24 (617)253-1293 margretb at mit.edu http://dspace.mit.edu From Theo.Andrew at ed.ac.uk Wed Sep 17 11:16:38 2003 From: Theo.Andrew at ed.ac.uk (Theo Andrew) Date: Wed, 17 Sep 2003 16:16:38 +0100 (BST) Subject: [Dspace-general] Theses in DSpace In-Reply-To: <5.2.1.1.2.20030917093545.01e8ba90@po10.mit.edu> References: <5.2.1.1.2.20030916142738.01de45c0@po10.mit.edu> <5.2.1.1.2.20030916142738.01de45c0@po10.mit.edu> <5.2.1.1.2.20030917093545.01e8ba90@po10.mit.edu> Message-ID: <1063811798.3f687ad675af3@staffmail.ed.ac.uk> Hello All, This discussion is extremely timely as we (the Theses Alive! team) are currently investigating metadata schemas for ETDs. It seems we are taking the same approach as Margret in that we are "exploring alternatives and seeing what others are using before making a decision". It would be extremely useful if we could all together reach a consensus on what to use. So far we have compared the DSPace default DC with the ETD-MS schema and the TDM DTD and come up with a proposed list that we are thinking of using. If you are interested you can visit our web site and see our Proposed Submission Fields and Related Metadata Elements: http://www.thesesalive.ac.uk/archive/SchemaComparison.html or have a look at a compiled list of the main DTDs for ETDs available; http://www.thesesalive.ac.uk/archive/MetadataSchemas.html We would welcome feedback on our proposed list! Kind regards Theo ****************************************************** Dr. Theo Andrew * Project Officer for * Tel: 0131 651 1612 Theses Alive! & SHERPA * Fax: 0131 650 3380 Edinburgh University * Main Library * http://www.thesesalive.ac.uk George Square * http://www.sherpa.ac.uk Edinburgh EH8 9LJ * ****************************************************** From ellermann at ubib.eur.nl Wed Sep 17 15:07:14 2003 From: ellermann at ubib.eur.nl (Henk Ellermann) Date: Wed, 17 Sep 2003 21:07:14 +0200 Subject: [Dspace-general] Theses in DSpace In-Reply-To: <5.2.1.1.2.20030917093545.01e8ba90@po10.mit.edu> References: <5.2.1.1.2.20030916142738.01de45c0@po10.mit.edu> <5.2.1.1.2.20030916142738.01de45c0@po10.mit.edu> <5.2.1.1.2.20030917093545.01e8ba90@po10.mit.edu> Message-ID: <3F68B0E2.9000101@ubib.eur.nl> Hi Margret, It's great that you are finding 'good practices' elsewhere when it comes to the dissertations metadata. It seems to me that > Thanks for responding to my question. We are planning to use the > existing qualified DC in DSpace for our theses, but we would like to add > a few fields for the thesis-specific information, such as thesis > department and degree granted. We were originally planning to put the Not sure what degree granted is about. are the possible Palues h D or dr? > > thesis.degree.name Name of degree (Masters in Operations > Research) > thesis.degree.level Level of education (masters, doctoral) > thesis.degree.discipline Area of study (name of department or > program) > thesis.degree.grantor Institution granting the degree There is no problem with these fields if the values are not restricted, except for the service providers of course :) Wouldn't it be an idea to constrain the values, or set a language? If I'm giving dutch strings and yours are in English we do have a slight problem. > > I believe that the Thesis Alive! project is seriously considering using > this. I am also in communication with Ed Fox (NDLTD) and Thom > Hickey(OCLC) to find out how likely it is that the NDLTD standard will > be brought into the Dublin Core. And I'm also trying to find out if the > electronic thesis/dissertation OAI Union Catalog will ever adopt those > fields (So far it uses simple DC.) Yes, good idea. Keep us posted. If there is anything I can do, if only to keep an eye on non-english users, let me know. >> We have adapted DSpace to expert qualified dublin core too, so we can >> use this field for localized services (web display) in the near future. > > > I'm assuming you meant "export" in this sentence? Have you created an > XML Schema of the DSpace metadata? Blush. Yes I meant export. No XML Schema as yet. We are using it for internal purposes only and have not yet 'fixed' the elements we want to use. We are experimenting a little. Of course, an xsd will be made in due time. Regards, Henk -- -- ------------------------------------------------------------------------------- - dr. Henk Ellermann - Erasmus Electronic Publishing Initiative - University Library, Erasmus University Rotterdam - P.O. Box 1738, 3000 DR, Rotterdam, The Netherlands - ellermann at ubib.eur.nl - http://eepi.ubib.eur.nl/iliit/index.html - tel: +31 (0) 10 4081284/81208 - cell: +31 (0) 6 41 50 2002 ------------------------------------------------------------------------------- -- From scott.yeadon at anu.edu.au Sun Sep 21 19:11:21 2003 From: scott.yeadon at anu.edu.au (Scott Yeadon) Date: Mon, 22 Sep 2003 09:11:21 +1000 Subject: [Dspace-general] DSpace customisation Message-ID: <200309220911.21312.scott.yeadon@anu.edu.au> Hi, We're looking at introducing DSpace to ANU (Australian National University), and I have just read a paper date Jan 2003 in D-Lib magazine entitled DSpace - An OpenSource Dynamic Digital Repository, located at http://www.dlib.org/dlib/january03/smith/01smith.html. The section entitled "The DSpace Federation" contains a paragraph as follows: "In 2002, MIT formed collaborative partnerships with a small number of other academic research institutions in the US, UK, and Canada, to address some specific questions such as: what will it take to successfully deploy the system at another institution? How much localization, how much customization, and how much time and effort are needed?" I was wondering what sort of feedback (if any) had been received on these topics, especially where non-trivial modifications werer required such as more complex authorisation and low-level code modifications were required, and how these we done to avoid issues when upgrading to future versions. Thanks. Scott. From rrodgers at MIT.EDU Mon Sep 22 15:18:08 2003 From: rrodgers at MIT.EDU (Richard Rodgers) Date: 22 Sep 2003 15:18:08 -0400 Subject: [Dspace-general] Persistent Bitstream IDs - Call For Discussion Message-ID: <1064258288.15587.3.camel@dspace-03.mit.edu> Bitstream Identifiers in DSpace - Call for Discussion Part of the planning process for enhancements to DSpace is requirements analysis - obtaining a more precise understanding of the needs of the adopter community. We have frequently heard articulated the need for bitstream-level - rather than item-level - handles or other persistent identifiers. Recall that in DSpace terminology, an 'item' is a logical construct consisting of a Dublin Core metadata record, and one or more digital objects (files), each of which is referred to as a 'bitstream'. In the current design, when a item has exited the workflow, it is assigned a handle, but the individual bitstreams are not. The rationale for this - without delving too deeply into digital preservation debates - is fairly simple: the item represents some sort of usable content, but its digital expression may vary over time. For instance, a bitstream may need to be migrated into a physically distinct bitstream of another format for preservation purposes (e.g. because the original format has become obsolete): the bitstream has changed, but the item 'content' has not. The thing that persists is what is given a persistent identifier. So why would one need a persistent identifier for an individual bitstream? This write-up is an attempt to solicit your feedback on the subject. Any response is welcome - but best of all would be a 'use-case' description: a concrete set of practices or problems for which a different bitstream identifier system would provide a solution. Disentangling the Issues There are actually a few distinct but related issues here, and it is useful to attempt to tease them apart. First, what counts as an identifier in this context? Bitstreams (files) in DSpace already possess an identifier of a sort, viz. the URL appearing on the item display page: https://hpds1.mit.edu/retrieve/1042/Porter_debate.pdf This identifier, composed of the server name, the primary key in the bitstream database table, and the filename assigned upon submission has several noteworthy characteristics: (1) it is fixed, in that it always refers to the same bitstream (2) like all URLs, the identifier is a location reference: you can use it to retrieve the bitstream (3) it has limited persistence, viz. as long as server name and database tables do not change (4) one cannot use it to locate or retrieve the 'parent' item (its metadata and related bitstreams) For many purposes this identifier may be adequate. For instance, if the need is to retrieve bitstreams for near-term reuse as learning objects, then the time-scale is likely to be such that the URL will remain valid. Even if the repository is re-hosted (the server name changes), standard redirection techniques would ensure that the URL will resolve to the desired bitstream. Still, the bitstream URL is *fragile* in ways a handle is not: if the database is exported and re-imported (as was done for the DSpace 1.1 upgrade), there is no guarantee that the bitstream key part of the URL (therefore its validity) will be preserved. This quick dissection suggests some of the issues in play: do you need a bitstream identifier to be persistent for a longer period, or simply more 'durable'? Does it have to be a handle? Should bitstream IDs also be required to get you to the item of which it is a part? Do they have to be a location identifier (like a URL)? Does the identifier system need to independently maintained (like the handle system), or not? What are other required/desirable characteristics of bitstream identifiers? Please share your insights on the dspace-general list; again, a concrete use-case is the most valuable driver of design: a specific set of circumstances and outcomes that any design must satisfy. From jqj at darkwing.uoregon.edu Mon Sep 22 19:52:35 2003 From: jqj at darkwing.uoregon.edu (JQ Johnson) Date: Mon, 22 Sep 2003 16:52:35 -0700 Subject: [Dspace-general] Persistent Bitstream IDs - Call For Discussion In-Reply-To: <1064258288.15587.3.camel@dspace-03.mit.edu> Message-ID: Overall, I do not believe that persistent bitstream IDs are a good idea. However, the question of persistent IDs reminds me of a closely related question, how to provide multiple revisions of an item in the DSpace context. Our faculty seem likely to use DSpace heavily as a repository for working papers. Such working papers have a short useful life, and are replaced by new versions fairly rapidly. How would one handle such versions in DSpace? The easiest option is separate items for each version, but then there's no automatic version control or tracking of the connections between versions (no "previous version" metadata, etc.). Another option would be to treat all versions as a single item, with different versions appearing as additional bitstreams. This has the advantage of preserving the connections between the versions, but would require implementation changes to allow bitstream additions by item owners and to provide a small amount of additional per-bitstream metadata (the version info; currently the only significant per-bitstream metadata is the filename). This issue is connected with the problem of persistent bitstream IDs. If we were to have multiple versions in the same item, then we'd certainly want persistent IDs at the bitstream level. Conversely, persistent bitstream IDs would encourage a future evolution of DSpace into making bitstreams first class citizens with more of their own metadata. However, I think that the key issue that should drive this discussion is "what do the faculty want?" I agree with Harnad that the major problem for institutional repositories is getting faculty to contribute. If real faculty care about PURLs and such (I don't think they do, by the way), then that should be the key desideratum. JQ Johnson Office: 115F Knight Library Academic Education Coordinator e-mail: jqj at darkwing.uoregon.edu 1299 University of Oregon 1-541-346-1746 (v); -3485 (fax) Eugene, OR 97403-1299 http://darkwing.uoregon.edu/~jqj From scott.yeadon at anu.edu.au Thu Sep 25 02:14:32 2003 From: scott.yeadon at anu.edu.au (Scott Yeadon) Date: Thu, 25 Sep 2003 16:14:32 +1000 Subject: [Dspace-general] Submitting documents as a non-administrator user Message-ID: <200309251614.32666.scott.yeadon@anu.edu.au> Hello, At the ANU we've been performing some informal testing of DSpace, and one major issue appears to be setting up a group of non-adminstrative users who can submit documents. The DSpace documentation states that if "a collection has no e-person groups associated with any [workflow] step, submissions to that collection are installed straight into the main archive". This does not appear to be the case - non-adminstrator users do not appear to be able to store documents, but they can approve/reject submissions. For example, I have set up Community A which has the default anonymous read authorisations. Within this community is a single Collection. This Collection, as well as the default anonymous authorisations, has a group called Submitters containing two members - one an administrator user and one a non-administrator. This group has been granted all possible permissions add, read, write, remove, etc. against the Collection. There are no workflow steps for the Collection. The issue is that when logging on as the Submitter group administrator user, I can submit documents to the collection without issue, however when logged on as the Submitter group's non-adminstrator user (a basic author-type user) I get an authorisation error whenever I attempt to submit a document to the collection. In addition a log file error is generated stating that the user does not have WRITE access for the ITEM being submitted. This does not appear to be a problem related to the collection authorisation, but something at the item metadata level. Given that the item does not exist at this point as a DSpace item that can be manipulated via the DSpace GUI, I have drawn a blank as far as being able to get any further information and what I can do about this. Is this a known problem or can anyone shed any light on this problem? Thanks. Scott. From david.stuve at hp.com Thu Sep 25 17:39:02 2003 From: david.stuve at hp.com (STUVE,DAVID (HP-Corvallis,ex1)) Date: Thu, 25 Sep 2003 14:39:02 -0700 Subject: [Dspace-general] Submitting documents as a non-administrator user Message-ID: <5755325D04C5834187459E1E17D81F6F0834F03D@xcor01.cv.hp.com> Hi Scott, This sounds like an issue we had with DSpace 1.1, and is fixed in the latest version (1.1.1). If you are running 1.1.1 and are still getting this error, can you reply with a copy of the logged error? Thanks, Dave David Stuve / HP Labs Corvallis / David.Stuve at hp.com / 541-715-4106 -----Original Message----- From: Scott Yeadon [mailto:scott.yeadon at anu.edu.au] Sent: Wednesday, September 24, 2003 11:15 PM To: dspace-general at mit.edu; dspace-tech-request at lists.sourceforge.net Subject: [Dspace-general] Submitting documents as a non-administrator user Hello, At the ANU we've been performing some informal testing of DSpace, and one major issue appears to be setting up a group of non-adminstrative users who can submit documents. The DSpace documentation states that if "a collection has no e-person groups associated with any [workflow] step, submissions to that collection are installed straight into the main archive". This does not appear to be the case - non-adminstrator users do not appear to be able to store documents, but they can approve/reject submissions. For example, I have set up Community A which has the default anonymous read authorisations. Within this community is a single Collection. This Collection, as well as the default anonymous authorisations, has a group called Submitters containing two members - one an administrator user and one a non-administrator. This group has been granted all possible permissions add, read, write, remove, etc. against the Collection. There are no workflow steps for the Collection. The issue is that when logging on as the Submitter group administrator user, I can submit documents to the collection without issue, however when logged on as the Submitter group's non-adminstrator user (a basic author-type user) I get an authorisation error whenever I attempt to submit a document to the collection. In addition a log file error is generated stating that the user does not have WRITE access for the ITEM being submitted. This does not appear to be a problem related to the collection authorisation, but something at the item metadata level. Given that the item does not exist at this point as a DSpace item that can be manipulated via the DSpace GUI, I have drawn a blank as far as being able to get any further information and what I can do about this. Is this a known problem or can anyone shed any light on this problem? Thanks. Scott. _______________________________________________ Dspace-general mailing list Dspace-general at mit.edu http://mailman.mit.edu/mailman/listinfo/dspace-general From dallan_quass at hotmail.com Fri Sep 26 13:26:37 2003 From: dallan_quass at hotmail.com (Dallan Quass) Date: Fri, 26 Sep 2003 11:26:37 -0600 Subject: [Dspace-general] Any archives using DSpace? Message-ID: Are any archives (in contrast to libraries) currently using or considering using DSpace? If so, can you tell me if you have needed to make any changes to the codebase? -Dallan From kenzie at MIT.EDU Sun Sep 28 22:23:16 2003 From: kenzie at MIT.EDU (MacKenzie Smith) Date: Sun, 28 Sep 2003 22:23:16 -0400 Subject: [Dspace-general] DSpace customisation In-Reply-To: <200309220911.21312.scott.yeadon@anu.edu.au> Message-ID: <5.0.2.1.2.20030928221008.035cfa60@hesiod> Hi Scott, The DSpace Federation project you asked about is still underway, but we've learned quite a bit on the subject since last fall. First of all, the DSpace software itself has not been extensively modified by other universities adopting it so far. Most of them have modified the UI to make it reflect their own institutional culture, and some have modified the submission process, added full-text indexing, etc. Three of the institutions we're working with are considering adding Shibboleth support over the default X.509 (certificates) or logon/password access control. The main area of technical development seems to be in modules that will be outside of DSpace itself, e.g. publishing tools or rendering applications for non-Web-native formats. The major effort at most institutions to implement DSpace as an institutional repository seems not to be in the technology at all, but rather in the definition of policies and business models that the library (or other part of the organization) needs to provide a production service to its researchers. As for avoiding upgrade problems if you make modifications, we try to keep the development process as open as possible (documenting future releases, as well as the code contribution process). The best way to ensure future compatibility is to communicate with us about the changes you're making, and offer them back to the main codebase when you're done! Hope this helps, MacKenzie/ At 09:11 AM 9/22/2003 +1000, Scott Yeadon wrote: >Hi, > >We're looking at introducing DSpace to ANU (Australian National University), >and I have just read a paper date Jan 2003 in D-Lib magazine entitled DSpace >- An OpenSource Dynamic Digital Repository, located at >http://www.dlib.org/dlib/january03/smith/01smith.html. The section entitled >"The DSpace Federation" contains a paragraph as follows: > >"In 2002, MIT formed collaborative partnerships with a small number of other >academic research institutions in the US, UK, and Canada, to address some >specific questions such as: what will it take to successfully deploy the >system at another institution? How much localization, how much customization, >and how much time and effort are needed?" > >I was wondering what sort of feedback (if any) had been received on these >topics, especially where non-trivial modifications werer required such as >more complex authorisation and low-level code modifications were required, >and how these we done to avoid issues when upgrading to future versions. > >Thanks. > >Scott. > >_______________________________________________ >Dspace-general mailing list >Dspace-general at mit.edu >http://mailman.mit.edu/mailman/listinfo/dspace-general MacKenzie Smith Associate Director for Technology MIT Libraries Building 14S-208 77 Massachusetts Avenue Cambridge, MA 02139 (617)253-8184 kenzie at mit.edu From Kalbs at post.queensu.ca Mon Sep 29 12:42:36 2003 From: Kalbs at post.queensu.ca (Sam Kalb) Date: Mon, 29 Sep 2003 12:42:36 -0400 Subject: [Dspace-general] Re: Dspace-general Digest, Vol 2, Issue 10 In-Reply-To: <200309291601.h8TG0fgK015283@pch.mit.edu> Message-ID: <5.2.1.1.0.20030929123946.03c8a710@post.queensu.ca> MacKenzie, Where can we get information about the institutions and the changes they have made - to assist some of us in setting up our DSpace projects? I am particularly interested in the addition of full-text indexing. Sam >Date: Sun, 28 Sep 2003 22:23:16 -0400 >From: MacKenzie Smith >To: dspace-general at MIT.EDU >Subject: Re: [Dspace-general] DSpace customisation >Message-ID: <5.0.2.1.2.20030928221008.035cfa60 at hesiod> >In-Reply-To: <200309220911.21312.scott.yeadon at anu.edu.au> >Content-Type: text/plain; charset="us-ascii"; format=flowed >MIME-Version: 1.0 >Precedence: list >Message: 1 > >Hi Scott, > >The DSpace Federation project you asked about is still underway, >but we've learned quite a bit on the subject since last fall. First of all, >the DSpace software itself has not been extensively modified by >other universities adopting it so far. Most of them have modified the >UI to make it reflect their own institutional culture, and some have >modified the submission process, added full-text indexing, etc. >Three of the institutions we're working with are considering adding >Shibboleth support over the default X.509 (certificates) or >logon/password access control. The main area of technical >development seems to be in modules that will be outside of DSpace >itself, e.g. publishing tools or rendering applications for >non-Web-native formats. > >The major effort at most institutions to implement DSpace as >an institutional repository seems not to be in the technology >at all, but rather in the definition of policies and business models >that the library (or other part of the organization) needs to provide >a production service to its researchers. > >As for avoiding upgrade problems if you make modifications, >we try to keep the development process as open as possible >(documenting future releases, as well as the code contribution >process). The best way to ensure future compatibility is to >communicate with us about the changes you're making, and >offer them back to the main codebase when you're done! > >Hope this helps, > >MacKenzie/ > >At 09:11 AM 9/22/2003 +1000, Scott Yeadon wrote: > >Hi, > > > >We're looking at introducing DSpace to ANU (Australian National University), > >and I have just read a paper date Jan 2003 in D-Lib magazine entitled DSpace > >- An OpenSource Dynamic Digital Repository, located at > >http://www.dlib.org/dlib/january03/smith/01smith.html. The section entitled > >"The DSpace Federation" contains a paragraph as follows: > > > >"In 2002, MIT formed collaborative partnerships with a small number of other > >academic research institutions in the US, UK, and Canada, to address some > >specific questions such as: what will it take to successfully deploy the > >system at another institution? How much localization, how much > customization, > >and how much time and effort are needed?" > > > >I was wondering what sort of feedback (if any) had been received on these > >topics, especially where non-trivial modifications werer required such as > >more complex authorisation and low-level code modifications were required, > >and how these we done to avoid issues when upgrading to future versions. > > > >Thanks. > > > >Scott. > > > >_______________________________________________ > >Dspace-general mailing list > >Dspace-general at mit.edu > >http://mailman.mit.edu/mailman/listinfo/dspace-general > >MacKenzie Smith >Associate Director for Technology >MIT Libraries >Building 14S-208 >77 Massachusetts Avenue >Cambridge, MA 02139 >(617)253-8184 >kenzie at mit.edu > >------------------------------ > >_______________________________________________ >Dspace-general mailing list >Dspace-general at mit.edu >http://mailman.mit.edu/mailman/listinfo/dspace-general > > >End of Dspace-general Digest, Vol 2, Issue 10 >********************************************* ---------------------------------------------------------------------- Sam Kalb Coordinator, Technical Services, Queen's University Libraries Kingston, Ontario, Canada K7L 5C4 Phone: (613) 533-2830; Fax: (613) 533-6819 Email: kalbs at post.queensu.ca URL (QTECH Web): stauffer.queensu.ca/techserv/qtechweb.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20030929/05d6f740/attachment.htm From Kalbs at post.queensu.ca Mon Sep 29 12:48:56 2003 From: Kalbs at post.queensu.ca (Sam Kalb) Date: Mon, 29 Sep 2003 12:48:56 -0400 Subject: [Dspace-general] DSpace customisation Message-ID: <5.2.1.1.0.20030929124843.01090db0@post.queensu.ca> MacKenzie, Where can we get information about the institutions and the changes they have made - to assist some of us in setting up our DSpace projects? I am particularly interested in the addition of full-text indexing. Sam >Date: Sun, 28 Sep 2003 22:23:16 -0400 >From: MacKenzie Smith >To: dspace-general at MIT.EDU >Subject: Re: [Dspace-general] DSpace customisation >Message-ID: <5.0.2.1.2.20030928221008.035cfa60 at hesiod> >In-Reply-To: <200309220911.21312.scott.yeadon at anu.edu.au> >Content-Type: text/plain; charset="us-ascii"; format=flowed >MIME-Version: 1.0 >Precedence: list >Message: 1 > >Hi Scott, > >The DSpace Federation project you asked about is still underway, >but we've learned quite a bit on the subject since last fall. First of all, >the DSpace software itself has not been extensively modified by >other universities adopting it so far. Most of them have modified the >UI to make it reflect their own institutional culture, and some have >modified the submission process, added full-text indexing, etc. >Three of the institutions we're working with are considering adding >Shibboleth support over the default X.509 (certificates) or >logon/password access control. The main area of technical >development seems to be in modules that will be outside of DSpace >itself, e.g. publishing tools or rendering applications for >non-Web-native formats. > >The major effort at most institutions to implement DSpace as >an institutional repository seems not to be in the technology >at all, but rather in the definition of policies and business models >that the library (or other part of the organization) needs to provide >a production service to its researchers. > >As for avoiding upgrade problems if you make modifications, >we try to keep the development process as open as possible >(documenting future releases, as well as the code contribution >process). The best way to ensure future compatibility is to >communicate with us about the changes you're making, and >offer them back to the main codebase when you're done! > >Hope this helps, > >MacKenzie/ > >At 09:11 AM 9/22/2003 +1000, Scott Yeadon wrote: > >Hi, > > > >We're looking at introducing DSpace to ANU (Australian National University), > >and I have just read a paper date Jan 2003 in D-Lib magazine entitled DSpace > >- An OpenSource Dynamic Digital Repository, located at > >http://www.dlib.org/dlib/january03/smith/01smith.html. The section entitled > >"The DSpace Federation" contains a paragraph as follows: > > > >"In 2002, MIT formed collaborative partnerships with a small number of other > >academic research institutions in the US, UK, and Canada, to address some > >specific questions such as: what will it take to successfully deploy the > >system at another institution? How much localization, how much > customization, > >and how much time and effort are needed?" > > > >I was wondering what sort of feedback (if any) had been received on these > >topics, especially where non-trivial modifications werer required such as > >more complex authorisation and low-level code modifications were required, > >and how these we done to avoid issues when upgrading to future versions. > > > >Thanks. > > > >Scott. > > > >_______________________________________________ > >Dspace-general mailing list > >Dspace-general at mit.edu > >http://mailman.mit.edu/mailman/listinfo/dspace-general > >MacKenzie Smith >Associate Director for Technology >MIT Libraries >Building 14S-208 >77 Massachusetts Avenue >Cambridge, MA 02139 >(617)253-8184 >kenzie at mit.edu > >------------------------------ > >_______________________________________________ >Dspace-general mailing list >Dspace-general at mit.edu >http://mailman.mit.edu/mailman/listinfo/dspace-general > > >End of Dspace-general Digest, Vol 2, Issue 10 >********************************************* ---------------------------------------------------------------------- Sam Kalb Coordinator, Technical Services, Queen's University Libraries Kingston, Ontario, Canada K7L 5C4 Phone: (613) 533-2830; Fax: (613) 533-6819 Email: kalbs at post.queensu.ca URL (QTECH Web): stauffer.queensu.ca/techserv/qtechweb.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20030929/5bbd4dc0/attachment.htm From emurphy1 at email.arizona.edu Mon Sep 29 14:42:11 2003 From: emurphy1 at email.arizona.edu (Ed Murphy) Date: Mon, 29 Sep 2003 11:42:11 -0700 Subject: [Dspace-general] DSpace v1.2 Message-ID: <000001c386b9$64cc2cc0$33a48796@ilc.arizona.edu> Hello, I was excited to see the next release of DSpace, v1.2, is being planned. We are very interested in the enhancement to allow one item to be stored in multiple collections. Is there a general target date for the release of DSpace v1.2 yet? If so, what is it? Thanks, Ed Murphy Applications Systems Analyst, Sr. Integrated Learning Center The University of Arizona Tucson, Arizona -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20030929/fc7b846b/attachment.htm From mjordan at sfu.ca Mon Sep 29 15:20:27 2003 From: mjordan at sfu.ca (Mark Jordan) Date: Mon, 29 Sep 2003 12:20:27 -0700 Subject: [Dspace-general] Nothing showing up in Authorization Tool Message-ID: <20030929192027.GL8366@sfu.ca> Hello, Perhaps I'm missing some crucial step, so please feel free to tell me to RTFM a bit more closely if that's the case. I've set up a test community and collection, I've created a sumbitter group for the collection, but when I go into the Authorization Tool to give this group ad permission, nothing is showing up. I am selecting the collection title and clicking on the Edit button. The same symptoms happen when I use the Authorizations tool to modify community policies -- I select the community name and click on Edit policies, and a blank page shows up. The only lines in my dspace.log are ones like "2003-09-23 14:41:02,064 INFO org.dspace.app.webui.servlet.RetrieveServlet @ anonymous:session_id=FFFC1375F04446FC82223844069AF244:view_bitstream:bitstream_id=2", and I know the Anonymous group has read permissions on this collection since it's showing up in the public user interface. Anyone else experience the same thing? If so, what's the solution? Mark Mark Jordan Acting Coordinator of Library Systems W.A.C. Bennett Library, Simon Fraser University Burnaby, British Columbia, V5A 1S6, Canada Phone (604) 291 5753 / Fax (604) 291 3023 mjordan at sfu.ca / http://www.sfu.ca/~mjordan/ From david.stuve at hp.com Mon Sep 29 15:41:55 2003 From: david.stuve at hp.com (STUVE,DAVID (HP-Corvallis,ex1)) Date: Mon, 29 Sep 2003 12:41:55 -0700 Subject: [Dspace-general] Nothing showing up in Authorization Tool Message-ID: <5755325D04C5834187459E1E17D81F6F0834F04C@xcor01.cv.hp.com> Hi Mark, This sounds like a problem that DSpace 1.1 had with creating policy entries that were NULLs (no value in the database table), especially when people would select "create policy" and then hit the browser's back button. The problem is tough to diagnose because for some reason those errors are quietly swallowed, generating no log entry and no error page - simply a blank screen. 1) Are you running DSpace 1.1 or 1.1.1? If 1.1, an upgrade will help. 2) If upgrading doesn't help, the next easy answer is to use psql or another Postgres tool and delete the null rows from the policy table. 3) The problem has never made it past #1 and #2. :-) But if you're the lucky first one, we can help more. Dave David Stuve / HP Labs Corvallis / David.Stuve at hp.com / 541-715-4106 -----Original Message----- From: Mark Jordan [mailto:mjordan at sfu.ca] Sent: Monday, September 29, 2003 12:20 PM To: dspace-general at mit.edu Subject: [Dspace-general] Nothing showing up in Authorization Tool Hello, Perhaps I'm missing some crucial step, so please feel free to tell me to RTFM a bit more closely if that's the case. I've set up a test community and collection, I've created a sumbitter group for the collection, but when I go into the Authorization Tool to give this group ad permission, nothing is showing up. I am selecting the collection title and clicking on the Edit button. The same symptoms happen when I use the Authorizations tool to modify community policies -- I select the community name and click on Edit policies, and a blank page shows up. The only lines in my dspace.log are ones like "2003-09-23 14:41:02,064 INFO org.dspace.app.webui.servlet.RetrieveServlet @ anonymous:session_id=FFFC1375F04446FC82223844069AF244:view_bitstream:bitstre am_id=2", and I know the Anonymous group has read permissions on this collection since it's showing up in the public user interface. Anyone else experience the same thing? If so, what's the solution? Mark Mark Jordan Acting Coordinator of Library Systems W.A.C. Bennett Library, Simon Fraser University Burnaby, British Columbia, V5A 1S6, Canada Phone (604) 291 5753 / Fax (604) 291 3023 mjordan at sfu.ca / http://www.sfu.ca/~mjordan/ _______________________________________________ Dspace-general mailing list Dspace-general at mit.edu http://mailman.mit.edu/mailman/listinfo/dspace-general From mjordan at sfu.ca Mon Sep 29 16:23:12 2003 From: mjordan at sfu.ca (Mark Jordan) Date: Mon, 29 Sep 2003 13:23:12 -0700 Subject: [Dspace-general] Nothing showing up in Authorization Tool In-Reply-To: <5755325D04C5834187459E1E17D81F6F0834F04C@xcor01.cv.hp.com> References: <5755325D04C5834187459E1E17D81F6F0834F04C@xcor01.cv.hp.com> Message-ID: <20030929202311.GN8366@sfu.ca> Hi Dave, Sorry I didn't include my version in my original email: it's 1.1. I downloaded dspace-1.1.1.tar.gz, and following the updating instructions at http://dspace.org/technology/system-docs/update.html#11_111, I ran ant -Dconfig=/dspace/config/dspace.cfg update and got the error Buildfile: build.xml update: BUILD FAILED /tmp/dspace-1.1.1-source/build.xml:184: /tmp/dspace-1.1.1-source/build/classes not found. Total time: 0 seconds Line 184 of build.xml specifies basedir="${basedir}/build/classes", basedir being defined previously as ".". When I run a 'find . -name classes' at the top of the untarred dspace-1.1.1-source directory, I don't find anything. The .jar files in the update are in the dspace-1.1.1-source/lib directory. Should I modify build.xml to use that directory? Sorry to introduce a new problem, Mark On Mon, Sep 29, 2003 at 12:41:55PM -0700, STUVE,DAVID (HP-Corvallis,ex1) wrote: > Hi Mark, > > This sounds like a problem that DSpace 1.1 had with creating policy entries > that were NULLs (no value in the database table), especially when people > would select "create policy" and then hit the browser's back button. The > problem is tough to diagnose because for some reason those errors are > quietly swallowed, generating no log entry and no error page - simply a > blank screen. > > 1) Are you running DSpace 1.1 or 1.1.1? If 1.1, an upgrade will help. > 2) If upgrading doesn't help, the next easy answer is to use psql or another > Postgres tool and delete the null rows from the policy table. > 3) The problem has never made it past #1 and #2. :-) But if you're the > lucky first one, we can help more. > > Dave > > David Stuve / HP Labs Corvallis / David.Stuve at hp.com / 541-715-4106 > > -----Original Message----- > From: Mark Jordan [mailto:mjordan at sfu.ca] > Sent: Monday, September 29, 2003 12:20 PM > To: dspace-general at mit.edu > Subject: [Dspace-general] Nothing showing up in Authorization Tool > > > Hello, > > Perhaps I'm missing some crucial step, so please feel free to tell me to > RTFM a bit more closely if that's the case. > > I've set up a test community and collection, I've created a sumbitter group > for the collection, but when I go into the > Authorization Tool to give this group ad permission, nothing is showing up. > I am selecting the collection title and clicking > on the Edit button. > > The same symptoms happen when I use the Authorizations tool to modify > community policies -- I select the community name and click on Edit > policies, and a blank page shows up. > > The only lines in my dspace.log are ones like "2003-09-23 14:41:02,064 INFO > org.dspace.app.webui.servlet.RetrieveServlet @ > anonymous:session_id=FFFC1375F04446FC82223844069AF244:view_bitstream:bitstre > am_id=2", and I know the Anonymous group has read > permissions on this collection since it's showing up in the public user > interface. > > Anyone else experience the same thing? If so, what's the solution? > > Mark > > > Mark Jordan > Acting Coordinator of Library Systems > W.A.C. Bennett Library, Simon Fraser University > Burnaby, British Columbia, V5A 1S6, Canada > Phone (604) 291 5753 / Fax (604) 291 3023 > mjordan at sfu.ca / http://www.sfu.ca/~mjordan/ > > > _______________________________________________ > Dspace-general mailing list > Dspace-general at mit.edu > http://mailman.mit.edu/mailman/listinfo/dspace-general -- Mark Jordan Acting Coordinator of Library Systems W.A.C. Bennett Library, Simon Fraser University Burnaby, British Columbia, V5A 1S6, Canada Phone (604) 291 5753 / Fax (604) 291 3023 mjordan at sfu.ca / http://www.sfu.ca/~mjordan/ From rrodgers at MIT.EDU Mon Sep 29 17:03:24 2003 From: rrodgers at MIT.EDU (Richard Rodgers) Date: 29 Sep 2003 17:03:24 -0400 Subject: [Dspace-general] DSpace v1.2 In-Reply-To: <000001c386b9$64cc2cc0$33a48796@ilc.arizona.edu> References: <000001c386b9$64cc2cc0$33a48796@ilc.arizona.edu> Message-ID: <1064869404.12403.83.camel@dspace-03.mit.edu> Hi Ed: We haven't fixed on an exact date yet, since we are still in the process of characterizing some of the functionality that we recently announced. But we hope to release 1.2 this calendar year. Regards, Richard Rodgers DSpace Federation Systems Manager On Mon, 2003-09-29 at 14:42, Ed Murphy wrote: > Hello, > > I was excited to see the next release of DSpace, v1.2, is being > planned. We are very interested in the enhancement to allow one item > to be stored in multiple collections. Is there a general target date > for the release of DSpace v1.2 yet? If so, what is it? > > Thanks, > > Ed Murphy > > Applications Systems Analyst, Sr. > Integrated Learning Center > The University of Arizona > Tucson, Arizona > ---- > > _______________________________________________ > Dspace-general mailing list > Dspace-general at mit.edu > http://mailman.mit.edu/mailman/listinfo/dspace-general From kenzie at MIT.EDU Mon Sep 29 17:55:07 2003 From: kenzie at MIT.EDU (MacKenzie Smith) Date: Mon, 29 Sep 2003 17:55:07 -0400 Subject: [Dspace-general] DSpace customisation In-Reply-To: <5.2.1.1.0.20030929123946.03c8a710@post.queensu.ca> References: <200309291601.h8TG0fgK015283@pch.mit.edu> Message-ID: <5.0.2.1.2.20030929175216.034e2898@hesiod> At 12:42 PM 9/29/2003 -0400, Sam Kalb wrote: >Where can we get information about the institutions and the changes they >have made - to assist some of us in setting up our DSpace projects? I am >particularly interested in the addition of full-text indexing. The institution that mentioned they were implementing this was Drexel, in Philadelphia. I haven't confirmed it. But we're also planning to add an option for full-text indexing with Lucene in the next release (1.2, due later this year, we hope). If someone else out there has worked on full-text indexing in DSpace hopefully they'll speak up and let us know! And feel free to ask on the dspace-tech list too, which is where most of the developers are lurking... Regards, MacKenzie/ MacKenzie Smith Associate Director for Technology MIT Libraries Building 14S-208 77 Massachusetts Avenue Cambridge, MA 02139 (617)253-8184 kenzie at mit.edu From gabriela.mircea at utoronto.ca Tue Sep 30 11:27:14 2003 From: gabriela.mircea at utoronto.ca (Gabriela Mircea) Date: Tue, 30 Sep 2003 11:27:14 -0400 Subject: [Dspace-general] DSpace customisation References: <5.2.1.1.0.20030929124843.01090db0@post.queensu.ca> Message-ID: <3F79A0D2.A8D539BF@utoronto.ca> Hello Sam, We would be happy to assist you to set up your DSpace. We made some changes to DSpace to suit our needs, and we also worked on full-text indexing (with help from Drexel). It may not be the best way to do it, but the full-text search is now working for pdf, doc, txt, htm, html, and xls on our test server and it is perfectly integrated with the advanced search tool. You can try it at http://tort.library.utoronto.ca:8080/advanced-search, and choose "contents" from the drop-down menu. I look forward to our collaboration. Gabriela Mircea Information Technology Services Robarts Library, 130 St. George St. Toronto, ON, Canada, M5S 1A5 416 946 0114 Sam Kalb wrote: > MacKenzie, > Where can we get information about the institutions and the changes > they have made - to assist some of us in setting up our DSpace > projects? I am particularly interested in the addition of full-text > indexing. > Sam > > >> Date: Sun, 28 Sep 2003 22:23:16 -0400 >> From: MacKenzie Smith >> To: dspace-general at MIT.EDU >> Subject: Re: [Dspace-general] DSpace customisation >> Message-ID: <5.0.2.1.2.20030928221008.035cfa60 at hesiod> >> In-Reply-To: <200309220911.21312.scott.yeadon at anu.edu.au> >> Content-Type: text/plain; charset="us-ascii"; format=flowed >> MIME-Version: 1.0 >> Precedence: list >> Message: 1 >> >> Hi Scott, >> >> The DSpace Federation project you asked about is still underway, >> but we've learned quite a bit on the subject since last fall. First >> of all, >> the DSpace software itself has not been extensively modified by >> other universities adopting it so far. Most of them have modified >> the >> UI to make it reflect their own institutional culture, and some have >> >> modified the submission process, added full-text indexing, etc. >> Three of the institutions we're working with are considering adding >> Shibboleth support over the default X.509 (certificates) or >> logon/password access control. The main area of technical >> development seems to be in modules that will be outside of DSpace >> itself, e.g. publishing tools or rendering applications for >> non-Web-native formats. >> >> The major effort at most institutions to implement DSpace as >> an institutional repository seems not to be in the technology >> at all, but rather in the definition of policies and business models >> >> that the library (or other part of the organization) needs to >> provide >> a production service to its researchers. >> >> As for avoiding upgrade problems if you make modifications, >> we try to keep the development process as open as possible >> (documenting future releases, as well as the code contribution >> process). The best way to ensure future compatibility is to >> communicate with us about the changes you're making, and >> offer them back to the main codebase when you're done! >> >> Hope this helps, >> >> MacKenzie/ >> >> At 09:11 AM 9/22/2003 +1000, Scott Yeadon wrote: >> >Hi, >> > >> >We're looking at introducing DSpace to ANU (Australian National >> University), >> >and I have just read a paper date Jan 2003 in D-Lib magazine >> entitled DSpace >> >- An OpenSource Dynamic Digital Repository, located at >> >http://www.dlib.org/dlib/january03/smith/01smith.html. The section >> entitled >> >"The DSpace Federation" contains a paragraph as follows: >> > >> >"In 2002, MIT formed collaborative partnerships with a small number >> of other >> >academic research institutions in the US, UK, and Canada, to >> address some >> >specific questions such as: what will it take to successfully >> deploy the >> >system at another institution? How much localization, how much >> customization, >> >and how much time and effort are needed?" >> > >> >I was wondering what sort of feedback (if any) had been received on >> these >> >topics, especially where non-trivial modifications werer required >> such as >> >more complex authorisation and low-level code modifications were >> required, >> >and how these we done to avoid issues when upgrading to future >> versions. >> > >> >Thanks. >> > >> >Scott. >> > >> >_______________________________________________ >> >Dspace-general mailing list >> >Dspace-general at mit.edu >> >http://mailman.mit.edu/mailman/listinfo/dspace-general >> >> MacKenzie Smith >> Associate Director for Technology >> MIT Libraries >> Building 14S-208 >> 77 Massachusetts Avenue >> Cambridge, MA 02139 >> (617)253-8184 >> kenzie at mit.edu >> >> ------------------------------ >> >> _______________________________________________ >> Dspace-general mailing list >> Dspace-general at mit.edu >> http://mailman.mit.edu/mailman/listinfo/dspace-general >> >> >> End of Dspace-general Digest, Vol 2, Issue 10 >> ********************************************* > > > ---------------------------------------------------------------------Sam > Kalb Coordinator, Technical Services,Queen's University > LibrariesKingston, Ontario, Canada K7L 5C4Phone: (613) 533-2830; Fax: > (613) 533-6819Email: kalbs at post.queensu.caURL (QTECH Web): > stauffer.queensu.ca/techserv/qtechweb.html > > ---------------------------------------------------------------- > _______________________________________________ > 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/20030930/841fed63/attachment.htm From margretb at MIT.EDU Tue Sep 30 15:10:36 2003 From: margretb at MIT.EDU (Margret Branschofsky) Date: Tue, 30 Sep 2003 15:10:36 -0400 Subject: [Dspace-general] Improvements to Administrator's User Interface Message-ID: <5.2.1.1.2.20030930150051.02312980@po10.mit.edu> Hello, One of the new features we are adding to the next version of DSpace is an improved Administrator's User Interface. I am going to be writing up the feature definition for this, so please send me suggestions for improving the admin. interface, your pet peeves, functions you would like to add...etc. This is your chance to have an impact on the tools you use. Margret Margret Branschofsky DSpace User Support Manager Digital Library Research Group Bldg. 14S-M24 (617)253-1293 margretb at mit.edu http://dspace.mit.edu From scott.yeadon at anu.edu.au Tue Sep 30 19:47:09 2003 From: scott.yeadon at anu.edu.au (Scott Yeadon) Date: Wed, 1 Oct 2003 09:47:09 +1000 Subject: [Dspace-general] failed 1.1.1 build due to missing build/classes directory Message-ID: <200310010947.09893.scott.yeadon@anu.edu.au> Mark, I had this problem, however by manually creating the directories the problem is resolved. {basedir} represents the directory you unzipped the install package to e.g. /tmp/dspace-1.1.1-source/build/classes The directory is basically a working directory for the installation process. Scott.