From annamavroudi at yahoo.gr  Sat Nov  3 08:12:50 2007
From: annamavroudi at yahoo.gr (anna mavroudi)
Date: Sat, 3 Nov 2007 12:12:50 +0000 (GMT)
Subject: [Dspace-general] problem with the pluggable package importer and
	exporter
Message-ID: <812422.48884.qm@web27715.mail.ukl.yahoo.com>

Hi all, 
  i'm trying to import items into dspace using the pluggable package importer.
  So, I typed the following lines to the command line:
  C:\DSpace\bin\dsrun org.dspace.app.packager.Packager 
  -e annamavroudi at yahoo.gr  -c 123456789/2 
  -t PDF C:\import_package_test1\ebd9_10.pdf
   
  where C:\import_package_test1\ebd9_10.pdf   is the item's path.
   
  But i got the following error:
  Using Dspace installation in C:\Dspace
  Destination Collections:
  Owning Collection: ???????????? ??????????
  org.dspace.content.crosswalk.MetadataValidationException: This packager cannot accept an encrypted PDF document
         at org.dspace.content.packager.PDFPackager.crosswalkPDF<PDFPackager.java:282>
  at org.dspace.content.packager.PDFPackager.ingest<PDFPackager.java:185>
  at org.dspace.content.packager.PDFPackager.main<PDFPackager.java:274>
  org.dspace.content.crosswalk.MetadataValidationException: This packager cannot accept an encrypted PDF document
   
  why do i get this error?
  thanks in advance,
  anna

 		
---------------------------------
 ?????????????? Yahoo!
 ?????????? ?? ?????????? ???? ???? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? 
 http://login.yahoo.com/config/mail?.intl=gr 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20071103/5696bcfe/attachment.htm

From lcs at MIT.EDU  Mon Nov  5 15:21:35 2007
From: lcs at MIT.EDU (Larry Stone)
Date: Mon, 5 Nov 2007 15:21:35 EST
Subject: [Dspace-general] problem with the pluggable package importer
 and exporter
In-Reply-To: Your message of Sat, 3 Nov 2007 12:12:50 +0000 (GMT)
Message-ID: <CMM.0.90.4.1194294095.lcs@crufthenge.mit.edu>

The message with the exception was supposed to be pretty self-explanatory:
"This packager cannot accept an encrypted PDF document" -- if the PDF is
set so it cannot be printed or edited, that is done by encrypting it.
The PDFbox tools which extract metadata from the PDF "package" may not work,
so it is rejected.  Turn off the encryption in the PDF if you can..

Note that the PDF "packager" is really just an example and was written
to demonstrate the concept of package ingesters.  It wasn't really intended
to be used in production, since PDF files don't have adequate metadata anyway.

    -- Larry


>   i'm trying to import items into dspace using the pluggable package importer.
>   So, I typed the following lines to the command line:
>   C:\DSpace\bin\dsrun org.dspace.app.packager.Packager
>   -e annamavroudi at yahoo.gr  -c 123456789/2
>   -t PDF C:\import_package_test1\ebd9_10.pdf
>
>   where C:\import_package_test1\ebd9_10.pdf   is the item's path.
>
>   But i got the following error:
>   Using Dspace installation in C:\Dspace
>   Destination Collections:
>   Owning Collection:
>   org.dspace.content.crosswalk.MetadataValidationException: This packager cannot accept an encrypted PDF document
>          at org.dspace.content.packager.PDFPackager.crosswalkPDF<PDFPackager.java:282>
>   at org.dspace.content.packager.PDFPackager.ingest<PDFPackager.java:185>
>   at org.dspace.content.packager.PDFPackager.main<PDFPackager.java:274>
>   org.dspace.content.crosswalk.MetadataValidationException: This packager cannot accept an encrypted PDF document
>
>   why do i get this error?
>   thanks in advance,
>   anna
>
>
> ---------------------------------
>   Yahoo!
>       (spam);  Yahoo! Mail
>  http://login.yahoo.com/config/mail?.intl=gr
> --0-1772219453-1194091970=:48884
> Content-Type: text/html; charset=iso-8859-7
> Content-Transfer-Encoding: 8bit
>
> <div>Hi all, </div>  <div>i'm trying to import items into dspace using the pluggable package importer.</div>  <div>So, I typed the following lines to the command line:</div>  <div><SPAN lang=EN-GB style="mso-ansi-language: EN-GB"><FONT face="Times New Roman" size=3>C:\DSpace\bin\dsrun org.dspace.app.packager.Packager </FONT></SPAN></div>  <div><SPAN lang=EN-GB style="mso-ansi-language: EN-GB"><FONT face="Times New Roman" size=3>-e </FONT><A href="mailto:annamavroudi at yahoo.gr"><FONT face="Times New Roman" size=3>annamavroudi at yahoo.gr</FONT></A><FONT size=3><FONT face="Times New Roman"><SPAN style="mso-spacerun: yes">&nbsp; </SPAN>-c 123456789/2 </FONT></FONT></SPAN></div>  <div><SPAN lang=EN-GB style="mso-ansi-language: EN-GB"><FONT size=3><FONT face="Times New Roman">-t PDF C:\import_package_test1\ebd9_10.pdf<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></FONT></FONT></SPAN></div>  <div>&nbsp;</div>  <div>where <SPAN lang=EN-GB
>  style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">C:\import_package_test1\ebd9_10.pdf&nbsp;&nbsp; is the item's path.</SPAN></div>  <div><SPAN lang=EN-GB style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA"></SPAN>&nbsp;</div>  <div><SPAN lang=EN-GB style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">But i got the following error:</SPAN></div>  <div><SPAN lang=EN-GB style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">Using
>  Dspace installation in C:\Dspace</SPAN></div>  <div><SPAN lang=EN-GB style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">Destination Collections:</SPAN></div>  <div><SPAN lang=EN-GB style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">Owning Collection:  </SPAN></div>  <div><SPAN lang=EN-GB style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">org.dspace.content.crosswalk.MetadataValidationException: This packager cannot accept an encrypted PDF document</SPAN></div>  <div><SPAN lang=EN-GB style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY:
>  'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;at org.dspace.content.packager.PDFPackager.crosswalkPDF&lt;PDFPackager.java:282&gt;</SPAN></div>  <div><SPAN lang=EN-GB style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">at org.dspace.content.packager.PDFPackager.ingest&lt;PDFPackager.java:185&gt;</SPAN></div>  <div><SPAN lang=EN-GB style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">at org.dspace.content.packager.PDFPackager.main&lt;PDFPackager.java:274&gt;</SPAN></div><SPAN lang=EN-GB style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman';
>  mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">  <div><SPAN lang=EN-GB style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">org.dspace.content.crosswalk.MetadataValidationException: This packager cannot accept an encrypted PDF document</SPAN></div></SPAN>  <div><SPAN lang=EN-GB style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA"></SPAN>&nbsp;</div>  <div><SPAN lang=EN-GB style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">why do i get this error?</SPAN></div>  <div><SPAN lang=EN-GB
>  style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">thanks in advance,</SPAN></div>  <div><SPAN lang=EN-GB style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">anna</SPAN></div><p>&#32;
>               <hr size=1><font size=-1 face=Arial>
>  Yahoo!<br>
>      (spam);  Yahoo! Mail          <br>
> <a href="http://login.yahoo.com/config/mail?.intl=gr">http://login.yahoo.com/config/mail?.intl=gr</a> </font>
> --0-1772219453-1194091970=:48884--
>
> --===============1373228826==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Dspace-general mailing list
> Dspace-general at mit.edu
> http://mailman.mit.edu/mailman/listinfo/dspace-general
>
> --===============1373228826==--



From susan.parham at gmail.com  Tue Nov  6 09:50:14 2007
From: susan.parham at gmail.com (Susan Parham)
Date: Tue, 6 Nov 2007 09:50:14 -0500
Subject: [Dspace-general] Library catalog/repository overlap
Message-ID: <5f4ba2340711060650q5bd31979j67579a3027daec37@mail.gmail.com>

I'm curious as to how other institutions handle overlap between their
catalog and repository item records.  The obvious collection example
is ETDs, though we have other local collections which also appear in
both our catalog and IR.

We have never included call numbers in our repository, but now that we
are changing our workflow to create catalog records directly from
repository records, some of our librarians want the inclusion of call
numbers (including for non-print items).  Does anyone else do this?

Additionally, how do others plan to handle duplicate records via a
next gen library search interface such as VuFind?  We have discussed
suppressing the catalog record in favor of the repository record
because it provides the full-text.  In such a scenario, the call
number of the print item would not then be available.

Your thoughts?

-- 
Susan Wells Parham
Digital Repository Architect
Georgia Institute of Technology
Library & Information Center
404-894-4522
susan.parham at gatech.edu


From swarna.bandara at uwimona.edu.jm  Tue Nov  6 10:51:42 2007
From: swarna.bandara at uwimona.edu.jm (Swarna Bandara)
Date: Tue, 6 Nov 2007 10:51:42 -0500
Subject: [Dspace-general] Library catalog/repository overlap
In-Reply-To: <5f4ba2340711060650q5bd31979j67579a3027daec37@mail.gmail.com>
Message-ID: <001701c8208c$ed57be80$c1003ac6@uwimona.edu.jm>


There will be an overlap between catalogue and IR records; this can not be
prevented unless one is willing to compromise the subject access. Meaning
when you catalogue a theses for an example, you will include subject
headings using a controlled vocabulary, where as with IR, this is not
possible. Subject access is only through key words.

I think at the last year's ETD conference National Library of Canada made a
presentation on not including theses in the catalogue and saving that they
made by doing so. There were concerns raised at this presentation about
limiting the subject access points.

Suppressing the catalogue to give way for IR again will compromise the
subject access. I know more libraries include in their catalogue entry the
IR location of the item. So there is a link from the catalogue entry to the
full text item, when ever it is available.

Hope this is helpful

Swarna Bandara
Head, Medical Library
ETD Coordinator/Mona Campus
Mona Campus
University of the West Indies
Kingston 7
Jamaica

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

-----Original Message-----
From: dspace-general-bounces at mit.edu [mailto:dspace-general-bounces at mit.edu]
On Behalf Of Susan Parham
Sent: Tuesday, November 06, 2007 9:50 AM
To: dspace
Subject: [Dspace-general] Library catalog/repository overlap

I'm curious as to how other institutions handle overlap between their
catalog and repository item records.  The obvious collection example
is ETDs, though we have other local collections which also appear in
both our catalog and IR.

We have never included call numbers in our repository, but now that we
are changing our workflow to create catalog records directly from
repository records, some of our librarians want the inclusion of call
numbers (including for non-print items).  Does anyone else do this?

Additionally, how do others plan to handle duplicate records via a
next gen library search interface such as VuFind?  We have discussed
suppressing the catalog record in favor of the repository record
because it provides the full-text.  In such a scenario, the call
number of the print item would not then be available.

Your thoughts?

-- 
Susan Wells Parham
Digital Repository Architect
Georgia Institute of Technology
Library & Information Center
404-894-4522
susan.parham at gatech.edu
_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general



From Ingrid.Mason at vuw.ac.nz  Tue Nov  6 20:06:33 2007
From: Ingrid.Mason at vuw.ac.nz (Ingrid Mason)
Date: Wed, 7 Nov 2007 14:06:33 +1300
Subject: [Dspace-general] Library catalog/repository overlap
In-Reply-To: <001701c8208c$ed57be80$c1003ac6@uwimona.edu.jm>
Message-ID: <75CF552F30ECFA439D9B3008906F2A37027A9F75@STAWINCOMAILCL1.staff.vuw.ac.nz>

Hi,

I have to disagree about subject access and controlled vocabulary being
compromised in IRs.  The subject metadata you put into an IR can
essentially be whatever is deemed fit for purpose, controlled or
uncontrolled.  We are using controlled vocabulary (research codes)
across the nation here in New Zealand - see nzresearch.org 

At Victoria University of Wellington we are using both the research
codes but also aim to utilise subject specific controlled vocabularies.
To wit we are using the CINAHL thesaurus for the theses and research
papers that come from our Graduate School of Nursing, Midwifery and
Health to enhance intellectual access to those resources.

The overlap of the catalogue and the IR for intellectual access is
inevitable.  If you want the most basic level of cataloguing information
then they are going to share: Author, Title, Publisher and Date.  That
that set of shared metadata might be turned into an efficient work flow
seems entirely fit.  I'm not sure why it would be helpful to have the
call number in an IR record when the item is online.  But it seems
helpful to be able to point to an item where it is available online from
a library catalogue record as they do for links to journals available
fulltext online.  

At Victoria University of Wellington we are continuing to catalogue
Master and Doctorate theses as per usual but now adding a link in the
catalogue record to the item in the repository.  

In terms of purpose, my personal opinion is that the library catalogue
and institutional repositories serve different purposes.  IRs if they
are open access open the metadata up for indexing by search engines and
harvesting by subject specific or open access research hubs.  They may
also offer an opportunity to add a controlled vocabulary that enhances
intellectual access in a way that is different, and complements the
library catalogue.  

But hey, so nice to see this debate online!

Much of the activity is going on behind the scenes and it helps to share
information.  I guess when federated search becomes more of a reality
for more large libraries with multiple repositories of metadata then
this debate will really heat up about where to apply your valuable
cataloguing/metadata attribution resources.  

Cheers, Ingrid

Digital Research Repository Coordinator
ResearchArchive at Victora: http://researcharchive.vuw.ac.nz 
Victoria University of Wellington
New Zealand = Aotearoa




-----Original Message-----
From: dspace-general-bounces at mit.edu
[mailto:dspace-general-bounces at mit.edu] On Behalf Of Swarna Bandara
Sent: Wednesday, 7 November 2007 4:52 a.m.
To: 'Susan Parham'; 'dspace'
Subject: Re: [Dspace-general] Library catalog/repository overlap


There will be an overlap between catalogue and IR records; this can not
be
prevented unless one is willing to compromise the subject access.
Meaning
when you catalogue a theses for an example, you will include subject
headings using a controlled vocabulary, where as with IR, this is not
possible. Subject access is only through key words.

I think at the last year's ETD conference National Library of Canada
made a
presentation on not including theses in the catalogue and saving that
they
made by doing so. There were concerns raised at this presentation about
limiting the subject access points.

Suppressing the catalogue to give way for IR again will compromise the
subject access. I know more libraries include in their catalogue entry
the
IR location of the item. So there is a link from the catalogue entry to
the
full text item, when ever it is available.

Hope this is helpful

Swarna Bandara
Head, Medical Library
ETD Coordinator/Mona Campus
Mona Campus
University of the West Indies
Kingston 7
Jamaica

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

-----Original Message-----
From: dspace-general-bounces at mit.edu
[mailto:dspace-general-bounces at mit.edu]
On Behalf Of Susan Parham
Sent: Tuesday, November 06, 2007 9:50 AM
To: dspace
Subject: [Dspace-general] Library catalog/repository overlap

I'm curious as to how other institutions handle overlap between their
catalog and repository item records.  The obvious collection example
is ETDs, though we have other local collections which also appear in
both our catalog and IR.

We have never included call numbers in our repository, but now that we
are changing our workflow to create catalog records directly from
repository records, some of our librarians want the inclusion of call
numbers (including for non-print items).  Does anyone else do this?

Additionally, how do others plan to handle duplicate records via a
next gen library search interface such as VuFind?  We have discussed
suppressing the catalog record in favor of the repository record
because it provides the full-text.  In such a scenario, the call
number of the print item would not then be available.

Your thoughts?

-- 
Susan Wells Parham
Digital Repository Architect
Georgia Institute of Technology
Library & Information Center
404-894-4522
susan.parham at gatech.edu
_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general

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



From annamavroudi at yahoo.gr  Wed Nov  7 05:56:06 2007
From: annamavroudi at yahoo.gr (anna mavroudi)
Date: Wed, 7 Nov 2007 10:56:06 +0000 (GMT)
Subject: =?iso-8859-7?q?=C8=DD=EC=E1:=20Re:=20[Dspace-general]=20problem=20with=20?=
	=?iso-8859-7?q?the=20pluggable=20package=20importer=20and=20=20=20=20=20?=
	=?iso-8859-7?q?=20=20=20exporter?=
In-Reply-To: <CMM.0.90.4.1194294095.lcs@crufthenge.mit.edu>
Message-ID: <715236.88715.qm@web27706.mail.ukl.yahoo.com>

Hi,
  i forgot to mention that the encryption in the specific pdf document i was trying to import wasn't turned on....
  The fact that pdf documents  don't have adequate metadata means that it is impossible to import them via the package ingester?
  Thanks, Anna

Larry Stone <lcs at mit.edu> ??????:
  The message with the exception was supposed to be pretty self-explanatory:
"This packager cannot accept an encrypted PDF document" -- if the PDF is
set so it cannot be printed or edited, that is done by encrypting it.
The PDFbox tools which extract metadata from the PDF "package" may not work,
so it is rejected. Turn off the encryption in the PDF if you can..

Note that the PDF "packager" is really just an example and was written
to demonstrate the concept of package ingesters. It wasn't really intended
to be used in production, since PDF files don't have adequate metadata anyway.

-- Larry


> i'm trying to import items into dspace using the pluggable package importer.
> So, I typed the following lines to the command line:
> C:\DSpace\bin\dsrun org.dspace.app.packager.Packager
> -e annamavroudi at yahoo.gr -c 123456789/2
> -t PDF C:\import_package_test1\ebd9_10.pdf
>
> where C:\import_package_test1\ebd9_10.pdf is the item's path.
>
> But i got the following error:
> Using Dspace installation in C:\Dspace
> Destination Collections:
> Owning Collection:
> org.dspace.content.crosswalk.MetadataValidationException: This packager cannot accept an encrypted PDF document
> at org.dspace.content.packager.PDFPackager.crosswalkPDF

> at org.dspace.content.packager.PDFPackager.ingest

