A page for notes and thoughts from DSUG Bergen 2006 - http://dsug2006.uib.no/^{Image Removed}

If we all use the tag 'dspacebergen2006' for our photos on flickr, and links on del.icio.us (and so on, please add others), we'll have a convenient source of photos and web resources related to this user group meeting.

Presentations

Presentations will be available on the conference website shortly.

...

• Content type is entered in the keywords
• No particular structure is imposed (Cambridge)
• Each community can structure on their own needs
• By research areas
• By file or document type
• By time
• By the way the university is structured; departments - – though some may be closed so those documents become legacied and/ or placed in other departments.
• Decentralized, by faculty structure of the university (Cambridge - – most likely decision)
• Originally organized by units within the university (Edinburgh), but lists are large without many entries; did not reflect the whole university. Interdisciplinary groups did not fit into the traditional academic structure; set up separate communities for them. Can choose to submit single items into several collections.
• Authors can select one or more collections for their submissions (MINHO); can appear in the collection of the library as well as the community. Advise authors to limit levels of hierarchy.
• Does this matter with Search capability? perhaps this is a theoretical discussion but not really critical
• How to structure the e-thesis for harvest? Separate collection for theses and student reports.

How deep can our hierarchies be?

Naming conventions - – best practice

Multilingual problems and solutions

...

Submission and Workflow B.O.F

(1) Need for more information to enter and store for several fields

Many bibliographic systems, like Aleph, have resolutions for this and call it subfields.

...

Example (2) is the author-field where there is a need to store also email address and some unique number (Digital Author Identiefier). This unique Author ID is needed to make lists of works from the same author easily, to generate lists of author works made in multiple universities and eg to identify that an author has published with different names (before and after marriage p.e) but in fact is the same person. Furthermore the option is required to call external routines to show a list of authors (like from SAP or from a nation-wide author-thesaurus as available in the Netherlands at Pica). The University of Leuven (Lieven Droogmans) demonstrated a possible solution for what is required on authors.

(2) Need for specification of input-forms.xml on document-type rather than collection or community.

Although the current collection or community level is very nice and a big improvement, many institutions store multiple document types in a single collection. And each document type requires a different set of metadata fields to maintain. Now institutions create workarounds to organize collections by document-type. Specification at document-type level therefore would be needed.

(3) Possibility to move items to other collections

Possibility to move an item to another collection during the submission process. This to correct mistakes during submission. Now that is impossible and the author has to re-enter all data

Possibility to move an item to another collection when finalized in dspace. This is needed and handsome when eg. re-organizing collections.

(4) Possibility to upload items directly into multiple collections

Would be nice during submission to directly be able to specify multiple collections. Currently this must be done afterwards, after submission, by administrative people. One of the examples was also 'automapper' (not in the standard dspace), but manually during submission are needed as well.

(5) Store a URL to a bitstream rather than the bitstream itself

Is handsome when the bitstreams are huge (video streams) or when the bitstreams are available elsewhere in another repository or at a commercial publisher.

(6) Propose example values and/or default values in input-forms.xml

Examples given during data-entry greatly clarify how users should enter fields during submission.

Proposing defaults would greatly reduce the amount of work for a user during submission while leaving the option open to deviate from the default.

(7) Possibility for hiding bitstreams and relating bitstreams to each other.

example (1)

Uploading a word document which must be hidden in the UI and uploading (or generating) the related pdf-file which must be shown.

example (2)

Replacing a bitstream in dspace because of eg. format upgrade, like a better version of pdf, or because the author deliveres an improved version of the bitstream. The newer bitstream must replace the existing bitstream but the previous bitstream should remain available as previous version in the archive.

Problems with input-forms.xml

Not possible to enter eg Norwegian strings in input-forms.xml. Presumably this should be an an installation-problem or setup problem but nobody knew at the moment. Suggest to ask it as q question /problem in the dspace-tech mailinglist ?!

...

AddOn and Patch writing B.O.F

Reasons for customisations / extensions /addons

• interop to particular local services
• small presentational changes (usability or branding related, look and feel with other local sites)
• more systematic presentation-layer changes
• functionality that is outside scope of the core DSpace

One common problems is managing JSP changes - particularly tricky. Probably will NOT be in the scope of an addon mech (not in the sense of merging different JSPs anyway!). Perhaps Manakin (XSL/Cocoon presentation layer framework) will help with this (??)

Current customisation code management practices

• Use of patches - but head can change in the meantime so requires maintenance
• Tapir initially used a different code tree but now developed using patches
• In some project for minor changes a record is kept and the changes reapplied to later versions of the head

The Addon mechanism

