Dear Kim, Thanks for your message. I answer to your specific comments
Kim Shepherd <kim.sheph...@gmail.com> escribió: > 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. This is the basic misunderstanding. The repository end user is an author that whishes to increase the global visibility and usage of his/her deposited papers. Looking nice is relevant because the main tool of the author for obtaining visibility and visits is to cite them in his/her future papers or to mention it for example in Wikipedia or Twitter. Looking nice is adding informative value (authors name, publication year, topic) that can be relevant for the reader helping to decide if following the link. Looking nice also works as quality control, a mistake in lastname is easier to notice that in a series of numbers. But far more importat: By far the largest number of visitors came from Google or other engines. If you are not searching for specific title, then the semantic content of the URL is increasing considerably your positioning in Google. Of course, you can ignore that, but there is already many people who prefers to deposit in ResearchGate or Academia as the visibility of their works is better. > > 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. You are answering the question. Imagine that in the future I decide to use eprints instead of dspace or whatever other better that can be developed in the future. Then, are going to change the domain or not?. On the other side, why branding an intellectual result with the name of the tool?. I write my papers with MS Word and never made any significant mention of this fact in any of the papers. What is the problem with? http://repository.university.edu/ > > 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? Metrics? Who is talking about metrics? I only said Keep It Simple. > 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? We can discuss about the threshold, I think 50% is reasonably but it could be used only for contents after embargo ends (usually 6 or 12 months). > 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. Thanks for your cooperation ... > Cheers > > Kim (a DSpace dev/admin, and already biased against quantitative metrics in > IRs so not exactly an objective commenter ;)) You are a perfect objective commenter as you identify as dev/admin but the repository was not intended to serve you. The 'customers' are your authors and your institution and THEY are strongly biased to support metrics. Simply, ask them. > > 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, 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-general mailing list >> dspace-gene...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dspace-general >> -- 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