> at org.dspace.content.packager.PDFPackager.main

> org.dspace.content.crosswalk.MetadataValidationException: This packager cannot accept an encrypted PDF document
>
> why do i get this error?
> thanks in advance,
> anna
>
>
> ---------------------------------
> Yahoo!
> (spam); Yahoo! Mail
> http://login.yahoo.com/config/mail?.intl=gr
> --0-1772219453-1194091970=:48884
> Content-Type: text/html; charset=iso-8859-7
> Content-Transfer-Encoding: 8bit
>
>   Hi all, 
  i'm trying to import items into dspace using the pluggable package importer.
  So, I typed the following lines to the command line:
  C:\DSpace\bin\dsrun org.dspace.app.packager.Packager 
  -e annamavroudi at yahoo.gr  -c 123456789/2 
  -t PDF C:\import_package_test1\ebd9_10.pdf
   
  where > style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">C:\import_package_test1\ebd9_10.pdf   is the item's path.
   
  But i got the following error:
  Using
> Dspace installation in C:\Dspace
  Destination Collections:
  Owning Collection: 
  org.dspace.content.crosswalk.MetadataValidationException: This packager cannot accept an encrypted PDF document
  >  'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">       at org.dspace.content.packager.PDFPackager.crosswalkPDF<PDFPackager.java:282>
  at org.dspace.content.packager.PDFPackager.ingest<PDFPackager.java:185>
  at org.dspace.content.packager.PDFPackager.main<PDFPackager.java:274>
  org.dspace.content.crosswalk.MetadataValidationException: This packager cannot accept an encrypted PDF document
   
  why do i get this error?
  > style="FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: EL; mso-bidi-language: AR-SA">thanks in advance,
  anna
  
>   
---------------------------------
  
> Yahoo!

> (spam); Yahoo! Mail 

> http://login.yahoo.com/config/mail?.intl=gr 
> --0-1772219453-1194091970=:48884--
>
> --===============1373228826==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Dspace-general mailing list
> Dspace-general at mit.edu
> http://mailman.mit.edu/mailman/listinfo/dspace-general
>
> --===============1373228826==--






 		
---------------------------------
 ?????????????? Yahoo!
 ?????????? ?? ?????????? ???? ???? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? 
 http://login.yahoo.com/config/mail?.intl=gr 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20071107/3cbe66ee/attachment.htm

From swarna.bandara at uwimona.edu.jm  Wed Nov  7 18:28:55 2007
From: swarna.bandara at uwimona.edu.jm (Swarna Bandara)
Date: Wed, 7 Nov 2007 18:28:55 -0500
Subject: [Dspace-general] Library catalog/repository overlap
In-Reply-To: <5f4ba2340711071042s699bdd3aj25cc40b7761bdc31@mail.gmail.com>
Message-ID: <001001c82195$f6ec3ca0$06003ac6@uwimona.edu.jm>

Hi Susan & Ingrid

It is interesting to know that you do use LC headings for theses &
dissertations for IR and it is great that it can be done. I did not know
that this was possible and I think now I can see how it can be done.
However, it will involve a different workflow than we plan, as we will do
the self archiving, at least for now. We would not have the man power to
cover the task of subject metadata using LC which I believe must be done by
a librarian. We use LC in our library system and cross-walk form the
catalogue to IR can work without additional work. I have some things to work
out on the work flow. We are still at a very early stage of IR and theses
are not in the front line, because we have not been able to workout the
workflow that everybody can agree.

Ingrid I share your thoughts about the catalogue and IR serving different
purposes and IR complimenting the catalogue. Adding the call number even for
non print items can serve a purpose in that some users do search the
catalogue by call number, when they need the subject break down to follow? 

We at the University of the West Indies have a long way to go, so this
discussion is helpful to me as well.  

Swarna

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

-----Original Message-----
From: Susan Parham [mailto:susan.parham at gmail.com] 
Sent: Wednesday, November 07, 2007 1:43 PM
To: Swarna Bandara
Subject: Re: [Dspace-general] Library catalog/repository overlap

Hi Swarna,

Thanks for your reply.  Actually, we include the LC subject headings
in our IR as well, especially for our retrospective conversion of
theses & dissertations.  Actually, I should be more specific - we have
always included LC subject headings for the theses & dissertations
which we have converted from print and cross-walked from the catalog
into the IR.  Previously, we did not include the LC subject headings
from born digital ETDs because of our workflow, but we are now
changing that practice.  We will now have LC subject headings in our
IR for all of our ETDs -- both those born digital and the
retrospective conversions.

Because of this, suppressing the catalog record will not affect the
subject access.  But, if we don't include the call number in the IR
record, it may affect access to the print item!  The main reason we
are thinking of suppressing the catalog record is because with
metasearching, the user will retrieve the catalog record & the IR
record.  The 856 field in the catalog record will simply point to the
IR record.

Do you have any other thoughts?  Thank you for your comments - very helpful!

Susan

On Nov 6, 2007 10:51 AM, Swarna Bandara <swarna.bandara at uwimona.edu.jm>
wrote:
>
> There will be an overlap between catalogue and IR records; this can not be
> prevented unless one is willing to compromise the subject access. Meaning
> when you catalogue a theses for an example, you will include subject
> headings using a controlled vocabulary, where as with IR, this is not
> possible. Subject access is only through key words.
>
> I think at the last year's ETD conference National Library of Canada made
a
> presentation on not including theses in the catalogue and saving that they
> made by doing so. There were concerns raised at this presentation about
> limiting the subject access points.
>
> Suppressing the catalogue to give way for IR again will compromise the
> subject access. I know more libraries include in their catalogue entry the
> IR location of the item. So there is a link from the catalogue entry to
the
> full text item, when ever it is available.
>
> Hope this is helpful
>
> Swarna Bandara
> Head, Medical Library
> ETD Coordinator/Mona Campus
> Mona Campus
> University of the West Indies
> Kingston 7
> Jamaica
>
> ---------------------------------------------------------------
>
>
> -----Original Message-----
> From: dspace-general-bounces at mit.edu
[mailto:dspace-general-bounces at mit.edu]
> On Behalf Of Susan Parham
> Sent: Tuesday, November 06, 2007 9:50 AM
> To: dspace
> Subject: [Dspace-general] Library catalog/repository overlap
>
> I'm curious as to how other institutions handle overlap between their
> catalog and repository item records.  The obvious collection example
> is ETDs, though we have other local collections which also appear in
> both our catalog and IR.
>
> We have never included call numbers in our repository, but now that we
> are changing our workflow to create catalog records directly from
> repository records, some of our librarians want the inclusion of call
> numbers (including for non-print items).  Does anyone else do this?
>
> Additionally, how do others plan to handle duplicate records via a
> next gen library search interface such as VuFind?  We have discussed
> suppressing the catalog record in favor of the repository record
> because it provides the full-text.  In such a scenario, the call
> number of the print item would not then be available.
>
> Your thoughts?
>
> --
> Susan Wells Parham
> Digital Repository Architect
> Georgia Institute of Technology
> Library & Information Center
> 404-894-4522
> susan.parham at gatech.edu
> _______________________________________________
> Dspace-general mailing list
> Dspace-general at mit.edu
> http://mailman.mit.edu/mailman/listinfo/dspace-general
>
>



-- 
Susan Wells Parham
Digital Repository Architect
Georgia Institute of Technology
Library & Information Center
404-894-4522
susan.parham at gatech.edu



From kalyan_upadhyaya at byu.edu  Thu Nov  8 11:51:07 2007
From: kalyan_upadhyaya at byu.edu (Kalyan Upadhyaya)
Date: Thu, 8 Nov 2007 09:51:07 -0700
Subject: [Dspace-general] Batch upload in D-Space
Message-ID: <E44615519978CD4AA719AF3E5023C0A9432BEEB40B@Plow.exch.ad.byu.edu>

I'm recently started using D-Space, so this might be an easy question to answer.

I have harvested some metadata from various data providers and have it in a database. Is there a way I can do a batch upload of those metadata into D-Space?



Regards,
Kalyan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20071108/3ccd3454/attachment.htm

From pasi.kurvinen at helsinki.fi  Mon Nov 12 07:52:36 2007
From: pasi.kurvinen at helsinki.fi (Pasi Kurvinen)
Date: Mon, 12 Nov 2007 14:52:36 +0200
Subject: [Dspace-general] Customized Navigation - National Library of Finland
Message-ID: <002701c8252a$e696b630$eb5bd680@ad.helsinki.fi>


Hello,

Some background: Our DSpace-project in The National Library of Finland is
based on a consortium model. We are using DSpace to manage and store our own
documents, and we have customer organizations that use the same installation
as their institutional repositories. They typically manage their own branch,
beginning from a high-level community. Some organizations also maintain
their own individual themes.

Our customers often want to have their community separated from the rest of
the site, to have a kind of web site of their own. On the other hand, they
see that it is good for users to have access to rest of documents in site,
too. We have modified our navigation in attempt to find a balance between
these two poles. Some of our users have also complained that the original
navigation was a bit difficult. To comply, we also tried to simplify things
a bit.

I have uploaded a few images that display the main changes we have made. The
first image displays the front page (detailed explanations included in the
image):
http://img2.freeimagehosting.net/uploads/127c06fe8c.gif

The second image shows browsing titles in a collection level:
http://img2.freeimagehosting.net/uploads/d021d3d071.gif

Of course, you are also welcome to visit our web site. 
https://oa.doria.fi/?locale=len
takes you directly to the English version.

If anybody is interested, we are happy to give more information. The changes
mainly concern Manakin's Navigation-class under ArtifactBrowser, and the
structural.xsl-file.

Cheers,

Pasi Kurvinen


-- 

Pasi Kurvinen (Mr.)
Atk-suunnittelija                Systems Analyst
Suomen kansalliskirjasto         The National Library of Finland

Tel. +358 9 191 44592
FAX + 368 9 753 9514

http://www.kansalliskirjasto.fi/






From kalyan_upadhyaya at byu.edu  Mon Nov 12 11:09:01 2007
From: kalyan_upadhyaya at byu.edu (Kalyan Upadhyaya)
Date: Mon, 12 Nov 2007 09:09:01 -0700
Subject: [Dspace-general] Dspace upload requirements
Message-ID: <E44615519978CD4AA719AF3E5023C0A9432BEEB44F@Plow.exch.ad.byu.edu>

Can I upload just the metadata (e.g. paper summary, author, date) in the DSpace, or do I have to upload the whole paper ? I have this question as DSpace won't allow me to complete an entry without browsing to (uploading) an actual file.
Any help is greatly appreciated.

Regards,
Kalyan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20071112/1b6a9456/attachment.htm

From C.Voelker at gmx.net  Mon Nov 12 11:53:10 2007
From: C.Voelker at gmx.net (Christian Voelker)
Date: Mon, 12 Nov 2007 17:53:10 +0100
Subject: [Dspace-general] Dspace upload requirements
In-Reply-To: <E44615519978CD4AA719AF3E5023C0A9432BEEB44F@Plow.exch.ad.byu.edu>
References: <E44615519978CD4AA719AF3E5023C0A9432BEEB44F@Plow.exch.ad.byu.edu>
Message-ID: <A538EC87-E8F2-4741-A8EE-D184F7D94C10@gmx.net>

Hello,

Am 12.11.2007 um 17:09 schrieb Kalyan Upadhyaya:

> Can I upload just the metadata (e.g. paper summary, author, date)  
> in the DSpace, or do I have to upload the whole paper ? I have this  
> question as DSpace won?t allow me to complete an entry without  
> browsing to (uploading) an actual file.
I have a hard to understand what it would be worth
to do so. After all, DSpace is about archiving and
not just creating a catalog. But I guess you can
add an arbitrary file or even an empty file,
finish your ingestion process and then change
your item. The workflow isnt considered then
and you should be able to remove the nonsense
bitstream, thus creating an item without media.

Bye, Christian






From C.Voelker at gmx.net  Mon Nov 12 13:29:02 2007
From: C.Voelker at gmx.net (Christian Voelker)
Date: Mon, 12 Nov 2007 19:29:02 +0100
Subject: [Dspace-general] Dspace upload requirements
In-Reply-To: <ce611b9c0711120901l66a5365fi5124be67ba721d2c@mail.gmail.com>
References: <E44615519978CD4AA719AF3E5023C0A9432BEEB44F@Plow.exch.ad.byu.edu>
	<A538EC87-E8F2-4741-A8EE-D184F7D94C10@gmx.net>
	<ce611b9c0711120901l66a5365fi5124be67ba721d2c@mail.gmail.com>
Message-ID: <83778906-7AB7-4C18-86C4-0380C399D2F2@gmx.net>

Hello,

Am 12.11.2007 um 18:01 schrieb Kalyan Upadhyaya:

> I'm harvesting metadata from arxiv.org using PKP OAI harvester. So I
> don't have any pdf files or objects from arXiv.org but just the
> metadata. Then I want to upload those metadata into DSpace repository
> that my institution is already using.
> Is DSpace able to serve this purpose?

I am the tech guy for our site, so may not have right perspective.
It might make sense to do this to be able to search across your own
and the foreign data in one step. I dont know other ways to link two
repositories that keep content that is related in some way. We have
a site that works separately from others.

Your are in the right place to discuss this here on the general list.
However I understood your former question as more technically oriented.
I bet you can do this using the batch importer either right away or
with very little modification. If you need more help, you should
post further questions regarding this on the tech list. I have not
used the batch importer myself so far.

I see the advantage of an integrated search for content but think there
should be a link to the original source within each item. Maybe the data
harvested from the external source can be modified before import using
a script to add a link on a per item base to the metadata? This too
might be a thing you should ask about on the tech list.

Bye, Christian





From sdl at aber.ac.uk  Tue Nov 13 04:26:58 2007
From: sdl at aber.ac.uk (Stuart Lewis [sdl])
Date: Tue, 13 Nov 2007 09:26:58 -0000
Subject: [Dspace-general] Dspace upload requirements
In-Reply-To: <E44615519978CD4AA719AF3E5023C0A9432BEEB44F@Plow.exch.ad.byu.edu>
References: <E44615519978CD4AA719AF3E5023C0A9432BEEB44F@Plow.exch.ad.byu.edu>
Message-ID: <10EEADDAD601FA4D83DF79F3281B8CF6633F53@ISSVEXBE1.staff.aber.ac.uk>

Hi Kalyan,

There is a patch available to enable this at:

http://sourceforge.net/tracker/index.php?func=detail&aid=1370187&group_i
d=19984&atid=319984

This functionality will also be available in DSpace 1.5 when it is
released as part of the configurable submission system.

Thanks,


Stuart
_________________________________________________________________

Gwasanaethau Gwybodaeth                      Information Services
Prifysgol Aberystwyth                      Aberystwyth University

            E-bost / E-mail: Stuart.Lewis at aber.ac.uk             
                 Ffon / Tel: (01970) 622860
_________________________________________________________________




From: dspace-general-bounces at mit.edu
[mailto:dspace-general-bounces at mit.edu] On Behalf Of Kalyan Upadhyaya
Sent: 12 November 2007 16:09
To: Dspace-general at mit.edu
Subject: [Dspace-general] Dspace upload requirements

Can I upload just the metadata (e.g. paper summary, author, date) in the
DSpace, or do I have to upload the whole paper ? I have this question as
DSpace won't allow me to complete an entry without browsing to
(uploading) an actual file.
Any help is greatly appreciated. 

Regards, 
Kalyan



From Kovacev at ceu.hu  Tue Nov 13 06:55:34 2007
From: Kovacev at ceu.hu (Branislav Kovacevic)
Date: Tue, 13 Nov 2007 12:55:34 +0100
Subject: [Dspace-general] Author names in collections closed for public
	access
In-Reply-To: <002701c8252a$e696b630$eb5bd680@ad.helsinki.fi>
References: <002701c8252a$e696b630$eb5bd680@ad.helsinki.fi>
Message-ID: <47399EC6.0883.00A1.0@ceu.hu>

Dear All,

we are running DSpace installation 1.4.2 and have a problem with Author
names for those collections which are closed for public. These names are
still retrievable by browsing items by authors. They are also indexed by
search engines like Google. 

Is there a way to disable browsing closed collections for unauthorized
users and also to block search engines from indexing Author field?

Many thanks for any help.

Regards,
Branko Kovacevic



Records Coordinator
Open Society Archives
Arany Janos u. 32
1051 Budapest, Hungary
phone: (36-1) 327-3266  or 327-2029
e-mail: kovacev at ceu.hu 
website: www.osa.ceu.hu
++++++++++++++++++++++++++++



From mdiggory at MIT.EDU  Tue Nov 13 07:55:00 2007
From: mdiggory at MIT.EDU (Mark Diggory)
Date: Tue, 13 Nov 2007 07:55:00 -0500
Subject: [Dspace-general] Customized Navigation - National Library of
	Finland
In-Reply-To: <002701c8252a$e696b630$eb5bd680@ad.helsinki.fi>
References: <002701c8252a$e696b630$eb5bd680@ad.helsinki.fi>
Message-ID: <0EF68F33-1693-4E5F-A913-E1832FC8A76A@mit.edu>

Pasi,

I think the community would be very interested in how you've modiied  
the ArtifactBrowser.  I personally think that the ArtifactBrowser  
should eventually be broken up into a few separate aspects  
(CommunityViewer, CollectonViewer, ItemViewer, SearchViewer,  
BrowseViewer, ... ) rather than one monolithic one. This way any  
alternative solutions in those areas can evolve.

Would you be interested in contributing a page on http:// 
wiki.dspace.org reflecting the changes you've made?  I think this  
would also make an interesting discussion on the developers list,  
which your also welcome to participate in.

Cheers,
Mark


On Nov 12, 2007, at 7:52 AM, Pasi Kurvinen wrote:

