subject:"\[dspace\-tech\] Need to delete records on OAI"

Re: [dspace-tech] Need to delete records on OAI

2018-10-14 Thread admin

Did you try running [dspace]/bin/dspace oai import -c ?
I had many old records, with old handle, and this command helped to clear 
them.
See: https://wiki.duraspace.org/display/DSDOC6x/OAI+2.0+Server

Peter

W dniu piątek, 13 kwietnia 2018 19:51:41 UTC+1 użytkownik Aprendiz 2018 
napisał:
>
> Hello Andrea, I have a problem with the DSPACE and the OAI-PHM, similar to 
> the one of Demmis, it is not possible to update the records in the OAI 
> ../oai/request?verb=ListSets, It shows me the old configuration and old 
> records (33) Now they are 97. As I show you the output of the command:
> # curl 'http://localhost:8080/solr/oai/select?q=*:*=true=0'
> 
> 
>
> 
>   0
>   0
>   
> *:*
> true
> 0
>   
> 
> 
> 
> 
>
>
> A help please,
> Thanks
>
> El lunes, 8 de febrero de 2016, 23:15:17 (UTC-5), Andrea Schweer escribió:
>>
>> Hi,
>>
>> I'm really not sure what's going on. Your log shows DSpace posting 
>> information to Solr, which is what I'd expect. Have you checked the 
>> permissions of the Solr directory tree? It needs to be owned by the same 
>> user that Tomcat runs under ([dspace]/solr/oai and subdirectories).
>>
>> As a last resort, you could manually delete everything from that solr 
>> index, then run another import. It shouldn't really do anything different 
>> compared to clean-cache, but you never know. 
>>
>> If you run eg
>> curl 'http://localhost:8080/solr/oai/select?q=*:*=true=0'
>> then you'll see how many items the OAI solr core currently knows about -- 
>> look for numFound. numFound should be equal to the number of items (this 
>> might include non-public items and deleted items) after running import.
>>
>> You can run
>> curl --globoff http://localhost:8080/solr/oai/update -H "Content-Type: 
>> text/xml" --data-binary '*:*'
>> followed by
>> curl --globoff 'http://localhost:8080/solr/oai/update?commit=true'
>> to force-delete everything in that solr index (you might want to try this 
>> on a test server first).
>>
>> numFound in the first query above should then be 0. Run clean-cache and 
>> access your web interface *without* running the import command -- it too 
>> should tell you that there are 0 identifiers. If it still claims that there 
>> are items, you may have a web cache layer in front of your repository or 
>> something? If you do get 0 identifiers via the web interface after the 
>> delete, run the import command and check again. Hopefully you'll then see 
>> exactly those items you're expecting to see.
>>
>> Just a very final comment -- what are you looking at in the OAI 
>> interface? I just followed the links in your initial e-mail again and the 
>> OAI interface now shows 30 records/identifiers, the same number of items as 
>> shown in JSPUI. So perhaps your earlier steps actually did work and you're 
>> just looking at an out-of-date web page for some reason?
>>
>> cheers,
>> Andrea
>>
>> On 09/02/16 16:48, Demis Estabridis wrote:
>>
>> Hi Andrea, 
>>
>> Thanks again for your answer.
>> I can confirm that we're using SOLR as database source for OAI.
>>
>> We run again the suggested commands and we had no errors on the logs but 
>> no new result. Nothing changed. 
>>
>> /opt/dspace/bin/dspace oai clean-cache
>> /opt/dspace/bin/dspace oai import –c
>>
>> Please, find here the logs with debug mode on.
>> We did it with the tomcat user:
>>
>> 2016-02-08 22:24:29,115 INFO  org.dspace.core.ConfigurationManager @ 
>> Loading from classloader: file:/opt/dspace/config/dspace.cfg
>> 2016-02-08 22:24:29,148 INFO  org.dspace.core.ConfigurationManager @ 
>> Using dspace provided log configuration (log.init.config)
>> 2016-02-08 22:24:29,148 INFO  org.dspace.core.ConfigurationManager @ 
>> Loading: /opt/dspace/config/log4j.properties
>> 2016-02-08 22:24:33,149 DEBUG net.sf.ehcache.config.ConfigurationFactory 
>> @ Configuring ehcache from InputStream
>> 2016-02-08 22:24:33,271 DEBUG net.sf.ehcache.config.BeanHandler @ 
>> Ignoring ehcache attribute xmlns:xsi
>> 2016-02-08 22:24:33,271 DEBUG net.sf.ehcache.config.BeanHandler @ 
>> Ignoring ehcache attribute xsi:noNamespaceSchemaLocation
>> 2016-02-08 22:24:33,280 DEBUG 
>> net.sf.ehcache.config.DiskStoreConfiguration @ Disk Store Path: /tmp
>> 2016-02-08 22:24:33,306 DEBUG net.sf.ehcache.config.ConfigurationHelper @ 
>> No CacheManagerEventListenerFactory class specified. Skipping...
>> 2016-02-08 22:24:33,346 DEBUG net.sf.ehcache.config.ConfigurationHelper @ 
>> No BootstrapCacheLoaderFactory class specified. Skipping...
>> 2016-02-08 22:24:33,346 DEBUG net.sf.ehcache.config.ConfigurationHelper @ 
>> No CacheExceptionHandlerFactory class specified. Skipping...
>> 2016-02-08 22:24:35,926 INFO  org.dspace.storage.rdbms.DatabaseManager @ 
>> DBMS is 'PostgreSQL'
>> 2016-02-08 22:24:35,926 INFO  org.dspace.storage.rdbms.DatabaseManager @ 
>> DBMS driver version is '9.4.5'
>> 2016-02-08 22:24:35,966 INFO  org.dspace.storage.rdbms.DatabaseUtils @ 
>> Loading Flyway DB migrations from: filesystem:/opt/dspace/etc/postgres, 
>>

