Auto lookups would be helpful. For the moment the repository manager just wants to consolidate the two repeatable fields we have but still be able to qualify what they are, print, E, link etc – I think my approach is going to be to add a “type” dropdown to the Print ISSN field; we’ll work to move the existing E ISSN’s over. So back to my first question – will adding this dropdown to an existing field compromise the data it holds at all?

Hi Andrew,

for migration, you could add a new compound field with sub_name issn and type, sub_name type be of type set, with options "print", "online", and "link".

Then write a script that copies over the values of your print and online issn fields to the new field and sets the type accordingly.

However, I share the concern of John. Academics or submitters (e.g. institute secretaries) do not care whether an ISSN is ISSN (P), ISSN (E) or ISSN (L) - this is something for librarians. It's merely used to identify a journal if it may have an ambiguous name. The problem ist that the right information is entered at the right place, at best using autocompletion (see https://wiki.eprints.org/w/Autocompletion ).
I also like his idea of promoting a prefered value to the default field (which is used for export).


For autocompletion of journal information, we use a sophisticated method: A journal database (JDB) that is used during the submission process in the  publication repository (ZORA) for journal name lookups. It originally came from the university's requirement to track the refereed status of journals. The JDB itself is a separate EPrints repository.

A journal record contains
- all ISSN variants, if available
- title variants, including ISO-abbreviated titles
- refereed status
- rights and embargo information, either entered manuall or nightly updated via Sherpa/RomEO API lookup
- link to a publisher record
- Source import information

Example: http://www.jdb.uzh.ch/14208/

During journal name lookup (which can be done using journal title, abbreviated title or another title variant, or ISSN), the JDB ID and the official title and publisher name are copied over to the ZORA record. The issn field is set from the three ISSN fields in JDB in the priority L > P > E. The JDB ID is further used in the upload stage to look up copyright details and Sherpa/RoMEO conditions from the JDB. If we need to aggregate records in ZORA via ISSN (e.g. for statistical reasons), we again look up first the JDB ID and use it for searches in ZORA.


Best regards,

Martin


--
Dr. Martin Brändle
Zentrale Informatik
Universität Zürich
Stampfenbachstr. 73
CH-8006 Zürich

John Salter ---20/04/2017 12:45:56---I was going to suggest something similar - like the way the datesdatesdates plugin works. See: https

Von: John Salter <J.Salter@leeds.ac.uk>
An: "eprints-tech@ecs.soton.ac.uk" <eprints-tech@ecs.soton.ac.uk>
Datum: 20/04/2017 12:45
Betreff: Re: [EP-tech] Sub types on fields
Gesendet von: eprints-tech-bounces@ecs.soton.ac.uk

I was going to suggest something similar - like the way the datesdatesdates plugin works.
See: https://github.com/eprintsug/datesdatesdates/blob/master/lib/cfg.d/zz_datesdatesdates_triggers.pl#L3-L45
It chooses the *best* (most published) date to promote to the default field - which works well with export plugins that reference the default 'date' field.
 
Do your academics know whether an ISSN is print or online? Do you trust them to assert this accurately?
 
I'd possibly apply the logic:
If there's only one ISSN in your repeatable field, promote that to the default ISSN field.
If there are two (or more), prefer one.
 
*But* really you should be thinking about exposing all this data to other downstream systems (which would mean altering export plugins to output multiple ISSNs…)
 
Cheers,
John
 
From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of Adam Field
Sent: 20 April 2017 10:09
To: eprints-tech@ecs.soton.ac.uk
Subject: Re: [EP-tech] Sub types on fields
 
You could have a Print ISSN field and an Online ISSN field, and then an ISSN field which is virtual (or automatic) and selects an appropriate ISSN from the two and returns it.  That way the user would have two explicitly labelled fields, but the behavior of the issn field could be programmatically controlled.
 
--
Adam
 

From: <eprints-tech-bounces@ecs.soton.ac.uk> on behalf of Andrew Beeken <anbeeken@lincoln.ac.uk>
Reply-To: <eprints-tech@ecs.soton.ac.uk>
Date: Wednesday, 19 April 2017 15:21
To: "eprints-tech@ecs.soton.ac.uk" <eprints-tech@ecs.soton.ac.uk>
Subject: [EP-tech] Sub types on fields
 
Hello!
 
So, I’m trying to sort out an issue in our EPrints where we have two ISSN fields – a Print ISSN and an Online ISSN. The problem with these is that neither of these fields are the ACTUAL ISSN which causes some issues on both output as well as making adding records clunky to ensure that academics put their ISSN in the correct field.
 
What I’m looking at doing is adding a “Type” dropdown to the Print ISSN definition that can toggle the ISSN to Print or Online, change the phrase on the Print ISSN field to just identify it as an ISSN (it’s already repeatable) and make sure that the ISSN field is included in the export. There are a few potential “gotcha’s” with this that I’m concerned about.
 

·         Will doing this jeapordise the existing data in any way?
·         If I set the default to “Print” will this default any pre-existing records to a Print type?
·         At the moment we’re looking at manually moving the Online ISSN’s over to the new field, however if there is an easy way to consolidate these two fields I’m all ears! J

 
Thanks in advance!
 
Andrew

The University of Lincoln, located in the heart of the city of Lincoln, has established an international reputation based on high student satisfaction, excellent graduate employment and world-class research.

The information in this e-mail and any attachments may be confidential. If you have received this email in error please notify the sender immediately and remove it from your system. Do not disclose the contents to another person or take copies.

Email is not secure and may contain viruses. The University of Lincoln makes every effort to ensure email is sent without viruses, but cannot guarantee this and recommends recipients take appropriate precautions.

The University may monitor email traffic data and content in accordance with its policies and English law. Further information can be found at: http://www.lincoln.ac.uk/legal.
*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech *** Archive: http://www.eprints.org/tech.php/ *** EPrints community wiki: http://wiki.eprints.org/ *** EPrints developers Forum: http://forum.eprints.org/ *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/