>
> Hello,
>
> Some background: Our DSpace-project in The National Library of  
> Finland is
> based on a consortium model. We are using DSpace to manage and  
> store our own
> documents, and we have customer organizations that use the same  
> installation
> as their institutional repositories. They typically manage their  
> own branch,
> beginning from a high-level community. Some organizations also  
> maintain
> their own individual themes.
>
> Our customers often want to have their community separated from the  
> rest of
> the site, to have a kind of web site of their own. On the other  
> hand, they
> see that it is good for users to have access to rest of documents  
> in site,
> too. We have modified our navigation in attempt to find a balance  
> between
> these two poles. Some of our users have also complained that the  
> original
> navigation was a bit difficult. To comply, we also tried to  
> simplify things
> a bit.
>
> I have uploaded a few images that display the main changes we have  
> made. The
> first image displays the front page (detailed explanations included  
> in the
> image):
> http://img2.freeimagehosting.net/uploads/127c06fe8c.gif
>
> The second image shows browsing titles in a collection level:
> http://img2.freeimagehosting.net/uploads/d021d3d071.gif
>
> Of course, you are also welcome to visit our web site.
> https://oa.doria.fi/?locale=len
> takes you directly to the English version.
>
> If anybody is interested, we are happy to give more information.  
> The changes
> mainly concern Manakin's Navigation-class under ArtifactBrowser,  
> and the
> structural.xsl-file.
>
> Cheers,
>
> Pasi Kurvinen

~~~~~~~~~~~~~
Mark R. Diggory - DSpace Systems Manager
MIT Libraries, Systems and Technology Services
Massachusetts Institute of Technology



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

From pasi.kurvinen at helsinki.fi  Wed Nov 14 05:32:48 2007
From: pasi.kurvinen at helsinki.fi (Pasi Kurvinen)
Date: Wed, 14 Nov 2007 12:32:48 +0200
Subject: [Dspace-general] Customized Navigation - National Library of
	Finland
In-Reply-To: <0EF68F33-1693-4E5F-A913-E1832FC8A76A@mit.edu>
References: <002701c8252a$e696b630$eb5bd680@ad.helsinki.fi>
	<0EF68F33-1693-4E5F-A913-E1832FC8A76A@mit.edu>
Message-ID: <000a01c826a9$b397fcf0$eb5bd680@ad.helsinki.fi>


Hi,

I think separating aspects is a good idea, especially if they communicate
through interfaces that don't change much between DSpace versions. In that
way, one could plug in different behaviors from different projects, and not
get headaches from version updates.

I will try to make time for writing a more detailed explanation in wiki. I
will send a message to dspace-tech when it's done.

Cheers,

Pasi



> -----Original Message-----
> From: Mark Diggory [mailto:mdiggory at MIT.EDU]
> Sent: 13. marraskuuta 2007 14:55
> To: Pasi Kurvinen
> Cc: dspace-general at MIT.EDU
> Subject: Re: [Dspace-general] Customized Navigation - National Library of
> Finland
> 
> Pasi,
> 
> I think the community would be very interested in how you've modiied the
> ArtifactBrowser.  I personally think that the ArtifactBrowser should
> eventually be broken up into a few separate aspects (CommunityViewer,
> CollectonViewer, ItemViewer, SearchViewer, BrowseViewer, ... ) rather than
> one monolithic one. This way any alternative solutions in those areas can
> evolve.
> 
> Would you be interested in contributing a page on http://wiki.dspace.org
> reflecting the changes you've made?  I think this would also make an
> interesting discussion on the developers list, which your also welcome to
> participate in.
> 
> Cheers,
> Mark
> 
> 
> On Nov 12, 2007, at 7:52 AM, Pasi Kurvinen wrote:
> 
> 
> 
> 	Hello,
> 
> 	Some background: Our DSpace-project in The National Library of
> Finland is
> 	based on a consortium model. We are using DSpace to manage and store
> our own
> 	documents, and we have customer organizations that use the same
> installation
> 	as their institutional repositories. They typically manage their own
> branch,
> 	beginning from a high-level community. Some organizations also
> maintain
> 	their own individual themes.
> 
> 	Our customers often want to have their community separated from the
> rest of
> 	the site, to have a kind of web site of their own. On the other
> hand, they
> 	see that it is good for users to have access to rest of documents in
> site,
> 	too. We have modified our navigation in attempt to find a balance
> between
> 	these two poles. Some of our users have also complained that the
> original
> 	navigation was a bit difficult. To comply, we also tried to simplify
> things
> 	a bit.
> 
> 	I have uploaded a few images that display the main changes we have
> made. The
> 	first image displays the front page (detailed explanations included
> in the
> 	image):
> 	http://img2.freeimagehosting.net/uploads/127c06fe8c.gif
> 
> 	The second image shows browsing titles in a collection level:
> 	http://img2.freeimagehosting.net/uploads/d021d3d071.gif
> 
> 	Of course, you are also welcome to visit our web site.
> 	https://oa.doria.fi/?locale=len
> 	takes you directly to the English version.
> 
> 	If anybody is interested, we are happy to give more information. The
> changes
> 	mainly concern Manakin's Navigation-class under ArtifactBrowser, and
> the
> 	structural.xsl-file.
> 
> 	Cheers,
> 
> 	Pasi Kurvinen
> 
> 
> ~~~~~~~~~~~~~
> Mark R. Diggory - DSpace Systems Manager
> MIT Libraries, Systems and Technology Services
> Massachusetts Institute of Technology
> 
> 




From haider at lums.edu.pk  Wed Nov 14 23:48:57 2007
From: haider at lums.edu.pk (HAIDER)
Date: Thu, 15 Nov 2007 09:48:57 +0500
Subject: [Dspace-general] Presentation
In-Reply-To: <000a01c826a9$b397fcf0$eb5bd680@ad.helsinki.fi>
References: <002701c8252a$e696b630$eb5bd680@ad.helsinki.fi><0EF68F33-1693-4E5F-A913-E1832FC8A76A@mit.edu>
	<000a01c826a9$b397fcf0$eb5bd680@ad.helsinki.fi>
Message-ID: <004b01c82742$d590a390$1f20650a@lums.net>

Hello,

I need a power point presentation for some idea, so that I can make a
presentation for my university management for the implementation of Dspace
in our university. I'll be grateful to you.

Sincerely Yours,
 
Haider Ali
Assistant Manager/Electronic Resources Librarian
Lahore University of Management Sciences
Lahore-Cantt. 54792, Pakistan
Tel: +92-42-5722670-9 Ext. 4103
Fax: +92-42-5898307
Web: http://library.lums.edu.pk
-----Original Message-----
From: dspace-general-bounces at mit.edu [mailto:dspace-general-bounces at mit.edu]
On Behalf Of Pasi Kurvinen
Sent: Wednesday, November 14, 2007 3:33 PM
To: 'Mark Diggory'
Cc: dspace-general at mit.edu
Subject: Re: [Dspace-general] Customized Navigation - National Library
ofFinland


Hi,

I think separating aspects is a good idea, especially if they communicate
through interfaces that don't change much between DSpace versions. In that
way, one could plug in different behaviors from different projects, and not
get headaches from version updates.

I will try to make time for writing a more detailed explanation in wiki. I
will send a message to dspace-tech when it's done.

Cheers,

Pasi



> -----Original Message-----
> From: Mark Diggory [mailto:mdiggory at MIT.EDU]
> Sent: 13. marraskuuta 2007 14:55
> To: Pasi Kurvinen
> Cc: dspace-general at MIT.EDU
> Subject: Re: [Dspace-general] Customized Navigation - National Library of
> Finland
> 
> Pasi,
> 
> I think the community would be very interested in how you've modiied the
> ArtifactBrowser.  I personally think that the ArtifactBrowser should
> eventually be broken up into a few separate aspects (CommunityViewer,
> CollectonViewer, ItemViewer, SearchViewer, BrowseViewer, ... ) rather than
> one monolithic one. This way any alternative solutions in those areas can
> evolve.
> 
> Would you be interested in contributing a page on http://wiki.dspace.org
> reflecting the changes you've made?  I think this would also make an
> interesting discussion on the developers list, which your also welcome to
> participate in.
> 
> Cheers,
> Mark
> 
> 
> On Nov 12, 2007, at 7:52 AM, Pasi Kurvinen wrote:
> 
> 
> 
> 	Hello,
> 
> 	Some background: Our DSpace-project in The National Library of
> Finland is
> 	based on a consortium model. We are using DSpace to manage and store
> our own
> 	documents, and we have customer organizations that use the same
> installation
> 	as their institutional repositories. They typically manage their own
> branch,
> 	beginning from a high-level community. Some organizations also
> maintain
> 	their own individual themes.
> 
> 	Our customers often want to have their community separated from the
> rest of
> 	the site, to have a kind of web site of their own. On the other
> hand, they
> 	see that it is good for users to have access to rest of documents in
> site,
> 	too. We have modified our navigation in attempt to find a balance
> between
> 	these two poles. Some of our users have also complained that the
> original
> 	navigation was a bit difficult. To comply, we also tried to simplify
> things
> 	a bit.
> 
> 	I have uploaded a few images that display the main changes we have
> made. The
> 	first image displays the front page (detailed explanations included
> in the
> 	image):
> 	http://img2.freeimagehosting.net/uploads/127c06fe8c.gif
> 
> 	The second image shows browsing titles in a collection level:
> 	http://img2.freeimagehosting.net/uploads/d021d3d071.gif
> 
> 	Of course, you are also welcome to visit our web site.
> 	https://oa.doria.fi/?locale=len
> 	takes you directly to the English version.
> 
> 	If anybody is interested, we are happy to give more information. The
> changes
> 	mainly concern Manakin's Navigation-class under ArtifactBrowser, and
> the
> 	structural.xsl-file.
> 
> 	Cheers,
> 
> 	Pasi Kurvinen
> 
> 
> ~~~~~~~~~~~~~
> Mark R. Diggory - DSpace Systems Manager
> MIT Libraries, Systems and Technology Services
> Massachusetts Institute of Technology
> 
> 


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



From j.rogani at biblioteche.unical.it  Thu Nov 15 04:18:15 2007
From: j.rogani at biblioteche.unical.it (Joseph Frank Rogani)
Date: Thu, 15 Nov 2007 10:18:15 +0100
Subject: [Dspace-general] Presentation
References: <002701c8252a$e696b630$eb5bd680@ad.helsinki.fi><0EF68F33-1693-4E5F-A913-E1832FC8A76A@mit.edu><000a01c826a9$b397fcf0$eb5bd680@ad.helsinki.fi>
	<004b01c82742$d590a390$1f20650a@lums.net>
Message-ID: <001d01c82768$7a52d4f0$1b5061a0@biblioteche.unical.it>

Dear Hader,
I have found some information you are looking for at:

www.uoregon.edu/~jqj/presentations/olnw04/dspace.pdf


www.lib.cam.ac.uk/dspace/usergroup2005/Reilly.ppt


http://dsug2006.uib.no/index.php?p=dsug


libraries.mit.edu/dspace-mit/build/policies/format.html


http://icampus.mit.edu/projects/DSpace.shtml


but there are more if you make a simple search in Google, such as, for example : Dspace ppt


Good luck
Joseph

