Supporting Scholarly Communications with an Open Source Publishing System

1. Supporting Scholarly Communications with an Open Source Publishing System David Ruddy Cornell University Library JA-SIG 2004 Winter Conference

2. Why are we involved in scholarly publishing?

3. http://www.createchange.org

4. Why are we involved? • The “serials crisis” • Pricing crisis in scientific serials • Increasing concentration and control of scholarly literature in commercial hands • Traditional publishing paradigm for scholarly literature is no longer working • Responses from the academic community • Consortial buying, pre-print servers, institutional repositories, open access movement, efforts to educate faculty, SPARC, library e-publishing

5. Project Euclid • Mathematics and statistics serial literature online • Grant awarded by the Mellon Foundation in 2000 for initial development • Launched in 2003 as a fee-based service • 39 titles as of December 2004 http://ProjectEuclid.org

6. Current DPubS Project • Generalize and extend software developed for Project Euclid (DPubS) • Share software as Open Source, with the goal of encouraging lower-cost alternatives for scholarly publishing • Partner: Penn State University Libraries • Two year project • Ithaca meeting, Oct 2004

7. DPubS History • Early Dienst development (1994-95) • NCSTRL—Networked Computer Science Technical Report Library (1995-98) • CUL digital collections (1997—) • CUL electronic publishing • Project Euclid (2000— )

8. DPubS DevelopmentSince 2000 • Extensive additions to all services • Subscription Service developed • Flexible access control options • OAI 2.0 compliance • E-Commerce (pay-per-view) • Full-text searching • Subscriber/publisher usage statistics • Referral Service • Reference linking processes, DOI registration, remote db lookup processes…

9. DPubS services & APIs HTTP Request Service A Service B HTTP Response Request: …verb=verbName&version=2.0… Extending functionality: New version of verb New verb

10. DPubS Document Request User Registry Service UI Service Search Subscription Service Index Service Document Request Repository Service

11. Document Request Example User Registry Service UI Service Search Subscription Service Query Mediator Service Document Request Repository Service Index Service One Index Service Two Index Service Three

12. User DPubS Services Browse Service Referral Service Current Awareness Service Publisher User Interface Service Index Service Admin UI Service Editorial Service Repository Service Subscription Service Submission Service User Registry Service Reference Linking & Lookup Processes Author Metadata Service

13. DPubS Development Goals I. Generalization of the software • User interface service • Metadata service • Document types II. Creation of administrative interfaces III. Development of editorial management services IV. Addition of interoperability with Institutional Repositories

14. I. Generalization of the Software • Design a more flexible User Interface Service using XML/XSLT • Abstract the underlying configuration metadata within DPubS, allowing a more flexible range of hierarchical structures • Flexible collection building • Additional document types

15. User DPubS Services Referral Service Publisher User Interface Service Index Service Editorial Service Repository Service Subscription Service User Registry Service Reference Linking & Lookup Processes Metadata Service

17. User Interface Redesign • Move user interface customization out of core code • Technology? • XSL Transformations—XML pipelines • Template design

18. XML Pipeline Object XML Header XML Footer XML Nav Bar XML Issue XML XSLT Ref.Linking XML XSLT Page XSLT XSLT Access data XML XML

19. Goals of Metadata Service Redesign • Rationalize where and how configuration metadata is stored and accessed • Build support for more flexible groupings and hierarchical displays • Support a richer, more extensible object metadata model for defining document structure

20. Publications: Content objects Predictable structures, defined by an XML schema For example: Serials Proceedings Monographs Collections: Relationships among content objects and other collections Flexible structures Multiple structures, involving the same objects, must be possible “Publications” and “Collections”

21. Document Types • A generalized manner for defining document models will allow for more extensive document types journal title  volume  issue  article monograph  section  chapter conference proceeding  presentation • Defined down to the unit of distribution

22. Defining Collections <div label=“Cornell E-Publishing Serials”> <div label=“Statistics”> <publication id=“s1234”/> <publication id=“s5678”/> </div> <div label=“Duke University Press”> <publication id=“s135”/> ….

