Closed tomwrobel closed 5 years ago
Hi Tom & Jason,
Actually, having an incoming record (such as a Hyrax record) set an OA Policy Exception on the Elements Publication object is not something that is supported. The publication OA Exceptions can currently only managed through the OA Monitor. The data can freely flow the other way, though - the assigned OA Policy exceptions can be fed into the outbound metadata sent to Hyrax. These can indeed be mapped in the crosswalk, from the Elements values into an appropriate ORA value. I hope this won't cause issues for you - let me know your thoughts.
Cheers, Andrew
@AndrewBennet
Currently we have a custom script which takes data from an Excel spreadsheet and imports that into OA Monitor. @eugeniobarrio can give more details.
Would this script continue to work once we switch on the RT2 connector? If so, then we can continue to feed metadata into OA monitor this way.
This is going to be problematic
Regards,
Eugenio
F Eugenio Barrio Research Services
From: Andrew Bennet [mailto:notifications@github.com] Sent: 12 April 2019 10:21 To: tomwrobel/ora_data_model ora_data_model@noreply.github.com Cc: Eugenio Barrio eugenio.barrio@admin.ox.ac.uk; Assign assign@noreply.github.com Subject: Re: [tomwrobel/ora_data_model] REF exception values for OA monitor (#59)
Hi Tom & Jason,
Actually, having an incoming record (such as a Hyrax record) set an OA Policy Exception on the Elements Publication object is not something that is supported. The publication OA Exceptions can currently only managed through the OA Monitor. The data can freely flow the other way, though - the assigned OA Policy exceptions can be fed into the outbound metadata sent to Hyrax. These can indeed be mapped in the crosswalk, from the Elements values into an appropriate ORA value. I hope this won't cause issues for you - let me know your thoughts.
Cheers, Andrew
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/tomwrobel/ora_data_model/issues/59#issuecomment-482503626, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AmJC0VgatmBfph_Le8IxCBeql6mxqBMRks5vgE_2gaJpZM4cpKgx.
I can't say for sure without understanding some more details about your Excel import process, but I would expect that it could continue mostly unchanged. Perhaps let's have a call about this soon to make sure we understand each other.
@eugeniobarrio - could you give a little more detail about what you expect the issue(s) to be?
Cheers, Andrew
@AndrewBennet when would you like to have that call?
I can do Monday afternoon, at about 2:30pm, or 4:15pm. Or anytime on Tuesday.
2:30 is perfect. Speak then!
Sent from my iPhone
On 12 Apr 2019, at 17:39, Andrew Bennet notifications@github.com<mailto:notifications@github.com> wrote:
I can do Monday afternoon, at about 2:30pm, or 4:15pm. Or anytime on Tuesday.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/tomwrobel/ora_data_model/issues/59#issuecomment-482641761, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA-IR1zNEr6vUnXsnopsclw3DPKxV_kvks5vgLaogaJpZM4cpKgx.
Hi all, Apologies it took so long to get into this topic
issue: In out current processes with SE and ORA3, some circumstances that could lead to exceptions against the REF OA policy are only found and noted by the ORA reviewers on review. These are recorded in the reviewers' access DB and not covered by the RT1 feedback.
requirements: This information is necessary to be combined with info in, and available within the SE OAMonitor.
workaround: We have commissioned Symplectic for a script to import this data into the Elements DB. see Symp ticket #87852.
planned process: ORA reviewers extract data in xls from the reviewers DB. Research Services reformats the file into csv with the correct order of columns. ITS runs the SQL script. The script reads a csv with PID and exception code and exception comment text and inputs (amends) the record in Elements.
status: This script has been delivered for testing recently. Testing was generally good but has found some bugs to iron out. We are currently expecting the second version.
future: This Script was meant to help us get the data in the OAMonitor for the dry run (April to July). But we always thought of it as a workaround until ORA4 (who will replace the reviewers DB) and RT2 (who will replace the script) come online in August
I do request to be included in the first release of RT2 for hyrax
As a backup, I guess, when working, the script will still applicable after August, as long as ORA4 can report/extract the exception data against PID on csv (Jason could you please confirm?). As I understand, the script is SQL so is not dependent on the Elements API, nor RT, it may be dependant on the structure of the Elements DB (i.e. version) but also easily adapted.
Regards, Eugenio
To be moved into a Symplectic issue ticket, possibly to be done via a Symplectic API call rather than an SQL script. @eugeniobarrio to close once that ticket is created.
@AndrewBennet can you tell me why https://oxford-hyrax.elements.symplectic.org:8446/viewobject.html?cid=1&id=983570 still appears as non compliant? It should be perfectly fine!
Copying my email into this thread:
Yeah, compliance checking can be a bit mysterious and confusing at times.
If you click the Non-compliant box, you’ll see Elements’ attempt at communicating the reason why it isn’t compliant. In this case:
This publication is non-compliant with the OA policy because: There is neither a fulltext file nor an OA location of a compliant version in the repository
The key bit is “of a compliant version”. There is a fulltext file there (you can see it), so it must be the versioning which is the issue. Indeed, when I check the OA Policy settings, I can see that the compliant file versions have been configured as:
AM
CVoR
EVoR
VoR
And the files in this item have versions: Version Of Record
and Supporting information
.
This actually makes me realise something which I don’t think we’ve explicitly discussed, but may need discussion. In RT2, we cannot configure the allowed options in the file version selection: they are hardcoded to the standard 4 that we use (published, accepted, submitted, supporting info). This is a divergence in functionality from the RT1 connector. To be honest, I would like us to make this configurable in RT2 – we just haven’t got around to it yet.
Happy to talk more about this if necessary.
Yea! I changed it to 'VoR' and its complaint.
In that case, we need to make sure that these are the versions that are being crosswalked! We're happy to store as VoR, AAM, etc.
Are you able to make the change to the crosswalks?
I can make any changes you want :)
Would you be able to give me a table of the mappings you'd like to see for both Outbound (i.e. from Supporting Information, Accepted Version, etc) and for Inbound?
I think it's more can you give me the full list of values for OA monitor and we'll use those :)
In addition, I can't view embargo status or embargo end date for files any more. Where would that value be displayed (I could swear we used to be able to see this)?
Would you be free for a quick call? I think it'll be easier than going via typing
yup, number below (or google etc.)
-- Tom Wrobel Software Engineer - BDLSS thomas.wrobel@bodleian.ox.ac.uk / 01865 277608
From: Andrew Bennet notifications@github.com Sent: 18 April 2019 15:34:00 To: tomwrobel/ora_data_model Cc: tomwrobel; State change Subject: Re: [tomwrobel/ora_data_model] REF exception values for OA monitor (#59)
Would you be free for a quick call? I think it'll be easier than going via typing
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/tomwrobel/ora_data_model/issues/59#issuecomment-484536225, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAHYQR55MVDF7J7ZMSWVXWTPRCBFRANCNFSM4HFEVAYQ.
OK, I think the missing embargo dates is actually standard Elements behaviour when the repository item is not public. We only show the embargo once the item is Live. Could you make an item Live and see whether it shows up?
Yup, it does. Although I'm not sure this is entirely what we want. I'll create a ticket just to be sure. We're fine here though
And thank you! Time to go home :)
I just added some mappings between the Elements file versions to the rioxx ones, and they round-trip correctly.
Have a good weekend!
REF exception values issue now being tracked in https://support.symplectic.co.uk/support/tickets/100421
@AndrewBennet Thinking about testing and pushing values back to SE. With regards to exceptions in this instance, would the value that SE is expecting to see be: "Access1"; "Deposit1", "Other"; "Tech1" etc.?
In ORA these are currently recorded as the text values of the exceptions, e.g. "Publisher embargo too long" or "Publisher does not allow OA".
Do these values need to be mapped so that they can be understood by the crosswalk? I assume for testing we should look to send the SE values in order to see a change within OA Monitor for example?
Thanks, Jason
_Originally posted by @jjpartridge in https://github.com/tomwrobel/ora_data_model/issues/10#issuecomment-481648124_