Re: [dspace-tech] Need to delete records on OAI

2018-04-13 Thread Aprendiz 2018

Hello Andrea, I have a problem with the DSPACE and the OAI-PHM, similar to 
the one of Demmis, it is not possible to update the records in the OAI 
../oai/request?verb=ListSets, It shows me the old configuration and old 
records (33) Now they are 97. As I show you the output of the command:
# curl 'http://localhost:8080/solr/oai/select?q=*:*=true=0'




  0
  0
  
*:*
true
0
  






A help please,
Thanks

El lunes, 8 de febrero de 2016, 23:15:17 (UTC-5), Andrea Schweer escribió:
>
> Hi,
>
> I'm really not sure what's going on. Your log shows DSpace posting 
> information to Solr, which is what I'd expect. Have you checked the 
> permissions of the Solr directory tree? It needs to be owned by the same 
> user that Tomcat runs under ([dspace]/solr/oai and subdirectories).
>
> As a last resort, you could manually delete everything from that solr 
> index, then run another import. It shouldn't really do anything different 
> compared to clean-cache, but you never know. 
>
> If you run eg
> curl 'http://localhost:8080/solr/oai/select?q=*:*=true=0'
> then you'll see how many items the OAI solr core currently knows about -- 
> look for numFound. numFound should be equal to the number of items (this 
> might include non-public items and deleted items) after running import.
>
> You can run
> curl --globoff http://localhost:8080/solr/oai/update -H "Content-Type: 
> text/xml" --data-binary '*:*'
> followed by
> curl --globoff 'http://localhost:8080/solr/oai/update?commit=true'
> to force-delete everything in that solr index (you might want to try this 
> on a test server first).
>
> numFound in the first query above should then be 0. Run clean-cache and 
> access your web interface *without* running the import command -- it too 
> should tell you that there are 0 identifiers. If it still claims that there 
> are items, you may have a web cache layer in front of your repository or 
> something? If you do get 0 identifiers via the web interface after the 
> delete, run the import command and check again. Hopefully you'll then see 
> exactly those items you're expecting to see.
>
> Just a very final comment -- what are you looking at in the OAI interface? 
> I just followed the links in your initial e-mail again and the OAI 
> interface now shows 30 records/identifiers, the same number of items as 
> shown in JSPUI. So perhaps your earlier steps actually did work and you're 
> just looking at an out-of-date web page for some reason?
>
> cheers,
> Andrea
>
> On 09/02/16 16:48, Demis Estabridis wrote:
>
> Hi Andrea, 
>
> Thanks again for your answer.
> I can confirm that we're using SOLR as database source for OAI.
>
> We run again the suggested commands and we had no errors on the logs but 
> no new result. Nothing changed. 
>
> /opt/dspace/bin/dspace oai clean-cache
> /opt/dspace/bin/dspace oai import –c
>
> Please, find here the logs with debug mode on.
> We did it with the tomcat user:
>
> 2016-02-08 22:24:29,115 INFO  org.dspace.core.ConfigurationManager @ 
> Loading from classloader: file:/opt/dspace/config/dspace.cfg
> 2016-02-08 22:24:29,148 INFO  org.dspace.core.ConfigurationManager @ Using 
> dspace provided log configuration (log.init.config)
> 2016-02-08 22:24:29,148 INFO  org.dspace.core.ConfigurationManager @ 
> Loading: /opt/dspace/config/log4j.properties
> 2016-02-08 22:24:33,149 DEBUG net.sf.ehcache.config.ConfigurationFactory @ 
> Configuring ehcache from InputStream
> 2016-02-08 22:24:33,271 DEBUG net.sf.ehcache.config.BeanHandler @ Ignoring 
> ehcache attribute xmlns:xsi
> 2016-02-08 22:24:33,271 DEBUG net.sf.ehcache.config.BeanHandler @ Ignoring 
> ehcache attribute xsi:noNamespaceSchemaLocation
> 2016-02-08 22:24:33,280 DEBUG net.sf.ehcache.config.DiskStoreConfiguration 
> @ Disk Store Path: /tmp
> 2016-02-08 22:24:33,306 DEBUG net.sf.ehcache.config.ConfigurationHelper @ 
> No CacheManagerEventListenerFactory class specified. Skipping...
> 2016-02-08 22:24:33,346 DEBUG net.sf.ehcache.config.ConfigurationHelper @ 
> No BootstrapCacheLoaderFactory class specified. Skipping...
> 2016-02-08 22:24:33,346 DEBUG net.sf.ehcache.config.ConfigurationHelper @ 
> No CacheExceptionHandlerFactory class specified. Skipping...
> 2016-02-08 22:24:35,926 INFO  org.dspace.storage.rdbms.DatabaseManager @ 
> DBMS is 'PostgreSQL'
> 2016-02-08 22:24:35,926 INFO  org.dspace.storage.rdbms.DatabaseManager @ 
> DBMS driver version is '9.4.5'
> 2016-02-08 22:24:35,966 INFO  org.dspace.storage.rdbms.DatabaseUtils @ 
> Loading Flyway DB migrations from: filesystem:/opt/dspace/etc/postgres, 
> classpath:org.dspace.storage.rdbms.sqlmigration.postgres, 
> classpath:org.dspace.storage.rdbms.migration
> 2016-02-08 22:24:35,999 INFO 
>  org.flywaydb.core.internal.dbsupport.DbSupportFactory @ Database: 
> jdbc:postgresql://localhost:5432/dspace (PostgreSQL 9.4)
> 2016-02-08 22:24:36,005 DEBUG org.flywaydb.core.Flyway @ DDL Transactions 
> Supported: true
> 2016-02-08 22:24:36,018 DEBUG org.flywaydb.core.Flyway @ Schema:

