Yes, now we have to have a fundamental discussion on ³dark copy². Does this mean that anything that is considered ³dark copy² is hidden from open discovery to patrons?
In our case, no‹we want patrons to see what is available, and know that it needs special access. I find this is going to pose GRAVE issues for us to continue using the software since it is expected that dark copy means you cannot view it, but you can find it. What affect does this have on the harvesters? If this keeps the harvesters out of our system, I¹m really concerned since OCLC regularly harvests the data for OCLC (which we want). I cannot strongly‹I mean strongly recommend that this become something configurable ASAP. Until then, we will not be moving to 4.0 at any time soon. ‹Jeff Jeffrey Trimble Associate Director & Head of Information Services William F. Maag Library Youngstown State University 330.941.2483 (Office) [email protected] http://www.maag.ysu.edu http://digital.maag.ysu.edu "For he is the Kwisatz Haderach..." On 1/21/14, 11:38 AM, "Tim Donohue" <[email protected]> wrote: >Hi Jeff, > >This sounds like Discovery's normal actions (since DSpace 3.0). >Discovery only shows content that you have access to. So, accessing the >site as an anonymous user may show less content than if you access the >site as a logged in user or Admin user. In other words, you only can see >content that you actually have access to. "Dark" collections or Items >will not appear to anonymous users. > >This is part of the "Access rights based results" feature that came in >DSpace 3, briefly mentioned here: >https://wiki.duraspace.org/display/DSDOC4x/Discovery#Discovery-DSpace3.0 > >As of DSpace 4, of course, Discovery (Solr) is the default search & >browse system, which means that these Discovery features are now the >default. > >It's possible some of these features do need to be made more prominent >in the documentation, however. As they are now the default settings for >DSpace 4 and above. > >- Tim > >On 1/21/2014 10:29 AM, Jeffrey A Trimble wrote: >> Thanks all. >> >> Found the issue at hand, and I think it might be a potential bug. So, >> I¹m going to give you the scoop on what I found. It may be the solr is >> too restrictive‹literally. >> >> 1.Created a collection that is a ³dark copy². It appears in the list of >> collections. >> 2.No index entries generated unless you are signed in. (Previous >> experience and versions did not do this). >> >> 3. Created a collection that is a public copy. It appears in the list >> of collection. >> 4.Index entries generated. >> >> I used the same file, and loaded into two different collections. >> >> So, is this a new undocumented feature or a bug in the solr >>implementation? >> >> Thanks, >> >> ‹Jeff >> >> >> >> Jeffrey Trimble >> Associate Director & >> Head of Information Services >> William F. Maag Library >> Youngstown State University >> 330.941.2483 (Office) >> [email protected] >> http://www.maag.ysu.edu >> http://digital.maag.ysu.edu >> "For he is the Kwisatz Haderach..." >> >> >> From: Andrea Bollini <[email protected] <mailto:[email protected]>> >> Date: Monday, January 20, 2014 at 5:20 PM >> To: Jeffrey Trimble <[email protected] <mailto:[email protected]>>, >> "[email protected] >> <mailto:[email protected]>" >> <[email protected] >> <mailto:[email protected]>> >> Subject: R: [Dspace-tech] Tomcat 7.0.50 and Dspace 4.0 Implementation >> >> The solr webapp is not working. >> Check the solr logs or try to access, from the server or using a ssh >> tunnel, the url >> http://rspace.cc.ysu.edu:8080/solr/ >> <http://rspace.cc.ysu.edu:8080/solr/search> >> You should get more informations about the issue. >> Andrea >> >> Inviato da Samsung Mobile >> >> >> -------- Messaggio originale -------- >> Da: Jeffrey A Trimble >> Data:20/01/2014 22:30 (GMT+01:00) >> A: [email protected] >> <mailto:[email protected]> >> Oggetto: [Dspace-tech] Tomcat 7.0.50 and Dspace 4.0 Implementation >> >> I just finished up a clean install of DSpace 4.0 on a server. I¹m able >> to run the application, but if you choose any collection, the browser >> just sits there. >> But I¹m seeing other errors too. So, here are the two problems I am >>seeing: >> >> Most important, these were all batch loaded as the first bitstreams into >> this server. Is that an undocumented feature? After editing one of >> them and updating it there now appears to be one index entries. But I >> ³saw² before: >> >> 1. No index entries. I can retrieve by the URI or database # only. >> 2. Numerous solr errors in the logs: >> >> 2014-01-20 15:03:32,251 ERROR org.dspace.discovery.SolrServiceImpl @ >> Server at http://rspace.cc.ysu.edu:8080/solr/search returned non ok >> status:500, message:Internal Server Error >> org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: >> Server at http://rspace.cc.ysu.edu:8080/solr/search returned non ok >> status:500, message:Internal Server Error >> at >> >>org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.j >>ava:385) >> at >> >>org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.j >>ava:180) >> at >> >>org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(Abstra >>ctUpdateRequest.java:117) >> at >> >>org.apache.solr.client.solrj.SolrServer.deleteByQuery(SolrServer.java:285 >>) >> at >> >>org.apache.solr.client.solrj.SolrServer.deleteByQuery(SolrServer.java:271 >>) >> at >> >>org.dspace.discovery.SolrServiceImpl.unIndexContent(SolrServiceImpl.java: >>316) >> at >> >>org.dspace.discovery.SolrServiceImpl.unIndexContent(SolrServiceImpl.java: >>301) >> at >> >>org.dspace.discovery.SolrServiceImpl.indexContent(SolrServiceImpl.java:21 >>8) >> at >> org.dspace.discovery.IndexEventConsumer.end(IndexEventConsumer.java:170) >> at >> org.dspace.event.BasicDispatcher.dispatch(BasicDispatcher.java:147) >> at org.dspace.core.Context.commit(Context.java:373) >> at >> org.dspace.app.itemimport.ItemImport.addItem(ItemImport.java:987) >> at >> org.dspace.app.itemimport.ItemImport.addItems(ItemImport.java:780) >> at >>org.dspace.app.itemimport.ItemImport.main(ItemImport.java:567) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> >>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java >>:57) >> at >> >>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI >>mpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:606) >> >> Any answers? Is batch loading somehow circumventing the solr indexing? >> >> TIA, >> >> JAT >> >> >> Jeffrey Trimble >> Associate Director & >> Head of Information Services >> William F. Maag Library >> Youngstown State University >> 330.941.2483 (Office) >> [email protected] <mailto:[email protected]> >> http://www.maag.ysu.edu >> http://digital.maag.ysu.edu >> "For he is the Kwisatz Haderach..." >> >> >> >> >>------------------------------------------------------------------------- >>----- >> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >> Learn Why More Businesses Are Choosing CenturyLink Cloud For >> Critical Workloads, Development Environments & Everything In Between. >> Get a Quote or Start a Free Trial Today. >> >>http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clk >>trk >> >> >> >> _______________________________________________ >> 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 >> > ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ 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
