From analice at dsi.uminho.pt  Wed Oct  1 04:49:45 2003
From: analice at dsi.uminho.pt (Ana Alice Baptista)
Date: Wed, 1 Oct 2003 09:49:45 +0100
Subject: [Dspace-general] User studies on DSpace
Message-ID: <34A0DF38-F3EC-11D7-9206-000393CBB65E@dsi.uminho.pt>

Dear all,

My name is Ana Baptista and I'm emailing you from Universidade do 
Minho, Portugal.
We are implementing DSpace here at Uminho with (what we believe) the 
first Portuguese version of DSpace. We are now feeding the system with 
Thesis and Dissertations from the whole university. We are also 
starting to involve communities and we have started with 6 of them 
which will make available other scientific documents such as articles 
and reports. We hope to open the doors to our repository by the end of 
Octoober.

We have some students willing to do research using DSpace. In 
particular one of them is interested in studying the users that are 
producers of scholarly resources stored in DSpace. With this in mind, I 
would like to ask you the following:

- Are you doing similar studies in your intitutions? It seems to me 
that, if there are, all these researchers could share experiences that 
would benefit all of them. In particular for us it would be very 
helpful to know similar studies in other cultural contexts.

- Do you know of any international organization willing to sponsor 
these kind of studies?

I'm looking forward to hearing from you.

Best regards,

Ana Baptista


From SGibbons at library.rochester.edu  Wed Oct  1 15:02:52 2003
From: SGibbons at library.rochester.edu (Susan Gibbons)
Date: Wed, 01 Oct 2003 15:02:52 -0400
Subject: [Dspace-general] User studies on DSpace
Message-ID: <sf7aec9f.090@library.rochester.edu>

Dear Ana:
 
At the University of Rochester in New York we just received a federally
funded grant to study how different disciplines work with grey
literature (tech reports, pre-prints, conference papers, etc.) and make
modifications to DSpace based on our findings.  I'd be glad to email you
a copy of the grant proposal, if you are interested.
 
We'd be glad to share anything we learn from our studies and hope you
will do the same with yours.
 
Best wishes,
 
Susan Gibbons
Director, Digital Library Initiatives
River Campus Libraries
University of Rochester
585-275-6320
sgibbons at library.rochester.edu

>>> Ana Alice Baptista <analice at dsi.uminho.pt> 10/01/03 04:49AM >>>
Dear all,

My name is Ana Baptista and I'm emailing you from Universidade do 
Minho, Portugal.
We are implementing DSpace here at Uminho with (what we believe) the 
first Portuguese version of DSpace. We are now feeding the system with

Thesis and Dissertations from the whole university. We are also 
starting to involve communities and we have started with 6 of them 
which will make available other scientific documents such as articles 
and reports. We hope to open the doors to our repository by the end of

Octoober.

We have some students willing to do research using DSpace. In 
particular one of them is interested in studying the users that are 
producers of scholarly resources stored in DSpace. With this in mind, I

would like to ask you the following:

- Are you doing similar studies in your intitutions? It seems to me 
that, if there are, all these researchers could share experiences that

would benefit all of them. In particular for us it would be very 
helpful to know similar studies in other cultural contexts.

- Do you know of any international organization willing to sponsor 
these kind of studies?

I'm looking forward to hearing from you.

Best regards,

Ana Baptista

_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu 
http://mailman.mit.edu/mailman/listinfo/dspace-general 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20031001/75a20f2b/attachment.htm

From tull.9 at osu.edu  Fri Oct  3 11:47:00 2003
From: tull.9 at osu.edu (Laura Tull)
Date: Fri, 03 Oct 2003 11:47:00 -0400
Subject: [Dspace-general] Improvements to Administrator's User  Interface
In-Reply-To: <5.2.1.1.2.20030930150051.02312980@po10.mit.edu>
Message-ID: <4.3.2.7.2.20031003113956.02f538c0@pop.service.ohio-state.edu>

Margret,

I'd like to see the ability to search for an item by title or author as 
well as handle.  I never know the handle when I go into the Admin mode and 
then I have to go back and search for the item to find it.

Can I assume there will be a help page for the Admin interface similar to 
the user's interface that will explain how to create and delete community, 
collection and set policies for them, etc.  It seems that I ran into some 
issues with the order in which you had to do things.



At 03:10 PM 9/30/2003 -0400, you wrote:
>Hello,
>
>One of the new features we are adding to the next version of DSpace is an 
>improved Administrator's User Interface.  I am going to be writing up the 
>feature definition for this, so please send me suggestions for improving 
>the admin. interface, your pet peeves, functions you would like to 
>add...etc.  This is your chance to have an impact on the tools you use.
>
>Margret
>
>Margret Branschofsky
>DSpace User Support Manager
>Digital Library Research Group
>Bldg. 14S-M24
>(617)253-1293
>margretb at mit.edu
>http://dspace.mit.edu
>_______________________________________________
>Dspace-general mailing list
>Dspace-general at mit.edu
>http://mailman.mit.edu/mailman/listinfo/dspace-general



***********************************
Laura Tull
Systems Librarian
Ohio State University Libraries
1858 Neil Avenue Mall
Columbus OH 43210-1286
Phone:  614-247-6459
Fax:  614-292-7859
Email:  tull.9 at osu.edu
*********************************** 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20031003/be5796cf/attachment.htm

From Ilene.Strongin-Garry at ichotelsgroup.com  Sat Oct  4 12:02:36 2003
From: Ilene.Strongin-Garry at ichotelsgroup.com (Strongin-Garry, Ilene (IHG))
Date: Sat, 4 Oct 2003 12:02:36 -0400 
Subject: [Dspace-general] RE: Dspace-general Digest, Vol 3, Issue 3
Message-ID: <4201FDFD444BC84190DEF632181EB38F2AB612@bhratlexg03.hiw.com>

I agree with this suggestion 100%%%%%%%

-----Original Message-----
From: dspace-general-request at mit.edu
[mailto:dspace-general-request at mit.edu]
Sent: Saturday, October 04, 2003 12:01 PM
To: dspace-general at mit.edu
Subject: Dspace-general Digest, Vol 3, Issue 3


Send Dspace-general mailing list submissions to
	dspace-general at mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.mit.edu/mailman/listinfo/dspace-general
or, via email, send a message with subject or body 'help' to
	dspace-general-request at mit.edu

You can reach the person managing the list at
	dspace-general-owner at mit.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dspace-general digest..."


Today's Topics:

   1. Re: Improvements to Administrator's User  Interface (Laura Tull)


----------------------------------------------------------------------

Date: Fri, 03 Oct 2003 11:47:00 -0400
From: Laura Tull <tull.9 at osu.edu>
To: Dspace-general at mit.edu
Subject: Re: [Dspace-general] Improvements to Administrator's User
Interface
Message-ID: <4.3.2.7.2.20031003113956.02f538c0 at pop.service.ohio-state.edu>
In-Reply-To: <5.2.1.1.2.20030930150051.02312980 at po10.mit.edu>
Content-Type: multipart/mixed;    
	boundary="------------InterScan_NT_MIME_Boundary"
MIME-Version: 1.0
Precedence: list
Message: 1


--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
 boundary="Boundary_(ID_IAsoXf5kt+RpkVObkweLng)"

--Boundary_(ID_IAsoXf5kt+RpkVObkweLng)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

Margret,

I'd like to see the ability to search for an item by title or author as 
well as handle.  I never know the handle when I go into the Admin mode and 
then I have to go back and search for the item to find it.

Can I assume there will be a help page for the Admin interface similar to 
the user's interface that will explain how to create and delete community, 
collection and set policies for them, etc.  It seems that I ran into some 
issues with the order in which you had to do things.



At 03:10 PM 9/30/2003 -0400, you wrote:
>Hello,
>
>One of the new features we are adding to the next version of DSpace is an 
>improved Administrator's User Interface.  I am going to be writing up the 
>feature definition for this, so please send me suggestions for improving 
>the admin. interface, your pet peeves, functions you would like to 
>add...etc.  This is your chance to have an impact on the tools you use.
>
>Margret
>
>Margret Branschofsky
>DSpace User Support Manager
>Digital Library Research Group
>Bldg. 14S-M24
>(617)253-1293
>margretb at mit.edu
>http://dspace.mit.edu
>_______________________________________________
>Dspace-general mailing list
>Dspace-general at mit.edu
>http://mailman.mit.edu/mailman/listinfo/dspace-general



***********************************
Laura Tull
Systems Librarian
Ohio State University Libraries
1858 Neil Avenue Mall
Columbus OH 43210-1286
Phone:  614-247-6459
Fax:  614-292-7859
Email:  tull.9 at osu.edu
*********************************** 

--Boundary_(ID_IAsoXf5kt+RpkVObkweLng)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html>
<font size=3>Margret,<br>
<br>
I'd like to see the ability to search for an item by title or author as
well as handle.&nbsp; I never know the handle when I go into the Admin
mode and then I have to go back and search for the item to find it.<br>
<br>
Can I assume there will be a help page for the Admin interface similar to
the user's interface that will explain how to create and delete
community, collection and set policies for them, etc.&nbsp; It seems that
I ran into some issues with the order in which you had to do
things.&nbsp; <br>
<br>
<br>
<br>
At 03:10 PM 9/30/2003 -0400, you wrote:<br>
<blockquote type=cite cite>Hello,<br>
<br>
One of the new features we are adding to the next version of DSpace is an
improved Administrator's User Interface.&nbsp; I am going to be writing
up the feature definition for this, so please send me suggestions for
improving the admin. interface, your pet peeves, functions you would like
to add...etc.&nbsp; This is your chance to have an impact on the tools
you use.<br>
<br>
Margret<br>
<br>
Margret Branschofsky<br>
DSpace User Support Manager<br>
Digital Library Research Group<br>
Bldg. 14S-M24<br>
(617)253-1293<br>
margretb at mit.edu<br>
<a href="http://dspace.mit.edu/" eudora="autourl">http://dspace.mit.edu</a>
<br>
_______________________________________________<br>
Dspace-general mailing list<br>
Dspace-general at mit.edu<br>
<a href="http://mailman.mit.edu/mailman/listinfo/dspace-general"
eudora="autourl">http://mailman.mit.edu/mailman/listinfo/dspace-general</a><
/font></blockquote><br>
<br>
<br>
<div>***********************************</div>
<div>Laura Tull</div>
<div>Systems Librarian</div>
<div>Ohio State University Libraries</div>
<div>1858 Neil Avenue Mall</div>
<div>Columbus OH 43210-1286</div>
<div>Phone:&nbsp; 614-247-6459</div>
<div>Fax:&nbsp; 614-292-7859</div>
<div>Email:&nbsp; tull.9 at osu.edu</div>
***********************************
</html>

--Boundary_(ID_IAsoXf5kt+RpkVObkweLng)--
------------------------------

_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general


End of Dspace-general Digest, Vol 3, Issue 3
********************************************

--------------InterScan_NT_MIME_Boundary--

From Rachel.Lee at ucpress.edu  Sat Oct  4 12:44:32 2003
From: Rachel.Lee at ucpress.edu (Rachel Lee)
Date: Sat,  4 Oct 2003 08:44:32 PST
Subject: [Dspace-general] automated response
Message-ID: <10310040844.AA00229@ucpress.edu>

I am away from the office until 14th October.  I will respond to your message when I return.  Urgent enquiries *only* should be addressed to rebekah.darksmith at ucpress.edu.

thank you.

From margretb at MIT.EDU  Tue Oct  7 10:02:48 2003
From: margretb at MIT.EDU (Margret Branschofsky)
Date: Tue, 07 Oct 2003 10:02:48 -0400
Subject: Fwd: Re: [Dspace-general] Improvements to Administrator's User
   Interface
Message-ID: <5.2.1.1.2.20031007100229.02140cb8@po10.mit.edu>


