Re: [dspace-tech] How to import from internal academic system

2016-06-27 Thread Samuel Henrique
Hi Monika,

First, i'm sorry for taking so long to reply, i've got to swtich priorities
here and now i'm back to this problem.

I am not clear how much human involvement you think you need in the
> process.
>
> Step 1 ) export to dublin core in a way that DSPACE can import from
> directories
> Step 2) ???
> Step 3) import
>
> do you want a person to review the exported data to make decisions about
> whether to import or not, whether to fix up metadata , and to decide which
> collections items should be assigned to ? If the answer is yes your job
> will be difficult.
>

To answer the last question, kind of yes, i'm gonna try to give a better
explanation of what is my problem:

Let's say somebody is graduating (or getting a masther or doctorate
degree), this person has to do some academic work (tcc, thesis...), this
work is firstly submitted in our academic system with, by "submitted" i
mean that a lot of the metadata is being submitted, like: author names,
title, description, type...
IF this work is approved (example:the person graduates)[1], we then
*have[2]* to pass it to DSpace as a not finished[3] submission because we
have to add some fields that won't come from the academic system, like:
license, author curriculum (like orcid, but we use one called lattes), the
file itself (pdf) and so on, the person that will copy the metadata from
the academic system and add its missing metadata will be someone with a
submitter role for its collection, and after this person finishes it, some
reviewer[4] will have to accept the submission, finally publishing it.

Considering this is an all time ongoing process, you can see every attempt
to automate it would be great.

Now, what i want to do is the following, since we can't ask for an OAI
interface yet:
The academic system to have a button on this record view page that says
something like "export metadata", and it will generate a file containing
all the possible metadata used by Dspace, ready for import;
The person that is used to manually copy the metadata will access the
academic system, download it and import to DSpace, using the WebUI as a
non-admin user (altough as a submitter for this collection), as a non
finished submission;
This same person will now fulfill the missing fields, upload the pdf,
accept the license, simplifying, this person will finish the submission,
passing the ball to a reviewer whom will publish the submission.

We have an opportunity on the next few days of asking for the manager of
this academic system to implement this, at the same time aiming for an OAI
interface on the future (they won't do it now).
So i need to:
1) Define a metadata format that the academic system will follow to export
this data.
2) Find a way in which a non-admin DSpace user can import this metadata as
a non finished submission.

I need help with both 1) and 2)
For 2 i found this
https://wiki.duraspace.org/display/DSDOC5x/Importing+and+Exporting+Items+via+Simple+Archive+Format#ImportingandExportingItemsviaSimpleArchiveFormat-UIBatchImport(JSPUI)
Which says only admin users can import data and only mentions batch import,
i believe i would need the basic "import metadata" option above the batch
one.

For 1 i found some info on the DSpace wiki suggesting that i may use DC
Metadata for importation.

Every comment regarding this problem is highly appreciated, thanks!

If i wasn't clear about anything, please point out and i will happily try
to clarify it.

[1]When it is approved, it's made within the academic system, so there is a
way of identifying only those records we need from the academic system.
[2]We have to, but what is really made is that one person manually copies
the data showed on the academic system, so from this person's POV is just a
normal submission.
[3]By "not finished" i mean that this submission is still pending to the
submitter and is not available for review yet (no license accepted yet, for
example).
[4]This comes from the collection workflow setting, as i understood;
someone submits, another one review, and the review process publishes. The
separation of submitters and reviewers is given by grouping users and
setting their permissions for wanted collections.


Samuel Henrique O. P. [samueloph]

2016-05-13 12:26 GMT-03:00 Monika C. Mevenkamp <moni...@princeton.edu>:

> You are right of cause
>
> I am not clear how much human involvement you think you need in the
> process.
>
> Step 1 ) export to dublin core in a way that DSPACE can import from
> directories
> Step 2) ???
> Step 3) import
>
> do you want a person to review the exported data to make decisions about
> whether to import or not, whether to fix up metadata , and to decide which
> collections items should be assigned to ? If the answer is yes your job
> will be difficult.
>
> If the answer is no , along with we’ll generate Dublin core in batches
> that match

Re: [dspace-tech] Controlled Vocabularies shipped

2016-05-30 Thread Samuel Henrique
Hi Tim,

I'm sorry for taking so long to answer, but i didn't see the reply.

I just made a PR with the cnpq's xml.

https://github.com/DSpace/DSpace/pull/1423

You can discuss the licensing problem (if there's still any) there and i 
can directly contact other people if needed.

Thanks!

-- 
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] Multi language field's OAI XML

2016-02-23 Thread Samuel Henrique
Currently DSpace returns (through OAI) multi language fields as multiple 
fields with the same tag 

Practical example; I have an article with two descriptions, one in english 
and one in portuguese.
When I get this article's xml through OAI, i get the descriptions in the 
following format:

...
 Here be description
 Here be portuguese description
...

I believe this is problematic because it makes very difficult to detect the 
language of the field and harvest both (for example, VuFind only gets the 
first description. see [1]).

Also, please correct me if i'm wrong, but is a fault in DSpace on complying 
with Dublin Core guidelines, see Recommendation 9: 
*Where the language of the value is indicated, it should be encoded using 
the 'xml:lang' attribute.*From 
http://dublincore.org/documents/dc-xml-guidelines/.

I know that, by default, it's not obligatory to have a language field, but 
shouldn't be the case when you have fields with more than one language?

Can somebody confirm that? I was afraid that the problem was on VuFind 
side, i was looking at the article's xml returned from OAI stored in VuFind 
folders, but i believe thesse XMLs are exact ones returned by DSpace, and 
directly searching through DSpace OAI interface (dspacedomain/oai/request) 
gave me conffidence that its DSpace whos returning these XMLs.

[1]https://sourceforge.net/p/vufind/mailman/message/34785485/

-- 
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.