Bug 5735 - Expose important data for bibliographic control
Expose important data for bibliographic control
Status: NEW
Product: OJS
Classification: Unclassified
Component: Open Journal Systems
2.4.x
PC Windows 7
: P5 enhancement
Assigned To: PKP Support
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-13 18:29 PDT by Kevin Stranack
Modified: 2012-09-21 15:55 PDT (History)
1 user (show)

See Also:
Version Reported In:
Also Affects:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Stranack 2010-08-13 18:29:46 PDT
Expose important data for bibliographic control in OJS journals, including:

 - journal title
 - journal issn
 - journal doi
 - journal URL
 - journal OAI URL
 - year of first published item
 - year of last published item
 - volume number of first published item
 - volume number of last published item
 - issue number of first published item
 - issue number of last published item
 - publisher name
 - publisher URL
 - principal contact name
 - principal contact email
Comment 1 Alec Smecher 2010-08-16 09:56:59 PDT
Kevin, we don't currently have journal DOIs in the system as metadata; it's too late to add new fields to setup and we'd also need to consider where else to expose these. I'd suggest leaving that one out for this release. I would also suggest that we don't expose any information that wouldn't be exposed elsewhere on the site, i.e. if the journal's archives are closed behind a login, then we shouldn't expose first published / last published info.
Comment 2 Alec Smecher 2010-08-16 10:26:44 PDT
Suggest using the OAI <description> node, included in the Identify verb, to describe. This would also make the "OAI URL" entry a bit redundant. Would need to consider how to address both site-level and journal-level requests for this info.
Comment 3 Alec Smecher 2010-08-23 14:46:43 PDT
Kevin, can you think of a good XML standard that might hit at least a few of these? If we're only doing this for the sake of our own records, it's somewhat self-serving.
Comment 4 Kevin Stranack 2010-08-23 15:34:51 PDT
(In reply to comment #3)
> Kevin, can you think of a good XML standard that might hit at least a few of
> these? If we're only doing this for the sake of our own records, it's somewhat
> self-serving.

An emerging standard that might apply is the KBART standard:

http://www.uksg.org/kbart/s5/guidelines/data_fields

It is still early days, but this looks like it will move ahead. I believe that the SFU Library is starting to get some title lists from vendors in this format. I can try to find an example, if that would help.
Comment 5 Alec Smecher 2010-08-24 09:20:29 PDT
Kevin, good spotting -- that's a pretty close match. Unfortunately it's a CSV-based report (not embeddable in an OAI Identify response), typically delivered by FTP (a push-based mechanism), so I'm not sure how we can make the data available via a pull-based mechanism like OAI. Who releases a data exchange standard these days without at least a mention of XML?
Comment 6 Alec Smecher 2010-09-22 17:50:11 PDT
Deferring, unfortunately. Need to do some more requirements work on this first.