Re: [Dspace-tech] How can i move the view statisitcs link
Hi Hilton, Thank you so much. I will make use of the link. Cheers.. From: Hilton Gibson [mailto:hilton.gib...@gmail.com] Sent: Monday, September 01, 2014 3:03 PM To: Peter Sichilyango Tutu Cc: dspace-tech Subject: Re: [Dspace-tech] How can i move the view statisitcs link Hi Peter Perhaps this will help: http://wiki.lib.sun.ac.za/index.php/SUNScholar/XMLUI_Theme/M1/Page_Structure#Create_custom_navigation_list Cheers hg Hilton Gibson Ubuntu Linux Systems Administrator JS Gericke Library Room 1025D Stellenbosch University Private Bag X5036 Stellenbosch 7599 South Africa Tel: +27 21 808 4100 | Cell: +27 84 646 4758 http://scholar.sun.ac.za http://bit.ly/goodir http://library.sun.ac.za http://za.linkedin.com/in/hiltongibson On 1 September 2014 14:20, Peter Sichilyango Tutu petertu...@gmail.com wrote: From: Peter Sichilyango Tutu [mailto:petertu...@gmail.com] Sent: Tuesday, July 29, 2014 8:35 PM To: 'dspace-tech' Subject: How to move the view statisitcs link Dear all, I am running dspace 3.2 xmlui. I have enabled the statistics and all is fine. However, I would like to move “view statistics” link that appears on every items page, so that it is placed side by side with the “show full item record link”. Any hints /ideas and workarounds? -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] Hide Recent Submissions 4.1
Dear Gary, We've removed the Recent Submissions section (in XMLUI) from both the home page and community/collection pages by setting the maximum number of recent submissions to be shown to zero: https://wiki.duraspace.org/display/DSDOC4x/Discovery#Discovery-CustomizingtheRecentSubmissionsdisplay I realize that you are using JSPUI, but hope that this at least helps as a starting point. Kind regards, Vladimir On 9/2/2014 7:47 AM, Gary Browne wrote: Hello all, DSpace version: 4.1 UI: JSP Servlet container: Tomcat 7 Server: RHEL 6.5 64-bit Java: OpenJDK 1.7 Is there a configuration option to hide/remove the Recent Submissions sliders in DSpace 4.1 (from the home page and community/collection pages)? Thanks, Gary GARY BROWNE | Development Programmer Library IT Services | Fisher Library F03 THE UNIVERSITY OF SYDNEY T +61 2 9351 5946 | M +61 405 647 868 E gary.bro...@sydney.edu.au | W http://sydney.edu.au Sent from my plain old desktop computer. CRICOS 00026A This email plus any attachments to it are confidential. Any unauthorised use is strictly prohibited. If you receive this email in error, please delete it and any attachments. Please think of our environment and only print this e-mail if necessary. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] Request a copy
Dear Gary, You need to make changes in two configuration files and create a new one (current dspace git master version has already what you want - dspace 4.1 doesn't, so you need it to copy it somehow): 1) Go to dspace/config/spring/api/requestitem.xml and change the following line bean class=org.dspace.app.requestitem.RequestItemMetadataStrategy id=org.dspace.app.requestitem.RequestItemAuthorExtractor to this one: bean class=org.dspace.app.requestitem.RequestItemHelpdeskStrategy id=org.dspace.app.requestitem.RequestItemAuthorExtractor 2) Create a file at path dspace-api/src/main/java/org/dspace/app/requestitem/RequestItemHelpdeskStra tegy.java and copy the contents from this URL inside the file: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/ds pace/app/requestitem/RequestItemHelpdeskStrategy.java 3) Go to dspace/config/dspace.cfg file and add at the end the last lines from the following file: https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg You will see the REQUEST ITEM CONFIGURATION section at the end, copy it as it is in your cfg file. 4) From the aforementioned lines, change request.item.helpdesk.override option to true, and also, provide the helpdesk email for option mail.helpdesk. Rebuild, ant update and you are done! Regards, Kostas -Original Message- From: Gary Browne [mailto:gary.bro...@sydney.edu.au] Sent: Tuesday, September 02, 2014 9:59 AM To: dspace-tech Tech Subject: [Dspace-tech] Request a copy Hi all, DSpace version: 4.1 UI: JSP Servlet container: Tomcat 7 Server: RHEL 6.5 64-bit Java: OpenJDK 1.7 Is it possible to have the Request a copy button send to a DSpace administrator email address only, rather than to the item owner? If so, where would I configure/code/hack this? Thanks, Gary GARY BROWNE | Development Programmer Library IT Services | Fisher Library F03 THE UNIVERSITY OF SYDNEY T +61 2 9351 5946 | M +61 405 647 868 E gary.bro...@sydney.edu.au | W http://sydney.edu.au Sent from my plain old desktop computer. CRICOS 00026A This email plus any attachments to it are confidential. Any unauthorised use is strictly prohibited. If you receive this email in error, please delete it and any attachments. Please think of our environment and only print this e-mail if necessary. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories
Hi Hilton, It looks like a large proportion of DSpace instances would be excluded if this proposal were implemented. It seems a bit over the top, I think we may reply with a comment to that effect. Cheers, Robin. Robin Taylor Main Library University of Edinburgh From: Hilton Gibson hilton.gib...@gmail.com Sent: 01 September 2014 19:01 To: dspace-tech; General List Subject: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories The Ranking is also a powerful tool for penalizing bad practices, with especial emphasis in the awful naming proposals by software developers that ignore librarian traditions and in many ways are going against intellectual rights of depositing authors. We truly believe the lengthy and useless addresses coined for the repository items have a negative impact in their web visibility and affect the authors will to deposit as it makes difficult the citation of full texts in future papers. http://repositories.webometrics.info/en/node/26 ?Hi All Sorry for the cross-posting? ?How will this affect DSpace installations?? ?Regards hg? The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] Request a copy
Hi Gary,
Is it possible to have the Request a copy button send to a DSpace
administrator email address only, rather than to the item owner? If so, where
would I configure/code/hack this?
I've done something similar with our DSpace v4.1/JSPUI - Amongst other changes
to our Embargo/Request a copy handling, I hacked our Request a copy
implementation to send the Request email to an email address specified in the
item's metadata (rather than always sending to the submitter), and I added a
config option to dspace.cfg to specify the metadata field that held that
address (which is dc.author.email in our case).
To achieve this, I hacked RequestItemServlet.java (src in
/usr/src/dspace-4.1-src-release/dspace-jspui/src/main/java/org/dspace/app/webui/servlet
IIRC), and I've attached my hacked version in case it is of use or help to you
(I'm guessing the mailing list will strip this, though, so if anyone else is
interested in this, just let me know). If you search for MW in this file,
you'll see the places where I've added/hacked the code (all my hacks (should!)
have comments with my initials and the date) . . .
Basically, if you want to control where the email goes, I think you need to
affect the email address that is passed into this line (it was a while ago I
did this!):
email.addRecipient(emailRequest);
- which occurs in the processForm and processAdmin functions I think . . .
So, if you wanted to hard code it, you could simply put the email address in
there (probably pulled from the config using
ConfigurationManager.getProperty(mail.admin) rather hard coding the actual
address) . . .
Alternatively, I note that just above the addRecipient line, the code checks
if emailRequest is empty, and if it is, populates it with the Admin email
address instead (I THINK this is in the original, and isn't something I have
added!?):
if (emailRequest == null) {
emailRequest = ConfigurationManager
.getProperty(mail.admin);
}
So, you could hack this test to get the change you want?
If it were me, I'd probably add a flag to the config file (a key with a value
of true or false) and add a test for that value to the if statement above, that
way you could toggle between sending emails to the Admin or to the expected
email address simply by changing the config option - so, for example (off the
top of my head, and NOT TESTED!), in dspace.cfg, add:
request.item.adminemail = true
- and then hack the above to something like:
if ((emailRequest == null) ||
(true.equalsIgnoreCase(ConfigurationManager.getProperty(request.item.adminemail
))) {
emailRequest = ConfigurationManager
.getProperty(mail.admin);
}
[Not sure if you actually need to test against true, or if the value in
request.item.adminemail can be used as a Boolean as is (without a
comparison) - so you may be able to clean that up a little!]
The above may not be the best way to achieve what you want (and others are
welcome to correct me or offer other/better solutions!), but would probably get
you where you want to go!
I hope this is of some use.
Regards,
Mike
Michael White
eLearning Liaison and Development (eLD)
Information Services
S8, Library
University of Stirling
Stirling SCOTLAND
FK9 4LA
Email: michael.wh...@stir.ac.uk
Tel: +44 (0) 1786 466877
Fax: +44 (0) 1786 466880
http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld
Message: 5
Date: Tue, 2 Sep 2014 06:58:59 +
From: Gary Browne gary.bro...@sydney.edu.au
Subject: [Dspace-tech] Request a copy
To: dspace-tech Tech dspace-tech@lists.sourceforge.net
Message-ID: 23DF3A1C5648DD43BCAE0666B5AFAD119405096A@ex-mbx-
pro-02
Content-Type: text/plain; charset=iso-8859-1
Hi all,
DSpace version: 4.1
UI: JSP
Servlet container: Tomcat 7
Server: RHEL 6.5 64-bit
Java: OpenJDK 1.7
Is it possible to have the Request a copy button send to a DSpace
administrator email address only, rather than to the item owner? If so, where
would I configure/code/hack this?
Thanks,
Gary
GARY BROWNE?| Development Programmer
Library IT Services | Fisher Library F03?
THE UNIVERSITY OF SYDNEY
T +61 2 9351 5946 | M +61 405 647 868 ?
E gary.bro...@sydney.edu.au | W http://sydney.edu.au Sent from my plain
old desktop computer.
CRICOS 00026A
This email plus any attachments to it are confidential. Any unauthorised use
is
strictly prohibited. If you receive this email in error, please delete it and
any
attachments.
Please think of our environment and only print this e-mail if necessary.
--
The University of Stirling has been ranked in the top 12 of UK universities for
graduate employment*.
94% of our 2012 graduates were in work and/or further study within six months
of graduation.
*The Telegraph
The University of Stirling is a charity registered in Scotland, number SC
011159.
RequestItemServlet.java
[Dspace-tech] Tomcat takes forever
I have installed DSpace 4.2 through upgrade from 3.1 and also with a fresh install. Both times when I copied the webapps inside Tomcat installation, Tomcat stops rensponding and loading takes forever. If I delete the sword, swordv2 and xmlui folders, the jspui that I want to use works fine. What should cause this bug? System: Windows 2008 R2 Standard, Apache Tomcat 8, Apache Ant 1.9.4, Apache Maven 3.2.2, PostgreSQL 9.2, JDK 1.7.0_65 with JRE 7 Thanks, John -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories
Hi Hilton, Looking at their proposal I can see that as an institution we’ll be excluded on at least 3 points, assuming that they meant to finish point 4 with “will be excluded”. 4) Repositories using ports others than 80 or 8080 5) Institutional repositories that use the name of the software in the host name will be excluded. 6) Institutional repositories that use more than 4 directory levels for the URL address of the full texts will be excluded. We’ll be excluded by point 4 as we use https rather than http (there is a redirect on http that bounces visitors to the https site). We’ll be excluded by point 5 as our repository has a hostname of dspace. Finally we’ll be excluded by point 6 as our setup has 5 directories to the full text. But looking at what actually is important here, which I believe to be the visibility of our repository’s content, I found myself ruling out making any changes to comply with their proposal. If we switch to http as suggested by their point 4 then we’ll actually worsen our position in Google search results. From the point of view of point 5 I can’t see anyway to justify the workload required to switch hostnames and keep all the legacy links working (if we let the old links break then our visibility will definitely decrease). Finally trying to do anything about point 6 would require extensive changes to our DSpace configuration and code (and the same large workload to keep the legacy links working). In other words our repository’s visibility will be negatively affected if we try to complying with their new proposal. Regards, Jason Cooper. From: Hilton Gibson [mailto:hilton.gib...@gmail.com] Sent: 01 September 2014 19:01 To: dspace-tech; General List Subject: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories The Ranking is also a powerful tool for penalizing bad practices, with especial emphasis in the awful naming proposals by software developers that ignore librarian traditions and in many ways are going against intellectual rights of depositing authors. We truly believe the lengthy and useless addresses coined for the repository items have a negative impact in their web visibility and affect the authors will to deposit as it makes difficult the citation of full texts in future papers. http://repositories.webometrics.info/en/node/26 Hi All Sorry for the cross-posting How will this affect DSpace installations? Regards hg -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] Dspace 3.1 to 4.2 upgrade: XMLUI webapp not running and can not be started
Hi, Nason, did you ever configure Tomcat to run as the DSpace user? What are you using for a service init script? --Hardy Sent from my iPad On Sep 1, 2014, at 1:52 PM, Nason Bimbe nasonbi...@gmail.commailto:nasonbi...@gmail.com wrote: Hi, I am still having the same problem. I have made sure dspace is the owner of all files and I am also using dspace user to build the DSpace. I am running Debian Wheezy. This is how Tomcat was installed = - downloaded, copied Tomact 7 files into /usr/local, created a symbolic link mv /home/dspace/Downloads/apache-tomcat-7.0.54 /usr/local unlink tomcat ln -s apache-tomcat-7.0.54 tomcat - made sure that tomcat folder is owned by the dspace user cd /usr/local chown -R dspace:dspace apache-tomcat-7.0.54 - restarted tomcat /etc/init.d/tomcat restart - checked if tomcat is running and is running ok http://localhost:8080 This the change I made to the top level POM as advised by Bram by adding scope tag === dependency groupIdjavax.servlet/groupId artfactIdservlet-api/artfactID version2.5/version scopeprovided/scope /dependency Regards Nason On 1 September 2014 00:38, Pottinger, Hardy J. pottinge...@missouri.edumailto:pottinge...@missouri.edu wrote: Peter is right, you can ignore the info line. You probably have a permission issue. How did you install and start Tomcat? What OS are you using? --Hardy Sent from my Zact Mobile phone. Peter Dietz pe...@longsight.commailto:pe...@longsight.com wrote: Hmm, I don't know what's wrong in this case. Check your logs further back for a line that starts with ERROR, the INFO line might not be too much to worry about. When you built the DSpace 4 code, I would try mvn -U clean package. Also, double check that your tomcat/dspace user is the owner of all the files. Peter Dietz Longsight www.longsight.comhttp://www.longsight.com pe...@longsight.commailto:pe...@longsight.com p: 740-599-5005 x809 On Fri, Aug 29, 2014 at 11:56 AM, Nason Bimbe nasonbi...@gmail.commailto:nasonbi...@gmail.com wrote: Hello, I have upgraded the dspace from 3.1 to 4.2 but when I try to access XMLUI webapp I get a 404. Checking the Tomcat manager shows that xmlui webapp is not running but the rest are, that is oai and solr. When I try to start the webapp in Tomcat manager I get a FAIL error (FAIL - Application at contect path /xmlui could not be started). The dspace logs to not show any errors but the catalina out shows the following... Aug 29, 2014 2:16:01 PM org.apache.catalina.loader.WebappClassLoader validateJarFile INFO: validateJarFile(/usr/local/dspace/webapps/xmlui/WEB-INF/lib/jsp-api-2.1.jar) - jar not loaded. See Servlet Spec 3.0, section 10.7.2. Offending class: javax/el/Expression.class Aug 29, 2014 2:16:12 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Error listenerStart Aug 29, 2014 2:16:12 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Context [/xmlui] startup failed due to previous errors The platform I am using has: - OS: Debian Wheezy Java: 1.7.0_65 (OpenJDK) Tomcat: 7.0.54 Maven: 3.2.1 Has anyone encountered this problem or does anyone know a solution or where I am going wrong? Thanks Nason -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.netmailto:DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] Tomcat takes forever
On Tue, Sep 02, 2014 at 03:11:15PM +0300, John Chris wrote: I have installed DSpace 4.2 through upgrade from 3.1 and also with a fresh install. Both times when I copied the webapps inside Tomcat installation, Tomcat stops rensponding and loading takes forever. If I delete the sword, swordv2 and xmlui folders, the jspui that I want to use works fine. What should cause this bug? System: Windows 2008 R2 Standard, Apache Tomcat 8, Apache Ant 1.9.4, Apache Maven 3.2.2, PostgreSQL 9.2, JDK 1.7.0_65 with JRE 7 If you have no use for sword, swordv2, or xmlui then don't copy them into Tomcat. It is quite proper to only run the webapp.s that you intend to use. (solr is used by xmlui and jspui, and perhaps others, so it should always be included.) If the documentation says otherwise, we should correct it. Do you find anything suggestive in the Tomcat or DSpace log files, when Tomcat stops responding? I see that you have a very recent Tomcat, which is good, but Tomcat 8 and recent Tomcat 7 will search through every JAR looking for configuration fragments and taglibs unless told not to. We need to work out how DSpace should inform Servlet 3.x containers as to which JARs are worth inspecting. In the meantime, starting up DSpace on recent Tomcat releases may indeed just be slow. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: Digital signature -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
[Dspace-tech] DSpace Sword Client anyone?
With apologies for cross-posting. Hi all, Unfortunately the DSpace Sword Client feature (https://wiki.duraspace.org/display/DSDOC4x/SWORDv1+Client) has an unsupported dependency, Apache Httpclient (http://hc.apache.org/httpclient-3.x/). The practical choices are to leave the dependency in place knowing that it is past 'end of life', or remove/deprecate the Sword Client feature. To enable us to make the best decision could you please let me know if you make use of the Sword Client. Thanks, Robin. Robin Taylor Main Library University of Edinburgh -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] Dspace 3.1 to 4.2 upgrade: XMLUI webapp not running and can not be started
Hi Hardy, I will be trying it out again tomorrow afresh after restoring the system to before the attempted upgrade. I am using a script I created in /etc/init.d for starting/stopping Tomcat. I will also try Shaun Donovan's information which he sent directly to me and shown below. I will update you how it on progress. Thanks again for the help. Best Nason I had this problem, not on xmlui but on oai. I found the following on the web and tried it, and it worked. Check Inside the Following Directory for the jar file el-api.jar :C:\apache-tomcat-7.0.39\lib\el-api.jar if it exists then in this directory of your web application WEB-INF\lib\el-api.jar the jar should be removed What I did is find the file, and moved it, then the app started without issues. This was on a development machine. I then tried it on the production machine and my oai would still not start. I had other issues in my catalina.out which pointed to the web.xml file in tomcats conf directory which had !-- comments within a comment, which I also removed, and then production worked as well. On 2 September 2014 13:59, Pottinger, Hardy J. pottinge...@missouri.edu wrote: Hi, Nason, did you ever configure Tomcat to run as the DSpace user? What are you using for a service init script? --Hardy Sent from my iPad On Sep 1, 2014, at 1:52 PM, Nason Bimbe nasonbi...@gmail.com wrote: Hi, I am still having the same problem. I have made sure dspace is the owner of all files and I am also using dspace user to build the DSpace. I am running Debian Wheezy. This is how Tomcat was installed = - downloaded, copied Tomact 7 files into /usr/local, created a symbolic link mv /home/dspace/Downloads/apache-tomcat-7.0.54 /usr/local unlink tomcat ln -s apache-tomcat-7.0.54 tomcat - made sure that tomcat folder is owned by the dspace user cd /usr/local chown -R dspace:dspace apache-tomcat-7.0.54 - restarted tomcat /etc/init.d/tomcat restart - checked if tomcat is running and is running ok http://localhost:8080 This the change I made to the top level POM as advised by Bram by adding scope tag === dependency groupIdjavax.servlet/groupId artfactIdservlet-api/artfactID version2.5/version scopeprovided/scope /dependency Regards Nason On 1 September 2014 00:38, Pottinger, Hardy J. pottinge...@missouri.edu wrote: Peter is right, you can ignore the info line. You probably have a permission issue. How did you install and start Tomcat? What OS are you using? --Hardy Sent from my Zact Mobile phone. Peter Dietz pe...@longsight.com wrote: Hmm, I don't know what's wrong in this case. Check your logs further back for a line that starts with ERROR, the INFO line might not be too much to worry about. When you built the DSpace 4 code, I would try mvn -U clean package. Also, double check that your tomcat/dspace user is the owner of all the files. Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 On Fri, Aug 29, 2014 at 11:56 AM, Nason Bimbe nasonbi...@gmail.com wrote: Hello, I have upgraded the dspace from 3.1 to 4.2 but when I try to access XMLUI webapp I get a 404. Checking the Tomcat manager shows that xmlui webapp is not running but the rest are, that is oai and solr. When I try to start the webapp in Tomcat manager I get a FAIL error (FAIL - Application at contect path /xmlui could not be started). The dspace logs to not show any errors but the catalina out shows the following... Aug 29, 2014 2:16:01 PM org.apache.catalina.loader.WebappClassLoader validateJarFile INFO: validateJarFile(/usr/local/dspace/webapps/xmlui/WEB-INF/lib/jsp-api-2.1.jar) - jar not loaded. See Servlet Spec 3.0, section 10.7.2. Offending class: javax/el/Expression.class Aug 29, 2014 2:16:12 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Error listenerStart Aug 29, 2014 2:16:12 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Context [/xmlui] startup failed due to previous errors The platform I am using has: - OS: Debian Wheezy Java: 1.7.0_65 (OpenJDK) Tomcat: 7.0.54 Maven: 3.2.1 Has anyone encountered this problem or does anyone know a solution or where I am going wrong? Thanks Nason -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ DSpace-tech
Re: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories
Hi, there is more cause for concern than just the handle issue (which is alarming enough), re-read the announcement: http://repositories.webometrics.info/en/node/26 They intend to no longer rank repositories running on ports that are not cleartext (80 or 8080) which, I'm sorry, is completely wrong-headed. I will not ask my users to send their passwords in the clear. It's not even open for discussion. Even if we set aside the issue of login details, I am willing to bet there are a fair contingent of researchers who would prefer to keep their research activities out of a cleartext channel--despite the many concerns about SSL being compromised, running a repository on port 443 is, I think, at least a good-faith effort at securing the usage of the repository. Is this port requirement an attempt to penalize institutions who embargo some of their content? If that's Webometrics' desire, they will have to make a better effort than to lump all port 443 repositories into that category. It's a pity, I realize they have good intentions, but I think these decisions will likely diminish the relevance of their rankings. --Hardy From: TAYLOR Robin [robin.tay...@ed.ac.uk] Sent: Tuesday, September 02, 2014 5:42 AM To: Hilton Gibson; dspace-tech; General List Subject: Re: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories Hi Hilton, It looks like a large proportion of DSpace instances would be excluded if this proposal were implemented. It seems a bit over the top, I think we may reply with a comment to that effect. Cheers, Robin. Robin Taylor Main Library University of Edinburgh From: Hilton Gibson hilton.gib...@gmail.com Sent: 01 September 2014 19:01 To: dspace-tech; General List Subject: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories The Ranking is also a powerful tool for penalizing bad practices, with especial emphasis in the awful naming proposals by software developers that ignore librarian traditions and in many ways are going against intellectual rights of depositing authors. We truly believe the lengthy and useless addresses coined for the repository items have a negative impact in their web visibility and affect the authors will to deposit as it makes difficult the citation of full texts in future papers. http://repositories.webometrics.info/en/node/26 Hi All Sorry for the cross-posting How will this affect DSpace installations? Regards hg -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories
Points 4, 6 and 7 reveal a profound lack of understanding of hypertext and fundamental security issues, and I would not be surprised to learn that they ignore typical user behavior as well. Does anyone but a sysadmin. or developer really type in direct URLs to repository content? Citations please. I would argue that we can better do without appearing in the Ranking Web of Repositories, whatever that is, than to give up the ability to protect our users' credentials. (Point 4, which disallows HTTPS) Point 5 is just bizarre. Why does someone think this is a problem? Not that I think it particularly useful to use the name of supporting software in naming a repository service, but how can it possibly hurt? Are there any actual statistics to support the belief that long URLs in the interior of a service actually affect anyone's behavior? It sounds like there should be some discussion among the various parties. Where? -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: Digital signature -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories
Would it be possible for DuraSpace leadership to contact them to explain the problems with their proposal? I agree that this seems only likely to diminish the relevance of their rankings. Sarah Sarah L. Shreeves IDEALS Coordinator – http://ideals.illinois.edu/ Scholarly Commons Co-Coordinator – http://library.illinois.edu/sc/ Associate Professor, University Library University of Illinois at Urbana-Champaign sshre...@illinois.edumailto:sshre...@illinois.edu 217-244-3877 From: Pottinger, Hardy J. [mailto:pottinge...@missouri.edu] Sent: Tuesday, September 02, 2014 9:32 AM To: TAYLOR Robin; Hilton Gibson; dspace-tech; General List Subject: Re: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories Hi, there is more cause for concern than just the handle issue (which is alarming enough), re-read the announcement: http://repositories.webometrics.info/en/node/26 They intend to no longer rank repositories running on ports that are not cleartext (80 or 8080) which, I'm sorry, is completely wrong-headed. I will not ask my users to send their passwords in the clear. It's not even open for discussion. Even if we set aside the issue of login details, I am willing to bet there are a fair contingent of researchers who would prefer to keep their research activities out of a cleartext channel--despite the many concerns about SSL being compromised, running a repository on port 443 is, I think, at least a good-faith effort at securing the usage of the repository. Is this port requirement an attempt to penalize institutions who embargo some of their content? If that's Webometrics' desire, they will have to make a better effort than to lump all port 443 repositories into that category. It's a pity, I realize they have good intentions, but I think these decisions will likely diminish the relevance of their rankings. --Hardy From: TAYLOR Robin [robin.tay...@ed.ac.uk] Sent: Tuesday, September 02, 2014 5:42 AM To: Hilton Gibson; dspace-tech; General List Subject: Re: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories Hi Hilton, It looks like a large proportion of DSpace instances would be excluded if this proposal were implemented. It seems a bit over the top, I think we may reply with a comment to that effect. Cheers, Robin. Robin Taylor Main Library University of Edinburgh From: Hilton Gibson hilton.gib...@gmail.commailto:hilton.gib...@gmail.com Sent: 01 September 2014 19:01 To: dspace-tech; General List Subject: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories The Ranking is also a powerful tool for penalizing bad practices, with especial emphasis in the awful naming proposals by software developers that ignore librarian traditions and in many ways are going against intellectual rights of depositing authors. We truly believe the lengthy and useless addresses coined for the repository items have a negative impact in their web visibility and affect the authors will to deposit as it makes difficult the citation of full texts in future papers. http://repositories.webometrics.info/en/node/26 Hi All Sorry for the cross-posting How will this affect DSpace installations? Regards hg -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] Dspace 3.1 to 4.2 upgrade: XMLUI webapp not running and can not be started
Hi, Nason, here is the init script I use for running a binary install of Tomcat 7 on RHEL [1] Note that it gets progressively more aggressive when shutting down Tomcat. This script is a mash-up of a few sample Tomcat init scripts I found online, citations are given in the code. [1] https://gist.github.com/hardyoyo/9903387 From: Nason Bimbe [nasonbi...@gmail.com] Sent: Tuesday, September 02, 2014 9:25 AM To: Pottinger, Hardy J. Cc: Peter Dietz; dspace-tech Subject: Re: [Dspace-tech] Dspace 3.1 to 4.2 upgrade: XMLUI webapp not running and can not be started Hi Hardy, I will be trying it out again tomorrow afresh after restoring the system to before the attempted upgrade. I am using a script I created in /etc/init.d for starting/stopping Tomcat. I will also try Shaun Donovan's information which he sent directly to me and shown below. I will update you how it on progress. Thanks again for the help. Best Nason I had this problem, not on xmlui but on oai. I found the following on the web and tried it, and it worked. Check Inside the Following Directory for the jar file el-api.jar :C:\apache-tomcat-7.0.39\lib\el-api.jar if it exists then in this directory of your web application WEB-INF\lib\el-api.jar the jar should be removed What I did is find the file, and moved it, then the app started without issues. This was on a development machine. I then tried it on the production machine and my oai would still not start. I had other issues in my catalina.out which pointed to the web.xml file in tomcats conf directory which had !-- comments within a comment, which I also removed, and then production worked as well. On 2 September 2014 13:59, Pottinger, Hardy J. pottinge...@missouri.edumailto:pottinge...@missouri.edu wrote: Hi, Nason, did you ever configure Tomcat to run as the DSpace user? What are you using for a service init script? --Hardy Sent from my iPad On Sep 1, 2014, at 1:52 PM, Nason Bimbe nasonbi...@gmail.commailto:nasonbi...@gmail.com wrote: Hi, I am still having the same problem. I have made sure dspace is the owner of all files and I am also using dspace user to build the DSpace. I am running Debian Wheezy. This is how Tomcat was installed = - downloaded, copied Tomact 7 files into /usr/local, created a symbolic link mv /home/dspace/Downloads/apache-tomcat-7.0.54 /usr/local unlink tomcat ln -s apache-tomcat-7.0.54 tomcat - made sure that tomcat folder is owned by the dspace user cd /usr/local chown -R dspace:dspace apache-tomcat-7.0.54 - restarted tomcat /etc/init.d/tomcat restart - checked if tomcat is running and is running ok http://localhost:8080 This the change I made to the top level POM as advised by Bram by adding scope tag === dependency groupIdjavax.servlet/groupId artfactIdservlet-api/artfactID version2.5/version scopeprovided/scope /dependency Regards Nason On 1 September 2014 00:38, Pottinger, Hardy J. pottinge...@missouri.edumailto:pottinge...@missouri.edu wrote: Peter is right, you can ignore the info line. You probably have a permission issue. How did you install and start Tomcat? What OS are you using? --Hardy Sent from my Zact Mobile phone. Peter Dietz pe...@longsight.commailto:pe...@longsight.com wrote: Hmm, I don't know what's wrong in this case. Check your logs further back for a line that starts with ERROR, the INFO line might not be too much to worry about. When you built the DSpace 4 code, I would try mvn -U clean package. Also, double check that your tomcat/dspace user is the owner of all the files. Peter Dietz Longsight www.longsight.comhttp://www.longsight.com pe...@longsight.commailto:pe...@longsight.com p: 740-599-5005 x809 On Fri, Aug 29, 2014 at 11:56 AM, Nason Bimbe nasonbi...@gmail.commailto:nasonbi...@gmail.com wrote: Hello, I have upgraded the dspace from 3.1 to 4.2 but when I try to access XMLUI webapp I get a 404. Checking the Tomcat manager shows that xmlui webapp is not running but the rest are, that is oai and solr. When I try to start the webapp in Tomcat manager I get a FAIL error (FAIL - Application at contect path /xmlui could not be started). The dspace logs to not show any errors but the catalina out shows the following... Aug 29, 2014 2:16:01 PM org.apache.catalina.loader.WebappClassLoader validateJarFile INFO: validateJarFile(/usr/local/dspace/webapps/xmlui/WEB-INF/lib/jsp-api-2.1.jar) - jar not loaded. See Servlet Spec 3.0, section 10.7.2. Offending class: javax/el/Expression.class Aug 29, 2014 2:16:12 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Error listenerStart Aug 29, 2014 2:16:12 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Context [/xmlui] startup failed due to previous errors The platform I am using has: - OS: Debian Wheezy Java: 1.7.0_65 (OpenJDK) Tomcat: 7.0.54 Maven: 3.2.1 Has anyone encountered this problem or does anyone
Re: [Dspace-tech] Dspace 3.1 to 4.2 upgrade: XMLUI webapp not running and can not be started
Thanks for this, will try it out. On 2 September 2014 15:43, Pottinger, Hardy J. pottinge...@missouri.edu wrote: Hi, Nason, here is the init script I use for running a binary install of Tomcat 7 on RHEL [1] Note that it gets progressively more aggressive when shutting down Tomcat. This script is a mash-up of a few sample Tomcat init scripts I found online, citations are given in the code. [1] https://gist.github.com/hardyoyo/9903387 *From:* Nason Bimbe [nasonbi...@gmail.com] *Sent:* Tuesday, September 02, 2014 9:25 AM *To:* Pottinger, Hardy J. *Cc:* Peter Dietz; dspace-tech *Subject:* Re: [Dspace-tech] Dspace 3.1 to 4.2 upgrade: XMLUI webapp not running and can not be started Hi Hardy, I will be trying it out again tomorrow afresh after restoring the system to before the attempted upgrade. I am using a script I created in /etc/init.d for starting/stopping Tomcat. I will also try Shaun Donovan's information which he sent directly to me and shown below. I will update you how it on progress. Thanks again for the help. Best Nason I had this problem, not on xmlui but on oai. I found the following on the web and tried it, and it worked. Check Inside the Following Directory for the jar file el-api.jar :C:\apache-tomcat-7.0.39\lib\el-api.jar if it exists then in this directory of your web application WEB-INF\lib\el-api.jar the jar should be removed What I did is find the file, and moved it, then the app started without issues. This was on a development machine. I then tried it on the production machine and my oai would still not start. I had other issues in my catalina.out which pointed to the web.xml file in tomcats conf directory which had !-- comments within a comment, which I also removed, and then production worked as well. On 2 September 2014 13:59, Pottinger, Hardy J. pottinge...@missouri.edu wrote: Hi, Nason, did you ever configure Tomcat to run as the DSpace user? What are you using for a service init script? --Hardy Sent from my iPad On Sep 1, 2014, at 1:52 PM, Nason Bimbe nasonbi...@gmail.com wrote: Hi, I am still having the same problem. I have made sure dspace is the owner of all files and I am also using dspace user to build the DSpace. I am running Debian Wheezy. This is how Tomcat was installed = - downloaded, copied Tomact 7 files into /usr/local, created a symbolic link mv /home/dspace/Downloads/apache-tomcat-7.0.54 /usr/local unlink tomcat ln -s apache-tomcat-7.0.54 tomcat - made sure that tomcat folder is owned by the dspace user cd /usr/local chown -R dspace:dspace apache-tomcat-7.0.54 - restarted tomcat /etc/init.d/tomcat restart - checked if tomcat is running and is running ok http://localhost:8080 This the change I made to the top level POM as advised by Bram by adding scope tag === dependency groupIdjavax.servlet/groupId artfactIdservlet-api/artfactID version2.5/version scopeprovided/scope /dependency Regards Nason On 1 September 2014 00:38, Pottinger, Hardy J. pottinge...@missouri.edu wrote: Peter is right, you can ignore the info line. You probably have a permission issue. How did you install and start Tomcat? What OS are you using? --Hardy Sent from my Zact Mobile phone. Peter Dietz pe...@longsight.com wrote: Hmm, I don't know what's wrong in this case. Check your logs further back for a line that starts with ERROR, the INFO line might not be too much to worry about. When you built the DSpace 4 code, I would try mvn -U clean package. Also, double check that your tomcat/dspace user is the owner of all the files. Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 On Fri, Aug 29, 2014 at 11:56 AM, Nason Bimbe nasonbi...@gmail.com wrote: Hello, I have upgraded the dspace from 3.1 to 4.2 but when I try to access XMLUI webapp I get a 404. Checking the Tomcat manager shows that xmlui webapp is not running but the rest are, that is oai and solr. When I try to start the webapp in Tomcat manager I get a FAIL error (FAIL - Application at contect path /xmlui could not be started). The dspace logs to not show any errors but the catalina out shows the following... Aug 29, 2014 2:16:01 PM org.apache.catalina.loader.WebappClassLoader validateJarFile INFO: validateJarFile(/usr/local/dspace/webapps/xmlui/WEB-INF/lib/jsp-api-2.1.jar) - jar not loaded. See Servlet Spec 3.0, section 10.7.2. Offending class: javax/el/Expression.class Aug 29, 2014 2:16:12 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Error listenerStart Aug 29, 2014 2:16:12 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Context [/xmlui] startup failed due to previous errors The platform I am using has: - OS: Debian Wheezy Java: 1.7.0_65 (OpenJDK) Tomcat: 7.0.54 Maven: 3.2.1 Has
Re: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories
This odd collection of guidelines makes Webometrics lose credibility in my book. i.e. Google / Google Scholar indexing guidelines is all anyone should be paying attention to. Regarding #5 (software name in hostname). Should MIT be reconsidering the use of dspace.mit.edu ?? They have a very good historical reason to continue using that domain. #4 (insecure), #6 (four directory levels), #7 (numeric codes) are especially bizarre. Is their ideal repository just a url shortening service? And do they oppose the use of handle/doi, since including those in the url increases the length. Also, one reason for leaving ssl on all the time is so that nobody is altering the information being transferred. i.e. You could have an abusive ISP that alters the response by adding/removing information from a response. And since the payload is sent in cleartext, this abusive ISP is able to spy/monitor your activity, and manipulate the result once you encounter the content their trying to censor. Do you want repositories to be stuck in the realm of untrustable-repositories? My experience with this is that the public wifi at a local hospital filters your internet so that you can't actually look up medical information. (Wouldn't want the public to be an instant expert, and second guessing the medical staff, I'm guessing). Solution: Turn on SSL, leave it on, always. Do they have a proposal to alleviate these issues of awful naming proposals by software developers that ignore librarian traditions. I'm guessing they're also against IPv6, since it makes IP addresses too long to type, because I'm always typing in IP addresses... I don't think the internet needs to be rearchitected by well intended folks at webometrics. Sure, we could look at condensing things to just whats neccessary, to assist with making a citable link directly to bitstreams. But isn't that what handles/doi's are for? Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 On Tue, Sep 2, 2014 at 10:28 AM, Mark H. Wood mw...@iupui.edu wrote: Points 4, 6 and 7 reveal a profound lack of understanding of hypertext and fundamental security issues, and I would not be surprised to learn that they ignore typical user behavior as well. Does anyone but a sysadmin. or developer really type in direct URLs to repository content? Citations please. I would argue that we can better do without appearing in the Ranking Web of Repositories, whatever that is, than to give up the ability to protect our users' credentials. (Point 4, which disallows HTTPS) Point 5 is just bizarre. Why does someone think this is a problem? Not that I think it particularly useful to use the name of supporting software in naming a repository service, but how can it possibly hurt? Are there any actual statistics to support the belief that long URLs in the interior of a service actually affect anyone's behavior? It sounds like there should be some discussion among the various parties. Where? -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
[Dspace-tech] dc.creator
In previous DSpace versions dc.creator was reserved for the system. I assume because of some type of hard coding feature in OAI module. From XOAI on, all of this is outdated, isnt'ít? I don't know if is there some other consideration to take in account before starting to include creator in input-forms. Regards German PD: In metadata registry, creator continues appearing as Do not use; only for harvested metadata.. Time to change it? -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] harvester.handleMetadataField on oai.cfg
Hello Rodrigo, I actually don't see that setting in the DSpace 3.2 oai.cfg file: https://github.com/DSpace/DSpace/blob/dspace-3.2/dspace/config/modules/oai.cfg It doesn't look to exist by default. Is this some sort of custom code you've added or installed? - Tim On 8/29/2014 10:43 AM, Calloni, Rodrigo wrote: Hello We are using DSpace 3.2 XMLUI. I was looking at the oai.cfg file and I found this parameter on it harvester.handleMetadataField = dc.identifier.uri But I don’t find the documentation about it. Is there anything you could share about this parameter? Thanks in advance Rodrigo *Rodrigo Calloni* System Librarian Felipe Herrera Library Knowledge and Learning Sector Tel: 202-623-2952 Fax: 202-623-3183 Description: http://www.iadb.org/email/idb.gif 1300 New York Avenue, N.W. Washington, D.C. 20577 USA *www.iadb.org http://www.iadb.org/* /Knowledge. Empowering People. Transforming Lives./// *P**Please consider the environment before printing this email* -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] dc.creator
You can use dc.creator, but just note, there are several places where the author might be hardcoded to use dc.contributor.author. So, if someone wanted to make it configurable that DSpace was equally happy storing/using the author as either dc.creator or dc.contributor.author, then I'm sure many people would be happy for that improvement. Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 On Tue, Sep 2, 2014 at 3:00 PM, Germán Biozzoli germanbiozz...@gmail.com wrote: In previous DSpace versions dc.creator was reserved for the system. I assume because of some type of hard coding feature in OAI module. From XOAI on, all of this is outdated, isnt'ít? I don't know if is there some other consideration to take in account before starting to include creator in input-forms. Regards German PD: In metadata registry, creator continues appearing as Do not use; only for harvested metadata.. Time to change it? -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] harvester.handleMetadataField on oai.cfg
dc.identifier typically is the field DSpace automatically stored the URL for the records in. dc.identifier.uri: http://dspacetest.bridgeport.edu/xmlui/handle/123456789/978 -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
[Dspace-tech] Regarding Ranking of Repositories
Dear colleagues, As editor of the Ranking Web of Repositories I published the referred info in order to open debate about issues that are, in my humble opinion, very concerning for the future of repositories. As my email address is clearly stated in the webpage, I do not understand why you decided not consider my position and explanations in this debate. I am going to answer the specific points introduced by Mark Wood and, of course, I am open not only to further discussions but to modify my proposals accordingly. From: Mark H. Wood mw...@iupui.edu Date: 2 September 2014 16:28 Subject: Re: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories To: dspace-tech@lists.sourceforge.net, General List dspace-gene...@lists.sourceforge.net Points 4, 6 and 7 reveal a profound lack of understanding of hypertext and fundamental security issues, and I would not be surprised to learn that they ignore typical user behavior as well. Does anyone but a sysadmin. or developer really type in direct URLs to repository content? Citations please. Point 4. In many academic institutions the access to ports other than standards is forbidden due to security reasons. If you use other ones, the contents are invisible to the people accesing from other universities. Point 6 y 7. Explain me why .../handle/556/78/6789 is better than .../thesis/physics/Wood2013b and why aliasing is not possible. Probably authors will cite the URL of deposited files in their published papers, but with this awful, lengthy, useless addresses they probably prefer not to do. One of the main reasons for depositing papers is to increase their visibility, but this is only possible if other authors can locate easily them. Tipically, for example, in Google. Do you know the advantages of URL semantic content for improving position in Google? There are thousands of papers about academic SEO. For example, there are ones stating the advantages of using library instead of lib in webnames. I would argue that we can better do without appearing in the Ranking Web of Repositories, whatever that is, than to give up the ability to protect our users' credentials. (Point 4, which disallows HTTPS) Are you mixing public and private sections? You can protect your users without destroying visibility. Point 5 is just bizarre. Why does someone think this is a problem? Not that I think it particularly useful to use the name of supporting software in naming a repository service, but how can it possibly hurt? The repository is the probably the most important part of the intellectual treasure of the university and their authors, You are simply proposing to brand the continent instead of the content. Are there any actual statistics to support the belief that long URLs in the interior of a service actually affect anyone's behavior? Interior is irrelevant, the contents of the repository are for the end-users that are not sysadmin but the institution authors and authors and readers from the rest of the world. We are talking of Open Access and in my opinion the referred issues are barriers to the open. It sounds like there should be some discussion among the various parties. Where? As mentioned before here I am for further comments. Thanks for your cooperation. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Isidro F. Aguillo, HonPhD Cybermetrics Lab (3C1). CCHS - CSIC Albasanz, 26-28. 28037 Madrid. Spain isidro.aguillo @ cchs.csic.es www. webometrics.info - Terminar mensaje reenviado - -- Isidro F. Aguillo, HonPhD Cybermetrics Lab (3C1). CCHS - CSIC Albasanz, 26-28. 28037 Madrid. Spain isidro.aguillo @ cchs.csic.es www. webometrics.info -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] [Dspace-general] Regarding Ranking of Repositories
Hi All As meat for further constructive debate, I would like to submit our rationalisations for the selection of our URL. http://wiki.lib.sun.ac.za/index.php/SUNScholar/Guidelines/Step_2 (Step 2 - Marketing Friendly (Vanity URL), Persistent URL and Preservable Digital Objects) Regards Hilton *Hilton Gibson* Ubuntu Linux Systems Administrator JS Gericke Library Room 1025C Stellenbosch University Private Bag X5036 Stellenbosch 7599 South Africa Tel: +27 21 808 4100 | Cell: +27 84 646 4758 On 2 September 2014 21:56, Isidro F. Aguillo isidro.agui...@cchs.csic.es wrote: Dear colleagues, As editor of the Ranking Web of Repositories I published the referred info in order to open debate about issues that are, in my humble opinion, very concerning for the future of repositories. As my email address is clearly stated in the webpage, I do not understand why you decided not consider my position and explanations in this debate. I am going to answer the specific points introduced by Mark Wood and, of course, I am open not only to further discussions but to modify my proposals accordingly. From: Mark H. Wood mw...@iupui.edu Date: 2 September 2014 16:28 Subject: Re: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories To: dspace-tech@lists.sourceforge.net, General List dspace-gene...@lists.sourceforge.net Points 4, 6 and 7 reveal a profound lack of understanding of hypertext and fundamental security issues, and I would not be surprised to learn that they ignore typical user behavior as well. Does anyone but a sysadmin. or developer really type in direct URLs to repository content? Citations please. Point 4. In many academic institutions the access to ports other than standards is forbidden due to security reasons. If you use other ones, the contents are invisible to the people accesing from other universities. Point 6 y 7. Explain me why .../handle/556/78/6789 is better than .../thesis/physics/Wood2013b and why aliasing is not possible. Probably authors will cite the URL of deposited files in their published papers, but with this awful, lengthy, useless addresses they probably prefer not to do. One of the main reasons for depositing papers is to increase their visibility, but this is only possible if other authors can locate easily them. Tipically, for example, in Google. Do you know the advantages of URL semantic content for improving position in Google? There are thousands of papers about academic SEO. For example, there are ones stating the advantages of using library instead of lib in webnames. I would argue that we can better do without appearing in the Ranking Web of Repositories, whatever that is, than to give up the ability to protect our users' credentials. (Point 4, which disallows HTTPS) Are you mixing public and private sections? You can protect your users without destroying visibility. Point 5 is just bizarre. Why does someone think this is a problem? Not that I think it particularly useful to use the name of supporting software in naming a repository service, but how can it possibly hurt? The repository is the probably the most important part of the intellectual treasure of the university and their authors, You are simply proposing to brand the continent instead of the content. Are there any actual statistics to support the belief that long URLs in the interior of a service actually affect anyone's behavior? Interior is irrelevant, the contents of the repository are for the end-users that are not sysadmin but the institution authors and authors and readers from the rest of the world. We are talking of Open Access and in my opinion the referred issues are barriers to the open. It sounds like there should be some discussion among the various parties. Where? As mentioned before here I am for further comments. Thanks for your cooperation. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Isidro F. Aguillo, HonPhD Cybermetrics Lab (3C1). CCHS - CSIC Albasanz, 26-28. 28037 Madrid. Spain isidro.aguillo @ cchs.csic.es www. webometrics.info - Terminar mensaje reenviado - -- Isidro F. Aguillo, HonPhD Cybermetrics Lab (3C1). CCHS - CSIC Albasanz, 26-28. 28037 Madrid. Spain isidro.aguillo @ cchs.csic.es www. webometrics.info
Re: [Dspace-tech] [Dspace-general] Regarding Ranking of Repositories
Hi Isidro and lists, Regarding point 6 -- I see what you're saying, but it shouldn't really be up to the DSpace community repositories (who all use the handle prefix / identifier system, as I'm sure you know!) to argue why 1234/123 is better than thesis/phsyics/something, because we're not the ones proposing that URI segments be part of any metric used to judge the world ranking of a repository. It's also not as simple as you might think, particularly when ensuring unique URIs and persistent URIs, etc. I think you're saying that URIs should either look nice or be meaningful, or both, but I'm not sure we should rely on URIs to be too meaningful, especially when we have ways of including that with semantic markup in references, structured data in our METS/ORE feeds via OAI, etc. Regarding point 5 -- I don't see that this matters either. No end user cares what the IR is actually called, surely? Whatever arguments you can make for our IRs having bad names, punishing us for preserving the permanence of those names and URIs we've already minted seems a bit unfair? The first IR I thought of when reading this was, of course, http://dspace.mit.edu. I think point 5 actually punishes EPrints repositories most unfairly, since eprints is an accepted name for digital manuscripts as well as the platform used -- I think I've even seen IRs called eprints.something.etc running platforms other than EPrints. Numbers 6 and 7, I think I agree with Mark, but don't really have anything to add. I don't really understand why this would even be considered as a metric, let alone grounds for exclusion. What are some examples of cases where long URIs (or, eg. directories as fulltext hosted in IRs with their own dir structures, which happens) or URIs which happen to contain numbers result in end users or machines not being able to properly locate/use hosted resources? Number 8 is probably the thing that will punish my own institution most, which is a pity because we have a large absolute amount of fulltext, but for various reasons, a lot of record only items as well. This is probably a philisophical argument about defining an OA repository I guess? I hope my criticisms here don't seem too harsh - thanks for taking the time to listen to feedback. On a lighter note, I'm sort of pleased these proposals have been doing the rounds, as I think it might just be the thing that convinces my own institution to take world repository ranking off our KPIs, and concentrate more on qualitative value of the repository we host. Cheers Kim (a DSpace dev/admin, and already biased against quantitative metrics in IRs so not exactly an objective commenter ;)) On 3 September 2014 07:56, Isidro F. Aguillo isidro.agui...@cchs.csic.es wrote: Dear colleagues, As editor of the Ranking Web of Repositories I published the referred info in order to open debate about issues that are, in my humble opinion, very concerning for the future of repositories. As my email address is clearly stated in the webpage, I do not understand why you decided not consider my position and explanations in this debate. I am going to answer the specific points introduced by Mark Wood and, of course, I am open not only to further discussions but to modify my proposals accordingly. From: Mark H. Wood mw...@iupui.edu Date: 2 September 2014 16:28 Subject: Re: [Dspace-tech] IMPORTANT NEWS: Important Info for Future Editions | Ranking Web of Repositories To: dspace-tech@lists.sourceforge.net, General List dspace-gene...@lists.sourceforge.net Points 4, 6 and 7 reveal a profound lack of understanding of hypertext and fundamental security issues, and I would not be surprised to learn that they ignore typical user behavior as well. Does anyone but a sysadmin. or developer really type in direct URLs to repository content? Citations please. Point 4. In many academic institutions the access to ports other than standards is forbidden due to security reasons. If you use other ones, the contents are invisible to the people accesing from other universities. Point 6 y 7. Explain me why .../handle/556/78/6789 is better than .../thesis/physics/Wood2013b and why aliasing is not possible. Probably authors will cite the URL of deposited files in their published papers, but with this awful, lengthy, useless addresses they probably prefer not to do. One of the main reasons for depositing papers is to increase their visibility, but this is only possible if other authors can locate easily them. Tipically, for example, in Google. Do you know the advantages of URL semantic content for improving position in Google? There are thousands of papers about academic SEO. For example, there are ones stating the advantages of using library instead of lib in webnames. I would argue that we can better do without appearing in the Ranking Web of Repositories, whatever that is, than to give up the ability to protect our users' credentials. (Point 4,
Re: [Dspace-tech] Hide Recent Submissions 4.1
Hi Gary, Remove org.dspace.app.webui.components.RecentSiteSubmissions from plugin.sequence.org.dspace.plugin.SiteHomeProcessor in [dspace]/config/dspace.cfg for home page. and remove org.dspace.app.webui.components.RecentCommunitySubmissions from plugin.sequence.org.dspace.plugin.CommunityHomeProcessor for community home page. Regards, Keiji Suzuki 2014-09-02 14:47 GMT+09:00 Gary Browne gary.bro...@sydney.edu.au: Hello all, DSpace version: 4.1 UI: JSP Servlet container: Tomcat 7 Server: RHEL 6.5 64-bit Java: OpenJDK 1.7 Is there a configuration option to hide/remove the Recent Submissions sliders in DSpace 4.1 (from the home page and community/collection pages)? Thanks, Gary GARY BROWNE | Development Programmer Library IT Services | Fisher Library F03 THE UNIVERSITY OF SYDNEY T +61 2 9351 5946 | M +61 405 647 868 E gary.bro...@sydney.edu.au | W http://sydney.edu.au Sent from my plain old desktop computer. CRICOS 00026A This email plus any attachments to it are confidential. Any unauthorised use is strictly prohibited. If you receive this email in error, please delete it and any attachments. Please think of our environment and only print this e-mail if necessary. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] [Dspace-general] Regarding Ranking of Repositories
I'm not sure that knee-jerk reaction to an arbitrary list of bad practice is a good place to start and seems like a really bad driver for software development. Maybe we should be talking to our fellow implementers and building on the work of http://www.w3.org/Provider/Style/URI.html, http://www.w3.org/TR/cooluris/, http://www.openarchives.org/OAI/openarchivesprotocol.html, etc. to build a compilation of _best_ practice. Cheers stuart -Original Message- From: Tim Donohue [mailto:tdono...@duraspace.org] Sent: Wednesday, 3 September 2014 8:49 a.m. To: Isidro F. Aguillo; dspace-tech@lists.sourceforge.net Cc: Jonathan Markow; dspace-gene...@lists.sourceforge.net Subject: Re: [Dspace-general] [Dspace-tech] Regarding Ranking of Repositories Hello Isidro, DuraSpace (the stewarding organization behind DSpace and Fedora repository software) was planning to send you a compiled list of the concerns with your proposal. As you can tell from the previous email thread, many of the users of DSpace have similar concerns. Rather than bombard you with all of them individually (which you could see from browsing the thread), we hoped to draft up a response summarizing the concerns of the DSpace community. Below you'll find an initial draft of the summarized concerns. The rule numbering below is based on the numbering at: http://repositories.webometrics.info/en/node/26 --- Concerns with the Proposal from Ranking Web of Repositories * Rule #2 (IRs that don't use the institutional domain will be excluded) would cause the exclusion of some IRs which are hosted by DSpace service providers. As an example, some DSpaceDirect.org users have URLs https://[something].dspacedirect.org which would cause their exclusion as it is a non-institutional domain. Many other DSpace hosting providers have similar non-institutional domain URLs by default. * Rule #4 (Repositories using ports other than 80 or 8080) would wrongly exclude all DSpace sites which use HTTPS (port 443). Many institutions choose to run DSpace via HTTPS instead of HTTP. * Rule #5 (IRs that use the name of the software in the hostname would be excluded) may also affect IRs which are hosted by service providers (like DSpaceDirect). Again, some DSpaceDirect customers have URLs which use *.dspacedirect.org (includes dspace). This rule would also exclude MIT's IR which is the original DSpace (and has used the same URL for the last 10+ years): http://dspace.mit.edu/ * Rule #6 (IRs that use more than 4 directory levels for the URL address of the full texts will be excluded.) may accidentally exclude a large number of DSpace sites. The common download URLs for full text in DSpace are both are at least 4 directory levels deep: - XMLUI: [dspace-url]/bitstream/handle/[prefix]/[id]/[filename] - JSPUI: [dspace-url]/bitstream/[prefix]/[id]/[sequence]/[filename] NOTE: prefix and id are parts of an Item's Handle (http://hdl.handle.net/), which is the persistent identifier assigned to the item via the Handle System. So, this is how a persistent URL like http://hdl.handle.net/1721.1/26706 redirects to an Item in MIT's DSpace. * Rule #7 (IRs that use more than 3 different numeric (or useless) codes in their URLs will be excluded.). It is unclear how they would determine this, and what the effect may be on DSpace sites worldwide. Again, looking at the common DSpace URL paths above, if a file had a numeric name, it may be excluded as DSpace URLs already include 2-3 numeric codes by default ([prefix],[id], and [sequence] are all numeric). * Rule #8 (IRs with more than 50% of the records not linking to OA full text versions..). Again, unclear how they would determine this, and whether the way they are doing so would accidentally exclude some major DSpace sites. For example, there are major DSpace sites which include a larger number of Theses/Dissertations. These Theses/Dissertations may not be 100% Open Access to the world, but may be fully accessible everyone on campus. --- Another, perhaps more serious concern, is on the timeline you propose. You suggest a timeline of January 2015 when these newly proposed rules would be in place. Yet, if these rules were to go in place, some rules may require changes to the DSpace software itself (as I laid out above, some rules may not mesh well with DSpace software as it is, unless I'm misunderstanding the rule itself). Unfortunately, based on our DSpace open source release timelines, we have ONE new release (DSpace 5.0) planned between now and January 2015. Even if we were able to implement some of these recommended changes at a software level, the vast majority (likely 80-90%) of DSpace instances would likely NOT be able to upgrade to the latest DSpace version before your January deadline (as the 5.0 release is scheduled for Nov/Dec). Therefore, as is, your January 2015 ranking may accidentally exclude a large number of DSpace sites from your rankings, and DSpace is still the