>Date: Tue, 07 Oct 2003 10:01:45 -0400
>To: Jewel Ward <jewelw at lanl.gov>
>From: Margret Branschofsky <margretb at mit.edu>
>Subject: Re: [Dspace-general] Improvements to Administrator's User  Interface
>
>Have you all seen the Administration User Interface Documentation which 
>comes with the system documentation?  If so, is this documentation not 
>adequate?  (http://dspace.org/technology/system-docs/admin-ui.html ).
>
>Margret
>
>At 03:37 PM 10/6/2003 -0600, Jewel Ward wrote:
>>At 11:47 AM 10/3/2003 -0400, you wrote:
>>
>>>Can I assume there will be a help page for the Admin interface similar 
>>>to the user's interface that will explain how to create and delete 
>>>community, collection and set policies for them, etc.  It seems that I 
>>>ran into some issues with the order in which you had to do things.
>>
>>Margret,
>>
>>I had the same problem.  I'll try to think of things that are more 
>>specific and send them to you.
>>
>>Regards,
>>
>>Jewel
>>
>>
>>
>>>***********************************
>>>Laura Tull
>>>Systems Librarian
>>>Ohio State University Libraries
>>>1858 Neil Avenue Mall
>>>Columbus OH 43210-1286
>>>Phone:  614-247-6459
>>>Fax:  614-292-7859
>>>Email:  tull.9 at osu.edu
>>>***********************************
>>>_______________________________________________
>>>Dspace-general mailing list
>>>Dspace-general at mit.edu
>>>http://mailman.mit.edu/mailman/listinfo/dspace-general
>>
>>--
>>Jewel H. Ward
>>Graduate Research Assistant, Post-master's
>>Los Alamos National Laboratory
>>Research Library
>>(505) 664-0368
>>jewelw at lanl.gov


From jqj at darkwing.uoregon.edu  Tue Oct  7 14:28:12 2003
From: jqj at darkwing.uoregon.edu (JQ Johnson)
Date: Tue, 7 Oct 2003 11:28:12 -0700
Subject: [Dspace-general] RE: Improvements to Administrator's User   Interface
In-Reply-To: <5.2.1.1.2.20031007100229.02140cb8@po10.mit.edu>
Message-ID: <MMENIDDNIPBIJLHLNFHBEEMKCLAA.jqj@darkwing.uoregon.edu>

A couple of suggestions, mixing minor UI changes with significant
implementation changes:

1/ the whole ePeople system needs to be rethought and made more modular.
At many institutions we want to tie into our central directory (LDAP,
radius, or whatever) and give all of and only our people ePerson accounts,
or at least to allow such people privileged access (perhaps what's
needed is the notion of named guests, or a set of system-wide roles such
as {guest,normal,communitycreator,superuser}).  We need an easy way to
associate LDAP-derived membership in departments with DSpace-specific
groups that give access to the corresponding communities.

Just looking at the current admin interface (/admin/edit-epeople), We need
better tools for searching the list of ePeople ("Browse ePeople" may work
for a few hundred ePeople, but not if you have 20,000) and modifying their
properties both individually and as groups.

We may need to more clearly separate system-level authorization from
system-level authentication.

2/ We need an easy way to delegate responsibilities for community
management to community-specific gatekeepers who could create
collections, add members to groups specific to that community, etc.

This implies that groups as presently implemented may be too broad.  I think
we need to have an access control mechanism that more directly ties into
communities and collections.  DSpace started this process with the
special-semantics groups like COLLECTION_3_WFSTEP_1.  But this should be
carried much further.  At a minimum, creation of a collection should
automatically create the corresponding COLLECTION_n_ADD and add it to the
ACL for the collection.  Probably such a new group should inherit some
membership from a community-level group.  If groups as presently
conceptualized continue, it should be possible to delegate ability to change
membership in a particular group -- a non-administrator gatekeeper for a
particular collection, for instance, should be able to modify the membership
of COLLECTION_n_* groups.

It's perhaps symptomatic of the problem that the admin documentation
contains language errors.  For instance, in
http://dspace.org/technology/system-docs/admin-ui.html we read that
"Permissions do not 'commute'" when the actual concept is that permissions
do not inherit or are not transitive.  But note that DEFAULT_*_* properties
do sort of inherit!

The "Communities/Collections" admin interface is quite usable as is for
small numbers of collections, but doesn't work well if you have 200
communities and 500 collections.

Creating a collection should automatically create a COLLECTION_n_ADD group
for it.

Probably lots of other changes to the collection creation/editing form would
be useful as well.  E.g. "Item template" seems ill thought out.

3/ items:  we desperately need a way for a site to customize the
submission process and change the metadata collected.  I don't think we
need to change the actual metadata schema; qDC is adequate.

4/ the admin interface for Items needs a better search facility.  I don't
want to have to think in terms of handles or internal IDs.

5/ Multiple versions of an item:  unless a better item versioning system can
be implemented soon, we need a way to allow unprivileged users to add
bitstreams to an existing record (and to record and display timestamps on a
per-bitstream basis).  This might be the owner modifying a record, or might
be people in some collection-specific group.

6/ Item authorizations in the current admin interface (Authorize->Manage An
Item's Policies) are completely obscure.  The notion of "Bundles" isn't
reified anywhere else in the user interface.  The fact that bundles have
numbers and not names is a symptom of the problem.

General observation:  for power users it might be better instead of writing
a bunch of custom UI code to simply expose the database more directly.  If I
could download a .csv file with the metadata for an item or the list of
members in a group, edit it using Excel or whatever, then upload the
resulting file, that would be a lot more flexible than the current approach.
Absent such a feature, I'm tempted to connect to my DSpace database directly
from Access or DBtools or some similar graphical SQL editor, but that is
high-risk.

JQ Johnson                      Office: 115F Knight Library
Academic Education Coordinator  mailto:jqj at darkwing.uoregon.edu
1299 University of Oregon       phone: 1-541-346-1746; -3485 fax
Eugene, OR  97403-1299          http://darkwing.uoregon.edu/~jqj/


From Ilene.Strongin-Garry at ichotelsgroup.com  Tue Oct  7 15:41:12 2003
From: Ilene.Strongin-Garry at ichotelsgroup.com (Strongin-Garry, Ilene (IHG))
Date: Tue, 7 Oct 2003 15:41:12 -0400 
Subject: [Dspace-general] RE: Dspace-general Digest, Vol 3, Issue 5
Message-ID: <4201FDFD444BC84190DEF632181EB38F2AB636@bhratlexg03.hiw.com>

Other enhancements I'd like to see include:

When submitting an item, you are asked to submit to a collection.  However,
once you choose the collection it cannot be changed without having to
re-enter the entire amount of metadata and files.  I would like to have the
option to correct my collection choice.

Secondly, it would be great to be able to add additional files to an item
once it's in DSpace.  I know you can edit metadata, but it would be great to
be able to add files in case something has been accidentally left off or
found later after an item has been submitted.

-----Original Message-----
From: dspace-general-request at mit.edu
[mailto:dspace-general-request at mit.edu]
Sent: Tuesday, October 07, 2003 12:01 PM
To: dspace-general at mit.edu
Subject: Dspace-general Digest, Vol 3, Issue 5


Send Dspace-general mailing list submissions to
	dspace-general at mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.mit.edu/mailman/listinfo/dspace-general
or, via email, send a message with subject or body 'help' to
	dspace-general-request at mit.edu

You can reach the person managing the list at
	dspace-general-owner at mit.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dspace-general digest..."


Today's Topics:

   1. Fwd: Re: [Dspace-general] Improvements to Administrator's User
         Interface (Margret Branschofsky)


----------------------------------------------------------------------

Date: Tue, 07 Oct 2003 10:02:48 -0400
From: Margret Branschofsky <margretb at MIT.EDU>
To: dspace-general at MIT.EDU
Subject: Fwd: Re: [Dspace-general] Improvements to Administrator's User
   Interface
Message-ID: <5.2.1.1.2.20031007100229.02140cb8 at po10.mit.edu>
Content-Type: text/plain; charset="us-ascii"; format=flowed
MIME-Version: 1.0
Precedence: list
Message: 1


>Date: Tue, 07 Oct 2003 10:01:45 -0400
>To: Jewel Ward <jewelw at lanl.gov>
>From: Margret Branschofsky <margretb at mit.edu>
>Subject: Re: [Dspace-general] Improvements to Administrator's User
Interface
>
>Have you all seen the Administration User Interface Documentation which 
>comes with the system documentation?  If so, is this documentation not 
>adequate?  (http://dspace.org/technology/system-docs/admin-ui.html ).
>
>Margret
>
>At 03:37 PM 10/6/2003 -0600, Jewel Ward wrote:
>>At 11:47 AM 10/3/2003 -0400, you wrote:
>>
>>>Can I assume there will be a help page for the Admin interface similar 
>>>to the user's interface that will explain how to create and delete 
>>>community, collection and set policies for them, etc.  It seems that I 
>>>ran into some issues with the order in which you had to do things.
>>
>>Margret,
>>
>>I had the same problem.  I'll try to think of things that are more 
>>specific and send them to you.
>>
>>Regards,
>>
>>Jewel
>>
>>
>>
>>>***********************************
>>>Laura Tull
>>>Systems Librarian
>>>Ohio State University Libraries
>>>1858 Neil Avenue Mall
>>>Columbus OH 43210-1286
>>>Phone:  614-247-6459
>>>Fax:  614-292-7859
>>>Email:  tull.9 at osu.edu
>>>***********************************
>>>_______________________________________________
>>>Dspace-general mailing list
>>>Dspace-general at mit.edu
>>>http://mailman.mit.edu/mailman/listinfo/dspace-general
>>
>>--
>>Jewel H. Ward
>>Graduate Research Assistant, Post-master's
>>Los Alamos National Laboratory
>>Research Library
>>(505) 664-0368
>>jewelw at lanl.gov

------------------------------

_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general


End of Dspace-general Digest, Vol 3, Issue 5
********************************************

From scott.yeadon at anu.edu.au  Wed Oct  8 03:05:16 2003
From: scott.yeadon at anu.edu.au (Scott Yeadon)
Date: Wed, 8 Oct 2003 17:05:16 +1000
Subject: [Dspace-general] RE: Improvements to Administrator's User Interface
Message-ID: <200310081705.16171.scott.yeadon@anu.edu.au>

Hi Margaret,

Below are our suggestions that ANU would like to see. They are ordered from 
most important to least important.

1. Administration at Community and collection levels
For our implementation we want our users to establish and manage their own 
communities and collections without being able to change communities and 
collections which they don't have administrator access for. Currently there 
is only an overall administrator and we need an additional administrator 
layer.

2. Allow searching on items using metadata searches rather than handles
Item handles really don't mean much to users, when looking for an item 
metadata such as titles and authors is used.

3. Metadata should be configurable at community, collection and item levels. 
Currently only one standard metadata set is available across a single DSpace 
instance.
We would like to be able to allow the creation of multiple simultaneous 
metadata schemas. These schemas should be able to be attached at a community, 
collection and item level. The submission forms can then generated dynmically 
using the metadata schema.
We would like to also be able to create default metadata schema and forms. For 
example when a user selected a type of "image" then default metadata schema 
and forms could be assigned for the submission process rather than the user 
having to select or define a schema, or work their way through irrelevant 
metadata forms.

4. If clicking on the "Add EPerson" button a person is automatically added. 
There is no cancel operation on the Add EPerson screen. The new EPerson 
should not be added unless the administrator explicitly clicks on the "Save 
Edits" button.

5. Would be good to be able to edit items from the Edit collection screen. 
This should allow users to edit items belonging to the collection being 
added. Currently you have to go out of the collection to edit items that 
belong to it.

6. Navigation within multiscreen operations.
The breadcrumb links do not always represent where you are in the function 
hierarchy meaning the back button needs to be used on some occasions. As 
there appears to be problems when using the back button, the breadcrumbs need 
to be complete and session state information needs to be maintained so that 
the back button can be used.

7. When editing authorisations it would speed things up if you could select 
more than one access type. For example if I want a Group to have Read, Write, 
Add access, I should be able to select all thes in one operation rather than 
have to perform three separate operations.

8. On the community, collection, item authorisation pages it would be useful 
to be able to click on the group and have a popup displaying which EPersons 
belonged to the group. Currently you have to go out and back into the Group 
maintenance page to see this.

9. Similar to above, when viewing the groups it would be useful to be able to 
see which collections the groups had access to.

10. Look at performance improvements for update/delete queries, for example by 
using threads or asynchronous background transactions while the user moves to 
the next screen. This may also be an issue for drawing of screens for example 
when a repository has a large number of collections, groups, etc rendering 
may become slow. This could be improved through filtering what is displayed 
by providing search and browse facilities similar to what is currently in 
place for collections.

11. Consistent placement and use of buttons would be useful to avoid 
confusion. For example, on some screens you need to make a change and also 
click an "Update" button whereas on others you only need to make a change for 
it to take effect. On several screens where multiple operations may be 
performed (such as metadata, bitstream registries) the "New" button is placed 
at the bottom of the screen, where it may be better to put it at the top 
since the page returns to the top once the change has been applied.

12. Would be good to be able to apply advanced wildcard authorisation policies 
to collections, not just items and bitstreams.

13. Many of the tables run off the screen making it impossible to view the 
information without scrolling left-to-right. If the table cannot be made to 
fit on the screen it would be useful to allow columns to be hidden (similar 
to the hide/show functionality of tools like MS Excel/Access)

Hope that helps. If you would like any clarification on these requests, please 
feel free to contact me.

Thanks.

Scott.


From Ilene.Strongin-Garry at ichotelsgroup.com  Wed Oct  8 14:09:46 2003
From: Ilene.Strongin-Garry at ichotelsgroup.com (Strongin-Garry, Ilene (IHG))
Date: Wed, 8 Oct 2003 14:09:46 -0400 
Subject: [Dspace-general] RE: Dspace-general Digest, Vol 3, Issue 6
Message-ID: <4201FDFD444BC84190DEF632181EB38F2AB669@bhratlexg03.hiw.com>

I agree with the need for integrating epeople with other outside sources
like Microsoft Outlook.  We are a work population in the 1000's and once
more people start using DSpace, the Epeople system will become very time
consuming.

-----Original Message-----
From: dspace-general-request at mit.edu
[mailto:dspace-general-request at mit.edu]
Sent: Wednesday, October 08, 2003 12:04 PM
To: dspace-general at mit.edu
Subject: Dspace-general Digest, Vol 3, Issue 6


Send Dspace-general mailing list submissions to
	dspace-general at mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.mit.edu/mailman/listinfo/dspace-general
or, via email, send a message with subject or body 'help' to
	dspace-general-request at mit.edu

You can reach the person managing the list at
	dspace-general-owner at mit.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dspace-general digest..."


Today's Topics:

   1. RE: Improvements to Administrator's User   Interface (JQ Johnson)
   2. RE: Dspace-general Digest, Vol 3, Issue 5
       (Strongin-Garry, Ilene (IHG))
   3. RE: Improvements to Administrator's User Interface (Scott Yeadon)


----------------------------------------------------------------------

Date: Tue, 7 Oct 2003 11:28:12 -0700
From: "JQ Johnson" <jqj at darkwing.uoregon.edu>
To: <dspace-general at mit.edu>
Subject: [Dspace-general] RE: Improvements to Administrator's User
Interface
Message-ID: <MMENIDDNIPBIJLHLNFHBEEMKCLAA.jqj at darkwing.uoregon.edu>
In-Reply-To: <5.2.1.1.2.20031007100229.02140cb8 at po10.mit.edu>
Content-Type: text/plain;
	charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 1

A couple of suggestions, mixing minor UI changes with significant
implementation changes:

1/ the whole ePeople system needs to be rethought and made more modular.
At many institutions we want to tie into our central directory (LDAP,
radius, or whatever) and give all of and only our people ePerson accounts,
or at least to allow such people privileged access (perhaps what's
needed is the notion of named guests, or a set of system-wide roles such
as {guest,normal,communitycreator,superuser}).  We need an easy way to
associate LDAP-derived membership in departments with DSpace-specific
groups that give access to the corresponding communities.

Just looking at the current admin interface (/admin/edit-epeople), We need
better tools for searching the list of ePeople ("Browse ePeople" may work
for a few hundred ePeople, but not if you have 20,000) and modifying their
properties both individually and as groups.

We may need to more clearly separate system-level authorization from
system-level authentication.

2/ We need an easy way to delegate responsibilities for community
management to community-specific gatekeepers who could create
collections, add members to groups specific to that community, etc.

This implies that groups as presently implemented may be too broad.  I think
we need to have an access control mechanism that more directly ties into
communities and collections.  DSpace started this process with the
special-semantics groups like COLLECTION_3_WFSTEP_1.  But this should be
carried much further.  At a minimum, creation of a collection should
automatically create the corresponding COLLECTION_n_ADD and add it to the
ACL for the collection.  Probably such a new group should inherit some
membership from a community-level group.  If groups as presently
conceptualized continue, it should be possible to delegate ability to change
membership in a particular group -- a non-administrator gatekeeper for a
particular collection, for instance, should be able to modify the membership
of COLLECTION_n_* groups.

It's perhaps symptomatic of the problem that the admin documentation
contains language errors.  For instance, in
http://dspace.org/technology/system-docs/admin-ui.html we read that
"Permissions do not 'commute'" when the actual concept is that permissions
do not inherit or are not transitive.  But note that DEFAULT_*_* properties
do sort of inherit!

The "Communities/Collections" admin interface is quite usable as is for
small numbers of collections, but doesn't work well if you have 200
communities and 500 collections.

Creating a collection should automatically create a COLLECTION_n_ADD group
for it.

Probably lots of other changes to the collection creation/editing form would
be useful as well.  E.g. "Item template" seems ill thought out.

3/ items:  we desperately need a way for a site to customize the
submission process and change the metadata collected.  I don't think we
need to change the actual metadata schema; qDC is adequate.

4/ the admin interface for Items needs a better search facility.  I don't
want to have to think in terms of handles or internal IDs.

5/ Multiple versions of an item:  unless a better item versioning system can
be implemented soon, we need a way to allow unprivileged users to add
bitstreams to an existing record (and to record and display timestamps on a
per-bitstream basis).  This might be the owner modifying a record, or might
be people in some collection-specific group.

6/ Item authorizations in the current admin interface (Authorize->Manage An
Item's Policies) are completely obscure.  The notion of "Bundles" isn't
reified anywhere else in the user interface.  The fact that bundles have
numbers and not names is a symptom of the problem.

General observation:  for power users it might be better instead of writing
a bunch of custom UI code to simply expose the database more directly.  If I
could download a .csv file with the metadata for an item or the list of
members in a group, edit it using Excel or whatever, then upload the
resulting file, that would be a lot more flexible than the current approach.
Absent such a feature, I'm tempted to connect to my DSpace database directly
from Access or DBtools or some similar graphical SQL editor, but that is
high-risk.

JQ Johnson                      Office: 115F Knight Library
Academic Education Coordinator  mailto:jqj at darkwing.uoregon.edu
1299 University of Oregon       phone: 1-541-346-1746; -3485 fax
Eugene, OR  97403-1299          http://darkwing.uoregon.edu/~jqj/

------------------------------

Date: Tue, 7 Oct 2003 15:41:12 -0400 
From: "Strongin-Garry, Ilene (IHG)"
	 <Ilene.Strongin-Garry at ichotelsgroup.com>
To: "'dspace-general at mit.edu'" <dspace-general at mit.edu>
Subject: [Dspace-general] RE: Dspace-general Digest, Vol 3, Issue 5
Message-ID: <4201FDFD444BC84190DEF632181EB38F2AB636 at bhratlexg03.hiw.com>
Content-Type: text/plain;
	charset="iso-8859-1"
MIME-Version: 1.0
Precedence: list
Message: 2

Other enhancements I'd like to see include:

When submitting an item, you are asked to submit to a collection.  However,
once you choose the collection it cannot be changed without having to
re-enter the entire amount of metadata and files.  I would like to have the
option to correct my collection choice.

Secondly, it would be great to be able to add additional files to an item
once it's in DSpace.  I know you can edit metadata, but it would be great to
be able to add files in case something has been accidentally left off or
found later after an item has been submitted.

-----Original Message-----
From: dspace-general-request at mit.edu
[mailto:dspace-general-request at mit.edu]
Sent: Tuesday, October 07, 2003 12:01 PM
To: dspace-general at mit.edu
Subject: Dspace-general Digest, Vol 3, Issue 5


Send Dspace-general mailing list submissions to
	dspace-general at mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.mit.edu/mailman/listinfo/dspace-general
or, via email, send a message with subject or body 'help' to
	dspace-general-request at mit.edu

You can reach the person managing the list at
	dspace-general-owner at mit.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dspace-general digest..."


Today's Topics:

   1. Fwd: Re: [Dspace-general] Improvements to Administrator's User
         Interface (Margret Branschofsky)


----------------------------------------------------------------------

Date: Tue, 07 Oct 2003 10:02:48 -0400
From: Margret Branschofsky <margretb at MIT.EDU>
To: dspace-general at MIT.EDU
Subject: Fwd: Re: [Dspace-general] Improvements to Administrator's User
   Interface
Message-ID: <5.2.1.1.2.20031007100229.02140cb8 at po10.mit.edu>
Content-Type: text/plain; charset="us-ascii"; format=flowed
MIME-Version: 1.0
Precedence: list
Message: 1


>Date: Tue, 07 Oct 2003 10:01:45 -0400
>To: Jewel Ward <jewelw at lanl.gov>
>From: Margret Branschofsky <margretb at mit.edu>
>Subject: Re: [Dspace-general] Improvements to Administrator's User
Interface
>
>Have you all seen the Administration User Interface Documentation which 
>comes with the system documentation?  If so, is this documentation not 
>adequate?  (http://dspace.org/technology/system-docs/admin-ui.html ).
>
>Margret
>
>At 03:37 PM 10/6/2003 -0600, Jewel Ward wrote:
>>At 11:47 AM 10/3/2003 -0400, you wrote:
>>
>>>Can I assume there will be a help page for the Admin interface similar 
>>>to the user's interface that will explain how to create and delete 
>>>community, collection and set policies for them, etc.  It seems that I 
>>>ran into some issues with the order in which you had to do things.
>>
>>Margret,
>>
>>I had the same problem.  I'll try to think of things that are more 
>>specific and send them to you.
>>
>>Regards,
>>
>>Jewel
>>
>>
>>
>>>***********************************
>>>Laura Tull
>>>Systems Librarian
>>>Ohio State University Libraries
>>>1858 Neil Avenue Mall
>>>Columbus OH 43210-1286
>>>Phone:  614-247-6459
>>>Fax:  614-292-7859
>>>Email:  tull.9 at osu.edu
>>>***********************************
>>>_______________________________________________
>>>Dspace-general mailing list
>>>Dspace-general at mit.edu
>>>http://mailman.mit.edu/mailman/listinfo/dspace-general
>>
>>--
>>Jewel H. Ward
>>Graduate Research Assistant, Post-master's
>>Los Alamos National Laboratory
>>Research Library
>>(505) 664-0368
>>jewelw at lanl.gov

------------------------------

_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general


End of Dspace-general Digest, Vol 3, Issue 5
********************************************
------------------------------

Date: Wed, 8 Oct 2003 17:05:16 +1000
From: Scott Yeadon <scott.yeadon at anu.edu.au>
To: margretb at MIT.EDU
Cc: dspace-general at MIT.EDU
Cc: dspace-tech at sourceforge.lists.net
Subject: [Dspace-general] RE: Improvements to Administrator's User Interface
Message-ID: <200310081705.16171.scott.yeadon at anu.edu.au>
Content-Type: text/plain;
  charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: list
Reply-To: scott.yeadon at anu.edu.au
Message: 3

Hi Margaret,

Below are our suggestions that ANU would like to see. They are ordered from 
most important to least important.

1. Administration at Community and collection levels
For our implementation we want our users to establish and manage their own 
communities and collections without being able to change communities and 
collections which they don't have administrator access for. Currently there 
is only an overall administrator and we need an additional administrator 
layer.

2. Allow searching on items using metadata searches rather than handles
Item handles really don't mean much to users, when looking for an item 
metadata such as titles and authors is used.

3. Metadata should be configurable at community, collection and item levels.

Currently only one standard metadata set is available across a single DSpace

instance.
We would like to be able to allow the creation of multiple simultaneous 
metadata schemas. These schemas should be able to be attached at a
community, 
collection and item level. The submission forms can then generated
dynmically 
using the metadata schema.
We would like to also be able to create default metadata schema and forms.
For 
example when a user selected a type of "image" then default metadata schema 
and forms could be assigned for the submission process rather than the user 
having to select or define a schema, or work their way through irrelevant 
metadata forms.

4. If clicking on the "Add EPerson" button a person is automatically added. 
There is no cancel operation on the Add EPerson screen. The new EPerson 
should not be added unless the administrator explicitly clicks on the "Save 
Edits" button.

5. Would be good to be able to edit items from the Edit collection screen. 
This should allow users to edit items belonging to the collection being 
added. Currently you have to go out of the collection to edit items that 
belong to it.

6. Navigation within multiscreen operations.
The breadcrumb links do not always represent where you are in the function 
hierarchy meaning the back button needs to be used on some occasions. As 
there appears to be problems when using the back button, the breadcrumbs
need 
to be complete and session state information needs to be maintained so that 
the back button can be used.

7. When editing authorisations it would speed things up if you could select 
more than one access type. For example if I want a Group to have Read,
Write, 
Add access, I should be able to select all thes in one operation rather than

have to perform three separate operations.

8. On the community, collection, item authorisation pages it would be useful

to be able to click on the group and have a popup displaying which EPersons 
belonged to the group. Currently you have to go out and back into the Group 
maintenance page to see this.

9. Similar to above, when viewing the groups it would be useful to be able
to 
see which collections the groups had access to.

10. Look at performance improvements for update/delete queries, for example
by 
using threads or asynchronous background transactions while the user moves
to 
the next screen. This may also be an issue for drawing of screens for
example 
when a repository has a large number of collections, groups, etc rendering 
may become slow. This could be improved through filtering what is displayed 
by providing search and browse facilities similar to what is currently in 
place for collections.

11. Consistent placement and use of buttons would be useful to avoid 
confusion. For example, on some screens you need to make a change and also 
click an "Update" button whereas on others you only need to make a change
for 
it to take effect. On several screens where multiple operations may be 
performed (such as metadata, bitstream registries) the "New" button is
placed 
at the bottom of the screen, where it may be better to put it at the top 
since the page returns to the top once the change has been applied.

12. Would be good to be able to apply advanced wildcard authorisation
policies 
to collections, not just items and bitstreams.

13. Many of the tables run off the screen making it impossible to view the 
information without scrolling left-to-right. If the table cannot be made to 
fit on the screen it would be useful to allow columns to be hidden (similar 
to the hide/show functionality of tools like MS Excel/Access)

Hope that helps. If you would like any clarification on these requests,
please 
feel free to contact me.

Thanks.

Scott.

------------------------------

_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general


End of Dspace-general Digest, Vol 3, Issue 6
********************************************

From tull.9 at osu.edu  Thu Oct  9 14:22:45 2003
From: tull.9 at osu.edu (Laura Tull)
Date: Thu, 09 Oct 2003 14:22:45 -0400
Subject: [Dspace-general] Indexing more fields in Dspace
Message-ID: <4.3.2.7.2.20031009141923.029c7778@pop.service.ohio-state.edu>

We just added a collection for a newsletter. We added all of the titles of 
the articles within the newsletter to the description field, which doesn't 
appear to be indexed.

Example: http://hdl.handle.net/1811/53

I didn't see anything about indexing additional fields on the feature 
request list.  This is a field we would like to see indexed.  Is there 
anything in the works for this already?


***********************************
Laura Tull
Systems Librarian
Ohio State University Libraries
1858 Neil Avenue Mall
Columbus OH 43210-1286
Phone:  614-247-6459
Fax:  614-292-7859
Email:  tull.9 at osu.edu
*********************************** 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20031009/51fd588a/attachment.htm

From gabriela.mircea at utoronto.ca  Tue Oct 14 11:15:36 2003
From: gabriela.mircea at utoronto.ca (Gabriela Mircea)
Date: Tue, 14 Oct 2003 11:15:36 -0400
Subject: [Dspace-general] data sets - metadata 
References: <5.2.1.1.2.20031007100229.02140cb8@po10.mit.edu>
Message-ID: <3F8C1318.2090800@utoronto.ca>

Hi all,

We have some data sets that we would like to put into DSpace, but I am 
not sure how we should handle the metadata.
Does anyone have data sets in DSpace, and are you willing to share the 
way that metadata was organized?
We should probably add some more fields. The problem is not how to add 
the fields (technical), but what descriptors should we use for data 
sets. Are there any standards?

Thank you in advance,

Gabriela


From jqj at darkwing.uoregon.edu  Tue Oct 14 12:15:28 2003
From: jqj at darkwing.uoregon.edu (JQ Johnson)
Date: Tue, 14 Oct 2003 09:15:28 -0700
Subject: [Dspace-general] data sets - metadata 
In-Reply-To: <3F8C1318.2090800@utoronto.ca>
Message-ID: <MMENIDDNIPBIJLHLNFHBGEPMCLAA.jqj@darkwing.uoregon.edu>

I'm very interested in this question also.  Note that the format of the data
in computer file or DSPace format registry terms (Excel file, text file,
Access .mdb file, etc.) may be much less relevant than the internal format
of the data (for instance, a text file might be a comma-separated
spreadsheet dataset or an SPSS dataset or the raw SQL commands needed to
reconstitute a SQL database or ...).

Perhaps more important than the raw observational data is the internal
descriptive data that may or may not accompany the data itself -- the
codebook, if you will.  Note that in some data formats this is a separate
file, while in others it may be integrated into the data format.  This is
truly metadata, but it's sure as anything not qDC!

Perhaps equally important is the description of the data collection and data
cleaning technique -- the sort of information that is typically included in
the methods section of a paper based on the raw data.  If we really care
about having data sets useful in the future, then it's important that the
data set include links to such a methods section.  Such information is
highly discipline specific; the appropriate metadata for a gene sequence is
rather different from that for a statistical survey of domestic abuse
victims.

Many data sets are made available as supplements to published research; for
example, many journals such as _Science_ now provide web based repositories
for appendices to articles they publish.  At a bare minimum, the DC-style
metadata for a data set that corresponds to a published paper should include
a citation for the published paper.

Let's start with the qDC.  coverage.* are natural fields to fill in as is
unqualified format.  I'd say that relation.isbasedon and other relation.*
fields are also critical to include.  I'd also say that a policy that
required a human-readable codebook as one of the bitstreams associated with
a dataset (stored as one or more bitstreams in the same item) would be
extremely important.  But then what should the format fields refer to?  They
are item-level, so how do we relate the format.* values to the particular
bitstreams they apply to?  [This seems to be a major weakness in the current
DSpace architecture]

Our observation as we've begun to explore statistical data for our
institutional repository is that most researchers are very careless about
documenting their data in ways that would make it useful to other
researchers in the future.  We believe that the simple repository is only a
tiny fraction of the real issue, and that the important thing is to provide
advice and formal structures that make it easy for researchers to document
their data collection process.

I suspect that trying to answer the question if posed as "data sets" is
going to be a failure, and that we should pose the question in terms of some
particular kind of data set such as statistical sample observations. "Data
set" is so broad that it even includes a set of bibliography entries (in
bibtex, endnote, refer, MARC, or whatever format).  So the first thing to do
is for us to focus on a particular kind of data.

JQ Johnson                      Office: 115F Knight Library
Academic Education Coordinator  mailto:jqj at darkwing.uoregon.edu
1299 University of Oregon       phone: 1-541-346-1746; -3485 fax
Eugene, OR  97403-1299          http://darkwing.uoregon.edu/~jqj/

-----Original Message-----
From: dspace-general-bounces at mit.edu
[mailto:dspace-general-bounces at mit.edu]On Behalf Of Gabriela Mircea
Sent: Tuesday, October 14, 2003 8:16 AM
To: dspace-general at mit.edu
Subject: [Dspace-general] data sets - metadata


Hi all,

We have some data sets that we would like to put into DSpace, but I am
not sure how we should handle the metadata.
Does anyone have data sets in DSpace, and are you willing to share the
way that metadata was organized?
We should probably add some more fields. The problem is not how to add
the fields (technical), but what descriptors should we use for data
sets. Are there any standards?

Thank you in advance,

Gabriela

_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general


From sbell at library.rochester.edu  Wed Oct 15 12:46:57 2003
From: sbell at library.rochester.edu (Suzanne Bell)
Date: Wed, 15 Oct 2003 12:46:57 -0400
Subject: [Dspace-general] data sets - metadata
Message-ID: <sf8d41d5.051@library.rochester.edu>

Hello folks-

Would the work of the Data Documentation Initiative be germaine to this issue, I wonder? I have to admit I've not had any direct involvement with this project, but I know they've been working very hard on this issue (metadata for datasets) for several years. They have a good website at:
 http://www.icpsr.umich.edu/DDI/
(their focus is social science data, not scientific)

 -Suzanne

 

*******************************************
Suzanne Bell, Economics/Data Librarian
University of Rochester
585/275-9317
sbell at library.rochester.edu



From robert.tansley at hp.com  Wed Oct 15 16:24:27 2003
From: robert.tansley at hp.com (Tansley, Robert)
Date: Wed, 15 Oct 2003 13:24:27 -0700
Subject: [Dspace-general] Indexing more fields in Dspace
Message-ID: <40700B4C02ABD5119F00009027876644084DF262@hplex1.hpl.hp.com>

You can easily get that field indexed by having someone edit the DSIndexer.java code in the DSpace source tree.  I know this isn't ideal; perhaps the fields that are indexed should be another configuration parameter/set of parameters, and maybe made part of the Dublin Core Registry page in the admin UI.  If anyone wants to implement this functionality please let us know!

 Robert Tansley / Hewlett-Packard Laboratories / (+1) 617 551 7624 

-----Original Message-----
From: Laura Tull [mailto:tull.9 at osu.edu] 
Sent: 09 October 2003 14:23
To: dspace-general at mit.edu
Subject: [Dspace-general] Indexing more fields in Dspace


We just added a collection for a newsletter. We added all of the titles of the articles within the newsletter to the description field, which doesn't appear to be indexed.

Example: http://hdl.handle.net/1811/53 

I didn't see anything about indexing additional fields on the feature request list.  This is a field we would like to see indexed.  Is there anything in the works for this already?

From mcneillh at MIT.EDU  Mon Oct 20 13:20:27 2003
From: mcneillh at MIT.EDU (Katherine McNeill-Harman)
Date: Mon, 20 Oct 2003 13:20:27 -0400
Subject: [Dspace-general] data sets - metadata 
In-Reply-To: <5.2.1.1.2.20031014145546.01cff130@po10.mit.edu>
Message-ID: <5.2.1.1.2.20031020124444.02289e40@po11.mit.edu>

Hi everyone,

This is a great discussion, and I too am particularly interested in this 
subject.  I'm the Data Services Librarian here at MIT, and have been 
discussing issues particular to data sets with others (here & at other 
institutions).  For one perspective, I did a poster session on this topic 
at this year's meeting of IASSIST (the International Association for Social 
Science Information Service and Technology), see
http://macfadden.mit.edu:9500/presentations/iassist/.

Following are some thoughts on this specific issue.  First, though, are 
there others on the list interested in discussing data set issues on an 
ongoing basis?  I've discussed with others the possibility of establishing 
a separate email list on the topic, if there's enough interest.  Let me 
know if you would find this valuable, or if you'd rather just keep the 
discussion on the general list for now.

Regarding this issue, Suzanne brought up a good standard that we're looking 
at.  However, as was discussed, there are two kinds of metadata we're 
discussing:

1) the metadata used in DSpace to describe the items (we're using Dublin 
Core, but looking into different ways to take advantage of other metadata 
standards, such as DDI, see the SIMILE project at 
http://web.mit.edu/simile/www/)
2) the metadata about the data file in the form of the codebook, that for 
us will be one of the files (in addition to the data file) associated w/a 
given item in the system; ideally for social science data, this would be 
marked up in the DDI XML standard, but it's unclear as of yet if/how this 
would interface w/the main search system

But, as JQ said, sometimes the metadata is integrated w/the data (I believe 
this sometimes happens more in scientific communities).  JQ made some other 
important points, many with which we're still struggling, including how to 
have the system understand the internal/external structures of data files 
and how to encourage high-quality documentation of data.  And, as he 
alluded, treatment of statistical data may be different from that for "raw" 
data sets that yet require analysis.  Some of these will be managed at a 
system-wide level, while others (such as requiring/standardizing 
codebook-level metadata) are left up to our communities (e.g. departments) 
who deposit to DSpace; so organizational issues are as important to 
understand as are technical ones.

One question, what is qDC?  Is it a standard for describing scientific 
data?  For those of us not familiar.

Let's keep up the interesting discussion!

Kate McNeill-Harman
Data Services Librarian, MIT

>From: "Suzanne Bell" <sbell at library.rochester.edu>
>To: <dspace-general at mit.edu>
>Subject: RE: [Dspace-general] data sets - metadata
>
>Hello folks-
>
>Would the work of the Data Documentation Initiative be germaine to this 
>issue, I wonder? I have to admit I've not had any direct involvement with 
>this project, but I know they've been working very hard on this issue 
>(metadata for datasets) for several years. They have a good website at:
>  http://www.icpsr.umich.edu/DDI/
>(their focus is social science data, not scientific)
>
>  -Suzanne

>>From: "JQ Johnson" <jqj at darkwing.uoregon.edu>
>>To: <dspace-general at mit.edu>
>>Subject: RE: [Dspace-general] data sets - metadata
>>Date: Tue, 14 Oct 2003 09:15:28 -0700
>>
>>I'm very interested in this question also.  Note that the format of the 
>>data in computer file or DSPace format registry terms (Excel file, text 
>>file, Access .mdb file, etc.) may be much less relevant than the internal 
>>format of the data (for instance, a text file might be a comma-separated 
>>spreadsheet dataset or an SPSS dataset or the raw SQL commands needed to 
>>reconstitute a SQL database or ...).
>>
>>Perhaps more important than the raw observational data is the internal 
>>descriptive data that may or may not accompany the data itself -- the 
>>codebook, if you will.  Note that in some data formats this is a separate 
>>file, while in others it may be integrated into the data format.  This is 
>>truly metadata, but it's sure as anything not qDC!
>>
>>Perhaps equally important is the description of the data collection and 
>>data cleaning technique -- the sort of information that is typically 
>>included in the methods section of a paper based on the raw data.  If we 
>>really care about having data sets useful in the future, then it's 
>>important that the data set include links to such a methods 
>>section.  Such information is highly discipline specific; the appropriate 
>>metadata for a gene sequence is rather different from that for a 
>>statistical survey of domestic abuse victims.
>>
>>Many data sets are made available as supplements to published research; 
>>for example, many journals such as _Science_ now provide web based 
>>repositories for appendices to articles they publish.  At a bare minimum, 
>>the DC-style metadata for a data set that corresponds to a published 
>>paper should include a citation for the published paper.
>>
>>Let's start with the qDC.  coverage.* are natural fields to fill in as is 
>>unqualified format.  I'd say that relation.isbasedon and other relation.* 
>>fields are also critical to include.  I'd also say that a policy that
>>required a human-readable codebook as one of the bitstreams associated 
>>with a dataset (stored as one or more bitstreams in the same item) would 
>>be extremely important.  But then what should the format fields refer 
>>to?  They are item-level, so how do we relate the format.* values to the 
>>particular bitstreams they apply to?  [This seems to be a major weakness 
>>in the current DSpace architecture]
>>
>>Our observation as we've begun to explore statistical data for our 
>>institutional repository is that most researchers are very careless about 
>>documenting their data in ways that would make it useful to other
>>researchers in the future.  We believe that the simple repository is only 
>>a tiny fraction of the real issue, and that the important thing is to 
>>provide advice and formal structures that make it easy for researchers to 
>>document their data collection process.
>>
>>I suspect that trying to answer the question if posed as "data sets" is 
>>going to be a failure, and that we should pose the question in terms of 
>>some particular kind of data set such as statistical sample observations. 
>>"Data set" is so broad that it even includes a set of bibliography 
>>entries (in bibtex, endnote, refer, MARC, or whatever format).  So the 
>>first thing to do is for us to focus on a particular kind of data.
>>
>>JQ Johnson                      Office: 115F Knight Library
>>Academic Education Coordinator  mailto:jqj at darkwing.uoregon.edu
>>1299 University of Oregon       phone: 1-541-346-1746; -3485 fax
>>Eugene, OR  97403-1299          http://darkwing.uoregon.edu/~jqj/
>>
>>-----Original Message-----
>>From: dspace-general-bounces at mit.edu
>>[mailto:dspace-general-bounces at mit.edu]On Behalf Of Gabriela Mircea
>>Sent: Tuesday, October 14, 2003 8:16 AM
>>To: dspace-general at mit.edu
>>Subject: [Dspace-general] data sets - metadata
>>
>>Hi all,
>>
>>We have some data sets that we would like to put into DSpace, but I am 
>>not sure how we should handle the metadata.  Does anyone have data sets 
>>in DSpace, and are you willing to share the way that metadata was organized?
>>We should probably add some more fields. The problem is not how to add 
>>the fields (technical), but what descriptors should we use for data sets. 
>>Are there any standards?
>>
>>Thank you in advance,
>>
>>Gabriela
>>_______________________________________________
>>Dspace-general mailing list
>>Dspace-general at mit.edu
>>http://mailman.mit.edu/mailman/listinfo/dspace-general
>
>___________________________________________
>Katherine McNeill-Harman
>Data Services Reference Librarian
>Dewey Library for Management and Social Sciences
>Massachusetts Institute of Technology
>77 Massachusetts Avenue, E53-100
>Cambridge, MA 02139
>mcneillh at mit.edu
>617-253-0787 


From jqj at darkwing.uoregon.edu  Mon Oct 20 13:30:53 2003
From: jqj at darkwing.uoregon.edu (JQ Johnson)
Date: Mon, 20 Oct 2003 10:30:53 -0700
Subject: [Dspace-general] spam alert
In-Reply-To: <5.2.1.1.2.20031020124444.02289e40@po11.mit.edu>
Message-ID: <MMENIDDNIPBIJLHLNFHBMECFCMAA.jqj@darkwing.uoregon.edu>

Our institutional spam filters have started to complain about mail to
dspace-general at mit.edu.  Here's the report for email I got just now:

 pts rule name              description
---- ---------------------- ------------------------------------------------
--
 1.9 WEIRD_PORT             URI: Uses non-standard port number for HTTP
 2.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
                  [Blocked - see
<http://www.spamcop.net/bl.shtml?18.7.21.86>]
 1.3 RCVD_IN_NJABL_RELAY    RBL: NJABL: sender is confirmed open relay
                            [18.7.21.86 listed in dnsbl.njabl.org]
 0.1 RCVD_IN_NJABL          RBL: Received via a relay in dnsbl.njabl.org
                            [18.7.21.86 listed in dnsbl.njabl.org]

We'd be very appreciative if MIT could clean up the software on
melbourne-city-street.mit.edu to eliminate the potential for its use as an
open relay.  If that can be done, then it will disappear from the NJABL and
SPAMCOP blacklists.

JQ Johnson                      Office: 115F Knight Library
Academic Education Coordinator  mailto:jqj at darkwing.uoregon.edu
1299 University of Oregon       phone: 1-541-346-1746; -3485 fax
Eugene, OR  97403-1299          http://darkwing.uoregon.edu/~jqj/




From rrodgers at MIT.EDU  Tue Oct 21 14:40:46 2003
From: rrodgers at MIT.EDU (Richard Rodgers)
Date: 21 Oct 2003 14:40:46 -0400
Subject: [Dspace-general] DSpace 1.2 Feature Descriptions
Message-ID: <1066761646.25056.73.camel@dspace-03.mit.edu>


As promised, what follows are descriptions of several of the proposed
new features for DSpace 1.2. Please post comments and suggestions to
this list: we welcome your input!

Content Thumbnail Support

In DSpace's item display graphical content currently only has text to
describe it - users would like to see thumbnails, a more intuitive
representation.  Clicking on the thumbnail would then deliver the
content to the user.  Users may want to supply their own thumbnails, but
the vast majority would probably prefer to have the system generate
thumbnails for them.

There will probably be four methods of adding thumbnails to an item: 
the system could generate automatically during the workflow of
submission, a batch process accessing the repository could add thumbnail
bundles to items lacking them, or users could submit thumbnails along
with the item (highly unlikely!), or the system could generate
thumbnails dynamically.  To integrate thumbnail generation into a
workflow, DSpace needs to be able to take advantage of all of the tools
available to generate thumbnails, and many are not written in Java. 
Many of these tools are also specific types of content - some are image
tools, PDF utilities, or a even a script tying multiple tools together. 
A 'plug-in' architecture could handle these scenarios well:  a group of
classes wrap whatever tools are needed to generate thumbnails, and
register for certain types of submitted content. As content is
submitted, its type is checked and it is handed off to the
classes that want to process submitted content of that type.
A batch tool could also be created that used the same registry of
content handlers, looking for items without thumbnails, and then
attempting to create thumbnails when possible. 

Storing thumbnails shouldn't involve too many changes to the system. 
(None, if the thumbnails are generated dynamically.)  DSpace was
architected with alternate views of content in mind, where items can
have multiple bundles, each containing a different representation of the
item's content.  A thumbnail could simply be another bundle within the
item.  The item display page could look for a thumbnail bundle
containing images for each bitstream in the primary bundle (we may need
a type field to identify the primary bundle vs. a PDF or thumbnail or
extracted text bundle,) and then display the thumbnail next to the file
name. 

The thumbnail becomes an official part of the item, or a flag could be
used to indicate that the thumbnail is an annotation by the system
rather than a part of the original submission.


Full Text Searching

Currently DSpace users can only search the metadata for items - the text
that may be within the content is not searchable.  Users would like to
search the full text of items within DSpace.  It may also be handy for
users to have access to the extracted text for an item, possibly in the
'full' item display.

Our search engine Lucene can easily index the full text from items, so
the challenge is really extracting and storing the full text of
submitted items. This problem is remarkably similar to the generation of
thumbnails: generating a 'text' representation of an item's content is
very similar to generating a thumbnail representation of that content. 
DSpace's object model supports different representations of content with
bundles - each bundle stores a representation. 

Like thumbnail generation, there are many tools available to extract
text from content, many of which are not in Java, and many are specific
to certain types of content.  Again, a plug-in architecture would handle
representation generation well - as content is submitted, classes
registered for the type of that content are invoked and annotate the
item with a full-text bundle, which would then be recognized and indexed
by the search system.  A plug-in architecture would be handy for
integrating with workflows, or as part of a batch process to be run as
part of regular content 'maintenance.'  Again, these bundles may need to
be typed; in this case a 'full text' bundle type would be a hint for the
indexer that it could index the contents of that bundle.

Also like thumbnails, the extracted text for content becomes an official
part of the item, perhaps with a flag to indicate that it is an
annotation by the system and was not part of the original submission.



Items Shared by Multiple Collections

Currently DSpace assumes that items are part of a single collection. 
Users would like to share items between collections, even generation
'virtual' collections that are groupings of items from other
collections.

DSpace's data model supports mapping items to multiple collections, but
the GUI tools do not.  If an item is shared between collections, then
the question arises over who controls it.  One solution is to assign an
owning collection to an item.  The administrator of the owning
collection can modify the item, and assign viewing permissions - other
collection administrators do not have such control - they can only place
a reference to the item in their collection.  Administrators who could
not access an item themselves would of course not be able to reference
the item in their collection.  Since items in multiple collections are
references and not copies, if an item is for some reason removed or
withdrawn, then the references will also appear to be removed or
withdrawn.  A possible problem in the future to watch out for will be
when collection administrators want to attach metadata to or annotate
these references.



From kenzie at MIT.EDU  Tue Oct 21 14:39:38 2003
From: kenzie at MIT.EDU (MacKenzie Smith)
Date: Tue, 21 Oct 2003 14:39:38 -0400
Subject: [Dspace-general] spam alert
In-Reply-To: <MMENIDDNIPBIJLHLNFHBMECFCMAA.jqj@darkwing.uoregon.edu>
References: <5.2.1.1.2.20031020124444.02289e40@po11.mit.edu>
Message-ID: <5.2.1.1.2.20031021142524.01e3bdd8@hesiod>

Hi JQ,

dspace-general is using MIT's centrally managed listserv services
and mail relay, which are run by our central computer services group.
They've been working with AOL, spamcop, etc to demonstrate how
they're eliminating spam and to introduce smtp authentication. As
far as we know, spamcop should be removing MIT from their list soon.

Beyond this, there's not much we in the Libraries can do about it,
but if actual spam is becoming a problem then we'll convert the list
to a moderated one.

Thanks for the heads up,

MacKenzie/

At 10:30 AM 10/20/2003 -0700, JQ Johnson wrote:
>Our institutional spam filters have started to complain about mail to
>dspace-general at mit.edu.  Here's the report for email I got just now:
>
>  pts rule name              description
>---- ---------------------- ------------------------------------------------
>--
>  1.9 WEIRD_PORT             URI: Uses non-standard port number for HTTP
>  2.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
>                   [Blocked - see
><http://www.spamcop.net/bl.shtml?18.7.21.86>]
>  1.3 RCVD_IN_NJABL_RELAY    RBL: NJABL: sender is confirmed open relay
>                             [18.7.21.86 listed in dnsbl.njabl.org]
>  0.1 RCVD_IN_NJABL          RBL: Received via a relay in dnsbl.njabl.org
>                             [18.7.21.86 listed in dnsbl.njabl.org]
>
>We'd be very appreciative if MIT could clean up the software on
>melbourne-city-street.mit.edu to eliminate the potential for its use as an
>open relay.  If that can be done, then it will disappear from the NJABL and
>SPAMCOP blacklists.
>
>JQ Johnson                      Office: 115F Knight Library
>Academic Education Coordinator  mailto:jqj at darkwing.uoregon.edu
>1299 University of Oregon       phone: 1-541-346-1746; -3485 fax
>Eugene, OR  97403-1299          http://darkwing.uoregon.edu/~jqj/
>
>
>
>_______________________________________________
>Dspace-general mailing list
>Dspace-general at mit.edu
>http://mailman.mit.edu/mailman/listinfo/dspace-general

MacKenzie Smith
Associate Director for Technology
MIT Libraries
Building 14S-208
77 Massachusetts Avenue
Cambridge, MA  02139
(617)253-8184
kenzie at mit.edu 


From Ilene.Strongin-Garry at ichotelsgroup.com  Wed Oct 22 13:49:49 2003
From: Ilene.Strongin-Garry at ichotelsgroup.com (Strongin-Garry, Ilene (IHG))
Date: Wed, 22 Oct 2003 13:49:49 -0400
Subject: [Dspace-general] DSpace 1.2 Feature Descriptions
Message-ID: <4201FDFD444BC84190DEF632181EB38F2AB7E9@bhratlexg03.hiw.com>

The features named are definitely desired.  Full-text searching is probably
first on the list.  We would also like to be able to put an item into more
than one collection.

Also would like to see an Administer Interface that lets administrators
search for items not just be ID, but also by title or keywords or authors
(as was mentioned by another user in a previous DSpace digest).  I've also
had a request for better ASCII recognition (in the case of symbols like
umlauts and currency.  Also the following would be great:  
When submitting an item, you are asked to submit to a collection.  However,
once you choose the collection it cannot be changed without having to
re-enter the entire amount of metadata and files.  I would like to have the
option to correct my collection choice.

Secondly, it would be great to be able to add additional files to an item
once it's in DSpace.  I know you can edit metadata, but it would be great to
be able to add files in case something has been accidentally left off or
found later after an item has been submitted.

-----Original Message-----
From: dspace-general-request at mit.edu
[mailto:dspace-general-request at mit.edu]
Sent: Wednesday, October 22, 2003 12:01 PM
To: dspace-general at mit.edu
Subject: Dspace-general Digest, Vol 3, Issue 13


Send Dspace-general mailing list submissions to
	dspace-general at mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.mit.edu/mailman/listinfo/dspace-general
or, via email, send a message with subject or body 'help' to
	dspace-general-request at mit.edu

You can reach the person managing the list at
	dspace-general-owner at mit.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dspace-general digest..."


Today's Topics:

   1. DSpace 1.2 Feature Descriptions (Richard Rodgers)
   2. Re: spam alert (MacKenzie Smith)


----------------------------------------------------------------------

Date: 21 Oct 2003 14:40:46 -0400
From: Richard Rodgers <rrodgers at MIT.EDU>
To: dspace-general at MIT.EDU
Subject: [Dspace-general] DSpace 1.2 Feature Descriptions
Message-ID: <1066761646.25056.73.camel at dspace-03.mit.edu>
Content-Type: text/plain
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 1


As promised, what follows are descriptions of several of the proposed
new features for DSpace 1.2. Please post comments and suggestions to
this list: we welcome your input!

Content Thumbnail Support

In DSpace's item display graphical content currently only has text to
describe it - users would like to see thumbnails, a more intuitive
representation.  Clicking on the thumbnail would then deliver the
content to the user.  Users may want to supply their own thumbnails, but
the vast majority would probably prefer to have the system generate
thumbnails for them.

There will probably be four methods of adding thumbnails to an item: 
the system could generate automatically during the workflow of
submission, a batch process accessing the repository could add thumbnail
bundles to items lacking them, or users could submit thumbnails along
with the item (highly unlikely!), or the system could generate
thumbnails dynamically.  To integrate thumbnail generation into a
workflow, DSpace needs to be able to take advantage of all of the tools
available to generate thumbnails, and many are not written in Java. 
Many of these tools are also specific types of content - some are image
tools, PDF utilities, or a even a script tying multiple tools together. 
A 'plug-in' architecture could handle these scenarios well:  a group of
classes wrap whatever tools are needed to generate thumbnails, and
register for certain types of submitted content. As content is
submitted, its type is checked and it is handed off to the
classes that want to process submitted content of that type.
A batch tool could also be created that used the same registry of
content handlers, looking for items without thumbnails, and then
attempting to create thumbnails when possible. 

Storing thumbnails shouldn't involve too many changes to the system. 
(None, if the thumbnails are generated dynamically.)  DSpace was
architected with alternate views of content in mind, where items can
have multiple bundles, each containing a different representation of the
item's content.  A thumbnail could simply be another bundle within the
item.  The item display page could look for a thumbnail bundle
containing images for each bitstream in the primary bundle (we may need
a type field to identify the primary bundle vs. a PDF or thumbnail or
extracted text bundle,) and then display the thumbnail next to the file
name. 

The thumbnail becomes an official part of the item, or a flag could be
used to indicate that the thumbnail is an annotation by the system
rather than a part of the original submission.


Full Text Searching

Currently DSpace users can only search the metadata for items - the text
that may be within the content is not searchable.  Users would like to
search the full text of items within DSpace.  It may also be handy for
users to have access to the extracted text for an item, possibly in the
'full' item display.

Our search engine Lucene can easily index the full text from items, so
the challenge is really extracting and storing the full text of
submitted items. This problem is remarkably similar to the generation of
thumbnails: generating a 'text' representation of an item's content is
very similar to generating a thumbnail representation of that content. 
DSpace's object model supports different representations of content with
bundles - each bundle stores a representation. 

Like thumbnail generation, there are many tools available to extract
text from content, many of which are not in Java, and many are specific
to certain types of content.  Again, a plug-in architecture would handle
representation generation well - as content is submitted, classes
registered for the type of that content are invoked and annotate the
item with a full-text bundle, which would then be recognized and indexed
by the search system.  A plug-in architecture would be handy for
integrating with workflows, or as part of a batch process to be run as
part of regular content 'maintenance.'  Again, these bundles may need to
be typed; in this case a 'full text' bundle type would be a hint for the
indexer that it could index the contents of that bundle.

Also like thumbnails, the extracted text for content becomes an official
part of the item, perhaps with a flag to indicate that it is an
annotation by the system and was not part of the original submission.



Items Shared by Multiple Collections

Currently DSpace assumes that items are part of a single collection. 
Users would like to share items between collections, even generation
'virtual' collections that are groupings of items from other
collections.

DSpace's data model supports mapping items to multiple collections, but
the GUI tools do not.  If an item is shared between collections, then
the question arises over who controls it.  One solution is to assign an
owning collection to an item.  The administrator of the owning
collection can modify the item, and assign viewing permissions - other
collection administrators do not have such control - they can only place
a reference to the item in their collection.  Administrators who could
not access an item themselves would of course not be able to reference
the item in their collection.  Since items in multiple collections are
references and not copies, if an item is for some reason removed or
withdrawn, then the references will also appear to be removed or
withdrawn.  A possible problem in the future to watch out for will be
when collection administrators want to attach metadata to or annotate
these references.


------------------------------

Date: Tue, 21 Oct 2003 14:39:38 -0400
From: MacKenzie Smith <kenzie at MIT.EDU>
To: "JQ Johnson" <jqj at darkwing.uoregon.edu>
Cc: dspace-general at MIT.EDU
Subject: Re: [Dspace-general] spam alert
Message-ID: <5.2.1.1.2.20031021142524.01e3bdd8 at hesiod>
In-Reply-To: <MMENIDDNIPBIJLHLNFHBMECFCMAA.jqj at darkwing.uoregon.edu>
References: <5.2.1.1.2.20031020124444.02289e40 at po11.mit.edu>
Content-Type: text/plain; charset="us-ascii"; format=flowed
MIME-Version: 1.0
Precedence: list
Message: 2

Hi JQ,

dspace-general is using MIT's centrally managed listserv services
and mail relay, which are run by our central computer services group.
They've been working with AOL, spamcop, etc to demonstrate how
they're eliminating spam and to introduce smtp authentication. As
far as we know, spamcop should be removing MIT from their list soon.

Beyond this, there's not much we in the Libraries can do about it,
but if actual spam is becoming a problem then we'll convert the list
to a moderated one.

Thanks for the heads up,

MacKenzie/

At 10:30 AM 10/20/2003 -0700, JQ Johnson wrote:
>Our institutional spam filters have started to complain about mail to
>dspace-general at mit.edu.  Here's the report for email I got just now:
>
>  pts rule name              description
>---- ----------------------
------------------------------------------------
>--
>  1.9 WEIRD_PORT             URI: Uses non-standard port number for HTTP
>  2.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
>                   [Blocked - see
><http://www.spamcop.net/bl.shtml?18.7.21.86>]
>  1.3 RCVD_IN_NJABL_RELAY    RBL: NJABL: sender is confirmed open relay
>                             [18.7.21.86 listed in dnsbl.njabl.org]
>  0.1 RCVD_IN_NJABL          RBL: Received via a relay in dnsbl.njabl.org
>                             [18.7.21.86 listed in dnsbl.njabl.org]
>
>We'd be very appreciative if MIT could clean up the software on
>melbourne-city-street.mit.edu to eliminate the potential for its use as an
>open relay.  If that can be done, then it will disappear from the NJABL and
>SPAMCOP blacklists.
>
>JQ Johnson                      Office: 115F Knight Library
>Academic Education Coordinator  mailto:jqj at darkwing.uoregon.edu
>1299 University of Oregon       phone: 1-541-346-1746; -3485 fax
>Eugene, OR  97403-1299          http://darkwing.uoregon.edu/~jqj/
>
>
>
>_______________________________________________
>Dspace-general mailing list
>Dspace-general at mit.edu
>http://mailman.mit.edu/mailman/listinfo/dspace-general

MacKenzie Smith
Associate Director for Technology
MIT Libraries
Building 14S-208
77 Massachusetts Avenue
Cambridge, MA  02139
(617)253-8184
kenzie at mit.edu 

------------------------------

_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general


End of Dspace-general Digest, Vol 3, Issue 13
*********************************************

From aramnarine at library.uwi.tt  Wed Oct 22 13:24:21 2003
From: aramnarine at library.uwi.tt (Angela Ramnarine)
Date: Wed, 22 Oct 2003 13:24:21 -0400
Subject: [Dspace-general] RE: Dspace-general Digest, Vol 3, Issue 13
Message-ID: <21530F7443DED311AC3500C04F238E88A3BD13@SANTW40LIBRY001>

Already done.

Angela

-----Original Message-----
From: dspace-general-request at mit.edu
[mailto:dspace-general-request at mit.edu]
Sent: Wednesday, October 22, 2003 12:01 PM
To: dspace-general at mit.edu
Subject: Dspace-general Digest, Vol 3, Issue 13


Send Dspace-general mailing list submissions to
	dspace-general at mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.mit.edu/mailman/listinfo/dspace-general
or, via email, send a message with subject or body 'help' to
	dspace-general-request at mit.edu

You can reach the person managing the list at
	dspace-general-owner at mit.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dspace-general digest..."


Today's Topics:

   1. DSpace 1.2 Feature Descriptions (Richard Rodgers)
   2. Re: spam alert (MacKenzie Smith)


----------------------------------------------------------------------

Date: 21 Oct 2003 14:40:46 -0400
From: Richard Rodgers <rrodgers at MIT.EDU>
To: dspace-general at MIT.EDU
Subject: [Dspace-general] DSpace 1.2 Feature Descriptions
Message-ID: <1066761646.25056.73.camel at dspace-03.mit.edu>
Content-Type: text/plain
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 1


As promised, what follows are descriptions of several of the proposed
new features for DSpace 1.2. Please post comments and suggestions to
this list: we welcome your input!

Content Thumbnail Support

In DSpace's item display graphical content currently only has text to
describe it - users would like to see thumbnails, a more intuitive
representation.  Clicking on the thumbnail would then deliver the
content to the user.  Users may want to supply their own thumbnails, but
the vast majority would probably prefer to have the system generate
thumbnails for them.

There will probably be four methods of adding thumbnails to an item: 
the system could generate automatically during the workflow of
submission, a batch process accessing the repository could add thumbnail
bundles to items lacking them, or users could submit thumbnails along
with the item (highly unlikely!), or the system could generate
thumbnails dynamically.  To integrate thumbnail generation into a
workflow, DSpace needs to be able to take advantage of all of the tools
available to generate thumbnails, and many are not written in Java. 
Many of these tools are also specific types of content - some are image
tools, PDF utilities, or a even a script tying multiple tools together. 
A 'plug-in' architecture could handle these scenarios well:  a group of
classes wrap whatever tools are needed to generate thumbnails, and
register for certain types of submitted content. As content is
submitted, its type is checked and it is handed off to the
classes that want to process submitted content of that type.
A batch tool could also be created that used the same registry of
content handlers, looking for items without thumbnails, and then
attempting to create thumbnails when possible. 

Storing thumbnails shouldn't involve too many changes to the system. 
(None, if the thumbnails are generated dynamically.)  DSpace was
architected with alternate views of content in mind, where items can
have multiple bundles, each containing a different representation of the
item's content.  A thumbnail could simply be another bundle within the
item.  The item display page could look for a thumbnail bundle
containing images for each bitstream in the primary bundle (we may need
a type field to identify the primary bundle vs. a PDF or thumbnail or
extracted text bundle,) and then display the thumbnail next to the file
name. 

The thumbnail becomes an official part of the item, or a flag could be
used to indicate that the thumbnail is an annotation by the system
rather than a part of the original submission.


Full Text Searching

Currently DSpace users can only search the metadata for items - the text
that may be within the content is not searchable.  Users would like to
search the full text of items within DSpace.  It may also be handy for
users to have access to the extracted text for an item, possibly in the
'full' item display.

Our search engine Lucene can easily index the full text from items, so
the challenge is really extracting and storing the full text of
submitted items. This problem is remarkably similar to the generation of
thumbnails: generating a 'text' representation of an item's content is
very similar to generating a thumbnail representation of that content. 
DSpace's object model supports different representations of content with
bundles - each bundle stores a representation. 

Like thumbnail generation, there are many tools available to extract
text from content, many of which are not in Java, and many are specific
to certain types of content.  Again, a plug-in architecture would handle
representation generation well - as content is submitted, classes
registered for the type of that content are invoked and annotate the
item with a full-text bundle, which would then be recognized and indexed
by the search system.  A plug-in architecture would be handy for
integrating with workflows, or as part of a batch process to be run as
part of regular content 'maintenance.'  Again, these bundles may need to
be typed; in this case a 'full text' bundle type would be a hint for the
indexer that it could index the contents of that bundle.

Also like thumbnails, the extracted text for content becomes an official
part of the item, perhaps with a flag to indicate that it is an
annotation by the system and was not part of the original submission.



Items Shared by Multiple Collections

Currently DSpace assumes that items are part of a single collection. 
Users would like to share items between collections, even generation
'virtual' collections that are groupings of items from other
collections.

DSpace's data model supports mapping items to multiple collections, but
the GUI tools do not.  If an item is shared between collections, then
the question arises over who controls it.  One solution is to assign an
owning collection to an item.  The administrator of the owning
collection can modify the item, and assign viewing permissions - other
collection administrators do not have such control - they can only place
a reference to the item in their collection.  Administrators who could
not access an item themselves would of course not be able to reference
the item in their collection.  Since items in multiple collections are
references and not copies, if an item is for some reason removed or
withdrawn, then the references will also appear to be removed or
withdrawn.  A possible problem in the future to watch out for will be
when collection administrators want to attach metadata to or annotate
these references.


------------------------------

Date: Tue, 21 Oct 2003 14:39:38 -0400
From: MacKenzie Smith <kenzie at MIT.EDU>
To: "JQ Johnson" <jqj at darkwing.uoregon.edu>
Cc: dspace-general at MIT.EDU
Subject: Re: [Dspace-general] spam alert
Message-ID: <5.2.1.1.2.20031021142524.01e3bdd8 at hesiod>
In-Reply-To: <MMENIDDNIPBIJLHLNFHBMECFCMAA.jqj at darkwing.uoregon.edu>
References: <5.2.1.1.2.20031020124444.02289e40 at po11.mit.edu>
Content-Type: text/plain; charset="us-ascii"; format=flowed
MIME-Version: 1.0
Precedence: list
Message: 2

Hi JQ,

dspace-general is using MIT's centrally managed listserv services
and mail relay, which are run by our central computer services group.
They've been working with AOL, spamcop, etc to demonstrate how
they're eliminating spam and to introduce smtp authentication. As
far as we know, spamcop should be removing MIT from their list soon.

Beyond this, there's not much we in the Libraries can do about it,
but if actual spam is becoming a problem then we'll convert the list
to a moderated one.

Thanks for the heads up,

MacKenzie/

At 10:30 AM 10/20/2003 -0700, JQ Johnson wrote:
>Our institutional spam filters have started to complain about mail to
>dspace-general at mit.edu.  Here's the report for email I got just now:
>
>  pts rule name              description
>---- ----------------------
------------------------------------------------
>--
>  1.9 WEIRD_PORT             URI: Uses non-standard port number for HTTP
>  2.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
>                   [Blocked - see
><http://www.spamcop.net/bl.shtml?18.7.21.86>]
>  1.3 RCVD_IN_NJABL_RELAY    RBL: NJABL: sender is confirmed open relay
>                             [18.7.21.86 listed in dnsbl.njabl.org]
>  0.1 RCVD_IN_NJABL          RBL: Received via a relay in dnsbl.njabl.org
>                             [18.7.21.86 listed in dnsbl.njabl.org]
>
>We'd be very appreciative if MIT could clean up the software on
>melbourne-city-street.mit.edu to eliminate the potential for its use as an
>open relay.  If that can be done, then it will disappear from the NJABL and
>SPAMCOP blacklists.
>
>JQ Johnson                      Office: 115F Knight Library
>Academic Education Coordinator  mailto:jqj at darkwing.uoregon.edu
>1299 University of Oregon       phone: 1-541-346-1746; -3485 fax
>Eugene, OR  97403-1299          http://darkwing.uoregon.edu/~jqj/
>
>
>
>_______________________________________________
>Dspace-general mailing list
>Dspace-general at mit.edu
>http://mailman.mit.edu/mailman/listinfo/dspace-general

MacKenzie Smith
Associate Director for Technology
MIT Libraries
Building 14S-208
77 Massachusetts Avenue
Cambridge, MA  02139
(617)253-8184
kenzie at mit.edu 

------------------------------

_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general


End of Dspace-general Digest, Vol 3, Issue 13
*********************************************

From ajhatfie at iupui.edu  Wed Oct 22 18:03:09 2003
From: ajhatfie at iupui.edu (Hatfield, Amy J)
Date: Wed, 22 Oct 2003 17:03:09 -0500
Subject: [Dspace-general] DSpace 1.2 Feature Descriptions
Message-ID: <34FCF4854FC72B478C655EFD2CE8FD34E91E32@iu-mssg-mbx03.exchange.iu.edu>

I emphatically agree that full text indexing should be a priority!  I
also feel that the ability of items to 'belong' to more than one
Collection and the ability to create 'Virtual' Collections, with a
single 'owner' Collection, is desirable.

Finally, the suggestion, "...it would be great to be able to add files
in case something has been accidentally left off or found later after an
item has been submitted.", is right on target.  I would like to see this
functionality as well.  It could be that an Item ends up with cumulative
versions and it would be so fantastic if the versions could be added to
the same Item allowing end users to view the different versions in 1
place.  Very powerful!

Thanks,
Amy

Amy Jo Hatfield
Information Systems Librarian
Ruth Lilly Medical Library
317-278-8402
ajhatfie at iupui.edu
 

-----Original Message-----
From: dspace-general-bounces at mit.edu
[mailto:dspace-general-bounces at mit.edu] On Behalf Of Strongin-Garry,
Ilene (IHG)
Sent: Wednesday, October 22, 2003 12:50 PM
To: 'dspace-general at mit.edu'
Subject: [Dspace-general] DSpace 1.2 Feature Descriptions

The features named are definitely desired.  Full-text searching is
probably
first on the list.  We would also like to be able to put an item into
more
than one collection.

Also would like to see an Administer Interface that lets administrators
search for items not just be ID, but also by title or keywords or
authors
(as was mentioned by another user in a previous DSpace digest).  I've
also
had a request for better ASCII recognition (in the case of symbols like
umlauts and currency.  Also the following would be great:  
When submitting an item, you are asked to submit to a collection.
However,
once you choose the collection it cannot be changed without having to
re-enter the entire amount of metadata and files.  I would like to have
the
option to correct my collection choice.

Secondly, it would be great to be able to add additional files to an
item
once it's in DSpace.  I know you can edit metadata, but it would be
great to
be able to add files in case something has been accidentally left off or
found later after an item has been submitted.

-----Original Message-----
From: dspace-general-request at mit.edu
[mailto:dspace-general-request at mit.edu]
Sent: Wednesday, October 22, 2003 12:01 PM
To: dspace-general at mit.edu
Subject: Dspace-general Digest, Vol 3, Issue 13


Send Dspace-general mailing list submissions to
	dspace-general at mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.mit.edu/mailman/listinfo/dspace-general
or, via email, send a message with subject or body 'help' to
	dspace-general-request at mit.edu

You can reach the person managing the list at
	dspace-general-owner at mit.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dspace-general digest..."


Today's Topics:

   1. DSpace 1.2 Feature Descriptions (Richard Rodgers)
   2. Re: spam alert (MacKenzie Smith)


----------------------------------------------------------------------

Date: 21 Oct 2003 14:40:46 -0400
From: Richard Rodgers <rrodgers at MIT.EDU>
To: dspace-general at MIT.EDU
Subject: [Dspace-general] DSpace 1.2 Feature Descriptions
Message-ID: <1066761646.25056.73.camel at dspace-03.mit.edu>
Content-Type: text/plain
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 1


As promised, what follows are descriptions of several of the proposed
new features for DSpace 1.2. Please post comments and suggestions to
this list: we welcome your input!

Content Thumbnail Support

In DSpace's item display graphical content currently only has text to
describe it - users would like to see thumbnails, a more intuitive
representation.  Clicking on the thumbnail would then deliver the
content to the user.  Users may want to supply their own thumbnails, but
the vast majority would probably prefer to have the system generate
thumbnails for them.

There will probably be four methods of adding thumbnails to an item: 
the system could generate automatically during the workflow of
submission, a batch process accessing the repository could add thumbnail
bundles to items lacking them, or users could submit thumbnails along
with the item (highly unlikely!), or the system could generate
thumbnails dynamically.  To integrate thumbnail generation into a
workflow, DSpace needs to be able to take advantage of all of the tools
available to generate thumbnails, and many are not written in Java. 
Many of these tools are also specific types of content - some are image
tools, PDF utilities, or a even a script tying multiple tools together. 
A 'plug-in' architecture could handle these scenarios well:  a group of
classes wrap whatever tools are needed to generate thumbnails, and
register for certain types of submitted content. As content is
submitted, its type is checked and it is handed off to the
classes that want to process submitted content of that type.
A batch tool could also be created that used the same registry of
content handlers, looking for items without thumbnails, and then
attempting to create thumbnails when possible. 

Storing thumbnails shouldn't involve too many changes to the system. 
(None, if the thumbnails are generated dynamically.)  DSpace was
architected with alternate views of content in mind, where items can
have multiple bundles, each containing a different representation of the
item's content.  A thumbnail could simply be another bundle within the
item.  The item display page could look for a thumbnail bundle
containing images for each bitstream in the primary bundle (we may need
a type field to identify the primary bundle vs. a PDF or thumbnail or
extracted text bundle,) and then display the thumbnail next to the file
name. 

The thumbnail becomes an official part of the item, or a flag could be
used to indicate that the thumbnail is an annotation by the system
rather than a part of the original submission.


Full Text Searching

Currently DSpace users can only search the metadata for items - the text
that may be within the content is not searchable.  Users would like to
search the full text of items within DSpace.  It may also be handy for
users to have access to the extracted text for an item, possibly in the
'full' item display.

Our search engine Lucene can easily index the full text from items, so
the challenge is really extracting and storing the full text of
submitted items. This problem is remarkably similar to the generation of
thumbnails: generating a 'text' representation of an item's content is
very similar to generating a thumbnail representation of that content. 
DSpace's object model supports different representations of content with
bundles - each bundle stores a representation. 

Like thumbnail generation, there are many tools available to extract
text from content, many of which are not in Java, and many are specific
to certain types of content.  Again, a plug-in architecture would handle
representation generation well - as content is submitted, classes
registered for the type of that content are invoked and annotate the
item with a full-text bundle, which would then be recognized and indexed
by the search system.  A plug-in architecture would be handy for
integrating with workflows, or as part of a batch process to be run as
part of regular content 'maintenance.'  Again, these bundles may need to
be typed; in this case a 'full text' bundle type would be a hint for the
indexer that it could index the contents of that bundle.

Also like thumbnails, the extracted text for content becomes an official
part of the item, perhaps with a flag to indicate that it is an
annotation by the system and was not part of the original submission.



Items Shared by Multiple Collections

Currently DSpace assumes that items are part of a single collection. 
Users would like to share items between collections, even generation
'virtual' collections that are groupings of items from other
collections.

DSpace's data model supports mapping items to multiple collections, but
the GUI tools do not.  If an item is shared between collections, then
the question arises over who controls it.  One solution is to assign an
owning collection to an item.  The administrator of the owning
collection can modify the item, and assign viewing permissions - other
collection administrators do not have such control - they can only place
a reference to the item in their collection.  Administrators who could
not access an item themselves would of course not be able to reference
the item in their collection.  Since items in multiple collections are
references and not copies, if an item is for some reason removed or
withdrawn, then the references will also appear to be removed or
withdrawn.  A possible problem in the future to watch out for will be
when collection administrators want to attach metadata to or annotate
these references.


------------------------------

Date: Tue, 21 Oct 2003 14:39:38 -0400
From: MacKenzie Smith <kenzie at MIT.EDU>
To: "JQ Johnson" <jqj at darkwing.uoregon.edu>
Cc: dspace-general at MIT.EDU
Subject: Re: [Dspace-general] spam alert
Message-ID: <5.2.1.1.2.20031021142524.01e3bdd8 at hesiod>
In-Reply-To: <MMENIDDNIPBIJLHLNFHBMECFCMAA.jqj at darkwing.uoregon.edu>
References: <5.2.1.1.2.20031020124444.02289e40 at po11.mit.edu>
Content-Type: text/plain; charset="us-ascii"; format=flowed
MIME-Version: 1.0
Precedence: list
Message: 2

Hi JQ,

dspace-general is using MIT's centrally managed listserv services
and mail relay, which are run by our central computer services group.
They've been working with AOL, spamcop, etc to demonstrate how
they're eliminating spam and to introduce smtp authentication. As
far as we know, spamcop should be removing MIT from their list soon.

Beyond this, there's not much we in the Libraries can do about it,
but if actual spam is becoming a problem then we'll convert the list
to a moderated one.

Thanks for the heads up,

MacKenzie/

At 10:30 AM 10/20/2003 -0700, JQ Johnson wrote:
>Our institutional spam filters have started to complain about mail to
>dspace-general at mit.edu.  Here's the report for email I got just now:
>
>  pts rule name              description
>---- ----------------------
------------------------------------------------
>--
>  1.9 WEIRD_PORT             URI: Uses non-standard port number for
HTTP
>  2.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in
bl.spamcop.net
>                   [Blocked - see
><http://www.spamcop.net/bl.shtml?18.7.21.86>]
>  1.3 RCVD_IN_NJABL_RELAY    RBL: NJABL: sender is confirmed open relay
>                             [18.7.21.86 listed in dnsbl.njabl.org]
>  0.1 RCVD_IN_NJABL          RBL: Received via a relay in
dnsbl.njabl.org
>                             [18.7.21.86 listed in dnsbl.njabl.org]
>
>We'd be very appreciative if MIT could clean up the software on
>melbourne-city-street.mit.edu to eliminate the potential for its use as
an
>open relay.  If that can be done, then it will disappear from the NJABL
and
>SPAMCOP blacklists.
>
>JQ Johnson                      Office: 115F Knight Library
>Academic Education Coordinator  mailto:jqj at darkwing.uoregon.edu
>1299 University of Oregon       phone: 1-541-346-1746; -3485 fax
>Eugene, OR  97403-1299          http://darkwing.uoregon.edu/~jqj/
>
>
>
>_______________________________________________
>Dspace-general mailing list
>Dspace-general at mit.edu
>http://mailman.mit.edu/mailman/listinfo/dspace-general

MacKenzie Smith
Associate Director for Technology
MIT Libraries
Building 14S-208
77 Massachusetts Avenue
Cambridge, MA  02139
(617)253-8184
kenzie at mit.edu 

------------------------------

_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general


End of Dspace-general Digest, Vol 3, Issue 13
*********************************************
_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general


From ardp at drtc.isibang.ac.in  Thu Oct 23 01:22:26 2003
From: ardp at drtc.isibang.ac.in (ard)
Date: Thu, 23 Oct 2003 10:52:26 +0530
Subject: [Dspace-general] 
Message-ID: <004f01c39925$a5e517c0$2402a8c0@isibang.ac.in>

I have configured Dspace on Redhat 9.0, using apache+ssl+tomcat4.0.6

Though in Apache configuration, I have used user
and Group as Apache (as against the suggestion to
use dspace user).  It is working.  Will there be
any side effects for this.  The problem is, if I
change the user, group as something other than
apache many of my other software do not work
(e.g. squirrelmail).  Please let me know.


-- ard


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20031023/4201fc61/attachment.htm

From harnad at ecs.soton.ac.uk  Sun Oct 26 05:43:42 2003
From: harnad at ecs.soton.ac.uk (Stevan Harnad)
Date: Sun, 26 Oct 2003 10:43:42 +0000 (GMT)
Subject: [Dspace-general] Re: Berlin Declaration on Open Access
In-Reply-To: <Pine.GSO.4.10.10310240240080.11966-100000@pandora>
Message-ID: <Pine.GSO.4.10.10310261014090.273-100000@pandora>

Below is a web series of powerpoint slides. The first one is the excerpted
core of the Berlin Declaration, followed by a series of suggestions
about how the Declaration could be implemented by universities and
research-funders. Please note that the implementation suggestions are
my own; they are *not* part of the Berlin Declaration.

http://www.ecs.soton.ac.uk/~harnad/Temp/berlin.htm

The original powerpoints for the above are also available and permission
is granted to anyone who wishes to use them in promoting open access. They
are part of a longer series of powerpoints, also linked below, for which
permission is likewise granted to use them to promote open access.
(Please give credit to Tim Brody, my doctoral student, who helped me
create them):

http://www.ecs.soton.ac.uk/~harnad/Temp/berlin.ppt
http://www.ecs.soton.ac.uk/~harnad/Temp/self-archiving.ppt
http://www.ecs.soton.ac.uk/~harnad/Temp/self-archiving.htm

Stevan Harnad

NOTE: Complete archive of the ongoing discussion of providing open
access to the peer-reviewed research literature online is available at
the American Scientist September Forum (98 & 99 & 00 & 01 & 02 & 03):
    http://amsci-forum.amsci.org/archives/september98-forum.html
    http://www.cogsci.soton.ac.uk/~harnad/Hypermail/Amsci/index.html
    Posted discussion to: september98-forum at amsci-forum.amsci.org 

Dual Open-Access Strategy:
    BOAI-2: Publish your article in a suitable open-access journal
            whenever one exists.
    BOAI-1: Otherwise, publish your article in a suitable toll-access
            journal and also self-archive it.
    http://www.soros.org/openaccess/read.shtml