Results of DSpace Open Source Community Survey, Oct 2006

Use of DSpace

University Institutional Repository

90

77.6%

Government Organization Repository System

13

11.2%

Corporate Intranet repository

2

1.7%

Research or development project using DSpace as a platform

13

11.2%

Other (please specify)

13

11.2%

Total

116

112.9%

Other (please specify)

Sub-institutional repository

Research Institute Institutional Repository

Institute

State Library Institutional Repository

public archive for NGO

historical archive

Digital Archival Repository

ETD site

Multi-user object repository

Archives

Museum DAMS

Public Opinion Repository

Subject Repository

Maturity

Production service

62

53.4%

Pilot service

41

35.3%

Evaluation for potential future service

9

7.8%

Not applicable (e.g. using it for research)

4

3.4%

Total

116

100.0%

Version

1.0 or 1.0.1

0

0.0%

1.1 or 1.1.1

0

0.0%

1.2, 1.2.1 or 1.2.2

17

14.7%

1.3, 1.3.1 or 1.3.2

46

39.7%

1.4

42

36.2%

Bleeding-edge CVS version

4

3.4%

Don't know/can't remember

7

6.0%

Total

116

100.0%

Maturity

Production service

Pilot service

Evaluation for potential future service

Not applicable (e.g. using it for research)

1.0 or 1.0.1

0

0.0%

0

0.0%

0

0.0%

0

0.0%

1.1 or 1.1.1

0

0.0%

0

0.0%

0

0.0%

0

0.0%

1.2, 1.2.1 or 1.2.2

15

24.2%

2

4.9%

0

0.0%

0

0.0%

1.3, 1.3.1 or 1.3.2

29

46.8%

15

36.6%

1

11.1%

1

25.0%

1.4

15

24.2%

21

51.2%

5

55.6%

1

25.0%

Bleeding-edge CVS version

1

1.6%

2

4.9%

0

0.0%

1

25.0%

Don't know/can't remember

2

3.2%

1

2.4%

3

33.3%

1

25.0%

Total

62

100.0%

41

100.0%

9

100.0%

4

100.0%

Use priorities

Very important

Important

Useful but not critical

Unimportant

Total

Open access to refereed articles

66

56.9%

28

24.1%

16

13.8%

6

5.2%

116

100.0%

Preservation

71

61.2%

36

31.0%

9

7.8%

0

0.0%

116

100.0%

Branding of university content

34

29.3%

41

35.3%

30

25.9%

11

9.5%

116

100.0%

Indexing by search engines

67

57.8%

34

29.3%

11

9.5%

4

3.4%

116

100.0%

Ability to store and manage diverse digital collections of content (e.g. audio, video etc)

52

44.8%

43

37.1%

19

16.4%

2

1.7%

116

100.0%

Interoperability with other systems

71

61.2%

35

30.2%

10

8.6%

0

0.0%

116

100.0%

Online collaboration of users

17

14.7%

43

37.1%

41

35.3%

15

12.9%

116

100.0%

Use for research/experimentation with repository technologies

14

12.1%

36

31.0%

46

39.7%

20

17.2%

116

100.0%

Content in DSpace

Have in DSpace now

Plan to store in DSpace

No plans to store

Total

Refereed scholarly articles

64

55.2%

40

34.5%

12

10.3%

116

100.0%

Grey literature (e.g. tech reports)

55

47.4%

40

34.5%

21

18.1%

116

100.0%

Theses/dissertations

64

55.2%

41

35.3%

11

9.5%

116

100.0%

Teaching materials

27

23.3%

51

44.0%

38

32.8%

116

100.0%

Web sites

12

10.3%

25

21.6%

79

68.1%

116

100.0%

Digital surrogates of library materials

36

31.0%

30

25.9%

50

43.1%

116

100.0%

Images (e.g. photos)

41

35.3%

47

40.5%

28

24.1%

116

100.0%

Video

30

25.9%

54

46.6%

32

27.6%

116

100.0%

Audio

31

26.7%

54

46.6%

31

26.7%

116

100.0%

Datasets

18

15.5%

62

53.4%

36

31.0%

116

100.0%

Software source code

11

9.5%

39

33.6%

66

56.9%

116

100.0%

Other (please specify)

18

48.6%

7

18.9%

12

32.4%

37

100.0%

Other (please specify)

music

manscripts

CAD models

tables

Links to Archived Portfolios in Moodle

preprints

n/a

Metadata about external resources

In house document

-

none

none

-

x

none

none

proceedings

conference papers

preprint, project outcome

any born digital material produced by the XXX Chemical Company

Journal article

administrative laws

Student papers

-

Newsletters, Meeting Minutes

Documentation

Faculty Bio, CV

a

None

emails

office documents

books and book chapters

Surveys

not sure, but things arise

unpublished research, undergraduate research, university archives

Archives

more

Metadata

Customized Dublin Core fields (not in default configuration or standard DCMI vocabulary)

93

80.2%

Non-Dublin Core metadata, using the new multi-schema support in 1.4

13

11.2%

XML metadata, stored in a bitstream in the item

16

13.8%

RDF metadata, stored in a bitstream in the item

7

6.0%

Have extended the database schema to accomodate

13

11.2%

Total

116

122.4%

Updating

Yes, soon after they are released

29

25.0%

Yes, but it takes long time to merge in my customizations/configuration

52

44.8%

No, my customizations are too difficult to merge

7

6.0%

No, I don't have time/expertise/available staff to upgrade

7

6.0%

Not applicable

21

18.1%

Total

116

100.0%

Customization

Almost no changes (just configuration)

13

11.2%

Minor cosmetics (e.g. stylesheet/fonts, different logo)

40

34.5%

Significant user interface customization

25

21.6%

Implemented new features

31

26.7%

Significant changes to core code/architecture

7

6.0%

Total

116

100.0%

Customization

Applied LNI patches, will be tinkering with the Handle handling. Added custom packagers and disseminators

Custom Crosswalks Custom Export and Import Packagers Custom UI modifications Custom Servlets for special behaviors Custom Authenticators

Changed ItemListTag to get rid of the dreadful table. Changed ItemTag to reorder display and make it a little nicer. A few small patches that have mostly made their way into core. Working on integrating COinS into item pages and item lists (will send patch when ready). Hoping to cut down on page clutter in some of the workspace processes.

trying to add interoperability features

Changed look and feel to match corp. style pages.

