Dear Anton, Thanks for your different point of view. It is good to opening the debate to further issues.
Anton Angelo <[email protected]> escribió: > Hi Isidro, > > As a librarian/technologist managing a institutional repository I have to > disagree with you on the definition of our end users. There are two ways > to look at this, and neither end up with the authors as end users. > > An idealistic approach would see the final readers of the items as the end > users. They are the ones, defined by various OA declarations, the ones for > whom we are doing this. Idealistic? It is the current situation. I search for a topic related to my research in Google and I obtain a few hundred results. I focus on the ones coming from the repositories because in most cases that means the full text is openly available. What are the problems? a) Sometimes the repositories results does not appear first, but those from Researchgate or Academia.edu. A few researchers already realizes that and now prefer those portals instead their own institutions for depositing. b) Checking the results some of them are deposited in webserves with suspicious names. I can not recognize trusted reliable university names when that info is not in the URL. c) The paper is in the correct webdomain but from the url I have no hints about if it is a unpublished thesis, a paper in a major journal, authored by a well known colleague or even how recent is it > A pragmatic approach would say the funders of the research are the end > users, as they are demanding the output of their funding to be made OA. For that users it is completely unneeded the huge effort for bulding an open public repository. An annual report of research results is more than enough. > The latter group are the ones your service is most useful for, in > determining the performance of their outputs - the more visible, the better > vehicle for publication. Well, I accept 100 funders. According to the statistics of visits of major repositories we are talking of millions of unique visitor each year. I think there is some misunderstanding about who is really using your (any) repository. > I am beginning to think that rankings are not a very useful manner in which > to compare IRs, but a list of platform agnostic best practice standards > (like the orange book for security, back in the day) is the way forward. Current situation is that most of the world scientific production is not deposited in open access repositories. ANY licit strategy to change that should be welcomed. The ranking is helping, at least pushing managers to convince authors to increase the number of papers deposited. > Though I have extensively used the service in my research on IR > effectiveness, that was mostly because the repository I manage has a high > ranking, and it was useful to promote it internally. Thanks, this is an intended welcomed use of our work This kind of > behaviour usually ends up in 'gaming', and is counterproductive - exactly > what OA is trying to get away from (h-index, impact factor, etc). I know you and the rest of the members of this list are professionals, not gamers. > > IRs are really about getting the right output to the right person - even > one download can be a total success. I think in the future altmetric tools > are probably going to be more use than a ranking service, as useful as it > has been in the past - provided they report on the work in OA being done in > the global south. Do you know that our ranking is including for at least the two last editions altmetrics indicators? Ten of them: Academia, Facebook, LinkedIn, Mendeley, ResearchGate, Slideshare, Twitter, Wikipedia (2) & YouTube. > aa > > > > > > > On 4 September 2014 09:12, Isidro F. Aguillo <[email protected]> > wrote: > >> Dear Stuart, >> >> I do not know if you understand the ultimate purpose of Open access >> initiatives in general and the institutional repositories in >> particular. But I think you are mising the central point that the >> end-users should guide the design of the repository according to their >> real needs. >> >> Well, in OA the end users are the authors of the papers, their >> institutions that fund the research and host the papers and the >> librarians who manage the repository. In this scenario the software >> developers task is to fulfill in the most professional way the needs >> of the authors. >> >> Regarding authors needs, the W3C organization and its 'cool' proposals >> is arbitrary basically because they do not know how scholarly >> communication works, and the aims and methods of OA. They are not >> stakeholders for us. >> >> In any case, I will prefer and thank from you comments on the specific >> proposals and not a general, ambigous and unsupported global criticism. >> >> Best regards, >> >> >> Stuart Yeates <[email protected]> escribió: >> >> > 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:[email protected]] >> > Sent: Wednesday, 3 September 2014 8:49 a.m. >> > To: Isidro F. Aguillo; [email protected] >> > Cc: Jonathan Markow; [email protected] >> > 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 most widely used Institutional Repository software in the >> > world. >> > >> > So, in general, I think our response is that these proposed >> > rules/guidelines are a bit concerning to many users of DSpace (as >> > you can see from this long thread of concerns from various people >> > and institutions). We worry that a larger number of DSpace instances >> > would be accidentally excluded from the rankings, which makes the >> > final ranking less useful to users of DSpace overall. >> > >> > I know DuraSpace would be open to discussing this with you and your >> > colleagues. Perhaps there's a middle ground here, or a way to slowly >> > "roll out" some of your recommended changes. This could allow DSpace >> > developers more time to enhance DSpace software itself, and allow >> > users of DSpace more time to upgrade to ensure they are included in >> > the Rankings. (Note: we've similarly had discussions with the Google >> > Scholar team to help gradually add improvements to DSpace to better >> > meet their indexing needs...so it seems like the same could occur >> > with the Webometrics team.) >> > >> > I've copied our DuraSpace Chief Strategy Officer, Jonathan Markow, >> > on this message as well. >> > >> > Tim Donohue >> > Technical Lead for DSpace & DSpaceDirect DuraSpace.org | DSpace.org >> > | DSpaceDirect.org >> > >> > >> ------------------------------------------------------------------------------ >> > 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 >> > >> > >> ------------------------------------------------------------------------------ >> > 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 >> >> >> -- >> 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 >> > > > > -- > *Anton Angelo, "A brainstorm in a teacup"* -* www.mojo.org - +64 27 509 7905 > * -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
