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 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 the debate.
I am going to answer the specific points introduced by Mark Wood and of course open not only to further discussions but to modify my proposals accordingly. > From: Mark H. Wood <[email protected]> > Date: 2 September 2014 16:28 > Subject: Re: [Dspace-tech] IMPORTANT NEWS: Important Info for Future > Editions | Ranking Web of Repositories > To: [email protected], General List < > [email protected]> > > > 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 the contents are invisible to the people accesing from that university. 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 their deposited files in their published papers, but with this awful, lengthy, useless address they probably prefer not to do Depositing papers increase their visibility if other authors can locate easily them 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 > 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 honour 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 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 > [email protected] > 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 ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Dspace-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-general
