A page for notes and thoughts from DSUG Bergen 2006 - http://dsug2006.uib.no/

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.

Contents

Presentations

Presentations will be available on the conference website shortly.

Collection Structuring B.O.F

What logical structures are available to us?

How deep can our hierarchies be?

Naming conventions – best practice

Multilingual problems and solutions

Administrative policies

– Amy Hale

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 (1) is with citations where multiple fields are needed. This means that input-forms.xml should be enhanced to support 'subfields' for about any possible character field possible.

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 ?!

– Peter Ruijgrok

AddOn and Patch writing B.O.F

Reasons for customisations / extensions /addons

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

The Addon mechanism

Other tools and addon architectures

Road map for component/extension management

– Liam Lynch

Installation, Deployment and Configuration B.O.F

The group consisted of some who have installed DSpace dozens of times and have niggles with it, new users who have installed it once and had some problems, and users who had never installed it.

Here are some ideas that came out of the discussion:

– Stuart Lewis

Network APIs B.O.F.

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: -

*Interoperability The standards based approach is obviously far stronger, based on an object model that is shared, rather than DSpace's own.
*Comprehension Whilst standards are generally understood by more people, they may require more effort in learning to achieve a particular individual task. This is one of the reasons people have implemented WS services in the past.
*Stability Because standards based approaches are abstracted from DSpace's implementation, the web service APIs supported should remain more stable across changes to DSpace. Exposing code directly means the API changes with the code.
*Speed of implementation Writing support for a standard such as WebDAV is a major undertaking, whilst with tools such as Apache Axis, client and server stubs can be generated far more easily.

What is the minimum set of standard that would be needed to provide ws access to the DSpace core?

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.

Cross system authorization requires a shared model of rights and groups. LDAP is most usually used to store this information, and organizational hierarchy used as the model for groups (department, research group) and rights levels (PhD, Professor etc). Conversion is required to translate between DSpace permissions and this institutional model.

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: -

Finally

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

– JimDowning, 2006-04-21

Community Discussion Session

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

Three tiers:

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

– Richard Jones