Date: Thu, 28 Mar 2024 06:46:41 -0400 (EDT)
Message-ID: <1506871329.27424.1711622801234@lyrasis1-roc-mp1>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_27423_1805024374.1711622801234"
------=_Part_27423_1805024374.1711622801234
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
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 l=
inks on del.icio.us (and so on, please add others), we'll have a convenient=
source of photos and w=
eb resources related to this user group meeting.
Presentations
Presentations will be available on the conference website shortly.
Collection =
Structuring B.O.F
What logical structures are available to us?
- 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 =E2=80=93 though s=
ome may be closed so those documents become legacied and/ or placed in othe=
r departments.
- Decentralized, by faculty structure of the university (Cambridge =E2=80=
=93 most likely decision)
- Originally organized by units within the university (Edinburgh), but li=
sts are large without many entries; did not reflect the whole university. I=
nterdisciplinary groups did not fit into the traditional academic structure=
; set up separate communities for them. Can choose to submit single items i=
nto 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. Ad=
vise 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 thes=
es and student reports.
How deep can our hierarchies be?
Naming conventions =E2=80=93 best practice
Multilingual problems and solutions
- Collection names
- English vs. native language of authors/ institutions
- Researchers want to reach the world, so they use English names; would b=
e preferable to list in multiple languages
- Institutes and Faculties must be named in one language though text may =
be in two languages; preference for English for international adoption
Administrative policies
- At least one mandatory step: Library metadata review and validation (MI=
NHO)
- Reserved? Open? Peer reviewed material only? Community determined? (Is =
this worrisome? Will some things that should be preserved be lost?)
- Faculty don't want to deal with any of the administrative elements.
- What about one collection, rather than divided into smaller collections=
?
- Bergen: browse on titles, areas and dates
=E2=80=93 Amy Hale
Submission =
and Workflow B.O.F
Many bibliographic systems, like Aleph, have resolutions for this and ca=
ll it subfields.
Example (1) is with citations where multiple fields are needed. This mea=
ns 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 emai=
l 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 iden=
tify that an author has published with different names (before and after ma=
rriage p.e) but in fact is the same person. Furthermore the option is requi=
red to call external routines to show a list of authors (like from SAP or f=
rom a nation-wide author-thesaurus as available in the Netherlands at Pica)=
. The University of Leuven (Lieven Droogmans) demonstrated a possible solut=
ion for what is required on authors.
Although the current collection or community level is very nice and a bi=
g improvement, many institutions store multiple document types in a single =
collection. And each document type requires a different set of metadata fie=
lds to maintain. Now institutions create workarounds to organize collection=
s 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 dspa=
ce. 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 a=
dministrative 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 its=
elf
Is handsome when the bitstreams are huge (video streams) or when the bit=
streams are available elsewhere in another repository or at a commercial pu=
blisher.
(6) Propose example values and/or default values in i=
nput-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 du=
ring submission while leaving the option open to deviate from the default.<=
/p>
(7) Possibility for hiding bitstreams and rela=
ting 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 be=
tter 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.
Not possible to enter eg Norwegian strings in input-forms.xml. Presumabl=
y this should be an an installation-problem or setup problem but nobody kne=
w at the moment. Suggest to ask it as q question /problem in the dspace-tec=
h mailinglist ?!
=E2=80=93 Peter Ruijgrok
AddOn and Pa=
tch writing B.O.F
Reasons for customisations / extensions /addons
- interop to particular local services
- small presentational changes (usability or branding related, look and f=
eel 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. Proba=
bly 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 fra=
mework) will help with this (??)
Current customisation code management practices
- Use of patches - but head can change in the meantime so requires mainte=
nance
- Tapir initially used a different code tree but now developed using patc=
hes
- In some project for minor changes a record is kept and the changes reap=
plied to later versions of the head
The Addon mechanism<=
/h2>
- to ease the installation of additional components
- ideally would be some kind of runtime plugin, but due to the current st=
ate of affairs, the idea is simply to be able to manage the addition of com=
ponents 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 t=
argets to install this together with the core DSpace code
- we are getting to a workable basic soln for an addon mechanism, but thi=
s needs refinement
- a working group on this problem has been suggested - needs involvement =
from more than just Richard J, to work on=20
- 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 wor=
k together well
- work on the DSpace config system generally may help with that
- OSGi (Open Services Gateway Initative) - swiss army knife of componenti=
sed Java applications. Standarised way to define Java functionality and add=
/swap implementations at runtime. Bundles expose interfaces/abstractions an=
d require others. Big but complex. OSGi=
link another OSGi link=
- Maven - better build system than ant for straightforward/std projects, =
and great for dependency management of e.g. jar files providing underlying =
services/utilities. But would it be adaptable enough for, or help with, a c=
omplex/custom build like the addon mech?
- Also - not discussed but may be relevant -=20
Road map for component/extension management
- Short term=20
- move to a workable system for component management (i.e. addon mechanis=
m)
- move to coding and building more modularly
- move to a compartimentalized DSpace=20
- use a minimal DSpace core ?
- Long term=20
- move to a more standard and/or powerful extension management system
=E2=80=93 Liam Lynch
Installation, Deployment and Configuration B.O.F
The group consisted of some who have installed DSpace dozens of times an=
d have niggles with it, new users who have installed it once and had some p=
roblems, and users who had never installed it.
Here are some ideas that came out of the discussion:
- It might be good if the installation documents (as well as the applicat=
ion interface) was translated into different languages
- A pre-install check tool (like ./configure perhaps) included to check f=
or 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<=
/li>
- A tool to check the DC registry against the input-forms so that interna=
l server errors are not thrown when you update input-forms but forget the D=
B registry
- install_configs is confusing - which config files do you edit (dspace-s=
rc|dspace-src/config or dspace/config or the templates?) and when do you ru=
n install_configs
=E2=80=93 Stuart Lewis
Network APIs B.O.F.<=
/h1>
The group consisted of some who have implemented web services around DSp=
ace, 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 tha=
t conform to open standards (WebDAV, SRU, OAI) and those that expose the DS=
pace logic directly (e.g. Generate WSDL directly from DSpace application cl=
asses). There are a number of differentiators: -
*Interoperability The standards based approach is obvio=
usly far stronger, based on an object model that is shared, rather than DSp=
ace's own.
*Comprehension Whilst standards are generally understood =
by more people, they may require more effort in learning to achieve a parti=
cular individual task. This is one of the reasons people have implemented W=
S services in the past.
*Stability Because standards based approaches are abstrac=
ted from DSpace's implementation, the web service APIs supported should rem=
ain more stable across changes to DSpace. Exposing code directly means the =
API changes with the code.
*Speed of implementation Writing support for a standard s=
uch 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 a=
ccess to the DSpace core?
This is not particularly a question of SOAP vs REST - the LNI is a stand=
ards base, high level service that supports both.
Packaging
Packaging is seen as a key aspect of web service access to DSpace, and t=
he package manager plugin that allows support for arbitrary packaging stand=
ards 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 (usuall=
y with certificates). No-one in the group has heard of a better solution.=
p>
Cross system authorization requires a shared model of rights and groups.=
LDAP is most usually used to store this information, and organizational hi=
erarchy used as the model for groups (department, research group) and right=
s 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 solutio=
n 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 si=
mple 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 requi=
rements 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 Ne=
tworkInterfaces page on this wiki
=E2=80=93 JimDowning, 2006-04-21
After Peter Morgan and Julie Walkers' Federation and Community update on=
Friday 21 April, a 30 minute community discussion session was held, facili=
tated by Jim+Downing. The following are different people's notes on the dis=
cussion. 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 mor=
e information on how this group will function and their purpose. Response: =
No decision made yet; will not be the committer process.=20
- Key role for working group is to establish where the platform should be=
heading, how that will happen. Steering committee will report on this.
- What's the scope for members to give feedback to the steering committee=
? How can users interact with them?
- How should "we" make decisions for the community?
- Response: The steering committee will not present things it as a fait a=
ccomplis. Steering committee will solicit opinions on the wiki. Or respond =
to questions personally.
- Do members want a voting process?
- Can there be a questionnaire to identify the needs of the DSpace commun=
ity? (innovation, governance, etc.)
- What do the institutions want to commit to?
- Is there any thought to paid memberships? Subscription fees? Resources?=
Participation? Are there other kinds of subscription contributions? E.g. D=
eveloper time?
- Consensus is that their institutions would be willing to make a commitm=
ent to the DSpace community at some level.
- Possible Fees: 500-1000 euros per year (under a thousand euros). Person=
al or institutional memberships would allow for wider spread. Any fees need=
to reflect the affluence level of different countries, perhaps through mul=
tiple tiered memberships.
- Formal membership with low financial contribution would provide a reaso=
nable solution; useful for getting new functionality but getting formal pos=
ition in the decision making process.
- Sentiment that people want to have a "right" to speak.
- There are national users groups that are organizing and considering dir=
ection as well. e.g. Dutch users group is currently looking for a central p=
lace where all Dspace is harvested; how can they deliver the metadata to th=
e central repository?
- How do users get representatives on the technology working group or the=
steering committee.
- HP and MiT own the code. Shift to non-profit entity would transfer code=
to them; universities would need to sign over their code to the non-profit=
. Ownership to the code might be able to stay with the developer of the cod=
e with a license for use from the non-profit.
- How will technology working group be formed? What do the users want? Ca=
n they have a say in it?
- Lack of coherent communication between users and technical direction. (=
handling of metadata); needs to be a stronger dialogue.
- Would like to see a technology roadmap. (needs a commitment for effort =
on the technology)
- If Roadmap had a tasklist assigned to it; you could find volunteers who=
might agree to elements of the roadmap.
- Short term and long term road maps, taken from the users =E2=80=93 what=
new features they want. Members vote which add-ons and features they value=
most.
- Big move towards modularity, but there are many different needs and int=
erests; risk bloat of the core package.
- Committer group vs User driven decisions on modules. Pitfalls
- Will this take away from the users with a management committee running =
things?
- Innovation will be based on short term problems; long term preservation=
is an issue to be solved.
- Mission statement should include statement about preservation.
Three tiers:
- High level steering committee
- Technical working group (architecture and roadmap)
- Code community
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 nee=
ds
of the organization and its users?
=E2=80=93 Amy Hale
2
- How do we provide feedback to the steering committee? This meeting is a=
n opportunity to investigate the concepts
- Would a questionnaire to the DSpace community do define the needs of th=
e participants be a good idea?=20
- What sorts of needs? e.g. Innovation
- Federation Membership?=20
- Some kind of feedback or return would be necessary
- Financial membership is a reasonable option. Formal involvement in the =
decision making procedure would be desireable
- Financial commitment "not very high" - ~=3D 100s not 1000s of Euros
- Tiered subscription - costs dependent on economic environment
- What do you get out of a subscription based model?=20
- Dutch DSpace User Group has a central DSpace harvested, and defines tog=
ether what they do locally
- Legal issues:=20
- Ownership of the code could go to the resulting non-profit organisation=
- Could institutions own their own code, and licence to DSpace?
- The Technical Working Group:=20
- Communication between users and developers
- develop the "Road Map"
- There will be different local requirem,ents of the working group
- A subscription model may make it easier to define the Road Map
- Not yet known how it will be formed - the steering committee must advis=
e
- What about having short term road maps initially. How could features be=
requested to appear on it?
- It may be appropriate to vote on features and addons to be included bef=
ore each Feature Freeze for releases (The community reiterated its interest=
in the AddOn Mechanism)
- The idea of a community wide commitment to preservation was raised
=E2=80=93 Richard Jones
------=_Part_27423_1805024374.1711622801234--