_____________________________________________
Joseph Frank Rogani
Digital Library Manager (http://www.biblioteche.unical.it)
University of Calabria - Italy (http://www.unical.it)



***********************************************************************************************
----- Original Message ----- 
From: "HAIDER" <haider at lums.edu.pk>
To: <dspace-general at mit.edu>
Sent: Thursday, November 15, 2007 5:48 AM
Subject: Re: [Dspace-general] Presentation


> Hello,
> 
> I need a power point presentation for some idea, so that I can make a
> presentation for my university management for the implementation of Dspace
> in our university. I'll be grateful to you.
> 
> Sincerely Yours,
> 
> Haider Ali
> Assistant Manager/Electronic Resources Librarian
> Lahore University of Management Sciences
> Lahore-Cantt. 54792, Pakistan
> Tel: +92-42-5722670-9 Ext. 4103
> Fax: +92-42-5898307
> Web: http://library.lums.edu.pk
> -----Original Message-----
> From: dspace-general-bounces at mit.edu [mailto:dspace-general-bounces at mit.edu]
> On Behalf Of Pasi Kurvinen
> Sent: Wednesday, November 14, 2007 3:33 PM
> To: 'Mark Diggory'
> Cc: dspace-general at mit.edu
> Subject: Re: [Dspace-general] Customized Navigation - National Library
> ofFinland
> 
> 
> Hi,
> 
> I think separating aspects is a good idea, especially if they communicate
> through interfaces that don't change much between DSpace versions. In that
> way, one could plug in different behaviors from different projects, and not
> get headaches from version updates.
> 
> I will try to make time for writing a more detailed explanation in wiki. I
> will send a message to dspace-tech when it's done.
> 
> Cheers,
> 
> Pasi
> 
> 
> 
>> -----Original Message-----
>> From: Mark Diggory [mailto:mdiggory at MIT.EDU]
>> Sent: 13. marraskuuta 2007 14:55
>> To: Pasi Kurvinen
>> Cc: dspace-general at MIT.EDU
>> Subject: Re: [Dspace-general] Customized Navigation - National Library of
>> Finland
>> 
>> Pasi,
>> 
>> I think the community would be very interested in how you've modiied the
>> ArtifactBrowser.  I personally think that the ArtifactBrowser should
>> eventually be broken up into a few separate aspects (CommunityViewer,
>> CollectonViewer, ItemViewer, SearchViewer, BrowseViewer, ... ) rather than
>> one monolithic one. This way any alternative solutions in those areas can
>> evolve.
>> 
>> Would you be interested in contributing a page on http://wiki.dspace.org
>> reflecting the changes you've made?  I think this would also make an
>> interesting discussion on the developers list, which your also welcome to
>> participate in.
>> 
>> Cheers,
>> Mark
>> 
>> 
>> On Nov 12, 2007, at 7:52 AM, Pasi Kurvinen wrote:
>> 
>> 
>> 
>> Hello,
>> 
>> Some background: Our DSpace-project in The National Library of
>> Finland is
>> based on a consortium model. We are using DSpace to manage and store
>> our own
>> documents, and we have customer organizations that use the same
>> installation
>> as their institutional repositories. They typically manage their own
>> branch,
>> beginning from a high-level community. Some organizations also
>> maintain
>> their own individual themes.
>> 
>> Our customers often want to have their community separated from the
>> rest of
>> the site, to have a kind of web site of their own. On the other
>> hand, they
>> see that it is good for users to have access to rest of documents in
>> site,
>> too. We have modified our navigation in attempt to find a balance
>> between
>> these two poles. Some of our users have also complained that the
>> original
>> navigation was a bit difficult. To comply, we also tried to simplify
>> things
>> a bit.
>> 
>> I have uploaded a few images that display the main changes we have
>> made. The
>> first image displays the front page (detailed explanations included
>> in the
>> image):
>> http://img2.freeimagehosting.net/uploads/127c06fe8c.gif
>> 
>> The second image shows browsing titles in a collection level:
>> http://img2.freeimagehosting.net/uploads/d021d3d071.gif
>> 
>> Of course, you are also welcome to visit our web site.
>> https://oa.doria.fi/?locale=len
>> takes you directly to the English version.
>> 
>> If anybody is interested, we are happy to give more information. The
>> changes
>> mainly concern Manakin's Navigation-class under ArtifactBrowser, and
>> the
>> structural.xsl-file.
>> 
>> Cheers,
>> 
>> Pasi Kurvinen
>> 
>> 
>> ~~~~~~~~~~~~~
>> Mark R. Diggory - DSpace Systems Manager
>> MIT Libraries, Systems and Technology Services
>> Massachusetts Institute of Technology
>> 
>> 
> 

> _______________________________________________
> Dspace-general mailing list
> Dspace-general at mit.edu
> http://mailman.mit.edu/mailman/listinfo/dspace-general
> 
> _______________________________________________
> 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/20071115/1b4ba039/attachment.htm

From Michele at dspace.org  Thu Nov 15 10:18:52 2007
From: Michele at dspace.org (Michele Kimpton)
Date: Thu, 15 Nov 2007 10:18:52 -0500
Subject: [Dspace-general] [Dspace-tech] Development goals
In-Reply-To: <473BFEC2.4030203@destin.be>
References: <4739B2A2.4070803@vcu.edu>	<EA63A396-607D-480B-ADAC-D035B0177C91@gmu.edu>	<4739CAA4.1030604@imperial.ac.uk>	<4739F9C1.3070001@vcu.edu>	<356cf3980711131154p7a594fd6n3a7fd21def55c4eb@mail.gmail.com>
	<473AAF89.2060603@destin.be> <473B24C7.5040405@uiuc.edu>
	<473BFEC2.4030203@destin.be>
Message-ID: <CC0A4070-7CE0-450C-AF6C-8E2AC1C9446D@dspace.org>

Dear Christophe and DSpace community,

One of the main projects the Foundation ( not federation, and I point  
this out as they are completely different) has taken on is to put  
together a team from the community and get funding for DSpace 2.0.   
The work to be done will involve core architectural changes- under  
the hood, so to speak- that will be somewhat transparent to many end  
users.  However, these changes will have large implications down the  
road, in a good way, for the community at large.

One of the complaints is to be able to easily change the UI, or  
create multiple UI's,  Web 2.0 interactions,ect., is due to the fact  
the code is not modular ( as Tim points out). One of the main goals  
of 2.0 is to make it more modular so organizations can "plug and  
play", meaning choose the interface(s) they prefer.  It also allows  
many more developers to participate in the process- as their  
contributions can be rolled into the releases much more easily, given  
the code will not have complex interdependencies with the rest of the  
core code ( we hope).

If we are successful in putting together a modular architecture- than  
we can have multiple UI's, asset stores, workflows ect.  As there are  
no dedicated developers within the community or the Foundation  
working full time on DSpace- it is important to empower the community  
to be able to contribute code that fits their organizational needs-  
and therefore we must put an architecture in place that supports this  
process.  We hope to start the work for DSpace 2.0 this winter.

Once 2.0 is in place we can start a process where users can assess  
user needs and feature requests(developers can do this now on source  
forge) but realize the work to develop those features will still need  
to be done within the community, and maybe the community will be  
willing to pay for development time to make it happen  
collaboratively, but that remains to be seen.  I plan on hiring a  
Technology Director within the Foundation to help lead this process 
(2.0 and beyond).  We have secured some of the funding and developer  
time to do the work required.  I hope to secure the remaining funding  
needed over the next few months.  If anyone in the community would  
like to help me in this process( getting funding, donating developer  
time, volunteering I welcome your help.


sincerely,
Michele
DSpace Foundation Director
On Nov 15, 2007, at 3:09 AM, Christophe Dupriez wrote:

> Hi Tim, (copy to Michele, Dorothea and the Tech list)
>
> Thanks for your views and congratulations for your work with IDEALS.
>
> Just to be sure to be well understood: I am not in any way  
> proposing to disturb developpers, I am speaking about organising  
> USERS so they express their needs, build concensus and propose  
> developers to build prototypes they can evaluate. I am also  
> proposing to organize better the commitment process to improve  
> consistency and reliability. This will ask for inter-institutional  
> efforts so I also propose institutions to finance parts of those  
> processes. This is the key of adequation and perenity.
>
> I am not saying nothing of this is done now, I am just proposing  
> this to be improved under the drive of the Federation.
>
> Wishing you and all a very nice day!
>
> Christophe Dupriez
>
> Tim Donohue a ?crit :
>> All,
>>
>> As a Committer, I'm going to go ahead and step out on limb here,  
>> and admit that I agree with most of what has been put forth by  
>> both Dorothea and Christophe.  That being said, I'm not claiming  
>> to speak on behalf of all the Committers :)
>>
>> I would *love* a more beautified DSpace...a clean, "flashy",  
>> web-2.0 interface, a modular system that is easy to extend via  
>> plugins/add-ons, an *easy* way to share/install those plugins/add- 
>> ons between institutions, and an *easy* way to upgrade core DSpace  
>> (without merge nightmares between your local hacks/customizations  
>> and the features of the new version).
>>
>> I'm also in full support of working towards better needs  
>> assessment. But, at the same time, a part of me feels that  
>> different institutions will have some different needs based on how  
>> they are using of DSpace. So, in the end, allowing for easy  
>> extensions/modules, and easy sharing of these community-developed  
>> features is a great way to go.
>>
>> That being said, I'd like to mention just a few things to look  
>> forward to with 1.5 and beyond:
>>
>> 1) I believe there will be vast strides to beautifying DSpace UI,  
>> once we all get our hands on Manakin in 1.5 (many thanks to Scott  
>> P & all at Texas A&M).  The modularity within Manakin should also  
>> allow us to all develop new an interesting Themes & Aspects, which  
>> should be much more shareable amongst institutions. (But, we also  
>> need to find a place to actually post these for sharing!)
>>
>> 2) I believe that our move towards the Maven build system (thanks  
>> to Mark D) with 1.5 will be a huge step in the right direction for  
>> better modularity within DSpace, and better separation between the  
>> core API and various Interfaces (Manakin, JSP, OAI-PMH, LNI,  
>> etc.).  There are still a few kinks here, but we're learning  
>> quickly and attempting to make things easier to manage as separate  
>> modules (and also easier to upgrade!).  The goal here is to  
>> hopefully help allow community-developed customizatins/add-ons to  
>> flourish and not be a continual pain in managing/updating.  In  
>> addition, we want to make them more easily shareable between  
>> institutions (i.e. without the pain of merging local code, etc.).   
>> I'm not claiming this will all be figured out or 100% perfect in  
>> 1.5...but, it is a goal I'm hoping we can get to by 1.6 or 2.0 (or  
>> whatever comes after 1.5).
>>
>> As a Committer, I also feel obligated to mention that the  
>> Committers are  all volunteers.  We are working hard to make  
>> DSpace better for all of us, but there's only so much we can do  
>> (and largely our development work is defined by our the individual  
>> interests of the institutions which pay our salaries).  Therefore,  
>> DSpace is still dependent on new features/ideas/functionality  
>> being proposed & developed/prototyped by an active user  
>> community.  The Committers may be able to step in and help out  
>> (when their institutions allow), but I believe an active community  
>> is still necessary.  Remember, the Committers are often just  
>> highly-active community members!  Case in point: I was only asked  
>> to become a Committer after my giving back to the community (in  
>> the form of DSpace tutorials and Q&A on listservs), as well as the  
>> large amount of work in designing, re-designing & developing the  
>> Configurable Submission (which my institution allowed me the  
>> opportunity to take on).
>>
>> I'm really glad to see these discussions taking place!  It means  
>> we do have people in the community who care strongly about DSpace  
>> and are willing to share their opinions and suggestions for moving  
>> forward.  I encourage you to continue to help drive DSpace in the  
>> right direction!
>>
>> Ok...that's my diatribe or rather long $0.02 :)
>>
>> - Tim
>>
>>
>> Christophe Dupriez wrote:
>>> Hi !
>>>
>>> At PoisonCentre.be, we use DSpace for scientific (medical)  
>>> information collection, organisation and internal re-publication,  
>>> e.g. Knowledge sharing (not ETDs)!
>>>
>>> I find rather funny that this discussion occurs in the technical  
>>> thread and not the general one.
>>> The technicities are the reasons we meet, the subjects vary!
>>>
>>> I share most of Dorothea opinions.
>>>
>>> I strongly support the creation of a DSpace group for user needs  
>>> assesment.
>>> The output of this group should be:
>>> 1) use cases,
>>> 2) value of thoses use cases for the institutions we represent,
>>> 3) essential "user side" characteristics of the corresponding  
>>> functionalities those uses cases imply.
>>>
>>>  From there:
>>> 1) a "designer board" could propose functionalities (no  
>>> buzzwords!) to fulfill those needs.
>>> 2) developpers would be invited to find "mentors" within the  
>>> users groups and to produce a prototype.
>>> 3) User group would then discuss prototypes results and would  
>>> choose those that must be worked further for inclusion in DSpace  
>>> trunk.
>>> 4) Committers would work on "mature prototypes" (user proof) to  
>>> make them 100% compliant to DSpace architecture and coding  
>>> standards.
>>>
>>> IMHO, this process should be tightly driven by the Foundation and  
>>> financed by institutions taking advantage of DSpace know how,  
>>> technology and emulation.
>>>
>>> It seems to me that project IDEALS is an example of this:
>>> https://services.ideals.uiuc.edu/wiki/bin/view/IDEALS/ 
>>> RequirementsProduction
>>>
>>> An example of the "users requirements" challenges we could  
>>> achieve for DSpace:
>>> http://www.vufind.org/
>>> http://zoombox.gmu.edu/vufind/
>>>
>>> For my institution, I need now to fulfill the challenge of  
>>> crosslinking different DSpace instances (or collections) to have  
>>> one serve as an authority list for some fields of others (and to  
>>> use those relations in searches).
>>>
>>> Have a nice day!
>>>
>>> Christophe Dupriez
>>> christophe.dupriez at poisoncentre.be
>>> dupriez at destin.be
>>>
>>> Dorothea Salo a ?crit :
>>>> On Nov 13, 2007 1:23 PM, Susan Teague Rector <seteague at vcu.edu>  
>>>> wrote:
>>>>
>>>>
>>>>> Our debate here is centered on future support of ETDs in  
>>>>> DSpace. We've
>>>>> had to do quite a bit of customization to support ETDs (thank  
>>>>> goodness
>>>>> for Tim Donahue's code :)! Does anyone know if there are future  
>>>>> plans to
>>>>> better support ETDs in DSpace?
>>>>>
>>>>
>>>> With the understanding that I'm not a DSpace committer and not
>>>> involved in any way with DSpace or the DSpace Foundation except as
>>>> DSpace user and occasional bug or patch submitter...
>>>>
>>>> My sense is that DSpace development has only vaguely and loosely  
>>>> been
>>>> guided by real-world use cases not arising from its inner circle of
>>>> contributing institutions. E.g., repeated emails to the tech and  
>>>> dev
>>>> lists concerning metadata-only deposits (the use case there  
>>>> generally
>>>> being institutional-bibliography development), ETD management, true
>>>> dark archiving, etc. etc. have not been answered by development
>>>> initiatives, or often by anything but "why would you even want  
>>>> that?"
>>>> incomprehension or "just hack it in like everybody else!"
>>>> condescension.
>>>>
>>>> There are hacks for some of these uses, yes... but from a  
>>>> sysadmin's
>>>> perspective, hacks endanger smooth upgrade paths, and from the
>>>> perspective of many librarians, hacks are entirely out of reach
>>>> because IT rather than the librarian controls the box DSpace  
>>>> lives on.
>>>>
>>>> When innovation has occurred around DSpace, it has generally  
>>>> died on
>>>> the vine because of the aforementioned threat to smooth upgrade  
>>>> paths.
>>>> TAPIR and Researcher Pages may serve as the requisite gruesome
>>>> warnings here; they died not because the ideas underlying them were
>>>> bad (they emphatically weren't! if we still had TAPIR, Susan  
>>>> wouldn't
>>>> have had to ask the question she just did!), but because almost  
>>>> nobody
>>>> dared adopt them. I see all kinds of nifty conference presentations
>>>> involving DSpace mods -- but they provide me no practical benefit
>>>> whatsoever, because the code isn't out there and I probably  
>>>> couldn't
>>>> use it if it were!
>>>>
>>>> DSpace's lack of a plugin/mod API, coupled with the amazing  
>>>> spaghetti
>>>> dinner under its hood, has stifled service innovation in the
>>>> repository space for years, and will continue to do so until the
>>>> defect is rectified. Neither EPrints nor Fedora is in a much better
>>>> position just now, but in all honesty, I predict that the first
>>>> platform to *have* a half-decent mod API (especially one that  
>>>> welcomes
>>>> mods written in friendlier languages than Java) will experience an
>>>> explosion of innovations that will eat the other platforms' lunch.
>>>> Manakin assuredly helps, but not quite enough.
>>>>
>>>> SWORD may also help, rather backhandedly, by providing an ingest  
>>>> path
>>>> that doesn't rely on the horrendous web UI or the awkward batch
>>>> ingester. We'll see; I'm hopeful. I'd far rather build an ETD  
>>>> app that
>>>> used SWORD to drop ETDs into DSpace than try to hack DSpace for  
>>>> ETDs
>>>> myself, much less try to push the committer group to do so.
>>>>
>>>> It may be worth noting at this point that I put my votes where my
>>>> mouth is; when the DSpace development survey came out, I put a  
>>>> mod API
>>>> at the very top of my desiderata. I encourage other repository
>>>> managers with unmet needs to speak up for this! It's vastly more
>>>> important for the long-term health of DSpace and the services we  
>>>> are
>>>> building around it than are (for example) controlled vocabularies.
>>>>
>>>> Dorothea
>>>>
>>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -----
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems?  Stop.
>>> Now Search log events and configuration files using AJAX and a  
>>> browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> ----
>>>
>>> _______________________________________________
>>> DSpace-tech mailing list
>>> DSpace-tech at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>>
>
> <christophe.dupriez.vcf>




From michele at dspace.org  Thu Nov 15 13:46:22 2007
From: michele at dspace.org (Michele Kimpton)
Date: Thu, 15 Nov 2007 13:46:22 -0500
Subject: [Dspace-general] DSpace Presentation
Message-ID: <D4B63983-5401-4212-8D0A-952E22926101@dspace.org>

Dear Haider,

You will also find a range of training and presentation materials on  
the www.dspace.org website.  Please visit resources>training  
materials for training on the application itself and a link to all  
the presentations done at the last user group meeting.  Also under  
Foundation>presentations for an overview of the DSpace community, and  
direction the Foundation is moving in evolving DSpace.  If you still  
do not find what you are looking for let me know and we will see if  
we can find/produce what you need.

Sincerely,
Michele
Director DSpace Foundation


From christophe.dupriez at destin.be  Fri Nov 16 03:40:33 2007
From: christophe.dupriez at destin.be (Christophe Dupriez)
Date: Fri, 16 Nov 2007 09:40:33 +0100
Subject: [Dspace-general] [Dspace-tech] Development goals
In-Reply-To: <CC0A4070-7CE0-450C-AF6C-8E2AC1C9446D@dspace.org>
References: <4739B2A2.4070803@vcu.edu>	<EA63A396-607D-480B-ADAC-D035B0177C91@gmu.edu>	<4739CAA4.1030604@imperial.ac.uk>	<4739F9C1.3070001@vcu.edu>	<356cf3980711131154p7a594fd6n3a7fd21def55c4eb@mail.gmail.com>
	<473AAF89.2060603@destin.be> <473B24C7.5040405@uiuc.edu>
	<473BFEC2.4030203@destin.be>
	<CC0A4070-7CE0-450C-AF6C-8E2AC1C9446D@dspace.org>
Message-ID: <473D5781.5030708@destin.be>

Dear Michele (copy to the community),

May be I am basically wrong seing DSpace as a community of practice 
making a tool to promote the dissemination of the "good" Open 
Repositories practices.
If I understand correctly your plans, DSpace is primarly a community of 
developpers where users requirements are tackled inside individual 
institutions and "mostly technical" problems are shared outside. I am 
sorry that my "dream" is different but I will play the "real game" ! I 
will follow the Claudia Juergen's advice: "Small contributions are 
beautiful".

To be constructive and pragmatic, my main technical challenge remains: 
adding "thesaurus based" query expansion to DSpace to be able to mimic 
PubMed searches exhaustivity and precision in DSpace (we now have 75 
thousands documents in our internal repository. MeSH is 30 thousands 
subjects headings). I will keep focused on this.

Have a nice day!

Christophe

Michele Kimpton a ?crit :
> Dear Christophe and DSpace community,
>
> One of the main projects the Foundation ( not federation, and I point 
> this out as they are completely different) has taken on is to put 
> together a team from the community and get funding for DSpace 2.0.  
> The work to be done will involve core architectural changes- under the 
> hood, so to speak- that will be somewhat transparent to many end 
> users.  However, these changes will have large implications down the 
> road, in a good way, for the community at large.
>
> One of the complaints is to be able to easily change the UI, or create 
> multiple UI's,  Web 2.0 interactions,ect., is due to the fact the code 
> is not modular ( as Tim points out). One of the main goals of 2.0 is 
> to make it more modular so organizations can "plug and play", meaning 
> choose the interface(s) they prefer.  It also allows many more 
> developers to participate in the process- as their contributions can 
> be rolled into the releases much more easily, given the code will not 
> have complex interdependencies with the rest of the core code ( we hope).
>
> If we are successful in putting together a modular architecture- than 
> we can have multiple UI's, asset stores, workflows ect.  As there are 
> no dedicated developers within the community or the Foundation working 
> full time on DSpace- it is important to empower the community to be 
> able to contribute code that fits their organizational needs- and 
> therefore we must put an architecture in place that supports this 
> process.  We hope to start the work for DSpace 2.0 this winter.
>
> Once 2.0 is in place we can start a process where users can assess 
> user needs and feature requests(developers can do this now on source 
> forge) but realize the work to develop those features will still need 
> to be done within the community, and maybe the community will be 
> willing to pay for development time to make it happen collaboratively, 
> but that remains to be seen.  I plan on hiring a Technology Director 
> within the Foundation to help lead this process(2.0 and beyond).  We 
> have secured some of the funding and developer time to do the work 
> required.  I hope to secure the remaining funding needed over the next 
> few months.  If anyone in the community would like to help me in this 
> process( getting funding, donating developer time, volunteering I 
> welcome your help.
>
>
> sincerely,
> Michele
> DSpace Foundation Director
> On Nov 15, 2007, at 3:09 AM, Christophe Dupriez wrote:
>
>> Hi Tim, (copy to Michele, Dorothea and the Tech list)
>>
>> Thanks for your views and congratulations for your work with IDEALS.
>>
>> Just to be sure to be well understood: I am not in any way proposing 
>> to disturb developpers, I am speaking about organising USERS so they 
>> express their needs, build concensus and propose developers to build 
>> prototypes they can evaluate. I am also proposing to organize better 
>> the commitment process to improve consistency and reliability. This 
>> will ask for inter-institutional efforts so I also propose 
>> institutions to finance parts of those processes. This is the key of 
>> adequation and perenity.
>>
>> I am not saying nothing of this is done now, I am just proposing this 
>> to be improved under the drive of the Federation.
>>
>> Wishing you and all a very nice day!
>>
>> Christophe Dupriez
>>
>> Tim Donohue a ?crit :
>>> All,
>>>
>>> As a Committer, I'm going to go ahead and step out on limb here, and 
>>> admit that I agree with most of what has been put forth by both 
>>> Dorothea and Christophe.  That being said, I'm not claiming to speak 
>>> on behalf of all the Committers :)
>>>
>>> I would *love* a more beautified DSpace...a clean, "flashy", web-2.0 
>>> interface, a modular system that is easy to extend via 
>>> plugins/add-ons, an *easy* way to share/install those 
>>> plugins/add-ons between institutions, and an *easy* way to upgrade 
>>> core DSpace (without merge nightmares between your local 
>>> hacks/customizations and the features of the new version).
>>>
>>> I'm also in full support of working towards better needs assessment. 
>>> But, at the same time, a part of me feels that different 
>>> institutions will have some different needs based on how they are 
>>> using of DSpace. So, in the end, allowing for easy 
>>> extensions/modules, and easy sharing of these community-developed 
>>> features is a great way to go.
>>>
>>> That being said, I'd like to mention just a few things to look 
>>> forward to with 1.5 and beyond:
>>>
>>> 1) I believe there will be vast strides to beautifying DSpace UI, 
>>> once we all get our hands on Manakin in 1.5 (many thanks to Scott P 
>>> & all at Texas A&M).  The modularity within Manakin should also 
>>> allow us to all develop new an interesting Themes & Aspects, which 
>>> should be much more shareable amongst institutions. (But, we also 
>>> need to find a place to actually post these for sharing!)
>>>
>>> 2) I believe that our move towards the Maven build system (thanks to 
>>> Mark D) with 1.5 will be a huge step in the right direction for 
>>> better modularity within DSpace, and better separation between the 
>>> core API and various Interfaces (Manakin, JSP, OAI-PMH, LNI, etc.).  
>>> There are still a few kinks here, but we're learning quickly and 
>>> attempting to make things easier to manage as separate modules (and 
>>> also easier to upgrade!).  The goal here is to hopefully help allow 
>>> community-developed customizatins/add-ons to flourish and not be a 
>>> continual pain in managing/updating.  In addition, we want to make 
>>> them more easily shareable between institutions (i.e. without the 
>>> pain of merging local code, etc.).  I'm not claiming this will all 
>>> be figured out or 100% perfect in 1.5...but, it is a goal I'm hoping 
>>> we can get to by 1.6 or 2.0 (or whatever comes after 1.5).
>>>
>>> As a Committer, I also feel obligated to mention that the Committers 
>>> are  all volunteers.  We are working hard to make DSpace better for 
>>> all of us, but there's only so much we can do (and largely our 
>>> development work is defined by our the individual interests of the 
>>> institutions which pay our salaries).  Therefore, DSpace is still 
>>> dependent on new features/ideas/functionality being proposed & 
>>> developed/prototyped by an active user community.  The Committers 
>>> may be able to step in and help out (when their institutions allow), 
>>> but I believe an active community is still necessary.  Remember, the 
>>> Committers are often just highly-active community members!  Case in 
>>> point: I was only asked to become a Committer after my giving back 
>>> to the community (in the form of DSpace tutorials and Q&A on 
>>> listservs), as well as the large amount of work in designing, 
>>> re-designing & developing the Configurable Submission (which my 
>>> institution allowed me the opportunity to take on).
>>>
>>> I'm really glad to see these discussions taking place!  It means we 
>>> do have people in the community who care strongly about DSpace and 
>>> are willing to share their opinions and suggestions for moving 
>>> forward.  I encourage you to continue to help drive DSpace in the 
>>> right direction!
>>>
>>> Ok...that's my diatribe or rather long $0.02 :)
>>>
>>> - Tim
>>>
>>>
>>> Christophe Dupriez wrote:
>>>> Hi !
>>>>
>>>> At PoisonCentre.be, we use DSpace for scientific (medical) 
>>>> information collection, organisation and internal re-publication, 
>>>> e.g. Knowledge sharing (not ETDs)!
>>>>
>>>> I find rather funny that this discussion occurs in the technical 
>>>> thread and not the general one.
>>>> The technicities are the reasons we meet, the subjects vary!
>>>>
>>>> I share most of Dorothea opinions.
>>>>
>>>> I strongly support the creation of a DSpace group for user needs 
>>>> assesment.
>>>> The output of this group should be:
>>>> 1) use cases,
>>>> 2) value of thoses use cases for the institutions we represent,
>>>> 3) essential "user side" characteristics of the corresponding 
>>>> functionalities those uses cases imply.
>>>>
>>>>  From there:
>>>> 1) a "designer board" could propose functionalities (no buzzwords!) 
>>>> to fulfill those needs.
>>>> 2) developpers would be invited to find "mentors" within the users 
>>>> groups and to produce a prototype.
>>>> 3) User group would then discuss prototypes results and would 
>>>> choose those that must be worked further for inclusion in DSpace 
>>>> trunk.
>>>> 4) Committers would work on "mature prototypes" (user proof) to 
>>>> make them 100% compliant to DSpace architecture and coding standards.
>>>>
>>>> IMHO, this process should be tightly driven by the Foundation and 
>>>> financed by institutions taking advantage of DSpace know how, 
>>>> technology and emulation.
>>>>
>>>> It seems to me that project IDEALS is an example of this:
>>>> https://services.ideals.uiuc.edu/wiki/bin/view/IDEALS/RequirementsProduction 
>>>>
>>>>
>>>> An example of the "users requirements" challenges we could achieve 
>>>> for DSpace:
>>>> http://www.vufind.org/
>>>> http://zoombox.gmu.edu/vufind/
>>>>
>>>> For my institution, I need now to fulfill the challenge of 
>>>> crosslinking different DSpace instances (or collections) to have 
>>>> one serve as an authority list for some fields of others (and to 
>>>> use those relations in searches).
>>>>
>>>> Have a nice day!
>>>>
>>>> Christophe Dupriez
>>>> christophe.dupriez at poisoncentre.be
>>>> dupriez at destin.be
>>>>
>>>> Dorothea Salo a ?crit :
>>>>> On Nov 13, 2007 1:23 PM, Susan Teague Rector <seteague at vcu.edu> 
>>>>> wrote:
>>>>>
>>>>>
>>>>>> Our debate here is centered on future support of ETDs in DSpace. 
>>>>>> We've
>>>>>> had to do quite a bit of customization to support ETDs (thank 
>>>>>> goodness
>>>>>> for Tim Donahue's code :)! Does anyone know if there are future 
>>>>>> plans to
>>>>>> better support ETDs in DSpace?
>>>>>>
>>>>>
>>>>> With the understanding that I'm not a DSpace committer and not
>>>>> involved in any way with DSpace or the DSpace Foundation except as
>>>>> DSpace user and occasional bug or patch submitter...
>>>>>
>>>>> My sense is that DSpace development has only vaguely and loosely been
>>>>> guided by real-world use cases not arising from its inner circle of
>>>>> contributing institutions. E.g., repeated emails to the tech and dev
>>>>> lists concerning metadata-only deposits (the use case there generally
>>>>> being institutional-bibliography development), ETD management, true
>>>>> dark archiving, etc. etc. have not been answered by development
>>>>> initiatives, or often by anything but "why would you even want that?"
>>>>> incomprehension or "just hack it in like everybody else!"
>>>>> condescension.
>>>>>
>>>>> There are hacks for some of these uses, yes... but from a sysadmin's
>>>>> perspective, hacks endanger smooth upgrade paths, and from the
>>>>> perspective of many librarians, hacks are entirely out of reach
>>>>> because IT rather than the librarian controls the box DSpace lives 
>>>>> on.
>>>>>
>>>>> When innovation has occurred around DSpace, it has generally died on
>>>>> the vine because of the aforementioned threat to smooth upgrade 
>>>>> paths.
>>>>> TAPIR and Researcher Pages may serve as the requisite gruesome
>>>>> warnings here; they died not because the ideas underlying them were
>>>>> bad (they emphatically weren't! if we still had TAPIR, Susan wouldn't
>>>>> have had to ask the question she just did!), but because almost 
>>>>> nobody
>>>>> dared adopt them. I see all kinds of nifty conference presentations
>>>>> involving DSpace mods -- but they provide me no practical benefit
>>>>> whatsoever, because the code isn't out there and I probably couldn't
>>>>> use it if it were!
>>>>>
>>>>> DSpace's lack of a plugin/mod API, coupled with the amazing spaghetti
>>>>> dinner under its hood, has stifled service innovation in the
>>>>> repository space for years, and will continue to do so until the
>>>>> defect is rectified. Neither EPrints nor Fedora is in a much better
>>>>> position just now, but in all honesty, I predict that the first
>>>>> platform to *have* a half-decent mod API (especially one that 
>>>>> welcomes
>>>>> mods written in friendlier languages than Java) will experience an
>>>>> explosion of innovations that will eat the other platforms' lunch.
>>>>> Manakin assuredly helps, but not quite enough.
>>>>>
>>>>> SWORD may also help, rather backhandedly, by providing an ingest path
>>>>> that doesn't rely on the horrendous web UI or the awkward batch
>>>>> ingester. We'll see; I'm hopeful. I'd far rather build an ETD app 
>>>>> that
>>>>> used SWORD to drop ETDs into DSpace than try to hack DSpace for ETDs
>>>>> myself, much less try to push the committer group to do so.
>>>>>
>>>>> It may be worth noting at this point that I put my votes where my
>>>>> mouth is; when the DSpace development survey came out, I put a mod 
>>>>> API
>>>>> at the very top of my desiderata. I encourage other repository
>>>>> managers with unmet needs to speak up for this! It's vastly more
>>>>> important for the long-term health of DSpace and the services we are
>>>>> building around it than are (for example) controlled vocabularies.
>>>>>
>>>>> Dorothea
>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------------------- 
>>>>
>>>> This SF.net email is sponsored by: Splunk Inc.
>>>> Still grepping through log files to find problems?  Stop.
>>>> Now Search log events and configuration files using AJAX and a 
>>>> browser.
>>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>>>
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> _______________________________________________
>>>> DSpace-tech mailing list
>>>> DSpace-tech at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>>>
>>
>> <christophe.dupriez.vcf>
>
>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: christophe_dupriez.vcf
Type: text/x-vcard
Size: 454 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20071116/ca5523e9/attachment.vcf

From mdiggory at MIT.EDU  Fri Nov 16 11:55:26 2007
From: mdiggory at MIT.EDU (Mark Diggory)
Date: Fri, 16 Nov 2007 11:55:26 -0500
Subject: [Dspace-general] [Dspace-tech] Development goals
In-Reply-To: <473D5781.5030708@destin.be>
References: <4739B2A2.4070803@vcu.edu>	<EA63A396-607D-480B-ADAC-D035B0177C91@gmu.edu>	<4739CAA4.1030604@imperial.ac.uk>	<4739F9C1.3070001@vcu.edu>	<356cf3980711131154p7a594fd6n3a7fd21def55c4eb@mail.gmail.com>
	<473AAF89.2060603@destin.be> <473B24C7.5040405@uiuc.edu>
	<473BFEC2.4030203@destin.be>
	<CC0A4070-7CE0-450C-AF6C-8E2AC1C9446D@dspace.org>
	<473D5781.5030708@destin.be>
Message-ID: <98243A3B-68AC-4201-9319-F3FA54BD0C67@mit.edu>


On Nov 16, 2007, at 3:40 AM, Christophe Dupriez wrote:

> Dear Michele (copy to the community),
>
> May be I am basically wrong seing DSpace as a community of practice  
> making a tool to promote the dissemination of the "good" Open  
> Repositories practices.

No. I think your right on in this regard, but just not "one tool",  
many tools that work collaboratively. Yet, also to be a good  
participant in a larger community of existing tools and platforms.

> If I understand correctly your plans, DSpace is primarily a  
> community of developpers where users requirements are tackled  
> inside individual institutions and "mostly technical" problems are  
> shared outside. I am sorry that my "dream" is different but I will  
> play the "real game" ! I will follow the Claudia Juergen's advice:  
> "Small contributions are beautiful".

I think we need to "be careful" about these definitions.  The DSpace  
Community is a reflection of what its members need and want in an  
organization of users, managers and developers around the DSpace  
platform.  The most salient roadblock to increasing the transmission  
of community enhancements into the codebase is that  DSpace was  
basically a monolithic platform with a centralized build process. A  
significant bottleneck existed (and may still exist until we have a  
SCM and Issue tracking system that is scalable in terms of Access  
control) in that the "commiters" managing the process of reviewing  
and getting changes into the codebase supplied by the community as  
"patches".

The developers who are "commiters" are so because they want to  
participate more intimately with the future direction of DSpace.  The  
previous viewpoint that "commiters" were basically "servants" or  
"gate-keepers" to the contributor community is both ill-fitting and  
unrealistic because a large number of the "commiters" are actually  
emeritus in their behavior and not very active, leaving much of the  
work in the role of "gate-keeper" actually to the newly elected  
commiters.  Thus the "paradox" and the "bottleneck".  The actual and  
ideal "maintainers", "shepherds" or "stewards" of the community are  
not on the continuum of "commiter vs. contributor", but actually on  
the continuum of "active vs. inactive"!  We need a better process for  
shifting the dial to the "active" side.

>
> To be constructive and pragmatic, my main technical challenge  
> remains: adding "thesaurus based" query expansion to DSpace to be  
> able to mimic PubMed searches exhaustivity and precision in DSpace  
> (we now have 75 thousands documents in our internal repository.  
> MeSH is 30 thousands subjects headings). I will keep focused on this.

You should be more aggressive in participating "in the community" on  
something like this,  prod the community to get more participation,  
and be flexible about the final outcome.  I think you'll find that  
there are other developers in the community with the same interest.   
It would behoove you and them to get out of the woodwork and have  
real transparent conversations together on the community lists (hint  
hint, nudge nudge, Richard Rodgers).

Cheers,
Mark

~~~~~~~~~~~~~
Mark R. Diggory - DSpace Systems Manager
MIT Libraries, Systems and Technology Services
Massachusetts Institute of Technology


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20071116/976c7888/attachment.htm

From roberttansley at google.com  Fri Nov 16 15:19:03 2007
From: roberttansley at google.com (Robert Tansley)
Date: Fri, 16 Nov 2007 15:19:03 -0500
Subject: [Dspace-general] [Dspace-tech] Development goals
In-Reply-To: <98243A3B-68AC-4201-9319-F3FA54BD0C67@mit.edu>
References: <4739B2A2.4070803@vcu.edu> <4739CAA4.1030604@imperial.ac.uk>
	<4739F9C1.3070001@vcu.edu>
	<356cf3980711131154p7a594fd6n3a7fd21def55c4eb@mail.gmail.com>
	<473AAF89.2060603@destin.be> <473B24C7.5040405@uiuc.edu>
	<473BFEC2.4030203@destin.be>
	<CC0A4070-7CE0-450C-AF6C-8E2AC1C9446D@dspace.org>
	<473D5781.5030708@destin.be>
	<98243A3B-68AC-4201-9319-F3FA54BD0C67@mit.edu>
Message-ID: <38d44e00711161219j3f9aedd1u53dd422594026ab7@mail.gmail.com>

I do have a great deal of sympathy with Dorothea's original point that
most development is guided by uses cases at the larger institutions,
in fact I started a conversation on this very point in the user group
meeting closing session -- and of course there was disagreement on how
to address it or even that there was an issue at all.

It's not hard to argue that plenty of innovation and contribution has
been stillborn -- a quick look at the patch queue is enough for that.
It's tempting and easy to lay the blame solely at the doorstop of the
technology, however there are many other issues:

- Most DSpace users have immediate requirements and limited resources,
and so do the minimum to get the functionality they need.  What's
needed here is an understanding by institutions of the increased
long-term costs of maintaining local customisations compared to the
upfront investment in developing something more generally useful.
Even the most wonderfully clean and modular system would only
ameliorate this problem and not eliminate it.

- No matter what tools we put in place, the existence of
well-supported and widely adopted add-ons is a chicken-and-egg
problem.  If people daren't adopt them, no one will work on them,
which means...  Yes, we can provide central tools for this but it's
about people stepping forward and actually doing the work.  In the
case of TAPIR (and I could stand to be corrected here) everyone pretty
much left it to Richard Jones to maintain it, which was clearly never
a sustainable solution.  TAPIR is a project on SourceForge to which
I'm sure Richard would have been more than happy to allow interested
contributors access.

- Potential contributors need to start a conversation early and be
flexible.  As I've said before, a contribution to DSpace is a
conversation, not a patch file.  Often people throw contributions over
the fence when they've no more time to work on it.  Share early, share
often, have a thick skin.

- When people do start these conversations, they should get
constructive feedback, but it's no one's job to do this yet, so often
it doesn't happen.

- There's no process whereby decisions can get made in a timely
manner.  The way things are now, pretty much anyone (certainly any
committer) can 'black ball' an idea or contribution.  We clearly need
something more agile.

So the technology is moving in the right direction now; once we have a
data model flexible enough to accommodate different use cases, and a
way to manage and distribute add-ons that include new UI pages,
business logic and have access to persistent storage, we'll be in
better shape.  However, just as importantly, we will also need better
education and communication, and people with time to give others
feedback on how to generalise their work.  I particularly like Mark's
advice, which I'll leave you with:

> You should be more aggressive in participating "in the community" on
> something like this,  prod the community to get more participation, and be
> flexible about the final outcome.

Rob


From graham at biomedcentral.com  Mon Nov 19 09:49:45 2007
From: graham at biomedcentral.com (Graham Triggs)
Date: Mon, 19 Nov 2007 14:49:45 +0000
Subject: [Dspace-general] DSpace User Group at Open Repositories 08
Message-ID: <1195483785.4431.37.camel@L562.lsc.net>


Hello everyone,

Now that the very successful user group in Rome (congratulations to all
concerned) is but a memory, it's time to turn our attention towards the
next DSpace user group.

This will be held as part of the Open Repositories conference in
Southampton from the 1st April 2008, with the DSpace sessions held on
Thursday 3rd and the morning of Friday 4th. On Friday afternoon there
will be an OAI-ORE meeting that most of you will probably want to
attend, but if not, there will be an open forum for people to discuss
any issues with DSpace.

I will be the Chair for the DSpace programme, and would like to invite
you to submit papers to be presented as part of the user group. Please
follow the submission guidelines for the general conference - to quote:

"The submissions should be of up to 4 pages in length and in any
suitable layout. Submissions must be in PDF or HTML format. Please note
that the page length is not critical for the submitted version; the
intention is to give you enough space to explain your contribution"

For more details:
http://or08.ecs.soton.ac.uk/cfp.html

You can submit your paper now using the EasyChair Conference system:

http://www.easychair.org/conferences/?conf=OR08

When submitting papers for the DSpace user group, please use the category:
~ DSpace meeting

Important Info
--------------

The deadline for submitting papers is Monday 21st January 2008.
Notification of acceptance will occur by Friday 1st February 2008.


If you have any further questions, please don't hesitate to contact me.

Thanks,
Graham

-- 
Graham Triggs
Technical Architect
Open Repository / BioMed Central
email: graham at biomedcentral.com
This email has been scanned by Postini.
For more information please visit http://www.postini.com



From graham at biomedcentral.com  Mon Nov 19 11:44:22 2007
From: graham at biomedcentral.com (Graham Triggs)
Date: Mon, 19 Nov 2007 16:44:22 +0000
Subject: [Dspace-general] [Dspace-devel] DSpace User Group at Open
	Repositories 08
In-Reply-To: <4741BB7B.1090005@hp.com>
References: <1195483785.4431.37.camel@L562.lsc.net> <4741BB7B.1090005@hp.com>
Message-ID: <1195490662.4431.52.camel@L562.lsc.net>

A. On Mon, 2007-11-19 at 11:36 -0500, John S. Erickson wrote:
> Graham, thanks for this!
> 
> Can you say something about how/whether submissions to the plenary may 
> get pushed to various UG's, i.e. if they are not appropriate for the 
> general session? I think that has happened in the past for some 
> submissions...
> 
> John


Hi John,

Yes, it's certainly possible for submissions to the general conference
to be handed over to an appropriate user group if they don't fit in to
the general programme.

Unfortunately, it won't be possible to pass user group submissions to
the general programme, due to the later submission deadline that we have
for the user group.

However, the submission and notification dates for the user group have
been chosen so that if we are unable to accomodate a submission as part
of the user group, there is still an opportunity to submit a poster
presentation.

Hope that clears things up.

G 
 
 
This e-mail is confidential and should not be used by anyone who is not the original intended recipient. BioMed Central Limited does not accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of BioMed Central Limited. No contracts may be concluded on behalf of BioMed Central Limited by means of e-mail communication. BioMed Central Limited Registered in England and Wales with registered number 3680030 Registered Office Middlesex House, 34-42 Cleveland Street, London W1T 4LB
This email has been scanned by Postini.
For more information please visit http://www.postini.com




From dsalo at library.wisc.edu  Mon Nov 19 13:35:55 2007
From: dsalo at library.wisc.edu (Dorothea Salo)
Date: Mon, 19 Nov 2007 12:35:55 -0600
Subject: [Dspace-general] [Dspace-tech] Development goals
In-Reply-To: <38d44e00711161219j3f9aedd1u53dd422594026ab7@mail.gmail.com>
References: <4739B2A2.4070803@vcu.edu> <4739F9C1.3070001@vcu.edu>
	<356cf3980711131154p7a594fd6n3a7fd21def55c4eb@mail.gmail.com>
	<473AAF89.2060603@destin.be> <473B24C7.5040405@uiuc.edu>
	<473BFEC2.4030203@destin.be>
	<CC0A4070-7CE0-450C-AF6C-8E2AC1C9446D@dspace.org>
	<473D5781.5030708@destin.be>
	<98243A3B-68AC-4201-9319-F3FA54BD0C67@mit.edu>
	<38d44e00711161219j3f9aedd1u53dd422594026ab7@mail.gmail.com>
Message-ID: <356cf3980711191035q16933d93j6a66e922698a3a6f@mail.gmail.com>

> It's not hard to argue that plenty of innovation and contribution has
> been stillborn -- a quick look at the patch queue is enough for that.
> It's tempting and easy to lay the blame solely at the doorstop of the
> technology, however there are many other issues:

(snipping excellent list)

I think there's an additional issue that may prove even more difficult
to address: the problem of a technical infrastructure widely adopted
by non-technical people.

I haven't taken a look at the wiki to be sure, but my gestalt sense is
that a substantial majority of DSpace instances live in academic
libraries and academic-library consortia. As the general run of
academic librarians goes, *I am highly technical*. (Tim Donohue is an
outright anomaly.)

For those who don't know me: I'm a self-taught Python coder, and I've
learned just enough Java to muck around a bit at the upper levels of
DSpace. I can do a little SQL, though a lot of trial and error is
involved and I know nothing of query optimization. I can do a little
XSLT, though some of the XPaths in Manakin frankly break my brain. I'm
fine with XHTML and CSS, though I'm not up on all the latest CSS
hacks. I haven't ever done any serious web programming. I'm good with
XML. I'm aware of usability issues and practices, though I don't have
any talent for coming up with fixes, and I'm well-grounded in web
accessibility.

And every single DSpace committer right now is laughing fit to kill,
because the above skill list is *pathetic*. As I said, though, I'm
atypical *on the technical high end* of librarianship. I don't think
DSpace has ever come to terms with what that means. It's not end-user
cluelessness that's the problem, as it is with many open-source
packages. It's cluelessness *in the managers of the software*, which
is a different and rather nastier problem.

To tell a story on myself, I told Robert Tansley at OR '07 that I was
a beginning-level Java coder and asked what I might contribute to
DSpace within the limits of my abilities. He suggested I look at
revamping the Browse system, perhaps to piggyback on a Lucene index. I
did. Believe me, I shouldn't be *touching* that. I hardly know where
to begin, and if I *did* begin, I don't have a solid enough grounding
(or, indeed, *any* grounding) in code optimization or testing to know
whether what I'd come up with would solve the lingering performance
problems.

The implications of this disconnect between the developer community
and DSpace managers include:

- DSpace isn't just difficult to customize for librarians, it is
frequently *impossible* to customize, because the box isn't controlled
by us but by IT. (Another story: when I interviewed for the position I
currently hold, I was told that I could not expect to have server
access to DSpace, much less permission to customize it, because to
give me those privileges might endanger the library's excellent
relationship with the IT group running the DSpace box. This turned out
not to be true, for which I am duly grateful, but it goes to show.)
Mods and plugins that aren't neatly packaged are just plain
non-starters with us. I disagree slightly with Robert that mod
adoption is a chicken-and-egg problem, and with Don Gourley that the
current API is sufficient for the level of innovation we hope for; I
believe that a stable, documented, vetted API and a blessed plugin
directory will make a considerable difference in innovation uptake.
(Librarians like authoritative sources -- and it's a lot easier for us
to approach IT with a "plugin" than with a miscellaneous chunk of
Somebody Else's Code.)

- Since discussion of DSpace development is (understandably!) heavily
tilted toward developers and people with developer-level skills, the
developer community has very little access to and therefore
comprehension of rubber-meets-road requirements and procedures in
real-world library contexts. Surveys are all very well, but are they
even reaching the librarians who form the public face of the software
(rather than the sysadmins who support it)? I doubt it. I really do.
Ethnographic, qualitative study and usability testing with librarians
as subjects are likely to be more productive approaches, but they have
not been tried.

- Librarians tend to have a passive and narrowminded attitude toward
our software. (I'll spare everyone the rant about integrated library
system vendors fostering this passivity.) What is, is, and there's
nothing we can do about it. This means, first, that we just don't
think in terms of "this wart can and should be fixed" -- we think
instead about workarounds, or we beat our workflows into the ground to
match the software. It can be insanely frustrating to elicit
requirements and useful feedback from us! Second, it means we don't
come forward with suggestions, or even think creatively about how to
improve the software; it's not in our culture.

- It has historically been extremely difficult for an individual at my
level of technical savvy or below to be heard by DSpace developers.
The problem is cultural. On the one hand, non-technical librarians do
not know how to approach an open-source community. On the other hand,
open-source developers are notorious for disdain of non-technical
input and the people who provide it, and DSpace has unfortunately not
departed from that pattern. Me, I've been aggressive and persistent
about engaging anyway, at high cost to myself in anxiety and
frustration. I have personally talked to several DSpace managers with
useful usability and workflow insights, however, who have turned on
their heels and walked silently away from the community after an
initial rebuff.

I welcome discussion of possible technical and non-technical fixes for
the above problems. Myself, I suggest the following technical goals:

- Removal of interface customizations from dspace.cfg in favor of a
web-based customization interface accessible to repository managers
who do not have admin access to the DSpace box. (Even something as
bare-bones as Firefox's about:config would be a major step forward.)

- Web-based administrative interfaces to input-forms.xml, Configurable
Submission, and similar, along the same lines as the metadata and
bitstream-format registries. (I'm still working on how to get
human-friendly bitstream format descriptions back into Manakin.
Anybody solved that problem yet? MIME types are horrible.)

And the following non-technical goals:

- A serious qualitative investigation into real-world DSpace workflows
and where they fall down. I will gladly serve as subject; goodness
knows I have a *lot* of frustration built up, and I'm not as bad at
articulating it intelligibly as many librarians are. Alternately, a
survey of sysadmins to find out where people are having to add or
change code might be productive.

- Support for the work Tim Donohue, Scott Phillips, and I have done
toward training librarians on DSpace customization. Tim and I have
both noticed that the DSpace customization materials we wrote up are
among the most popular downloads in our respective repositories.
*There is a significant need here,* and random pre-conference
tutorials aren't meeting it. Online courses might be a real help,
especially given DSpace's international reach, and I would be more
than willing to develop and teach them if the appropriate
infrastructure could be found. (I think the community might find that
this lessens repetitive questions on the dspace-tech list, too.)

- Mentoring for prospective developers and committers. As pathetic as
my skills are, it's not completely *impossible* that I might become a
DSpace committer (especially as I *do* sling XSLT a bit better than
Java). To accomplish that, though, I would need to be paired with an
experienced developer who can help me formulate problems properly,
approach them intelligently, and haul myself out when I get stuck.
This is a tall order, I'm afraid; we don't have enough developer
talent in the DSpace community as it is, so it's hard to justify
wasting some of it on tyros like me. Still -- where's the talent pool,
if it *doesn't* include people like me?

- Open acknowledgement that past development practices and politics
have alienated potential developer talent, and a plan to make amends
and recruit committers from that alienated group. Ou sont les NSpace
developers d'antan? (I know where one of them is!)

- A communication and contribution path for non-technical DSpace
managers. For the sake of everyone's sanity, it should probably be
wholly separate from the developer community, though someone should
have the job of summarizing useful suggestions to one of the developer
lists (and again, I would happily volunteer). Dspace-general is not a
good venue, because too many DSpace managers have abandoned it, or
consider it an announcement list only.

Dorothea

-- 
Dorothea Salo                dsalo at library.wisc.edu
Digital Repository Librarian      AIM: mindsatuw
University of Wisconsin
Rm 218, Memorial Library
(608) 262-5493


From lynch at middlebury.edu  Wed Nov 21 10:54:28 2007
From: lynch at middlebury.edu (Lynch, Michael)
Date: Wed, 21 Nov 2007 10:54:28 -0500
Subject: [Dspace-general] [Dspace-tech] Development goals
In-Reply-To: <356cf3980711191035q16933d93j6a66e922698a3a6f@mail.gmail.com>
References: <4739B2A2.4070803@vcu.edu>
	<4739F9C1.3070001@vcu.edu><356cf3980711131154p7a594fd6n3a7fd21def55c4eb@mail.gmail.com><473AAF89.2060603@destin.be>
	<473B24C7.5040405@uiuc.edu><473BFEC2.4030203@destin.be><CC0A4070-7CE0-450C-AF6C-8E2AC1C9446D@dspace.org><473D5781.5030708@destin.be><98243A3B-68AC-4201-9319-F3FA54BD0C67@mit.edu><38d44e00711161219j3f9aedd1u53dd422594026ab7@mail.gmail.com>
	<356cf3980711191035q16933d93j6a66e922698a3a6f@mail.gmail.com>
Message-ID: <434D586F5B9AAF4583F1344EC4103EE103BE0AC9@firefly.middlebury.edu>

As a moderately technical academic librarian, I wanted to chime in and
thank Dorothea for this excellent message.  (I used to be highly
technical, but almost no-one uses VMS anymore and I'm getting too old to
learn all this new stuff!)

My institution is participating in a pilot, hosted, consortial
implementation of DSpace (http://dspace.nitle.org) which certainly
complicates things quite a bit, but I can vouch for Dorothea's general
assessment of the view of DSpace from academic libraryland, for whatever
that is worth in the eyes of the technical developers.

-Mike Lynch 		lynch at middlebury.edu
 Systems Librarian
 Middlebury College
 Middlebury, VT


-----Original Message-----
From: dspace-general-bounces at mit.edu
[mailto:dspace-general-bounces at mit.edu] On Behalf Of Dorothea Salo
Sent: Monday, November 19, 2007 1:36 PM
To: dspace-tech
Cc: dspace
Subject: Re: [Dspace-general] [Dspace-tech] Development goals

(snipped excellent discussion)

The implications of this disconnect between the developer community
and DSpace managers include:

- DSpace isn't just difficult to customize for librarians, it is
frequently *impossible* to customize, because the box isn't controlled
by us but by IT. [...]
Mods and plugins that aren't neatly packaged are just plain
non-starters with us. [...] I
believe that a stable, documented, vetted API and a blessed plugin
directory will make a considerable difference in innovation uptake.
(Librarians like authoritative sources -- and it's a lot easier for us
to approach IT with a "plugin" than with a miscellaneous chunk of
Somebody Else's Code.)

[...]

- Librarians tend to have a passive and narrowminded attitude toward
our software. [...] What is, is, and there's
nothing we can do about it. This means, first, that we just don't
think in terms of "this wart can and should be fixed" -- we think
instead about workarounds, or we beat our workflows into the ground to
match the software. It can be insanely frustrating to elicit
requirements and useful feedback from us! Second, it means we don't
come forward with suggestions, or even think creatively about how to
improve the software; it's not in our culture.

[...]

I welcome discussion of possible technical and non-technical fixes for
the above problems. Myself, I suggest the following technical goals:

- Removal of interface customizations from dspace.cfg in favor of a
web-based customization interface accessible to repository managers
who do not have admin access to the DSpace box. (Even something as
bare-bones as Firefox's about:config would be a major step forward.)

- Web-based administrative interfaces to input-forms.xml, Configurable
Submission, and similar, along the same lines as the metadata and
bitstream-format registries. (I'm still working on how to get
human-friendly bitstream format descriptions back into Manakin.
Anybody solved that problem yet? MIME types are horrible.)

And the following non-technical goals:

- A serious qualitative investigation into real-world DSpace workflows
and where they fall down. I will gladly serve as subject; goodness
knows I have a *lot* of frustration built up, and I'm not as bad at
articulating it intelligibly as many librarians are. Alternately, a
survey of sysadmins to find out where people are having to add or
change code might be productive.

- Support for the work Tim Donohue, Scott Phillips, and I have done
toward training librarians on DSpace customization. Tim and I have
both noticed that the DSpace customization materials we wrote up are
among the most popular downloads in our respective repositories.
*There is a significant need here,* and random pre-conference
tutorials aren't meeting it. Online courses might be a real help,
especially given DSpace's international reach, and I would be more
than willing to develop and teach them if the appropriate
infrastructure could be found. (I think the community might find that
this lessens repetitive questions on the dspace-tech list, too.)

- Mentoring for prospective developers and committers. As pathetic as
my skills are, it's not completely *impossible* that I might become a
DSpace committer (especially as I *do* sling XSLT a bit better than
Java). To accomplish that, though, I would need to be paired with an
experienced developer who can help me formulate problems properly,
approach them intelligently, and haul myself out when I get stuck.
This is a tall order, I'm afraid; we don't have enough developer
talent in the DSpace community as it is, so it's hard to justify
wasting some of it on tyros like me. Still -- where's the talent pool,
if it *doesn't* include people like me?

- Open acknowledgement that past development practices and politics
have alienated potential developer talent, and a plan to make amends
and recruit committers from that alienated group. Ou sont les NSpace
developers d'antan? (I know where one of them is!)

- A communication and contribution path for non-technical DSpace
managers. For the sake of everyone's sanity, it should probably be
wholly separate from the developer community, though someone should
have the job of summarizing useful suggestions to one of the developer
lists (and again, I would happily volunteer). Dspace-general is not a
good venue, because too many DSpace managers have abandoned it, or
consider it an announcement list only.

Dorothea

-- 
Dorothea Salo                dsalo at library.wisc.edu
Digital Repository Librarian      AIM: mindsatuw
University of Wisconsin
Rm 218, Memorial Library
(608) 262-5493
_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general



From kenzie at MIT.EDU  Thu Nov 22 09:55:14 2007
From: kenzie at MIT.EDU (MacKenzie Smith)
Date: Thu, 22 Nov 2007 09:55:14 -0500
Subject: [Dspace-general] Work Study Opportunity - The Banff Centre (Digital
	Repository)
Message-ID: <47459852.8030401@mit.edu>

Of possible interest

-----Original Message-----
Digital Repository Work Study
http://www.banffcentre.ca/programs/program.aspx?id=667

Program dates: 		January 21, 2008 - March 17, 2008
Application deadline:  	December 10, 2007

Preserving digital assets and content is one of the most significant
challenges facing institutions and organizations throughout the world.
Enormous amounts of digital information have already been lost forever.

    "Digital evolution has been too rapid and costly for governments and
institutions to develop timely and informed preservation strategies. The
threat to the economic, social, intellectual and cultural potential of the
heritage - the building blocks of the future - has not been fully
grasped...unless the prevailing threats are addressed, the loss of the
digital heritage will be rapid and inevitable."

    - UNESCO Charter on the Preservation of the Digital Heritage

The Digital Repository Work Study program is an exciting opportunity to
learn and develop experience in this cutting-edge and challenging field.
Participants will be given direct hands-on experience in implementing
technology solutions to support the long-term preservation of digital
assets. They will be provided with an opportunity to implement and test a
range of open-source and commercial applications, including DSpace (MIT),
Fedora (Cornell University), Greenstone (New Zealand), DAITSS (Florida
State), and ContentDM (OCLC). Learning opportunities may also include
research into emerging standards, challenges, and technical innovations
related to digital preservation.

This work study opportunity is intended for individuals with working
knowledge and experience in SE Linux/Unix, Tomcat, Apache, PostgresSQL,
Perl, and Java.  Participants will work as part of a team that includes
system administrators, programmers, archivists and librarians.

Participants accepted to the work study program will receive a scholarship
to cover the program fee and are awarded a weekly stipend to offset the
costs associated with room and board during the program.

Work study programs are intended to provide participants with a combination
of learning opportunities and supervised, practical work related to the
participant's learning objectives. Participation in a work study term is
considered to be full-time study, rather that employment. All participants
sign a learning contract that assists in the evaluation of their work study
experience. Scholarship stipend payments are not specifically linked to work
performed or performance but are intended to enable participants to pursue
the overall learning objectives.

All applications must include:

    * A completed application form;
    * A non-refundable application processing fee of $59 Cdn, payable to The
Banff Centre;
    * A current r?sume;
    * Two letters of reference, or the names, addresses, and telephone
numbers of two references who are willing to support the candidate's
application and professional development objectives.

Application details:
http://www.banffcentre.ca/programs/program.aspx?id=667&p=apply


-- 
MacKenzie Smith
Associate Director for Technology
MIT Libraries



From kenzie at mit.edu  Thu Nov 22 11:43:40 2007
From: kenzie at mit.edu (MacKenzie Smith)
Date: Thu, 22 Nov 2007 11:43:40 -0500
Subject: [Dspace-general] [Dspace-tech] Development goals
In-Reply-To: <356cf3980711191035q16933d93j6a66e922698a3a6f@mail.gmail.com>
References: <4739B2A2.4070803@vcu.edu>
	<4739F9C1.3070001@vcu.edu>	<356cf3980711131154p7a594fd6n3a7fd21def55c4eb@mail.gmail.com>	<473AAF89.2060603@destin.be>
	<473B24C7.5040405@uiuc.edu>	<473BFEC2.4030203@destin.be>	<CC0A4070-7CE0-450C-AF6C-8E2AC1C9446D@dspace.org>	<473D5781.5030708@destin.be>	<98243A3B-68AC-4201-9319-F3FA54BD0C67@mit.edu>	<38d44e00711161219j3f9aedd1u53dd422594026ab7@mail.gmail.com>
	<356cf3980711191035q16933d93j6a66e922698a3a6f@mail.gmail.com>
Message-ID: <4745B1BC.5050101@mit.edu>

Dorothea,
> I think there's an additional issue that may prove even more difficult
> to address: the problem of a technical infrastructure widely adopted
> by non-technical people.
>   
We should establish that this is actually the norm (as you point out 
later) and in every industry,
not just libraries or archives. Business managers theoretically know 
what they need, but do
not (should not) be expected to write the software to accomplish those 
goals.
> I haven't taken a look at the wiki to be sure, but my gestalt sense is
> that a substantial majority of DSpace instances live in academic
> libraries and academic-library consortia. As the general run of
> academic librarians goes, *I am highly technical*. (Tim Donohue is an
> outright anomaly.)
>   
I think you're right that the majority of DSpace adopters right now are 
in the library or
related domains. At least the visible ones. But those institutions are 
taking various
approaches to defining and managing their repository services. Some have 
one-person-to-
do-everything, and some have much more fine-grained support. As one 
example, at MIT
we have a dedicated product manager (not hands-on technical, but quite 
capable of writing
requirements and talking to developers), a dedicated developer, and a 
sysadmin to look
after the production system day-to-day. I wish I had more staff to help 
out, but this is
what we could support for the moment.

The one-person-who-does-it-all model is definitely not going to scale 
for the sorts of
DSpace applications that we're seeing. And if you look at the staffing 
models for
other production systems like ILSes or course management systems no one 
would
expect one person to deal with every aspect of them (including writing 
the software).

These are complex problems that we're just beginning to understand, so 
expect to see
plenty of dead ends and throw-away code before it's over. In other 
words, *more*
investment, not less, at this stage of the game.
> As I said, though, I'm
> atypical *on the technical high end* of librarianship. I don't think
> DSpace has ever come to terms with what that means. It's not end-user
> cluelessness that's the problem, as it is with many open-source
> packages. It's cluelessness *in the managers of the software*, which
> is a different and rather nastier problem.
>   
I will argue strenuously that service managers (or product managers, or 
program managers,
or whatever you prefer to call that role) should *not* be trying to hack 
the system.
They should be, and are, asking for changes that they think will improve 
the service
they run. But who to ask? There are two paths: ask local developers 
(MIT's case) or
ask the DSpace developer community at large. Obviously the former has a 
better chance
of actually getting done, but the latter happens sometimes.

For example, your request for an easier, less technical way to configure 
the system that
doesn't require programming skills is very reasonable, but it would take 
a developer
a lot of time to implement that, and it would be to the benefit of the 
whole community
rather than a single institutions (especially the ones that have 
developers who might
do this work, but who don't particularly need it themselves). So how to 
get that done?
You could hire a developer of your own to do it. Or talk your 
institution (or CIC)
into pooling its resources to hire a developer at the Foundation to do 
the work. etc.

> - Since discussion of DSpace development is (understandably!) heavily
> tilted toward developers and people with developer-level skills, the
> developer community has very little access to and therefore
> comprehension of rubber-meets-road requirements and procedures in
> real-world library contexts.
Also a generalization. Many DSpace developers are confronted daily with 
local service
managers that want stuff. The problem as I see it is that those product 
roadmaps aren't
being widely shared by their service managers (at least not on the 
DSpace lists) so we
don't know where they converge or differ. That's what I'd like to see 
improved, but I
wonder how much agreement there really is between institutions about the 
right way
for repository services to evolve... what you perceive as indifference 
from developers
may actually be indifference from the service managers that decide what 
those
developers should work on... so you may be arguing with the wrong people.
> - It has historically been extremely difficult for an individual at my
> level of technical savvy or below to be heard by DSpace developers.
>   
So (not to belabor the point) but could you ask Ken and Nolan to give you a
dedicated developer for a year? If repository services are a priority 
for your institution,
can you make the case that you need more resources to do what you 
believe it should?
> On the other hand,
> open-source developers are notorious for disdain of non-technical
> input and the people who provide it, and DSpace has unfortunately not
> departed from that pattern.
I know most of the DSpace developers, and they all march to some 
business need or
other, usually determined by their managers (or those who sell services 
to library managers).
But as several of the highly-visible developers have pointed out, none 
of them work for the
"DSpace community", they work for a particular university  or company or 
institute and
they usually aren't at liberty to work on whatever they like.
> - A communication and contribution path for non-technical DSpace
> managers. For the sake of everyone's sanity, it should probably be
> wholly separate from the developer community, though someone should
> have the job of summarizing useful suggestions to one of the developer
> lists (and again, I would happily volunteer). Dspace-general is not a
> good venue, because too many DSpace managers have abandoned it, or
> consider it an announcement list only.
>   
I heartily share your desire for this, and have tried repeatedly to 
create such a forum without
success. So how do we do it, and get people to use it?

MacKenzie

-- 
MacKenzie Smith
Associate Director for Technology
MIT Libraries



From roberta.caccialupi at unimib.it  Fri Nov 23 06:33:14 2007
From: roberta.caccialupi at unimib.it (Roberta Caccialupi)
Date: Fri, 23 Nov 2007 12:33:14 +0100
Subject: [Dspace-general] Dspace 1.5 - test community administrator
Message-ID: <00a801c82dc4$a3176b00$43128495@LENOVOD7D5B976>

Hi,

we are testing Dspace 1.5 alpha and have a question about the community administration. The last Dspace version allowed to the community administrator to create new collections. On the contrary with the new version we can't do the same. We would ask you if it is the new policy, and in this case if it is possible to restore the previous functionality. Thank you
Best regards

Roberta Caccialupi

-----------------------------------------------------------------
Roberta Caccialupi
Centro di Produzione Multimediale
Universit? degli Studi di Milano Bicocca
V.le dell'Innovazione, 10
Edificio U9
I-20125 Milano
Tel: +39 02 6448.7458
www.cpm.unimib.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20071123/c1d89fdc/attachment.htm

From annamavroudi at yahoo.gr  Sat Nov 24 15:28:25 2007
From: annamavroudi at yahoo.gr (anna mavroudi)
Date: Sat, 24 Nov 2007 20:28:25 +0000 (GMT)
Subject: [Dspace-general] exception when importing items
Message-ID: <609722.81798.qm@web27708.mail.ukl.yahoo.com>

Hi all,
i'm trying to import items in dspace using the item importer in org.dspace.app.itemimport.ItemImport, but i get an exception as following:
**Test Run** - not actually importing items.
Destination Collections:
Owning Collection:????????    ?????????
Adding Items from directory:
Generating mapfile:mapfile7
java.lang.NullPointerException
at org.dspace.app.itemimport.ItemImport.addItems<ItemImport.java:498>
at org.dspace.app.itemimport.ItemImport.main<ItemImport.java:415>
java.lang.NullPointerException
***End of Test Run ***
Any ideas?
Thanks in advance,
Anna


 		
---------------------------------
 ?????????????? Yahoo!
 ?????????? ?? ?????????? ???? ???? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? 
 http://login.yahoo.com/config/mail?.intl=gr 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20071124/212f717b/attachment.htm

From Claudia.Juergen at ub.uni-dortmund.de  Mon Nov 26 07:04:21 2007
From: Claudia.Juergen at ub.uni-dortmund.de (=?UTF-8?B?Q2xhdWRpYSBKw7xyZ2Vu?=)
Date: Mon, 26 Nov 2007 13:04:21 +0100
Subject: [Dspace-general] exception when importing items
In-Reply-To: <609722.81798.qm@web27708.mail.ukl.yahoo.com>
References: <609722.81798.qm@web27708.mail.ukl.yahoo.com>
Message-ID: <474AB645.5010107@ub.uni-dortmund.de>

Hi Anna,

seems as if the source directory you specified is not valid, check the 
source path specified with the -s option.


hope that helps

Claudia


anna mavroudi schrieb:
> Hi all,
> i'm trying to import items in dspace using the item importer in org.dspace.app.itemimport.ItemImport, but i get an exception as following:
> **Test Run** - not actually importing items.
> Destination Collections:
> Owning Collection:????????    ?????????
> Adding Items from directory:
> Generating mapfile:mapfile7
> java.lang.NullPointerException
> at org.dspace.app.itemimport.ItemImport.addItems<ItemImport.java:498>
> at org.dspace.app.itemimport.ItemImport.main<ItemImport.java:415>
> java.lang.NullPointerException
> ***End of Test Run ***
> Any ideas?
> Thanks in advance,
> Anna
> 
> 
>  		
> ---------------------------------
>  ?????????????? Yahoo!
>  ?????????? ?? ?????????? ???? ???? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? 
>  http://login.yahoo.com/config/mail?.intl=gr 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Dspace-general mailing list
> Dspace-general at mit.edu
> http://mailman.mit.edu/mailman/listinfo/dspace-general


From roberta.caccialupi at unimib.it  Mon Nov 26 08:19:05 2007
From: roberta.caccialupi at unimib.it (Roberta Caccialupi)
Date: Mon, 26 Nov 2007 14:19:05 +0100
Subject: [Dspace-general] Dspace 1.5 - test community administrator
Message-ID: <003801c8302e$ebe2fe50$43128495@LENOVOD7D5B976>

Hi,

we are testing Dspace 1.5 alpha and have a question about the community administration. The last Dspace version allowed to the community administrator to create new collections, manage item's permissions, etc. On the contrary with the new version only the system administrator can do it. We would ask you if it is the new policy, and in this case if it is possible to restore the previous functionality. Thank you
Best regards

Roberta Caccialupi
-----------------------------------------------------------------
Roberta Caccialupi
Centro di Produzione Multimediale
Universit? degli Studi di Milano Bicocca
V.le dell'Innovazione, 10
Edificio U9
I-20125 Milano
Tel: +39 02 6448.7458
www.cpm.unimib.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20071126/f0ce57db/attachment.htm

From bollini at cilea.it  Mon Nov 26 09:00:17 2007
From: bollini at cilea.it (Andrea Bollini)
Date: Mon, 26 Nov 2007 15:00:17 +0100
Subject: [Dspace-general] Dspace 1.5 - test community administrator
In-Reply-To: <003801c8302e$ebe2fe50$43128495@LENOVOD7D5B976>
References: <003801c8302e$ebe2fe50$43128495@LENOVOD7D5B976>
Message-ID: <474AD171.30801@cilea.it>

Hi Roberta,
what do you mean for "community administrator"?
DSpace have not "out-of-box" a similar role, have you used my patch
"Community Admin"?
Andrea

Roberta Caccialupi ha scritto:
> Hi,
>
> we are testing Dspace 1.5 alpha and have a question about the community administration. The last Dspace version allowed to the community administrator to create new collections, manage item's permissions, etc. On the contrary with the new version only the system administrator can do it. We would ask you if it is the new policy, and in this case if it is possible to restore the previous functionality. Thank you
> Best regards
>
> Roberta Caccialupi
> -----------------------------------------------------------------
> Roberta Caccialupi
> Centro di Produzione Multimediale
> Universit? degli Studi di Milano Bicocca
> V.le dell'Innovazione, 10
> Edificio U9
> I-20125 Milano
> Tel: +39 02 6448.7458
> www.cpm.unimib.it
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Dspace-general mailing list
> Dspace-general at mit.edu
> http://mailman.mit.edu/mailman/listinfo/dspace-general
>   


-- 
Dott. Andrea Bollini
Responsabile tecnico sviluppo e formazione applicativi JAVA
Sezione Servizi per le Biblioteche e l'Editoria Elettronica
CILEA, http://www.cilea.it
tel. +39 06-59292831  cel. +39 348-8277525



From Claudia.Juergen at ub.uni-dortmund.de  Mon Nov 26 09:00:41 2007
From: Claudia.Juergen at ub.uni-dortmund.de (=?ISO-8859-1?Q?Claudia_J=FCrgen?=)
Date: Mon, 26 Nov 2007 15:00:41 +0100
Subject: [Dspace-general] Dspace 1.5 - test community administrator
In-Reply-To: <003801c8302e$ebe2fe50$43128495@LENOVOD7D5B976>
References: <003801c8302e$ebe2fe50$43128495@LENOVOD7D5B976>
Message-ID: <474AD189.4090100@ub.uni-dortmund.de>

Hi Roberta,

this seems to have been a local customization or maybe a test with a 
user belonging to the administrator group.

As far as I know there never was  a community administrator, you only 
got a collection adminstrator, which  is not able to create new 
collections. For collections administrator information see
[dspace-source]/jsp/help/collection-admin.html or login to your system 
as a collection administrator and call the help page.

Sunny greetings

Claudia




Roberta Caccialupi schrieb:
> Hi,
> 
> we are testing Dspace 1.5 alpha and have a question about the community administration. The last Dspace version allowed to the community administrator to create new collections, manage item's permissions, etc. On the contrary with the new version only the system administrator can do it. We would ask you if it is the new policy, and in this case if it is possible to restore the previous functionality. Thank you
> Best regards
> 
> Roberta Caccialupi
> -----------------------------------------------------------------
> Roberta Caccialupi
> Centro di Produzione Multimediale
> Universit? degli Studi di Milano Bicocca
> V.le dell'Innovazione, 10
> Edificio U9
> I-20125 Milano
> Tel: +39 02 6448.7458
> www.cpm.unimib.it
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Dspace-general mailing list
> Dspace-general at mit.edu
> http://mailman.mit.edu/mailman/listinfo/dspace-general


From roberta.caccialupi at unimib.it  Mon Nov 26 09:48:48 2007
From: roberta.caccialupi at unimib.it (Roberta Caccialupi)
Date: Mon, 26 Nov 2007 15:48:48 +0100
Subject: [Dspace-general] Dspace 1.5 - test community administrator
References: <003801c8302e$ebe2fe50$43128495@LENOVOD7D5B976>
	<474AD189.4090100@ub.uni-dortmund.de>
Message-ID: <007101c8303b$747138c0$43128495@LENOVOD7D5B976>

This is true. But in the previous Dspace version the system administrator 
could authorize a "person" to create and administrate sub-communities and 
collections. So this "person" became independent in the administration of 
communities and collections (included collection and item authorizations). 
Now only the system administration can do it and can't delegate anyone.
Thank you

Roberta


----- Original Message ----- 
From: "Claudia J?rgen" <Claudia.Juergen at ub.uni-dortmund.de>
To: "Roberta Caccialupi" <roberta.caccialupi at unimib.it>
Cc: <dspace-general at mit.edu>
Sent: Monday, November 26, 2007 3:00 PM
Subject: Re: [Dspace-general] Dspace 1.5 - test community administrator


> Hi Roberta,
>
> this seems to have been a local customization or maybe a test with a user 
> belonging to the administrator group.
>
> As far as I know there never was  a community administrator, you only got 
> a collection adminstrator, which  is not able to create new collections. 
> For collections administrator information see
> [dspace-source]/jsp/help/collection-admin.html or login to your system as 
> a collection administrator and call the help page.
>
> Sunny greetings
>
> Claudia
>
>
>
>
> Roberta Caccialupi schrieb:
>> Hi,
>>
>> we are testing Dspace 1.5 alpha and have a question about the community 
>> administration. The last Dspace version allowed to the community 
>> administrator to create new collections, manage item's permissions, etc. 
>> On the contrary with the new version only the system administrator can do 
>> it. We would ask you if it is the new policy, and in this case if it is 
>> possible to restore the previous functionality. Thank you
>> Best regards
>>
>> Roberta Caccialupi
>> -----------------------------------------------------------------
>> Roberta Caccialupi
>> Centro di Produzione Multimediale
>> Universit? degli Studi di Milano Bicocca
>> V.le dell'Innovazione, 10
>> Edificio U9
>> I-20125 Milano
>> Tel: +39 02 6448.7458
>> www.cpm.unimib.it
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Dspace-general mailing list
>> Dspace-general at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/dspace-general 



From graham at biomedcentral.com  Tue Nov 27 13:43:11 2007
From: graham at biomedcentral.com (graham@biomedcentral.com)
Date: Tue, 27 Nov 2007 18:43:11 -0000
Subject: [Dspace-general] Open Repository - announcing a new release
Message-ID: <F7B2A5954104184797FFAD77E26ED4C008DFF2@ms3.lsc.net>


Hi Everyone,

I would like to take a tiny amount of your time to announce a major upgrade to the Open Repository hosted service - to be accompanied by a small fanfare (ie. me and a trumpet).

Some people have asked about the relationship between Open Repository and the DSpace code in the past, which I've attempted to answer along the way, and this release is a good example of where that relationship is heading.

Whilst the work was commenced prior to the 1.4.2 release, it has tracked a lot of the changes made to DSpace in that time, and presents almost all the significant user functionality from the forthcoming 1.5 release in one place. In doing so, it has allowed us to contribute back many fixes and improvements. So, without further ado, some things you can see (and some you can't):

* New Browse System - this release incorporates the new browse system from Richard Jones. This can be seen here:

http://www.e-space.mmu.ac.uk/e-space/browse?type=type

in doing so, OR has contributed back to the forthcoming 1.5 release Oracle compatibility and improvements to the configuration. Also, we've added improved unicode and multi-lingual sorting:

http://rivm.openrepository.com/rivm/browse?type=title

and configurable columns for different indexes / sort options:

http://rivm.openrepository.com/rivm/browse?type=dateissued
http://rivm.openrepository.com/rivm/browse?type=dateaccessioned

(all currently included in the 1.5 branch). Also, we have enabled Richard's cached communities and collections count:

http://www.e-space.mmu.ac.uk/e-space/community-list

* Multi-lingual interface - this time, respect to Claudia Juergen for the multi-lingual interface. Admittedly, we haven't completed any translations as yet, but we do have a basic proof of existence on our test repository:

http://test.openrepository.com/test/

* Withdrawn items browse - unfortunately, one you can't see this one, but we added this based off of Richard's browse code. Now, in the admin interface you can see a list of all withdrawn items (sortable in the way as the item browse lists above). Again, this is part of the 1.5 branch.

* Confgurable Submission - thanks to Tim Donohue this time. The most recent patch made available of this has been used, making it very close to the code that is in the 1.5 branch. Another one you won't be able to see, unfortunately, and to be honest, we haven't done that much with it yet... but we do have some additional steps, added - like a document converter based off of Tim's offline OpenOffice document conversion patch (this isn't publicly available as yet, but hopefully will be shared soon). Although taking such a recent version of the patch has meant that we've found and repaired a few bugs for the 1.5 release.

So, as I said, our new repositories represent a lot of what people can expect to achieve with the 1.5 release - and now all of that's out of the way, I'll hopefully find some time to help finish it off!

Graham Triggs
Technical Architect
Open Repository




This email has been scanned by Postini.
For more information please visit http://www.postini.com

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

From annamavroudi at yahoo.gr  Wed Nov 28 02:35:55 2007
From: annamavroudi at yahoo.gr (anna mavroudi)
Date: Wed, 28 Nov 2007 07:35:55 +0000 (GMT)
Subject: [Dspace-general] dspace_migrate
Message-ID: <755115.21572.qm@web27710.mail.ukl.yahoo.com>

Hi all, 
  i would like to ask about the command :dspace_migrate.
  has anyone used it on windows?and if so, what exactly should I type in the command line?
  thanks, Anna

 		
---------------------------------
 ?????????????? Yahoo!
 ?????????? ?? ?????????? ???? ???? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? 
 http://login.yahoo.com/config/mail?.intl=gr 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20071128/eb0ac855/attachment.htm

From annamavroudi at yahoo.gr  Wed Nov 28 06:32:24 2007
From: annamavroudi at yahoo.gr (anna mavroudi)
Date: Wed, 28 Nov 2007 11:32:24 +0000 (GMT)
Subject: =?iso-8859-7?q?=C8=DD=EC=E1:=20Re:=20[Dspace-general]=20exception=20when?=
	=?iso-8859-7?q?=20importing=20items?=
In-Reply-To: <474AB645.5010107@ub.uni-dortmund.de>
Message-ID: <120027.74536.qm@web27713.mail.ukl.yahoo.com>


the directory path was D:/dspace_import_test1. After changing to
D:/import_item_test1, the test run was ok,as following:
**Test Run** - not actually importing items.
Destination Collections:
Owning Collection:????????    ?????????
Adding Items from directory:import_item_test1
Generating mapfile: mapfile3
***End of Test Run ***

But when i run the same command without the test flag, the item isn't inserted in dspace, only an empty mapfile is generated....
Anna

Claudia J??rgen <Claudia.Juergen at ub.uni-dortmund.de> ??????: Hi Anna,

seems as if the source directory you specified is not valid, check the 
source path specified with the -s option.


hope that helps

Claudia


anna mavroudi schrieb:
> Hi all,
> i'm trying to import items in dspace using the item importer in org.dspace.app.itemimport.ItemImport, but i get an exception as following:
> **Test Run** - not actually importing items.
> Destination Collections:
> Owning Collection:????????    ?????????
> Adding Items from directory:
> Generating mapfile:mapfile7
> java.lang.NullPointerException
> at org.dspace.app.itemimport.ItemImport.addItems
> at org.dspace.app.itemimport.ItemImport.main
> java.lang.NullPointerException
> ***End of Test Run ***
> Any ideas?
> Thanks in advance,
> Anna
> 
> 
>    
> ---------------------------------
>  ?????????????? Yahoo!
>  ?????????? ?? ?????????? ???? ???? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? 
>  http://login.yahoo.com/config/mail?.intl=gr 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Dspace-general mailing list
> Dspace-general at mit.edu
> http://mailman.mit.edu/mailman/listinfo/dspace-general


 		
---------------------------------
 ?????????????? Yahoo!
 ?????????? ?? ?????????? ???? ???? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? 
 http://login.yahoo.com/config/mail?.intl=gr 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20071128/98c6b6b7/attachment.htm

From annamavroudi at yahoo.gr  Wed Nov 28 08:59:14 2007
From: annamavroudi at yahoo.gr (anna mavroudi)
Date: Wed, 28 Nov 2007 13:59:14 +0000 (GMT)
Subject: =?iso-8859-7?q?=C8=DD=EC=E1:=20Re:=20[Dspace-general]=20exception=20when?=
	=?iso-8859-7?q?=20importing=20items-solved?=
Message-ID: <252671.20535.qm@web27710.mail.ukl.yahoo.com>


the problem with the names of the subdirectories of the items is now solved.i had to pay attention  the name of the file "contents" (it's "contents", not "contents.txt") 
now, i suppose that i want to import a webpage as an item using the itemimporter from the command line.
Must all the files that consist the webpage be stored at the same level/depth of the subdirectory? 
And is there any way for a simple user (not admin) who has the rights to submit to a collection to insert items with multiple files using batch import tools?
anna


anna mavroudi <annamavroudi at yahoo.gr> ??????: 
the directory path was D:/dspace_import_test1. After changing to
D:/import_item_test1, the test run was ok,as following:
**Test Run** - not actually importing items.
Destination Collections:
Owning Collection:????????    ?????????
Adding Items from directory:import_item_test1
Generating mapfile: mapfile3
***End of Test Run ***

But when i run the same command without the test flag, the item isn't inserted in dspace, only an empty mapfile is generated....
Anna

Claudia J??rgen <Claudia.Juergen at ub.uni-dortmund.de> ??????: Hi Anna,

seems as if the source directory you specified is not valid, check the 
source path specified with the -s option.


hope that helps

Claudia


anna mavroudi schrieb:
> Hi all,
> i'm trying to import items in dspace using the item  importer in org.dspace.app.itemimport.ItemImport, but i get an exception as following:
> **Test Run** - not actually importing items.
> Destination Collections:
> Owning Collection:????????    ?????????
> Adding Items from directory:
> Generating mapfile:mapfile7
> java.lang.NullPointerException
> at org.dspace.app.itemimport.ItemImport.addItems
> at org.dspace.app.itemimport.ItemImport.main
> java.lang.NullPointerException
> ***End of Test Run ***
> Any ideas?
> Thanks in advance,
> Anna
> 
> 
>    
> ---------------------------------
>  ?????????????? Yahoo!
>  ?????????? ?? ?????????? ???? ???? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? 
>  http://login.yahoo.com/config/mail?.intl=gr 
> 
> 
>  ------------------------------------------------------------------------
> 
> _______________________________________________
> Dspace-general mailing list
> Dspace-general at mit.edu
> http://mailman.mit.edu/mailman/listinfo/dspace-general

    

---------------------------------
  ?????????????? Yahoo!
  ?????????? ?? ?????????? ???? ???? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? 
  http://login.yahoo.com/config/mail?.intl=gr 

 		
---------------------------------
 ?????????????? Yahoo!
 ?????????? ?? ?????????? ???? ???? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? 
 http://login.yahoo.com/config/mail?.intl=gr 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20071128/5eed8b49/attachment.htm

From Claudia.Juergen at ub.uni-dortmund.de  Wed Nov 28 09:27:21 2007
From: Claudia.Juergen at ub.uni-dortmund.de (=?UTF-8?B?Q2xhdWRpYSBKw7xyZ2Vu?=)
Date: Wed, 28 Nov 2007 15:27:21 +0100
Subject: =?UTF-8?B?zpjOrc68zrE6IFJlOiBbRHNwYWNlLWdlbmVyYWxdIGV4Y2VwdGk=?=
	=?UTF-8?B?b24gd2hlbiBpbXBvcnRpbmcgaXRlbXM=?=
In-Reply-To: <120027.74536.qm@web27713.mail.ukl.yahoo.com>
References: <120027.74536.qm@web27713.mail.ukl.yahoo.com>
Message-ID: <474D7AC9.5020909@ub.uni-dortmund.de>

Hello Anna,

the output of the test run you listed below is not "Ok". If you're 
running a test import, e.g. [dspace] being your installation directory

[dspace]\bin\dsrun.bat
org.dspace.app.itemimport.ItemImport
-t (for testing only)
-a  (add items)
-e 1 (The user id)
-c 6 (The collection id)
-s D:\dspace_import_test1 (your Source dircectory)
-m D:\dspaceTestImportMapfile.map (Location of map file)

Your output would be something like:

Using DSpace installation in: [dspace]
**Test Run** - not actually importing items.
Destination collections:
Owning  Collection: "Name of Your Collection"
Adding items from directory: D:\dspace_import_test1
Generating mapfile: D:\dspaceTestImportMapfile.map
Adding item from directory "NameOfTheFirstSubdirectory in 
D:\dspace_import_test1"
Loading dublin core from 
D:\dspace_import_test1\SubdirectoryPerItem\dublin_core.xml

Then follows the output of the processing of the dublin_core.xml file in 
the form, e.g.:

Schema: dc Element: contributor Qualifier: author Value: Anglin, J. R.
Schema: dc Element: contributor Qualifier: author Value: Busch, Th.
Schema: dc Element: date Qualifier: created Value: 2001
Schema: dc Element: date Qualifier: issued Value: 2003-06-03

...
Then the contents file is processed:

Processing contents file: D:\dspace_import_test1\Subdirectory\contents
Bitstream: foo.pdf
Processing handle file: handle
It appears there is no handle file -- generating one
0 SubdirectoryName

...
and so on until the import ist completed.

so you better check the command especially the paths again.

Sunny greetings

Claudia



anna mavroudi schrieb:
> the directory path was D:/dspace_import_test1. After changing to
> D:/import_item_test1, the test run was ok,as following:
> **Test Run** - not actually importing items.
> Destination Collections:
> Owning Collection:????????    ?????????
> Adding Items from directory:import_item_test1
> Generating mapfile: mapfile3
> ***End of Test Run ***
> 
> But when i run the same command without the test flag, the item isn't inserted in dspace, only an empty mapfile is generated....
> Anna
> 
> Claudia J??rgen <Claudia.Juergen at ub.uni-dortmund.de> ??????: Hi Anna,
> 
> seems as if the source directory you specified is not valid, check the 
> source path specified with the -s option.
> 
> 
> hope that helps
> 
> Claudia
> 
> 
> anna mavroudi schrieb:
>> Hi all,
>> i'm trying to import items in dspace using the item importer in org.dspace.app.itemimport.ItemImport, but i get an exception as following:
>> **Test Run** - not actually importing items.
>> Destination Collections:
>> Owning Collection:????????    ?????????
>> Adding Items from directory:
>> Generating mapfile:mapfile7
>> java.lang.NullPointerException
>> at org.dspace.app.itemimport.ItemImport.addItems
>> at org.dspace.app.itemimport.ItemImport.main
>> java.lang.NullPointerException
>> ***End of Test Run ***
>> Any ideas?
>> Thanks in advance,
>> Anna
>>
>>
>>    
>> ---------------------------------
>>  ?????????????? Yahoo!
>>  ?????????? ?? ?????????? ???? ???? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? 
>>  http://login.yahoo.com/config/mail?.intl=gr 
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Dspace-general mailing list
>> Dspace-general at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/dspace-general
> 
> 
>  		
> ---------------------------------
>  ?????????????? Yahoo!
>  ?????????? ?? ?????????? ???? ???? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? 
>  http://login.yahoo.com/config/mail?.intl=gr 


From michele at dspace.org  Fri Nov 30 14:01:09 2007
From: michele at dspace.org (Michele Kimpton)
Date: Fri, 30 Nov 2007 14:01:09 -0500
Subject: [Dspace-general] Open repositories call for papers deadline
Message-ID: <36681457-7A9F-4103-B5AE-5750DF6D1321@dspace.org>

Dear community,

This is just a reminder the deadline for submitting papers to Open  
Repositories 2008 is next FRIDAY Dec 7th.  The conference is in  
Southampton UK April 1-4th 08.  If your proposal is not accepted by  
the general conference it will be reviewed for the dspace user group  
meeting following the conference.  Here are the details:


OPEN REPOSITORIES 2008: Deadline 7th Dec 2007 for Papers & Panels  
(Calls for Posters and User Group Participation to follow later)
http://www.openrepositories.org/2008

We invite developers, researchers and practitioners to submit papers  
describing novel experiences or developments in the construction and  
use of digital repositories. Submissions of UP TO 4 pages in length  
are requested for review. See the CFP page at the conference site for  
submission instructions. Submissions for panel discussions are also  
requested.

Repositories are being deployed in a variety of settings (research,  
scholarship, learning, science, cultural heritage) and across a range  
of scales (subject, national, regional, institutional, project, lab,  
personal). The aim of this conference is to address the technical,  
managerial, practical and theoretical issues that arise from diverse  
applications of repositories in the increasingly pervasive  
information environment.

A programme of papers, panel discussions, poster presentations,  
workshops, tutorials and developer coding sessions will bring  
together all the key stakeholders in the field. Open source software  
community meetings for the major platforms (EPrints, DSpace and  
Fedora) will also provide opportunities to advance and co-ordinate  
the development of repository installations across the world.

IMPORTANT DATES AND CONTACT INFO
Paper Submission Deadline: Friday 7th December 2007
Notification of Acceptance: Monday January 21st 2008
Submission of DSpace/EPrints/Fedora User Group Presentations: TBA
Submission of Posters: Monday 4th February 2008
Conference: April 1-4, 2008. University of Southampton, UK.
Enquiries to: Program Committee Chair (e.lyon at ukoln.ac.uk) or General  
Chair (lac at ecs.soton.ac.uk)

CONFERENCE THEMES
====================
The themes of the conference include (but are not limited to) the
following:

TRANSFORMATIONAL CHANGE IN THE KNOWLEDGE WORKPLACE
- Embedding repositories in business processes and individual workflow.
- Change Management
- Advocacy and Culture Change
- Policy development and policy lag.

PROFESSIONALISM AND PRACTICE
- Professional Development
- Workforce Capacity
- Skills and Training
- Roles and Responsibilities

SUSTAINABILITY
- Economic sustainability and new business models,
- Technical sustainability of a repository over time, including  
platform change and migration.
- Technical sustainability of holdings over time. Preservation.  
Audit, certification. Trust. Assessment tools.
- Managing sustainability failure - when a repository outlives its  
organisation or its organisational commitment.

LEGAL ISSUES
- Embargoes
- Licensing and Digital Rights Management
- Mandates
- Overcoming legislative barriers
- Contractual relationships - facilitating and monitoring
- International and cross-border issues

SUCCESSFUL INTEROPERABILITY
- Content standards - discipline-specific vs general
- Metadata standards and application profiles
- Quality standards and quality control processes
- Achieving interchange in multi-disciplinary or multi-institutional  
environments
- Semantic web and linked data
- Identifier management for data and real world resources
- Access and authentication

MODELS, ARCHITECTURES AND FRAMEWORKS
- Beyond OAIS
- Federations
- Institutional Models - uber- or multi-repository environments
- Adapting to changing e-infrastructure: SOA, services, cloud computing
- Scalability

VALUE CHAINS and SCHOLARLY COMMUNICATIONS
- Multi-stakeholder value: preservation, open access, research,  
management, admninistratiion
- Multi-agenda, multi-function, multi-purpose repositories
- Usefulness and usability
- Reference, reuse, reanalysis and repurposing of content
- Citation of data / learning objects
- Changes in scholarly practice
- New benchmarks for scholarly success
- Repository metrics
- Bibliometrics: usage and impact

SERVICES BUILT ON REPOSITORIES
- OAI services
- User-oriented services
- Mashups
- Social networking
- Commentary / tagging
- Searching / information discovery
- Alerting
- Mining
- Visualisation
- Integration with Second life and Virtual environments

USE CASES FOR REPOSITORIES
- E-research/E-science (e.g., data and publication; collaborative
services)
- E-scholarship
- Institutional repositories
- Discipline-oriented repositories
- Open Access
- Scholarly Publishing
- Digital Library
- Cultural Heritage
- Scientific repositories / data repositories
- Interdisciplinary, cross-disciplinary and cross-sectoral repositories




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20071130/57bda976/attachment.htm