Re: [dspace-tech] Need to delete records on OAI

2016-02-08 Thread Andrea Schweer


  
  
Hi,

On 09/02/16 15:45, Demis Estabridis
  wrote:


  Hi Andrea,


Thanks for your quick response.
In fact, we have tried doing this:



  
[8/2/16
21:43] Erick Benites (ebeni...@tecsup.edu.pe):sudo rm –R -f
/opt/dspace/var/oai/requests/*
sudo /opt/dspace/bin/dspace oai clean-cache
sudo /opt/dspace/bin/dspace oai import –c
  

  


That looks good in general, but a few comments:

  You don't need to delete the directory yourself, the
clean-cache command should sort this out for you
  Don't run any dspace command using sudo (=root). You must
run these commands as the same user that Tomcat runs under,
which will most likely be "tomcat" or "dspace" depending on your
set-up. If you run these commands as root, chances are that the
permissions of any directories/files created by the command will
be wrong and will cause future operations to fail.
  I personally run import before clean-cache, just on the
off-chance that someone accesses an OAI page (and thus causes
the cached response to be re-generated) in between. This is
probably no longer necessary since import now also runs
clean-cache (I believe), but I'm not sure exactly when this
changed.
  




  

  
But we don't see any change on
 /oai/request records. Our Jspui shows 30 docs, and we
have 59 on the OAI interface.
  

  


That's odd. Just in case, check the DSpace log file for any error
messages around when you're running clean-cache / import.

Could you verify that you're indeed using the solr data source for
OAI? In [dspace]/config/modules/xoai.cfg file, the "storage" parameter
configures which data source is used (database vs solr). solr is now
the default. If yours is set to "database", you'll need to run
slightly different commands as given in this section here:
https://wiki.duraspace.org/display/DSDOC5x/OAI+2.0+Server#OAI2.0Server-OAIManager%28DatabaseDataSource%29


  Syntax
  [dspace]/bin/dspace oai  [parameters]
  Actions
  
clean-cache  Cleans the OAI cache
compile-items  Compiles DSpace items
erase-compiled-items  Erases all DSpace compiled items
  


cheers,
Andrea

-- 
Dr Andrea Schweer
Lead Software Developer, ITS Information Systems
The University of Waikato, Hamilton, New Zealand
+64-7-837 9120
  




-- 
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] Need to delete records on OAI

2016-02-08 Thread Demis Estabridis

Hi Andrea,

Thanks again for your answer.
I can confirm that we're using SOLR as database source for OAI.

We run again the suggested commands and we had no errors on the logs but no
new result. Nothing changed.

/opt/dspace/bin/dspace oai clean-cache
/opt/dspace/bin/dspace oai import –c

Please, find here the logs with debug mode on.
We did it with the tomcat user:

2016-02-08 22:24:29,115 INFO  org.dspace.core.ConfigurationManager @
Loading from classloader: file:/opt/dspace/config/dspace.cfg
2016-02-08 22:24:29,148 INFO  org.dspace.core.ConfigurationManager @ Using
dspace provided log configuration (log.init.config)
2016-02-08 22:24:29,148 INFO  org.dspace.core.ConfigurationManager @
Loading: /opt/dspace/config/log4j.properties
2016-02-08 22:24:33,149 DEBUG net.sf.ehcache.config.ConfigurationFactory @
Configuring ehcache from InputStream
2016-02-08 22:24:33,271 DEBUG net.sf.ehcache.config.BeanHandler @ Ignoring
ehcache attribute xmlns:xsi
2016-02-08 22:24:33,271 DEBUG net.sf.ehcache.config.BeanHandler @ Ignoring
ehcache attribute xsi:noNamespaceSchemaLocation
2016-02-08 22:24:33,280 DEBUG net.sf.ehcache.config.DiskStoreConfiguration
@ Disk Store Path: /tmp
2016-02-08 22:24:33,306 DEBUG net.sf.ehcache.config.ConfigurationHelper @
No CacheManagerEventListenerFactory class specified. Skipping...
2016-02-08 22:24:33,346 DEBUG net.sf.ehcache.config.ConfigurationHelper @
No BootstrapCacheLoaderFactory class specified. Skipping...
2016-02-08 22:24:33,346 DEBUG net.sf.ehcache.config.ConfigurationHelper @
No CacheExceptionHandlerFactory class specified. Skipping...
2016-02-08 22:24:35,926 INFO  org.dspace.storage.rdbms.DatabaseManager @
DBMS is 'PostgreSQL'
2016-02-08 22:24:35,926 INFO  org.dspace.storage.rdbms.DatabaseManager @
DBMS driver version is '9.4.5'
2016-02-08 22:24:35,966 INFO  org.dspace.storage.rdbms.DatabaseUtils @
Loading Flyway DB migrations from: filesystem:/opt/dspace/etc/postgres,
classpath:org.dspace.storage.rdbms.sqlmigration.postgres,
classpath:org.dspace.storage.rdbms.migration
2016-02-08 22:24:35,999 INFO
 org.flywaydb.core.internal.dbsupport.DbSupportFactory @ Database:
jdbc:postgresql://localhost:5432/dspace (PostgreSQL 9.4)
2016-02-08 22:24:36,005 DEBUG org.flywaydb.core.Flyway @ DDL Transactions
Supported: true
2016-02-08 22:24:36,018 DEBUG org.flywaydb.core.Flyway @ Schema: public

Any ideas what could be wrong here?
Is there any way to change this manually? It's very urgent to get this
fixed for us.



*Demis Estabridis*Director de TI
*UTEC*

*Universidad de Ingeniería & Tecnología*
* › *T: (511) 230 5000
 *› *Jr. Medrano Silva 165, Barranco
 › *www.utec.edu.pe* 


2016-02-08 22:02 GMT-05:00 Andrea Schweer :

> Hi,
>
> On 09/02/16 15:45, Demis Estabridis wrote:
>
> Hi Andrea,
>
> Thanks for your quick response.
> In fact, we have tried doing this:
>
> [8/2/16 21:43] Erick Benites (ebeni...@tecsup.edu.pe):sudo rm –R -f
> /opt/dspace/var/oai/requests/*
> sudo /opt/dspace/bin/dspace oai clean-cache
> sudo /opt/dspace/bin/dspace oai import –c
>
>
> That looks good in general, but a few comments:
>
>- You don't need to delete the directory yourself, the clean-cache
>command should sort this out for you
>- Don't run any dspace command using sudo (=root). You *must* run
>these commands as the same user that Tomcat runs under, which will most
>likely be "tomcat" or "dspace" depending on your set-up. If you run these
>commands as root, chances are that the permissions of any directories/files
>created by the command will be wrong and will cause future operations to
>fail.
>- I personally run import before clean-cache, just on the off-chance
>that someone accesses an OAI page (and thus causes the cached response to
>be re-generated) in between. This is probably no longer necessary since
>import now also runs clean-cache (I believe), but I'm not sure exactly when
>this changed.
>
>
> But we don't see any change on  /oai/request records. Our Jspui shows 30
> docs, and we have 59 on the OAI interface.
>
>
> That's odd. Just in case, check the DSpace log file for any error messages
> around when you're running clean-cache / import.
>
> Could you verify that you're indeed using the solr data source for OAI? In
> [dspace]/config/modules/xoai.cfg file, the "storage" parameter configures
> which data source is used (database vs solr). solr is now the default. If
> yours is set to "database", you'll need to run slightly different commands
> as given in this section here:
> https://wiki.duraspace.org/display/DSDOC5x/OAI+2.0+Server#OAI2.0Server-OAIManager%28DatabaseDataSource%29
>
> *Syntax*
>
> [dspace]/bin/dspace oai  [parameters]
>
> *Actions*
>
>- clean-cache  *Cleans the OAI cache*
>- compile-items  *Compiles DSpace items*
>- erase-compiled-items  *Erases all DSpace compiled items*
>
>
> cheers,
> Andrea
>
> --
> Dr Andrea Schweer
> Lead Software Developer, ITS Information Systems
> The

Re: [dspace-tech] Need to delete records on OAI

2016-02-08 Thread Demis Estabridis

Hi Andrea,

Thanks for your quick response.
In fact, we have tried doing this:

[8/2/16 21:43] Erick Benites (ebeni...@tecsup.edu.pe):sudo rm –R -f
/opt/dspace/var/oai/requests/*
sudo /opt/dspace/bin/dspace oai clean-cache
sudo /opt/dspace/bin/dspace oai import –c
But we don't see any change on  /oai/request records. Our Jspui shows 30
docs, and we have 59 on the OAI interface.

We're able to see new records (the two last you can see are tests) but we
still see all the old ones.

Thanks for your help.





*Demis Estabridis*Director de TI
*UTEC*

*Universidad de Ingeniería & Tecnología*
* › *T: (511) 230 5000
 *› *Jr. Medrano Silva 165, Barranco
 › *www.utec.edu.pe* 


2016-02-08 21:32 GMT-05:00 Andrea Schweer :

> Hi,
>
> looks like you're running DSpace 5.2. Documentation for maintaining the
> OAI index is here:
> https://wiki.duraspace.org/display/DSDOC5x/OAI+2.0+Server
>
> You're probably using the Solr data source (the default), unless you've
> set things up to use the database instead.
>
> See the 2.1.1 "OAI Manager" section for commands to interact with the OAI
> solr index. You most likely will just need to run the "import" command to
> make sure the right items are exposed; you may need to run the clean-cache
> command afterwards.
>
> You should also set up a scheduled task for the import command to run eg
> daily, see 2.1.2 "Scheduled tasks" on that page.
>
> As to whether this is what's called "harvesting", it depends :) Your OAI
> interface exposes items for harvesting by others. DSpace also includes
> separate functionality that goes in the other direction and lets you
> harvest items that other places expose via OAI.
>
> cheers,
> Andrea
>
> On 09/02/16 14:34, Demis Estabridis wrote:
>
> Hello,
>
> Greetings from UTEC at Lima, Peru. We're new to DSpace and have a problem:
>
> Our Jspui  interface looks good, but
> when we compare it with the OAI interface
> ,
> we see that there are still testing and old records.
> How can we get those out from that OAI interface? That is what you call
> "harvesting" right?
>
> Thanks
>
> La información contenida en este e-mail y sus anexos es confidencial,
> privilegiada y está dirigida exclusivamente a su destinatario, en
> consecuencia, solo puede ser utilizada por aquel. Si usted no es el
> destinatario original, no deberá examinar, usar, copiar o distribuir este
> mensaje o la información que contiene. Si lo recibe por error, por favor
> reenvíelo a la persona que se lo envió y elimínelo. Cualquier retención o
> uso total o parcial no autorizada de este mensaje está estrictamente
> prohibida y sancionada por ley. --
> You received this message because you are subscribed to the Google Groups
> "DSpace Technical Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dspace-tech+unsubscr...@googlegroups.com.
> To post to this group, send email to dspace-tech@googlegroups.com.
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Dr Andrea Schweer
> Lead Software Developer, ITS Information Systems
> The University of Waikato, Hamilton, New Zealand
> +64-7-837 9120
>
>

-- 
La información contenida en este e-mail y sus anexos es confidencial, 
privilegiada y está dirigida exclusivamente a su destinatario, en 
consecuencia, solo puede ser utilizada por aquel. Si usted no es el 
destinatario original, no deberá examinar, usar, copiar o distribuir este 
mensaje o la información que contiene. Si lo recibe por error, por favor 
reenvíelo a la persona que se lo envió y elimínelo. Cualquier retención o 
uso total o parcial no autorizada de este mensaje está estrictamente 
prohibida y sancionada por ley.

-- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Need to delete records on OAI

2016-02-08 Thread Demis Estabridis

Hello,

Greetings from UTEC at Lima, Peru. We're new to DSpace and have a problem:

Our Jspui  interface looks good, but when 
we compare it with the OAI interface 
,
 
we see that there are still testing and old records.
How can we get those out from that OAI interface? That is what you call 
"harvesting" right?

Thanks

-- 
La información contenida en este e-mail y sus anexos es confidencial, 
privilegiada y está dirigida exclusivamente a su destinatario, en 
consecuencia, solo puede ser utilizada por aquel. Si usted no es el 
destinatario original, no deberá examinar, usar, copiar o distribuir este 
mensaje o la información que contiene. Si lo recibe por error, por favor 
reenvíelo a la persona que se lo envió y elimínelo. Cualquier retención o 
uso total o parcial no autorizada de este mensaje está estrictamente 
prohibida y sancionada por ley.

-- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] Need to delete records on OAI

Re: [dspace-tech] Need to delete records on OAI

Re: [dspace-tech] Need to delete records on OAI

Re: [dspace-tech] Need to delete records on OAI

Re: [dspace-tech] Need to delete records on OAI

[dspace-tech] Need to delete records on OAI

6 matches

Site Navigation

Mail list logo

Footer information