we were wondering if you could integrate person name norm data in OJS 3?
It would be very convenient for us to have the opportunity to fill in norm data to uniquely identify authors. We thought about the german national norm data GND (http://www.dnb.de/DE/Standardisierung/GND/gnd_node.html), VIAF (https://viaf.org/) and ISNI (http://www.isni.org/), the LoC norm data and ORCID (http://orcid.org/), too.
Why is it useful? We are cataloging thousands of articles per year, and one step is to identify the author uniquely. We do this to ensure to match different forms of the names (less duplicates) in our shared cataloging-environment and to make
these data reusable. Once the identification is done in a shared cataloging environment, you (or any other institution) are free to reuse these data for bibliographies, Campus Management systems or semantic web components.
There was a thread regarding the integration of ORCID a year ago about this topic: http://pkp.sfu.ca/support/forum/viewtopic.php?f=1&t=11500
We would like to encourage you to integrate any of the mentioned person identifiers in OJS to foster the reuse of norm data.
Great, we do strongly support this point. Currently, we have the workaround using a metadata management system which is external to OJS. In that system, we are able to check and query person data from authority files that are available via SRU and then integrate them into the metadata set.
However, the downside of this is that once an upload has been done, data can only be changed (for example new mail adresses of authors that have not used the submission workflow) using screen scraping based interaction.
If authority files could be queried from within OJS, that would be a great feature in order to get and maintain a clean and correct database.
That’s some very helpful feedback. We mostly focus on ORCiD when we think about author disambiguation, but I’m also interested in finding out what other standards are in active use, particularly things like national standards.
Judging by the list you’ve presented, I think we’re going to have to support a plugin-based approach – integrating for example the national standard is not a good option, obviously, but it would still be good to support it somehow.
Currently we have ORCiDs in OJS 2.x and will release OJS 3.0 beta with the same. This is both for user profiles and author records, with data flowing from users into authors when submissions are created. For OJS 3.0, we’ve cleared the way for more identifiers by splitting up the user profile into more, smaller, sections. Identifiers will go into a tab called “public”.
We don’t yet have the ability e.g. to fetch data from the authority when filling in a record; could you describe the data flow you’d expect in a little more detail?
Regards,
Alec Smecher
Public Knowledge Project Team
we started using OJS actively last year. One use case for our OJS is the publication of articles for OA-journals. As a library we can’t stop at the point of publication of a journal article or issue.
For the proper reuse of Metadata it is crucial to produce high quality Metadata. Many international efforts face this challenge right now (currently research data archiving systems or Campus Management systems) and tackle it with the
integration of unique person identifier systems. But if you are at the end of a chain, it is hard to identify authors. It costs us up to half an hour or even longer for journal articles per author and article to identify them, if even
possible. It is much easier, if you identify persons uniquely at the begin of the publication process, in OJS.
The solution is in my eyes the identification of authors in OJS at the begin and to deliver these via interfaces (OAI) to other systems.
Like mentioned, we plan to deliver the generated Metadata to our Shared catalog automatically. Currently we are doing this by hand, in the future we want to get harvested by the shared catalog system and maybe other harvester systems
(like BASE https://www.base-search.net/).
In Germany many norm data are maintained and are reused on national level. We use the GND person name data to uniquely identify authors. It is quite clear for us, that we are acting in an international setting. So it is not necessarily only one identifier system we know of and we have to reuse. Normally there is only one (or maximum two) person identifiers we catalog. The main point for us is, that there are unique identifiers for persons and to know the identifier system.
Concordances between these identifier systems, like VIAF, help to resolve them for the local context.
In my opinion it is not necessary to query the person identifiers in OJS, even if that would be very comfy
We would like to have one or maximum two additional fields, where one could specify which person name identifier system to use and the identifier itself. This identifier is also crucial for the export (for OAI harvesting). There might be
problems in the export, but as long as you do have the identifier system it is doable.
You mentioned that a Plugin might be a solution. Of course this keeps the main system neat. We are running repository systems for over 16 years now. We experienced many obstacles in the normal migration process with Plugins or
optional modules, which were developed outside the main branch. So maybe we are a bit conservative in the update policy. We want to keep up with the normal upgrade process of a software to not run into security problems and to be able to get the latest features available, if needed. So we would prefer to have a solution in the mainline of OJS. On the other hand: could you give us insights in the further development of OJS-plugins?
That makes sense – and we’ve worked with a few groups in Germany on nationally important elements, such as meeting anonymization legislation requirements while still collecting statistics. (Perhaps @bozana can comment on some of this ).
I do think plugins are the only way to really do this properly, as what’s needed for German users will be useful for several sites but will confuse the majority of OJS users. Plugins will permit the German user community to share implementations for common requirements without needing that code to be built into OJS for all users.
My preference would be for all user identifiers to be implemented as plugins – ORCiD included – but for only certain plugins to be distributed with OJS by default. That way all user IDs could use the same pattern and API, rather than making less commonly used plugins “second-class citizens”.
I suspect that adding a generalized ID field (or two) would probably cause confusion, or at least be difficult to do anything with, since there will be a lot of variation across how they’re entered, and no validation of the ID formats. (Think ORCiDs with vs. without the “http” prefix, etc.)
The best case would probably be for someone (us) to move ORCiDs into a plugin structure, and have that serve as an example for other author/user ID systems. It would hopefully be a very brief and readable piece of code.
Thanks,
Alec Smecher
Public Knowledge Project Team
good to see this taking up speed. The idea to put IDs into plugins makes sense.
In the last post, @asmecher talks about user identifiers. Maybe this is just a language thing, but we should not forget that there is a difference between an author and a user. As I work for a library where a significant part of our OJS use concerns digitized print contents, I regularly import old issues from fifty years ago to OJS. These authors sometimes have identifiers that can be queried from VIAF or the like.
So, when talking about the implementation of user identifiers, it would be good to see them available not only as fields in user profiles for born-digital journals, but also as a database field for use in importing articles from authors who do not have an account in the system. (And I do realize this might be tricky to implement this through a plugin, as both user profiles and the author database are concerned.)
OJS 3.x has ORCID fields for users and authors on registration and submission. ORCID data, when present, adds a standard ORCID link to submission detail pages providing more information about authors. And ORCIDs should be deposited via CrossRef, which will then feed the ORCID website, resulting in populating of author profiles when the data is available.
Regards,
Alec Smecher
Public Knowledge Project Team
We want to keep up with the normal upgrade process of a software to not run into security problems and to be able to get the latest features available, if needed. So we would prefer to have a solution in the mainline of OJS. On the other hand: could you give us insights in the further development of OJS-plugins?