23. II. Creation of Administrative Interfaces • A DPubS extension • Rationalize production workflow • Create web interfaces to manage administrative processes

24. User DPubS Services Referral Service Publisher User Interface Service Index Service Admin UI Service Editorial Service Repository Service Subscription Service User Registry Service Reference Linking & Lookup Processes Metadata Service

25. Administrative Tasks • Configure new publication • Load content • Load subscription data • Configuring usage reporting • Troubleshoot access problems • Etc.

26. Goals • Simplify administrative task • Reduce risk • Lower staff costs

27. III. Development of Editorial Management Services • A DPubS extension • Support manuscript management and peer review activities

28. User DPubS Services Referral Service Publisher User Interface Service Index Service Admin UI Service Editorial Service Repository Service Subscription Service Submission Service User Registry Service Reference Linking & Lookup Processes Author Metadata Service

29. Editorial Management Services • Support manuscript management and peer review activities • Manuscript submission • Reviewing • Document tracking • Organization of publications • Publishing content (“making public”)

30. On-line Manuscript Submission • An author may: • Register with system • Complete metadata on article (forms) • Upload article in one or more formats • Submit article to selected recipient • Track progress of article • Request e-mail updates on progress of article • System will: • Send e-mail alert to editor • Route submission to recipient

31. Submission Management • Editor may: • View submission • Edit article metadata • Accept for review • Accept for consideration (forward) • Reject, with comments • Install articles submitted outside system

32. Reviewer Selection • Editor may: • Manage reviewer database • Assign article to a reviewer • Contact reviewer • Select mechanism for distributing manuscript to reviewer • Receive notice of reviewer acceptance or refusal • Receive feedback/comments from reviewer • Receive notice of delinquent reviews • Send, or automate the sending of, reminders

33. Reviewer Communications • Reviewer may: • Create/edit reviewer profile • List review history • Retrieve manuscript to review • Send acceptance or refusal to review • Submit feedback/comments on manuscript • Editor may: • Forward anonymous comments to author • System may: • Archive reviewer’s comments

34. Manuscript Tracking • Editor may: • Track accepted papers through the editorial and composition process • Establish editorial stages • Assign work to editors or staff • Upload manuscript versions • Administrative staff may: • Upload manuscript versions • Indicate when a stage is completed • System may: • Send alerts when manuscript has passed a stage

35. Managing Articles and Issues • Editor may: • List unpublished articles • Create forthcoming issues • Assign articles to forthcoming issues • View status and composition of forthcoming issues • Publish issues, or articles

36. Forthcoming Articles • Accepted articles can be made public before their issue is prepared • Access mechanisms set • Move articles to issue when “published”

37. Editorial Mtg. Challenges • Complexity and peculiarity of publisher workflows • Access controls • Must be group based • Authors, editors (head, associates, editorial boards), reviewers, administrative staff • Keeping tools (within a single service) operationally independent • Functionality must be easily extended

38. IV. Interoperability withInstitutional Repositories • A DPubS extension • Identified IRs: DSpace, Fedora • DPubS becomes an application layer on top of IR • DPubS Repository Service functions as an API for input/output to IR

39. User DPubS Services Referral Service Publisher User Interface Service Index Service Admin UI Service Editorial Service Repository Service Subscription Service Submission Service User Registry Service Reference Linking & Lookup Processes Author Metadata Service

40. DPubS and Institutional Repositories • DPubS vs. Institutional Repository? • Why interoperate with an IR? • That may be where the content is • Division of labor: publishing vs. archiving • Ability of both parties to focus on a more narrowly defined set of functionality • Interoperability will require cooperation and support of IR

41. Open Source • An additional project goal • Challenges • Documentation and support • Fostering and sustaining a distributed development community (how many institutions?) • An organization for maintenance and enhancement • Sustainable business model

42. DPubS • Web site: http://dpubs.org • Production implementation: http://projecteuclid.org • Questions? David Ruddy <dwr4@cornell.edu>