1
|
- David Ruddy
- DLF Fall Forum
- October 25, 2004
|
2
|
- Generalizing and extending software developed for Project Euclid
- Goal: to provide lower-cost publishing alternatives for scholarly
communications
- Partner: Penn State University Libraries
- Two year project
|
3
|
- Early Dienst development (1994-95)
- NCSTRL—Networked Computer Science Technical Report Library (1995-98)
- CUL digital collections (1997-2000)
- CUL electronic publishing
|
4
|
- 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…
|
5
|
|
6
|
|
7
|
|
8
|
- Generalization of the software
- Creation of administrative interfaces
- Development of editorial management services
- Addition of interoperability with Institutional Repositories
|
9
|
- 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
|
10
|
|
11
|
- Move user interface customization out of core code and into XSLT
stylesheets
- Make use of XML pipelines
|
12
|
|
13
|
- 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
|
14
|
- 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
|
15
|
- Create web interfaces to manage administrative processes
- Configuring new publication, load content, load subscription data,
troubleshooting access problems, etc.
- Goals
- Simplify administrative tasks
- Lower staff costs
- Reduce risk
|
16
|
- Support manuscript management and peer review activities
- Manuscript submission
- Reviewing
- Document tracking
- Organization of publications
- Publishing content (“making public”)
|
17
|
|
18
|
- 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
|
19
|
- 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
|
20
|
|
21
|
- 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
|
22
|
- Web site:
- Production implementation:
- http://projecteuclid.org
- Questions?
- David Ruddy <dwr4@cornell.edu>
|