Re: [dspace-tech] Error OAI import -c -v
Hi,
You can find it at
dspace-oai/src/main/java/org/dspace/xoai/app/XOAI.java
El martes, 18 de febrero de 2020, 14:43:14 (UTC), Ramón Cordeiro escribió:
>
> Thanks George.
>
> I need to create this file 'org.dspace.xoai.app.XOAI.java' or This already
> exist and I only need add these lines ?
>
> Em sábado, 26 de outubro de 2019 11:56:45 UTC-3, George Kozak escreveu:
>>
>> Ramón:
>> I had a similar problem a while ago. I was helped by Emilio Lorenzo (
>> elor...@arvo.es) and Adan Roman (adan...@gmail.com). They had a patch
>> that I made to the DSpace java code that gave me the ability to find the
>> record. Basically, this patch allows the OAI import to write in verbose
>> mode the id of an item before it is indexed. So, when the OAI import
>> stops, you know exactly what record caused it to stop. Then you can fix
>> the item and rerun the OAI import. The bad thing is that if you have
>> multiple "bad" records then you have to keep running the import until you
>> clean out the records one by one.
>> This is the patch:
>>
>> org.dspace.xoai.app.XOAI.java :
>>
>>
>> private SolrInputDocument index(Item item) throws SQLException,
>> MetadataBindException, ParseException, XMLStreamException,
>> WritingXmlException {
>>
>> if (verbose) {
>>
>> System.out.println("Trying to index into oai item with
>> id:"+item.getID().toString());
>>
>> }
>>
>> SolrInputDocument doc = new SolrInputDocument();
>>
>> doc.addField("item.id", item.getID());
>> Good luck.
>> George Kozak
>> Digital library Specialist
>> 218 Olin Library
>> Cornell University
>> Ithaca, NY 14853
>> gs...@cornell.edu
>>
>> On Thu, Oct 24, 2019 at 8:42 AM Ramón Cordeiro
>> wrote:
>>
>>>
>>> How I mentioned before, in dspace 5 solr indexing running in random way.
>>> Because IT, become hard to discovery which record is having the problem.
>>> Someone have some idea ?
>>>
>>> [image: error_solr_import-print.png]
>>>
>>>
>>>
>>>
>>> Em segunda-feira, 21 de outubro de 2019 11:27:26 UTC-3, Ramón Cordeiro
>>> escreveu:
>>>>
>>>> The dspace is already with xalan 1.7.0. But not work.
>>>> Do you know how do import forcing work in number order ?
>>>>
>>>> Em quinta-feira, 17 de outubro de 2019 17:03:16 UTC-3, Michel Santana
>>>> escreveu:
>>>>>
>>>>> I have posted this reply to another question here. Perhaps is the
>>>>> same:
>>>>> "We had a problem very similar and was because the OAI server has a
>>>>> bug in one library that causes a server crash when the dataset has an
>>>>> item
>>>>> with a non standard UNICODE character in the Metadata.
>>>>> The solution is to change that library (xalan 1.7.1) to a previous one
>>>>> (xalan 1.7.0) in the pom.xml file.
>>>>> I have done a pull request to solve this.
>>>>> https://github.com/4Science/DSpace/pull/101
>>>>> Take a look and try. Good luck!"
>>>>
>>>> --
>>> All messages to this mailing list should adhere to the DuraSpace Code of
>>> Conduct: https://duraspace.org/about/policies/code-of-conduct/
>>> ---
>>> 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 dspac...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/dspace-tech/91087dc0-c393-4af9-854b-9dde1d7be1b2%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/dspace-tech/91087dc0-c393-4af9-854b-9dde1d7be1b2%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> --
>> ***
>> George Kozak
>> Digital Library Specialist
>> Cornell University Library - IT
>> 218 Olin Library
>> Cornell University
>> Ithaca, NY 14853
>> 607-255-8924
>> gs...@cornell.edu
>>
>
--
All messages to this mailing list should adhere to the DuraSpace Code of
Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
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 view this discussion on the web visit
https://groups.google.com/d/msgid/dspace-tech/c2a9114f-9aaa-4f11-8a23-79c81a72a73c%40googlegroups.com.
[dspace-tech] Re: Published Item back to WorkflowItem
Hi, At least in DSpace-CRIS you can edit the item in "Submission Mode" so you go through the same submission flow that you have defined at input-forms.xml Here you have a snapshot: [image: submission.png] El martes, 5 de noviembre de 2019, 13:59:05 (UTC), Vlastimil Krejčíř escribió: > > Hi all, > > I've been recently asked whether it is possible to move published item > to the workflow process. Once the new Item is published you can edit the > metadata only in a simple DC form. This is not very user friendly. > > Is it possible to move a published Item back to the workflow process and > edit metadata via the forms configured by the input_forms.xml? > > Regards, > > Vlastik > > -- > > > Vlastimil Krejčíř > Library and Information Centre, Institute of Computer Science > Masaryk University, Brno, Czech Republic > Email: krejcir (at) ics (dot) muni (dot) cz > Phone: +420 549 49 3872 > OpenPGP key: https://kic-internal.ics.muni.cz/~krejvl/pgp/ > Fingerprint: 7800 64B2 6E20 645B 56AF C303 34CB 1495 C641 11B9 > > > -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- 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 view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/d82e6c4f-6003-45fa-aece-f0fa0b944b15%40googlegroups.com.
Re: [dspace-tech] Error OAI import -c -v
I have posted this reply to another question here. Perhaps is the same: "We had a problem very similar and was because the OAI server has a bug in one library that causes a server crash when the dataset has an item with a non standard UNICODE character in the Metadata. The solution is to change that library (xalan 1.7.1) to a previous one (xalan 1.7.0) in the pom.xml file. I have done a pull request to solve this. https://github.com/4Science/DSpace/pull/101 Take a look and try. Good luck!" -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- 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 view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/9e480ce6-3654-4375-939f-4f6816adf652%40googlegroups.com.
[dspace-tech] Limit on OAI harvested data?
We had a problem very similar and was because the OAI server has a bug in one library that causes a server crash when the dataset has an item with a non standard UNICODE character in the Metadata. The solution is to change that library (xalan 1.7.1) to a previous one (xalan 1.7.0) in the pom.xml file. I have done a pull request to solve this. https://github.com/4Science/DSpace/pull/101 Take a look and try. Good luck! -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- 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 view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/2bdd8320-15f1-468f-a56a-d4c97d135439%40googlegroups.com.
Re: [dspace-tech] Importing BibTeX files using BTE
Hi,
I know that this is pretty old but I'm having exactly the same issue with
splitting the authors. How did you finally do this?
Thank you very much!
Michel
El martes, 16 de agosto de 2016, 7:52:15 (UTC+1), Oliver Goldschmidt
escribió:
>
> Hello DSpace community,
>
> I have made some progress on my BTE issues and now I got it working to
> split the authors correctly into several fields and also to convert the
> LaTeX encoded characters automatically while importing. I did this by
> creating two new beans.
>
> But there is still one issue left: importing from a bibTeX file does not
> import the type of the publication correctly. In BibTeX the type is noted
> not in a field, but with an @ at the top of the record. I understand how to
> add field mappings in the bte config file, but as the type is not a normal
> field I do not understand how I can get that. Before I try to create an
> alternative BibtexDataLoader in order to implement the type detection there
> I would like to ask if anyone else already has done this or if anyone else
> has also this kind of problem.
>
> Thanks and best regards
> Oliver
>
> Am Freitag, 10. Juni 2016 16:13:26 UTC+2 schrieb Oliver Goldschmidt:
>>
>> Hi Claudia,
>>
>> thank you very much for your reply!
>> I know the config file for BTE, but I do not see how I can split the
>> BibTeX field for author into several dc.contributor.author fields in the
>> DSpace record. As far as I know I can only map a key from the bibtex file
>> to a key in the config file, which maps to a dc field (but it seems to me
>> that its always only one field). For example in the
>> bibTeXDataLoader-section in bte.xml:
>> maps to the outputMap, where I find this element: > key="dc.contributor.author" />. My interpreation is, that the value of the
>> author field is set into the field dc.contributor.author - but I can't see
>> if I can process the BibTeX field before putting it into the DSpace field
>> (and I guess that would be necessary to split off the author string to get
>> it into multiple DC attributes).
>>
>> About the latex encoded ü: if I understand you correctly, I will have no
>> choice and need to convert such characters before I import the record into
>> DSpace. I guess that's not very comfortable (as that means I need to check
>> every BibTeX record before importing), but okay...
>>
>> Thanks
>> Oliver
>>
>> Am Freitag, 10. Juni 2016 14:55:05 UTC+2 schrieb Claudia Jürgen:
>>>
>>> Hi Oliver,
>>>
>>> the config file for BTE is:
>>>
>>> https://github.com/DSpace/DSpace/blob/dspace-5.5/dspace/config/spring/api/bte.xml#L256
>>> which does a simple mapping of fields and defines the data loader.
>>>
>>> As for the encoding this is a bit tricky as it depends on the packages
>>> and inputenc used in the LaTeX itself.
>>> The indirect way to input e.g. ü is
>>> {\"u} or \"u
>>> using \usepackage[german]{babel} ü might be written "u
>>> and with
>>>
>>> \usepackage[ansinew]{inputenc}(windows) you can enter them directly afaik.
>>>
>>> Hope this helps
>>>
>>> Claudia Jürgen
>>>
>>>
>>>
>>>
>>> Am 10.06.2016 um 12:23 schrieb Oliver Goldschmidt:
>>>
>>> Hello DSpacers,
>>>
>>> currently I'm experimenting a little bit with importing BibTeX files using
>>> BTE. If a BibTeX record has multiple authors, I see something like this in
>>> the author field in the BibTeX file:
>>> author = {Me Myself and Oliver Goldschmidt and Fritz M{\"u}ller}
>>>
>>> As far as I know this is absolutely conform to the BibTeX standard. But the
>>> BTE importer messes the imported record up and writes exactly that string
>>> into one dc.contributor.author field. It also does not convert the latex
>>> encoding properly. I would expect the importer to create a record with
>>> three dc.contributor.author fields. Before I start digging in the code
>>> trying to improve this bad behavior: can this get corrected by
>>> configuration?
>>>
>>> Best
>>> Oliver
>>>
>>>
>>>
>>> --
>>> Claudia Juergen
>>> Eldorado
>>>
>>> Technische Universität Dortmund
>>> Universitätsbibliothek
>>> Vogelpothsweg 76
>>> 44227 Dortmund
>>>
>>> Tel.: +49 231-755 40 43
>>> Fax: +49 231-755 40 32claudia...@tu-dortmund.dewww.ub.tu-dortmund.de
>>>
>>>
>>>
>>>
>>> *Wichtiger Hinweis: Die Information in dieser E-Mail ist vertraulich.
>>> Sie ist ausschließlich für den Adressaten bestimmt. Sollten Sie nicht der
>>> für diese E-Mail bestimmte Adressat sein, unterrichten Sie bitte den
>>> Absender und vernichten Sie diese Mail. Vielen Dank. Unbeschadet der
>>> Korrespondenz per E-Mail, sind unsere Erklärungen ausschließlich final
>>> rechtsverbindlich, wenn sie in herkömmlicher Schriftform (mit eigenhändiger
>>> Unterschrift) oder durch Übermittlung eines solchen Schriftstücks per
>>> Telefax erfolgen. Important note: The information included in this e-mail
>>> is confidential. It is solely intended for the recipient. If you are not
>>> the intended recipient of this e-mail please contact the sender and delete
>>> th
