PubMan External Adopters Requirements
Please provide short information on your institution and list your requirements/questions regarding further PubMan development.
AWI[edit]
Contact: Ana Macario
Institution: Alfred Wegener Institute for Polar and Marine Research (AWI)
Requirements[edit]
- Port customization in the install scripts for both PubMan and eSciDoc.
- Motivation: we would like to have the possibility of running multiple PubMan instances with one single eSciDoc/Fedora; this is relevant for the cases in which setting different "contexts" is not enough (e.g, different cooporate identities). A single JBOSS installation for all is, of course, highly desirable. To give a concrete example: we would like to use one PubMan instance as frontend to AWI centric objects and a separate one as frontend to IODP (Integrated Ocean drilling Program) publication objects. Both PubMan instances would have distinct coorporate identities, schema, workflows and AuthN&AuthZ. This is why the different "context" solution would not do the trick in the long run.
- Flexible AuthN & AuthZ including support to LDAP and Shibolleth. Single sign-on is also desirable.
- Motivation: we will explicetely need to enforce policies at the collection, object and individual datastream levels . An evaluation as to whether the promising "Fedora Enhanced Security Layer" (see FESL <http://www.fedora-commons.org/confluence/display/DEV/Fedora_Enhanced_Security_Layer_FESL_Requirements>) could replace/be integrated with eSciDoc would be sensible. In adidtion, single sign-on is very relevant for us due to the multiple PubMan instances (one for AWI objects and other for IODP objects). To give a concrete example for the need of a separated role and policy enforcement concept: someone may have a curator/moderator role in the AWI repository while in the IODP repository the same person may only have a creator role.
- Flexible schema/"profile"
- Motivation: the simple addition of a new type of suplementary material as externally referenced datastream (e.g. for the sake of inserting a locator for a dataset associated with a given publication) is not enough for us. We need to be able to specifiy the "genre" of the suplementary material (another publication object like a "parent" publication, a primary dataset, an event/campaign/expedition, etc) and its relationship (ontology) with the publication object. In additonal, we would also like to treat publications as geo-referenced objects and thus need a customized schema for the purpose of entering boundaring boxes, geographic region, etc. Considerations like generic schema validation during ingestion (including checks on mandatory fields) are also relevant for us.
- User-friendly ingestion and searching
- Motivation: we find it would be helpful to use the lucene indeces for autocompletion in the ingestion forms(specially with identifiers and title fields so as to avoid the insertion of duplicates, as example) and naturally helpful in the searching purposes. It is not clear to me whether this (together with other goodies like solr support to facet search) could be built as a general functionality within PubMan or to be seen as a do-it-yourself with your preferred ajax framework. It is important to point out that it is crucial for us the lucene indeces from the various PubMan instances are separated from each other. In other words, in the frontend of the AWI repository, we want to be able to use only the lucene indeces associated with the AWI repository for the autocompletion (as opposed to seing all indeces, including the ones from the IODP repository).