• to ease the installation of additional components
• ideally would be some kind of runtime plugin, but due to the current state of affairs, the idea is simply to be able to manage the addition of components at build time (as the DSpace installation process is build-based in any case).
• details are in Richard Jones' presentation, but the general idea is to put addon code into an addon component template, and then run various ant targets to install this together with the core DSpace code
• we are getting to a workable basic soln for an addon mechanism, but this needs refinement
• a working group on this problem has been suggested - needs involvement from more than just Richard J, to work on
  • addon mech itself (XSLT skills for config merging esp desirable)
  • reference implementation
• the wider developer community can help by refactoring existing features to use the addon mech and also the plugin manager when appropriate
• work is also needed on making the addon mech and the plugin manager work together well
• work on the DSpace config system generally may help with that

Other tools and addon architectures

• OSGi (Open Services Gateway Initative) - swiss army knife of componentised Java applications. Standarised way to define Java functionality and add/swap implementations at runtime. Bundles expose interfaces/abstractions and require others. Big but complex. OSGi link another OSGi link

...

• Also - not discussed but may be relevant -
  • Java Plugin Framework - http://jpf.sourceforge.net/^{Image Removed}
  • Java services - http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider

Road map for component/extension management

• Short term
  • move to a workable system for component management (i.e. addon mechanism)
  • move to coding and building more modularly
  • move to a compartimentalized DSpace
    • use a minimal DSpace core ?
• Long term
  • move to a more standard and/or powerful extension management system

...

• It might be good if the installation documents (as well as the application interface) was translated into different languages
• A pre-install check tool (like ./configure perhaps) included to check for pre-requisites
• A post-install checker to ensure the application is healthy
• Possibly OS specific packages (e.g. an RH RPM)
• A specific install FAQ on the wiki
• Instructions on what to do if the FAQ does not answer the question (e.g. email dspace-tech)
• Support for other DBs (e.g. mysql)
• A tool to help edit dspace.cfg and input-forms.xml (maybe in the DSpace admin interface)
• Simplification of the stylesheet to allow for easier customisation
• A document with a 'tour of DSpace' for new users experimenting with it
• A tool to check the DC registry against the input-forms so that internal server errors are not thrown when you update input-forms but forget the DB registry
• install_configs is confusing - which config files do you edit (dspace-src|dspace-src/config or dspace/config or the templates?) and when do you run install_configs

...

The group consisted of some who have implemented web services around DSpace, some who are going to soon, and many more who were interested to learn about the issues and opportunities.

Standards vs direct exposure

The issue here is to consider the pros and cons between web services that conform to open standards (WebDAV, SRU, OAI) and those that expose the DSpace logic directly (e.g. Generate WSDL directly from DSpace application classes). There are a number of differentiators: -

...

This is not particularly a question of SOAP vs REST - the LNI is a standards base, high level service that supports both.

Packaging

Packaging is seen as a key aspect of web service access to DSpace, and the package manager plugin that allows support for arbitrary packaging standards was welcomed as necessary.

AuthN AuthZ

Most current implementations have web services consumed by other server clients, and use prior knowledge of the consumer to establish trust (usually with certificates). No-one in the group has heard of a better solution.

...

There was an interest in whether Shibboleth could provide a good solution for AuthZ.

Transactions, Versioning

Many envisaged use cases would require long term transactions or locking (e.g. external agents to perform metadata analysis / file migration).

The automation of content modification highlights the requirement for simple linear versioning.

Purpose

The current uses of web services with DSpace is usually moving packages in or out, e.g. for federation. Future use cases envisaged included: -

• Web interface as a web service consumer
• Add-ons (e.g. preservation plugins) as web service clients in order to simplify management of installed code, and to spread processing power requirements better.
• Customized collection portals with non-standard indices and interfaces.

Finally

Members of the group are to add a description of their efforts on the NetworkInterfaces page on this wiki

...

After Peter Morgan and Julie Walkers' Federation and Community update on Friday 21 April, a 30 minute community discussion session was held, facilitated by Jim+Downing. The following are different people's notes on the discussion. If you have a notes from that session, please add them below.

1

• Work by Technical working group is going to be critical. Would like more information on how this group will function and their purpose. Response: No decision made yet; will not be the committer process.

  Panel

• Key role for working group is to establish where the platform should be heading, how that will happen. Steering committee will report on this.

...

• Short term and long term road maps, taken from the users - – what new features they want. Members vote which add-ons and features they value most.

...

My thoughts:
Notable absence of all members of the steering committee and the technical
working group. Is there a huge gap between these groups and the users? How
can groups responsible for "destiny" questions properly reflect on the needs
of the organization and its users?

– Amy Hale

2

• How do we provide feedback to the steering committee? This meeting is an opportunity to investigate the concepts

...