I would like to edit the lower three options, but I don't have the technical know-how or time to learn. Would love it to be easier.

development of code to use the API to add, remove and modify entries in dspace from other java code.

Creation of new JSP Tags to reorganize and clean up DSpace UI. Implemented new functionality only currently available within patches (e.g. Configurable Submission, Delegate Admins patches). Also have implemented and mantained older patch functionality (e.g. U of Rochester's Researcher Pages). In addition, have customized the vast majority of DSpace JSPs to clean up interface, add new functionality, etc.

- subfield structure within QDC fields - 3 different types of collections - complete review of submission interface (doc template per doc type) - bitstream characteristics (version, accessibilty restrictions)

Video and audio streaming Created a navigation menu Multi file input in submit New UI using Manakin

I18N (sorting, listing)

plugin manager crosswalk plugins packager plugins METS and IMSCP packagers LNI property references in configuration event system new history system object URIs prototype AIP implementation various bug fixes

Changes in styles.

Support non-DC metadata schema Categoriesaton of entries Support for storing metadata about external resources

add Language Selection Switch, rss feed of toppage, download counter, edit "filtermedia" for CJK fonts, and edit for "Open URL 1.0"

Crosswalks and Ingest classes; stats extension; xml-based batch uploader

Institute Logo

ip recognition

many HTML modifications, IP recognition for authentication, added a few static pages with our content.

We built in IP-check for security and aggregation of different Communities to one main Community for harvesting-reasons (so that the Service Provider (DARE) just need to harvest one Set).

Included pathes (Items with no files) and (Request eprint). Not sure if we'll continue supporting the @Request eprint' patch in furutre versions due to the overhead of upgradign it and we only have 1 paper that needs it.

Custom workflows, custom OAI-PMH data providers, DAI support.

- problems to display more than one language - customize some things of submission form

- LDAP authentication/authorisation - added RDF to describe the relation between bitstreams/items/etc. - embargo support on bitstream level

we only added a few new fields for input

Added a counter to the Item Page to show how many times viewed. Added a "Quick Submit" button and feature that is a scaled down version of the submission process.

We made an Ip-check to hide items with embargo-dates from Open Access or even from access inside the campus.

quite some changes in JSP's, very small changes in code

(We are in the process of doing the following 2 items) 1) Improved Localization 2) Improved Roles/Permissions (Added more control to Community Admins)

We modified the deposit and admin forms substantially, and did a fair amount of jsp work as well. Visit deepblue.lib.umich.edu to see these results, and you can see descriptions of the more hidden changes at http://hdl.handle.net/2027.42/40249

edited jsp's for home and items pages, installed oclc's srw/u server

Article input from RSS feeds

- a sequencemaker for bitstreams of an item - embargo system - other login - diiferent font

submission process, interface, stylesheet and logo

Submission procedures have been simplified for the sake of end users. Several metadata (relevant to the description of ETDs) are retrieved from the registrar's department data warehouse.

- Web service layer to delegate submission and display to be embedded in an external system - minor modifications to DSpace core to improve reusability of code and extend functionality - rebranding of user interface - Addition of 5 or 6 user tool modules to aid in workflow administration - Implementation of LNI patch

Besides cosmetic changes and some interface costumization (namely in the submission forms) we implemented the functionalities of the Add-ons we developed: Statistics and Request a Copy.

Moving of collections/items Changes in the authorization of items for collection owner being more able.

creation of new metadata, advanced search, diacritical marks...

We´ve added some add-ons/plugins, namely researcher pages as well as items with no files

patches for localization, removing handle features

No bistream required for an item

Extensive JSP changes for UI. Originally (pre 1.3 patch) we made significant changes to SubmissionServlet and EditItemServlet and the tag libraries. With the patch we started experimenting with plugins and are in the process with 1.4 of moving customizations out of servlets and tag libraries and into packager plugins.

1. Bitstream Handles (before it was in main distribution) 2. Local authentication 3. Refworks citation direct export (in 1.4) 4. Local Handle resolver 5. researher pages from Rochester

Working with group to update the Commenting Add-On from Minho; plan to make other customizations which may include thesis submission (Tapir Add-On), bulletin board-like collaboration space, social tagging, and utility programs for images.

I have sucessfully installed 1.4 on a test box and have customized the Submission Metadata entry form by editing the input_form.xml file. I am learning Java to start to work with other customizations.

We revised input-forms.xml to add ETD-specifc pull down lists. We also made minor "branding" changes

Added hit highlighting to search results. Created web service for other applications to access some functionality. Added browse by any metadata field without having to create ITEMSBYXXX table.

- Make it possible to enter metadata only (use as Academic Bibliography) - Mask non-institute members in the author browse lists - Submission procedure based on type (8 types) with adapted input-forms.xml - Pop-ups with controlled alphabetic lists of authors (with unique ID for institute members)- journals - .... - Extended DC with bibliographicCitation with specific qualifiers (e.g. journal title - vol, issue, start and end page as separated fields - concatenated in identifier.citation) - more refined mods export in oai and creation of other formats (for agris - FAO)(in development) (developed by the informatics dept + students under my supervision)

Changes in DSpace 1.We are developing 28 different installations of DSpace and we have done some changes in the buil.xml so that we can build all the installations at the same time by using the same source code, but different css- and jsp-files. 2.We have made it possible to have an integration with BIBSYS library system. 3.We have integrated the Norwegian national access control FEIDE. 4.The administrator can give rights to a group by select a faculty, department etc. All the members of the faculty will get this group as a special group. This feature is only possible if the user uses FEIDE. 5.The user has the possibility to decide if and when a document should be public available

I'm not quite sure how significant our changes are, but we changed input form in a way that we changed labels, added new languages, type options and keyword lists in a dropdown menu for some collections.

Added ability to expose just theses in UKETD_DC in the OAI interface. This involved adding new fields to the metadata registry, making minor changes to DSpaceOAICatalog.java, creating a modified version of Harvest.java called EThOSHarvest.java and creating the UKETD_DC crosswalk

Added SingleSignOn to dspace - CAS from Yale. User import via a soup interface. We are also using the Tapir addon.

New menus, new feature for listing only collections, changes in submission flow system

Bitstream storage was modified to do on-the-fly encryption and decryption of files.

Mahor changes to user interface, including some classes that accompany those changes.

redesigned the UI

Remove display of handles

database code is too tightly coupled with postgres. Currently working to remove this problem.

ldap authentication maps users to groups for submisssion rights, ability to group communities into 'meta-communities' to enhance display, allow for one submission to be simlutaneously made to multiple collections.

Core code changes Added new SetSpecs to allow for selective harvesting (based on resource types)

Comfortable customizing

Yes, totally comfortable

35

30.2%

Somewhat comfortable

66

56.9%

Not comfortable

15

12.9%

Total

116

100.0%

Documentation

It helps greatly

27

23.3%

It helps somewhat, but I need to ask questions and/or do some digging

85

73.3%

The documentation is not clear at all

4

3.4%

Total

116

100.0%

Documentation improvement

More Tutorials on customization, more descriptive background and expected behavior in Javadoc...

Probably not your fault; I'm not an expert programmer.

index

More practical exmaples are needed for customizations. For example, LDAP authentication, perhaps schema/Postresql changes would be great additions.

I need the documentation to be more specific. How do I batch import? What are the exact steps?

Within the .jsp's there should be more comments. Having said this it has improved between 1.3.x and 1.4 code.

With more practical examples and links to the java code

Documentation could be inproved first by being easier to search, and second by being easier to update. I'd suggest placing all the documentation somewhere within the Wiki itself, where it will always be available, and can be updated (or add notes to it) easily. It's disappointing that the System Documentation on the DSpace website (http://dspace.org/technology/system-docs/) is not even current to the latest version of DSpace.

It could provide more examples for how a particular change would actually change DSpace. Too many times, you have to make a change to see the extend of the changes. Also, it would useful to have a basic set of step-by-step instructions to get a basic DSpace implementation up and running to do something very, very simple, such as be a portfolio storage location for a handful of scholars.

in other languagues

Organize it better, separating design doc and operations manuals. get trained technical writers to consult, at least on the overall organization and structure.

a reference guide, case studies, more examples

How the handle works and getting it to work is really obscure

Incorporating an FAQ in the same vein as the old "Black Book" series (i.e. use-case based) may help would-be developers become familiar with the plugin points and customisations

It requires some more details on customisation of JDBC and vi file details.

update web version of documentation

Describe things more detailed level

The basic documentation from version 1.0 is still useful, but my impression is that new features, add-ons that have been integrated in later versions etc are not covered as well by the documentation. In other words: is the documenation realy up to date with the latest version, and how do I tell?

No improvement necessary to the documention

It's pretty thorough from a technical standpoint but the administrative/functional documentation often lags behind. This makes it more difficult to implement new functionality from release to release because the non-technical people at this institution decide what functionality to implement.

I would like more detail concerning the SQL schema. What I have learned is from experimenting and talking to others. I'd like more details concerning the various Java Classes, as well.

More Diagrams of software design.

Clearer differentiation btw changes that can be made in adminUI and those that must be done with programming.

put the current release documentation (1.4 as of now) on the web -- it's only in the source download

- Better Javadocs to some parts of the code - Better code layout in some parts (ok, it's not technically documentation, but we read it to find out how it works, so it does help) - More up-to-date documentation available online, or have the documentation deployed with a live DSpace.

Our tech support is provided by a third party (a university student team). They had trouble getting the handle and thumbnail image parts of DSpace working. They also created their own step-by-step documentation on how to install an instance of DSpace so that other instances can be built in the future more easily, and are in the process of documenting how to upgrade from one version to another.

That question is being answered by the technical staff involved in BDJur Project (they are also sending there answers).

1. Documentation should focus on specific versions of OS and other software components. 2. It should be helpful to a person who has little knowledge of linux 3. Possible problems should be listed and solutions to overcome them should be suggested

Docimentation is sufficient, but the mailing-list archives should be more accessible (font, encoding and general ui considerations).

There are many underlying assumptions (knowledge of certain tools/environments) that are made, but not stated. When I first began supporting our universities DSpace instance the documentations felt very choppy, and it felt like there were many things that were left out for a first time user unfamiliar with postgres and tomcat. Some FAQs or some very basic steps and things to look for in trouble shooting these tools, specifically issues that we run into using DSpace would have been very helpful for me and saved me days of scouring the other products websites and the internet. Needless to say the exercise was good for me but it slowed me down significantly when I had a tight time constraint. So I repeat some basic explanations for some of these tools, i.e. postgres - how to get into postgres as the postgres user connect to the template1 database to manually modify the database before the DSpace database has been created.

It is not up to date. There are inconsistencies between reality and the documentation (specifically in the graphical database structure).

More code examples. There also needs to be a better explanation of how the jsp pages and java classes interact (though that may need to be done in code comments as well)

More documentation in code would be good.

It is VERY unclear which version of DSpace a given piece of documentation refers to. Many topics are covered only lightly, or not at all in the official docs (e.g., bulk import, thumbnails support). The wiki is NOT a substitute until it's better vetted and better organized.

Putting in more detail. I've many times been able to find mention of something, but not have enough facts to actually implement a change. (Much more necessary for those of us who are not sys admins.)

It needs to be updated quicker. The ommission of the input_forms.xml problem that I had to scan through the dspace_tech list archive wasn't updated. Then there are the multiple souces for DSpace information.

I'm a DSpace administrator, but customization is done by a programmer. He seems comfortable with the documentation.

Mainly rely on examing and tracing through code so good javadoc comments and code comments can be usefull.

Ensure all configuration options are covered in the documentation

Better than documentation are mail lists, which are the most valuable source of solutions for concrete problems. We are all very impressed how quickly people from the developing team respond to the query related to installation.

Keep going in the current direction (Wiki, knowledgebase, FAQs) - it's getting better all the time.

Updated documentation. 1.4 contains some documention related to 1.3.2.

made even more elemantarty, instead of assuming that the perosn reading is an admin or techy. step by steps of some things and many many examples would be ideal

Need docs for the new version, and quickly incorporate hacks and tweaks discovered by the community, improve administration docs and have a tutorial to build plugins for DSpace, e.g. How to develop plugins

Kept up to date, more exhaustive

I have only brief experience with the documentation thus far, but I find it a bit underdeveloped and difficult to use, although with a little effort at interpretation it seems to make sense.

Feels generated, rather than human-readable.

Customization/configuration

Modularity, More Object Oriented, Factory/Facade based implementation that can be overriden via Java Services and extension without modifying core code.

Tons! I want TAPIR and Researcher Pages, but I don't dare install them because they're not maintained and they're not cleanly separated from core code. I want Manakin. I want thumbnail-browse for certain collections (e.g. our Special Collections department). I want bitstream versioning. I want bitstream relationships (even just bitstream reordering for display would be nice!). I want METS to be able to govern item display (a la the METS Multimedia Viewer). I want to put websites and other bitstreams in the same item. I want easier ways to hook DSpace up to other library systems and services. I want an API so that I have some hope of building some of this myself. Don't mind me; I want it all!

verisioning

I would love to have the ability to add to the Postgresql schema a set of tables for indexing cross references for names and subjects (librarians call this authority control). Though there are no standard for storing such data in a dublin core record at this point in time. Perhaps Dspace community needs to come up with a standard and implement it in the Postgresql.

1. Templates- I would like the collection homepage to list the titles. My users always get to the collection homepage and don't know what to do next. Clicking on the Title or Author button is not intuitive. 2. Search box - I would like to add a "Subject" button to the Community search buttons beside "Titles, Authors, By Date" 3. Navigation button for admin to get to the Admin options like Metadata Registry from the homepage (after logging in of course)

single signon using acegis library

More customizable UI overall (but Manakin should help), and not as tied into the hardcoded HTML in many JSP Tags. Ability to more easily manage browsing larger Community/Collection structures (ability to specify order in which they appear, and expand/contract to see more or less). In addition, the ability to generate better reports and download statistics would be nice.

One would be the ability to look in more than one LDAP container to locate a user. (Many LDAP directories allows you to keep your primary user accounts in more than one place; DSpace seems to want it to be in one place only.

Better authorization concerning access restrictions on even metadata level (communities & collections)

I believe Dspace should also have a CMS like approach. It's not just about books or data, but people

bulk loading in a web interface

At the moment DSpace suffers greatly from the "not-invented-here syndrone". It's got its own database layers and plugin architecture, which is not as flexible (or as good) as something which is more widly used, and makes it mroe difficult for programmers to get up to speed on it

I wish DSpace have "patch [1409951] (Language Selection Switch)" default.

- Relationship/compound object management - Shibboleth plugin or capability - more comprehensive METS SIP/DIP profile for compound objects or container objects

No

authority control for authors/ subjects; correct alphabetical order for indexes (accents are not used correctly for Greek alphabet); cannot connect to our ldap server

I need templates so as to change appearance easily

An option of Keyword search ....or browsing classifiers.

Improve statistical tools and make more user friendly interface for creating virtual collections.

Flexibility on moving items to other Comms/Colls; A full-blown XML-dump from the repository is needed; Possibility for deleting E-people; Possibility for a workflow with more workflowsteps and different uploadtemplates; HTML coding possible for upload-template; Internal Structure of authors (including affiliation).

Customization of the submission process is important, (and I have seen that that is expected to come with 1.5). Some webui admin tools for OAI-interface customization would be very useful.

Native support for SOAP/REST, online collaboration, proper versioning

The ability to 'easily' move items from/to new collections.

I would like to query the PostgreSQL database for 'rights2items'. In other words, search for all items that have XYZ rights restrictions or are available to XYZ groups. Conversely, I would like to search for all groups and list the items/collections that they have rights(edit/submit, etc.) to.

Would like to include the Tapir or some sort of acceptance workflow for ETDs, but we lack the human resources at this time

I's like to be able to customize the collection displays so that they have unique look and feels. I'd like to have different submission acknowledgements for different collections. I'd like to be able to integrate with other systems like DPubS or Fedora.

Would like to change itemlist-tag (but we avoid too many code changes for not getting into trouble with future upgrades)

Would like to see more roles/permissions for restricting bitstreams and metadata so that DSpace could be used as a repository for all documents at our organization (not just publicly accessible documents). Current we must have 2 IR's, DSpace for public OA documents, and another IR for all other documents.

--Customize fields displayed in simple and detailed item view --Easier access to which DC fields are indexed for searching --Modular/readily customizable submission forms --Easier deposit of multiple bitstream items through UI

would like to add an "about" page for the university IR

Export selected item as RSS would be awesome and very useful

- making it possible to archive complex objects

i18n for submission fields of the table of results (eg browse and search)

- The data access layer could do with significant work, and implementation of some appropriate design patterns - Lightweight objects are needed to speed up certain processes involving lots of objects - some things (e.g. the Iterators in DSpace, need to actually be Iterators, rather than just look like it) - libraries of procedural functionality could be useful for common activities, and that this library be easily extensible. For example, obtaining metadata fields from configuration could be done inside one function which understands how to ask for the config option, and then to break down the metadata element supplied in the config into some object which can then be used to query the Item. - Standardisation of the data storage model. e.g. Triplestores for metadata all round, and a standardised access layer for this sort of metadata.

I'm not satisfied with the authorization scheme in 1.3.2. It is not robust enough to accomplish what I want and is not well documented requiring a lot of test scenarios to see what it really does. Authorization questions seem to be abundant on the listservs as is the request to be able to prevent users from seeing the list of records in a collection. It limits how the repository can be used unless a front-end authorization module is built. We don't have the resources to build that kind of front-end.

I dont think the documentation is the most important for customizing the code. Much more important are architetural changes that make it easier and so that we have to change less of the core code. APIs are important in any code, but still most of our changes are core-behauvior change. So APIs help but not that much. We need easy ways to plug in code...

That question is being answered by the technical staff involved in BDJur Project (they are also sending there answers).

Allow metadata standards to vary by collection. Each collection should have its own metadata standard, perhaps defaulting to a system-wide standard (Dublin core?). More granularity to access to communities, collections, and items. We would like to see access controlled such that even searches will return no results from areas where the user is not granted access. We would really like to revamp the UI, but we don't have the resources to make the changes we would have to make with each upgrade to DSpace.

Visibility options (have certain collections / collections be visible only to certain groups).

Better separation of interface and business logic would be welcom, and would make customization much easier. A service-oriented architecture would be even better

I'd be very happy if the remote handle server patch (1272731) made it into the DSpace core. It doesn't apply to v1.4 smoothly. We also want to create Faculty pages within DSpace which list all their publications along with a short Bio and headshot. This may be new development work by us.

Ability for more collaboration on workspace items.

I think most of the code that interfaces with the database could do with some refactoring or rearchitecting (especially the Browse code). Unfortunately the attempt to make the database code very abstract seems to have backfired and making a simple change like changing a field from an int to a long is very difficult. I'm not saying I would have done a better job. :)

- export functionalities for reference managers - multilingual help functions, introduction text, ... - Standard for use of author ID - Creation of OAI-sets with selection options (global and on collection level)

Migration of the content to XML within the system

Statistics reporting needs to be a lot more flexible and configurable

We are using the Tapir addon, but it seems like the development of this has stopped.

Full multi-lingual user interface. Move items between collections and collections between communities. Possibility for creating different types of collection templates

Use MySQL instead of PG!!! or as a choice, have a live cd type install like so many other things do, make it more turn key

Peer review of papers based on a voting system :-), maybe, I think that DSpace culd be used as a Conference Management System.

We would like to see support for video and audio. I would really like to see improvements to the Administrative interface. The ability to move items from one collection in a GUI.

Statistics count appears to include some non-relevant hits by bots. Ability to make a few individual items hidden from public view. Mapping documents from existing departmental websites into DSpace

Better UI control (Though Manakin is helping some of this)

Versioning, ability to handle complex objects.

Controlled vocabulary

oai java: the OAI-PMH usage, could be more easily configurable in DSpace

Core code changes

Database schema

27

23.3%

org.dspace.administer

10

8.6%

org.dspace.authorize

17

14.7%

org.dspace.browse

23

19.8%

org.dspace.checker

3

2.6%

org.dspace.content

25

21.6%

org.dspace.core

17

14.7%

org.dspace.eperson

10

8.6%

org.dspace.handle

13

11.2%

org.dspace.history

4

3.4%

org.dspace.license

9

7.8%

org.dspace.search

13

11.2%

org.dspace.storage.bitstore

7

6.0%

org.dspace.storage.rdbms

4

3.4%

org.dspace.workflow

13

11.2%

Total

116

168.1%

Core code changes - describe

Made a hacky local fix equivalent to the current extensible metadata support, can't remember others (sorry!)

Rewrite of ConfigurationManager Custom Authenticator Rewrite of DSIndexer and DsSearch

Making DSpace emit COinS. Haven't quite got there yet, but that's because I don't understand OpenURL well.

- IP based authentication - item display (as not configurable in 1.2.2)

I didn't even know this was an option. Documentation please....

added some additional tables to hold some additional user details

Added Delegate Admins functionality (from SF patch #1373613). Added UR Researcher Pages (which customize browse-by-author). Customized default "InstallItem" values, based on local configurations. Added custom authentication functionality. Customized Handle Server to notify admin if its unable to connect properly. Small amount of custom Workflow functionality.

see above

cleaning data for the indexes, treating foreign characters.

no time to explain. sorry

all in the course of developing prototype changes for the research projects i work on; this is not typical for a real site installation.

add new field do Dublin Core modify search options

translations an customization according our policies

Lots of custom requirements, with no good hooks in DSpace to add these requirements without cusomtizing the core code

org.dspace.search and org.dspace.browse: for CJK search. Database schema and org.dspace.eperson: I want add "eperson status" column.

Database schema to hold certain events for statistics. Change only involved creation of new tables Search to make Harvest.java accept an array of collections to support custom sets (oai classes also needed to be changed)

No

We've made changes to org.dspace.app.oai (not covered by the list above), to DSpaceRecordFactory.java. We needed the ability to customize the SetSpec/SetName value for OAI-export.

org.dspace.app - general webui changes

database schema: added tables for RDF support browse: added reversed item results content: embargo support functions

To make General Counsel happy

Created two new edu.cornell.* java packages under src and the new quick-submit directory under jsp. Changed changed the default.license, the dspace-web.xml (to add the new servlet) and some code in the MyDspace area (to add the new quick submit button). Added new field to Item schema and changed dspace/src/org/dspace/content/Item.Java; dspace/src/org/dspace/app/webui/servlet/handleServlet.Java; dspace/src/org/dspace/workflow/WorkflowManager.Java; dspace/config/emails/submit_metadata

I am not the developer. Therefore do not know exactly what code is touched. Main change is ip-check before allowing access to bitstreams from the UI of through a direct URL to the bitstream.

*disabled handle-system: local url everywhere now (one line code change) *DCDate.java: translated names of the months in Dutch (the archive is in Dutch only)

We are in the process of making changes, not sure which packages need change yet.

extra database schema's for LDAP login and bitstreams sequence. Administer and authorize also for login purposes. Workflow for semi automatic extern input

- Database Schema: to add our own database tables - Browse - implement Browse patch - Content - modifications to access rights for some constructors, addition of more methods for accessing Item data, creating a lightweight option for ItemIterators. - core - addition of further tools for Plugins; in this case a PluginException class, and a set of interfaces for servlets that might require pre-processing plugins.

to reflect metadata schema implemented

All of the modifications listed in the questions are code modifications- changing the Java servlets and classes that make up the DSpace application logic. I think they are trying to get a sense of how people are modifying the code so that they know which added features would be best to incorporate in a future standard release. Thus far we have not modified any of the listed code files so that upgrading to future releases will not involve merging existing modified code with the new standard code. All of our changes were done to text and XML descriptor files, which *should* be unaffected by an upgrade.

- Database Schema For the Request Item e Statistics Add-ons - org.dspace.content - DCDate (tranlsating the months that are hardcoded) - org.dspace.core - Configuration Manager - Constants (new custom permission for statistics Add-on) - org.dspace.eperson - Subscribe (some tranlstions of hardcoded text and others) - org.dspace.workflow - WorkflowManager (send email to co-authors)

The authorization system is not very flexible. We need authorizations for collection owners that are possible only for system wide administrators. We need Lucene to bring the documents in date order. We needed to change the handle.net url as it became a paid service. Etc etc

That question is being answered by the technical staff involved in BDJur Project (they are also sending there answers).

i18n patch changed the db schema, probably something else, too.

Browse.java, remove advisor from itemsbyauthor browsing, because it doesn't make intuitive sense for theses (especially if someone is a thesis author for one record and a thesis advisor for another record).

Patch files available upon request.

I needed to fix v1.4 to work with Oracle. Thankfully a contributer has now put Oracle fixes into CVS, so when v1.4.1 comes out I won't have to reapply my local patches.

Up to this point, all changes have been for Add-Ons.

I'm not sure which packages we had to modify.

Database schema - Create old style ITEMSBYXXX table, sequence and index for browsing. Created 4 more indexes on METADATAVALUE table on TEXT_VALUE, LOWER(TEXT_VALUE), (METADATA_FIELD_ID,TEXT_VALUE) and (METADATA_FIELD_ID,LOWER(TEXT_VALUE). Created a bunch of tables, sequences and indexes for other customizations. org.dspace.browse - added code to implement old style ITEMSBYXXX and new browse by any metadata field functionality. org.dspace.content - fixed ItemComparator to include schema in comparison. Added code to ensure statements and resultsets are closed. org.dspace.core - added rollback and close methods to Context. Added check for null to Utils.addEntities. org.dspace.history - Added code to ensure statements and resultsets are closed. org.dspace.search - Added code to implement hit highlighting org.dspace.storage.bitstore - cast file.length() to (int) when setting column "size_bytes" so works with Oracle org.dspace.storage.rdbms - added "continue;" statement to jdbctype == Types.BIGINT section of DatabaseManager.execute() and added some simple changes to make sure resultsets and statements are closed properly. Also got rid of unnecessary TableRowIterator.setStatement() method. A few of the above modifications have been submitted as patches.

See previous page

Database schema Added the tables institution, grouprule and group2rule to make it possible to assign a faculty, department etc to a group. We have added an attribute public_read in the workspaceitem and workflowitem table. org.dspace.administer We have extended RegistryLoader to load the institution hierarchy at fresh_install. org.dspace.authorize Added a new class GroupRule to make it possible to assign a faculty, department etc to a group. org.dspace.eperson Added some new classes (BIBSYSAdgangskontroll and Institution) Done some minor changes in Group, Eperson org.dspace.workflow We have done some minor changes to give the user the ability to choose the when and if the document should be public available.

As above, modified for file encryption

SMTP authetication for 1.3.1

to get the author's email address

Database too tightly coupled to postgres

see earlier list of modifications

* input-forms lack of support for checkboxes and radioboxes * modifications in relation to "skip file upload" patch

User interface

Style sheet

73

62.9%

"Layout" JSPs (header-default.jsp, footer-default.jsp)

81

69.8%

Other JSPs

61

52.6%

Servlets

35

30.2%

dspace-web.xml

28

24.1%

JSP tags

29

25.0%

Total

116

264.7%

Third-party customizations

Manakin

10

8.6%

SRW/U

13

11.2%

TAPIR (for e-theses)

6

5.2%

Lightweight Network Interface

5

4.3%

Other(s) -- please specify

10

8.6%

Total

116

37.9%

Other(s) -- please specify

I haven't installed any of these. They get out of date too quickly.

Configurable Submission, UR Researcher Pages, Authorization System: Delegate Admins patch

collection/community XML loader

Plan to use Manakin once it is stable

Browse patch

I don't know if it is included in the last release, but if it isn't I would definitely like to see the statistics add-on developed by Univ of Minho: http://mailman.mit.edu/pipermail/dspace-general/2006-May/000952.html

researcher pages

Researcher Pages, Download Counter

Researcher Pages

Remote Handle Patch 1272731

Handles

Yes, and I will continue to use it

70

60.3%

Yes, but I would prefer to use another scheme

13

11.2%

No

33

28.4%

Total

116

100.0%

Most important feature

Support for versioning of content

18

15.8%

Improved modularity

19

16.7%

More easily customized user interface

20

17.5%

Better support for "complex" objects (items containing multiple files)

13

11.4%

Better rich media support (e.g. audio, video)

5

4.4%

Better support for heterogenous/complex metadata

12

10.5%

Support for more complex workflows

3

2.6%

A better administrative UI

12

10.5%

Other (please specify)

12

10.5%

Total

114

100.0%

Other (please specify)

More specific documentation

support I18N

better interoperability with Library Management System

Safety and control of data and information

Recognition and validating formats of stored bitstreams (p.e. by integrating JHove into DSpace).

Better Localization

item RSS feeds

better authorisation mechanism, administration of communities, subcommunities, collections

Better scalability

Better statistics

full multi-lingual support

MySQL

Second most important feature

Support for versioning of content

8

7.0%

Improved modularity

15

13.2%

More easily customized user interface

25

21.9%

Better support for "complex" objects (items containing multiple files)

17

14.9%

Better rich media support (e.g. audio, video)

4

3.5%

Better support for heterogenous/complex metadata

9

7.9%

Support for more complex workflows

10

8.8%

A better administrative UI

16

14.0%

Other (please specify)

10

8.8%

Total

114

100.0%

Other (please specify)

Somethong like Youtube functionalities

Finer Access Control facilities

More powerful statistics

multilingualism support

better policy support (user who has access to admin UI can do anything, but we want to restrict that)

an easier way to decipher error messages generated by java

Better Roles/Permissions

better import / export tools

A more robust authorization scheme, including the ability to 'hide' collections

Improved architecture

Main problems

Very good

Good

Neutral

Poor

Very poor

Not applicable

Total

Installation procedure

21

18.4%

53

46.5%

23

20.2%

6

5.3%

0

0.0%

11

9.6%

114

100.0%

End-user documentation

4

3.5%

46

40.4%

38

33.3%

19

16.7%

3

2.6%

4

3.5%

114

100.0%

Developer documentation

5

4.4%

25

21.9%

47

41.2%

18

15.8%

2

1.8%

17

14.9%

114

100.0%

Ease of customization

0

0.0%

31

27.2%

49

43.0%

23

20.2%

7

6.1%

4

3.5%

114

100.0%

Ease of upgrading

2

1.8%

29

25.4%

37

32.5%

18

15.8%

6

5.3%

22

19.3%

114

100.0%

Usefulness of data model (communties/collections/items/bundles/bitstreams)

16

14.0%

52

45.6%

31

27.2%

10

8.8%

0

0.0%

5

4.4%

114

100.0%

Community tools (Wiki, mailing lists, SourceForge trackers and CVS)

21

18.4%

55

48.2%

27

23.7%

3

2.6%

0

0.0%

8

7.0%

114

100.0%

Ability to get involved in and/or influence development of the software

17

14.9%

47

41.2%

29

25.4%

3

2.6%

0

0.0%

18

15.8%

114

100.0%

Other issues/wishes

Packaging support still needs work - it's still not simple to ensure that you can get out exactly what you put in.

Administration eperson GUI needs major overhaul. Policies and Workflow administration gui on Item buggy and creates unwanted groups, blows away privious groups in policy when entering GUI. Submission Workflow admin doesn't work with custom groups. Browse system is too complex, needs major overhaul and replacement by Lucene Term Browsing.

The DSpace technology stack is so tall and complicated that diagnosing bugs and performance problems is utterly beyond me. I don't know what can be done about this, but I hope something can!

- the metadata/data-model is not concise enough - automatic extraction of inherent metadata (bitstreams) would be usefull - in need of better internationalization especially of metadata (both of content and structural) and internationalized searching and browsing - long term preservation - better addon mechanism - support of streaming data - enable peer reviewing processes - interface to a plagiarism tool - enhancement of MyDSpace, managing (annoting and so on) of DSpace resources

I think some of the customization is currently "under the hood" and the code needs to be strengthen in such a way that the customization can be done at the User Interface level. Some of the Dspace.cfg lines should be able to be made "on-the-fly" and some of the logon/authentication pieces need to much code attention to implement. (Okay, okay, my time is stretch to keep up with the complexities of Dspace). I realize that some of the limitations may be due to the software running on Tomcat and Java and not on some native C code program. But this should be no hurdle for future rapid development. I think that the reporting and ways of pulling of reports is cryptic or non-existant. I would be great to be able to create reports based on certain dublin core criteria at the user level. The biggest problem is the failover architecture should you have a hardware failure. Being depended on two parts: Postgres data and then an assetstore makes life treacherous. There should be a way to incorporate the database into the assetstore in the event of a failure, and not being nervous that your Postgres may not restore correctly. (I"ve yet to get a Postgres restore to work in testing--and I'm running production by the seat of my pants!) I envision that somewhere in the assetstore all of the dublin core elements (plus community/collection) are store in a file. Then should a failure happen, running some programs from the dsrun is able to read the assestore and write a NEW file to a new install Postgres data object.

1. I would like to customize the header and footer for each community and collection. I might be able to do that now, but I can't find it in the documentation. Sorry to harp on documentation so much but I've been struggling. Thanks for this survey, it's nice to send in my two cents.

occasional error messages in the tomcat logs concerning database activity that seem not to have a effect to the user experience but probably to the through put. Also browsing of large dataset seems not fast, hence I wonder about scalability of dspace for extremely large datasets, say 10000 communities/collections and millions of data items

Difficulty in establishing relationships between items (or bitstreams) in DSpace. Little support for custom "bundles" of bitstreams. Both of these may fall more into the "complex objects" realm. Heavy reliance on database for relationship between a document and its metadata. This creates the potential that if the database becomes corrupted (and was not backed up properly), you may lose knowledge of what metadata went with which item, and even which file(s) were associated with a single item. Wouldn't it be "safer" in terms of digital preservation to utilize METS packaging (or similar) to more closely associate metadata and files into item-level "packages" (and therefore not rely entirely on the database for this relationship)?

The access control ("resource policy") system needs to be chucked out and redone. History system is useless (but I'm working on that) Desperately need some form of AIPs so the asset store records object (Item, Coll, Comm) structure as a backup to the RDBMS (I'm working on that too) Relationships of bitstreams within an Item need to be expressed explicitly, see BitstreamRelationships wiki page for proposals. It is hard to share extensions and modifications, and keep them isolated to transfer from one version to the next. Need something like the AddOn proposal. Database should contain a marker for the version of DSpace to which its schema conforms. EVERY schema change (even minor ones checked into CVS between versions) must have a unique tag, probably 3 or 4-place version number. This will improve the upgrade procedure and help automate it. Add framework or at least much better documetation on backups for a DSpace and recovery procedures.

I'd like to see implemented more social functionalities like commenting, users with photos, rss, versioning, CMS approach to edition by admin using web interface, embed of vídeos and audio, suggest a friend link, batch upload using web interface, search that shows thumbnails when are images or videos, more stats, ratings.

Access control facilites - The ability to restrict and allow access to communities/collections/Items/bitstreams is not fine enough, and makes it difficult to manage resources where the rights are held by another party. This is an important barrier to the dSpace IR being taken up outside the university community, and makes more varied use within the university community difficult.

I think the underlying architecture of DSpace does what its supposed to do and to answer some of the customisation issues then tools like Mannakin are the way to deliver a customised project. However once you start customising DSpace and you have project funding at the beginning to do all this work, staff move on, upgrading becomes the biggest issue for sustainability in University environments. One area I'd like to see more work is on a simple interface for the Personal REsearcher pages thats where we could get lots of buy in from the Faculty staff.

The issues the architecture review will be looking at seem to be comprehensive. "Smaller" features specific to an installation are generally simpler to handle in-house and provided as a patch.

It is very good open source software. Country like India it is heavily downloading now. The Importancne of Open Source software has taken shape in the developing courntries like India.

Versioning and linking • In general: metadata and bitstreams need version control. • Changes to the metadata should preserve the old situation • Replacements of bitstreams should preserve the old bitstreams. • Using the admin module previous versions of metadata or bitstreams should be accessible • It should be possible to link items to each other easily. • Linking items can be seen as 'versioning' • Linking items can also be seen as natural evolution of items where the history of an item can be shown. Think of this in the way as "this item was originally based on item xxx. • Linking items can also be seen as citations pointing to other digital items. • Linked items must be presented nicely from the User Interface and through the Admin module. Relation with other repositories Facilities must be very easy to transport collections and items between repositories. It must be possible and easy to add additional identifiers to an item. Currently the handle-system is used, but likewise the item could be a copy of another digital item in another repository and than the original identifier must be availabe. This could be e.g. a DOI. Import / Export possibilities o export everything o export a collectionexport an item o export items changes since a certain point in time o import item and 'overwrite' existing item o import item and create new version of an item o import items in a new community/collection structure. o Of course again on a item, collection, timebased matter. Possibility for uploading compound documents (different hierarchial levels) Compound documents like websites where internal links are on different levels are impossible to present in the current Dspace. We solved this problem by zipping this kind of files during the upload phase and afterward unzipping these files for presentation-purposes. This is not the best solution, because you do not want to make submitting files any harder for the submitter by asking them to zip the files they want to submit. Moreover, for digital preservation purposes you do not want to archive zip-files instead of the separate files that are part of the compound document.

Many parts of the DSpace software work well, and we are very happy for the possibility to use DSpace! For the future, I believe that integration/compability (at one level or another) with more sofisticated e-publishing features will be required. I think that the DPubS initiative from Cornell and others are very interesting, and that the DSpace community should be contributing in that development. This could mean workflow support for peer review and editing process, some level of DRM for e-journals and e-books, perhaps server-side conversion from XML-formats to pdf:s etc.

Better communication (positive and negative) with patch developers. I submitted a patch but never heard back even if it meant telling me why my patch wasn't accepted.

A lot of the source code is very fragile and not well-tested in a normal user environment.

- better policy support (user who has access to admin UI can do anything, but we want to restrict that, so one "admin" can do one thing, and another can do some other things) - On the "Communities and collections" page, every collection is show. I would like to hide collections where users don't have access to.

Biggest problem is scalability. I have had lot of Tomcat/Java problems with memory leaks. I spent alot of time fine-tuning my Tomcat to get it to work correctly, and then when I installed a new version, I immediately started having memory problems. Also I have had a lot of probelms with media-filter. Disappearing icons and indexing not working properly.

We have submitted a list of requirements directly to Robert Tansley on october 16th.

possibility for private collections: with items that do not appear in search results for "guest" users

I think DSpace is ver good. Thank you and my hat is off to the core team that has put so much work and effort in DSpace! Has anyone considered implementing a retention schedule to DSpace. We currently have 2 IR's. One is DSpace for public (OA) documents. Our other "IR" is an non-open source software for records managment. A major reason that we maintain 2 IR's is that DSpace does not have retention management for documents.

"DSpace" is used to refer to two different entities: the software product and the original service at MIT. We've had to comb through the product and replace many instances of the latter usage with the name of our own service. I've been wanting to find time to add the concept of a "short name" which would be used wherever a reference to the service is intended, so that a single change in dspace.cfg would take care of them all. That is: dspace.name = "The wonderful HooHah Repository" dspace.name.short = "HooHah"

--Better mechanism for ingesting multiple bitstream items through submission interface --Groups/E-people/Authorization documentation needs improvement. There needs to be clearer documentation of how that part of the system meshes with community and item permissions.

overall, the installation and upgrade processes require too many steps.

Customization is a mess. Something needs to be done for it. Data model: need virtual collection via search queries and better community / item management systems. Eg. Item mapping, item deletion, collection repositioning etc.

It would be better to confine configurations (eg dspace.cgf) to one single place (now it can be done both at the source level and / or at the installation level). There is no i18n support for emails.

- Interfaces everywhere - Better divides between application layers

tools for language customization of indexing, etc.

The delegation of administrators to communities and collections does not seem to work in our instance of DSpace. The advanced item tool does not properly propagate new permissions. The administrative UI is not working well.

An ability to radically change the submission process for end-users woudl be nice. Too many pages discourages self-submitters. An ability to refine search results and to browse/page between items found in a search would be nice.

The product is designed heavily around its original intent as an institutional repository storing academic-related material. It is awkward to use off-the-shelf for an archive, as we are trying to do. If I had more support resources, I would do more with the authorization scheme, the labeling of metadata fields, and customization of the user interface screens. But the whole reason we're using DSPace is because it's free and we'll just have to make do with what we get. One frustration I do have is not being able to see 1.4 (couldn't access the 1.4 version that was mentioned in the listserv), or having more detailed descriptions of what's new or changed in terms of functionality. The developer community is rightly concerned with making the product more sound and robust from a software engineering perspective, but PLEASE work on getting someone to describe the new or changed functionality from non-techie point of view. A clear-cut description in the WIKI about the advantages of moving to 1.4 would be great.

Needed: Zipped files media filter

1. The administrative interface is very difficult to use. It isn't clear how groups, permissions, collections, and items relate. 2. It is very difficult to do much customization to the UI. There are those high in our ranks at our university library who would really like to see the UI revamped. We have pushed back on a technical standpoint because extensive UI changes require extensive resources for each upgrade. With limited resources we feel it is more important to keep up on the versions than to modify the UI, but it would be nice to do both. I have investigated Manakin, but have not had the time to implement it yet, but it looks very promising. A good CSS schema would help make UI changes easier. 3. It would be very helpful if there were a way to allow others (collection admins at least) to have the ability to at least add and possibly remove bitstreams to/from an existing item. For our current use adding bistreams to an existing item is much more important and needed than removing a bitstream.

Bundles. They just don't make sense, to me at least. They don't show up visually different. They only really serve to confuse the issue, as I can't see anyway to control which bitstreams go in which bundle. It wouldn't bother me so much if everything was in one bundle, but sometimes there are multiple bundles, and other times there is only one. The only real useful aspect I could project for bundles is if you were archiving a website and use the bundles to lump all the css, images, and original html into one nice chunk. However, there would need to be a way to access this as part of the UI. The one "feature" that really needs to be added is a link to the Admin pages on the default navbar (that only shows up if you are an admin, of course).

If you modularize the code, it would be *much* easier to integrate DSpace with other services, or to add our own services. The UI is too hooked into the business logic and the backend services. Fedora got this right. There seems to be a resource leak in the database layer that needs attention - we need to restart at least daily.

I'd like to see see easier ways to customize the submission process, and perhaps this functionality is provided by Tim Donohue's CSS patch. Closely related to this would be easier ways to incorporate our humble modifications into new DSpace releases. Right now, it takes way too much time to do this.

Browse system and database code could do with a rewrite.

Assigning groups to users can be very time consuming. At one point you have to choose the users how should have access to a given group. However this is probably not a trivial problem to solve. It should be possible for an administrator to add or remove metadata in the submission. And it should be easier to make custom submission forms. The administration gui is at times complex, and could be modified.

Full multi-lingual user interface. Move items between collections and collections between communities. Possibility for creating different types of collection templates

The simpliciity of the work flow works well; a linear progression. I would like the assets to be stored not as a long string, but as they are, so picture1.jpg, is stored as picture1.jpg The way it is now is soooooo arcane and not an easy one to create a good back up policy around. Whihc makes me think of antoher thing that is very important and not asked here, and that is, a very good and effective way to mamage backups and resotring backups into a new instance of dspace this is very difficult to understand and is almost a stopper in getting dspace implemented

Ability to batch restrict the visibility of files within an Item using some characteristics, e.g. file type.. Media streaming, e.g. audio books. Info about the times that an article has been cited by peers. Discussion phorum of content. Great job guys!!!!!!

I'd like to see improvements to the adminstrative interface... The ability to browse by types would be nive too (ability to browse all theses, images, etc.) Easier custiomization owuld be nice as well.