PubMan Func Spec Feeding local webpages

PubMan Functional Specification View · Browse Full Submission · Easy Submission Import · Export Quality Assurance · Search Collaboration · Copyright Collection Administration Organizational Unit Management User Management Feeding local webpages History of affiliations edit

General Scenario

To increase acceptance and usage of an institutional archive, local and invidual re-use of submitted data has to be increased. One main benefit for entering and maintaining publication data (in its broadest sense) is to ensure the re-use of data in local CMS and/or individual homepages. Possible re-uses include the feeding of dynamically updated publication lists into local/individual webpages, and re-use for local and individual compilation of specific lists, e.g. manually compiled lists on local webpages, lists for the annual yearbook, Fachbeiratsberichte, etc.

Use case Early Adopter MPI Psycholinguistics

Based on requirements for the Early Adopter MPI-PL, for downloading PubMan data to their local CMS (PLONE CMS based on ZOPE).

PubMan has to provide adequate interface and deliver the relevant record in the output format needed.

The interface to PLONE is provided by the institute.

An initial specification for the output needed, as well as first presentation of their local web pages structure and content, can be found here (provided by Jos van Berkum)

Mappping for MPI-PL can be found here.

Feed PubMan items into local website - basics

Status: implemented

Schedule: R3

Preparations & Agreements:

• Metadata, properties: Agreement on values for "publication status", "genre types", "content categories (i.e. types of full text attached)" (see PubMan File Properties)
• Labeling: Agreement on labeling for genre types
• Organisational units: Agreement on setting up the organisational units

Interface (Searching/Harvesting):

• Plone will upload the whole content nightly. No need to provide bookmarkable search. Indexing is done on Plone-side.
• No dynamic queries, but automatic daily update, optionally update "on demand" from Plone => needs modification of search service to provide output in certain format, e.g. citation style.

Output:

• List of items (items.xsd), plus an additional element (dcterms:bibilographicCitation) including the citation in APA style
• Supplementary material, which is stored on local primary data archive, will be linked from pubman with an external locator. That means, we need to provide on PubMan submission mask the option to upload binary content (=upload file) AND provide external locator for the binary content. The default content category for an external locator will be "supplementary material" and there will be NO visibility level set to an external locator (the user takes the responsibility for the accessibility of the external content). (see PubMan File Properties, Locator)
• No sorting/grouping needed on PubMan side. Grouping of items (expand/collapse) will be done on Plone side.
• Sorting the publications on the website in chronological order
  • in preparation
  • submitted for publication
  • in press
  • published in print
• Configuration of Jasper report needed => citation style output should be pure html, without style classes.

Testing the interface/output:

• should include all org units, different components, external locators, metadata values discussed
• test with revisions => local handling of revisions has to be explained: As no need to retrieve "older" revisions, just the latest valid "revision" of an item, the users should either modify released items or withdraw. Visualisation/support needed.
• testing of possible duplicates. Plone will provide duplicate checking on title base.
• access to org unit handler

Related pages:

Search and Output Interface

Rules for APA citation

Local tags

To be able to select subsets of publications, on criteria that go beyond the current metadata elements/properties, user need to be able to "mark" specific publications for individually created grouping, e.g. "The best of ..." listings. This information, a kind of "selector code", is provided during either submission directly or afterwards, e.g. as part of webmaster activities.

Status: in specification

Schedule: R4

Requirements

• Users with editing privileges can provide and edit local tags, no specific "local tag-editing" privileges are needed.

Rupert: For GUI a small tag management is required then. At least: add/remove tag (one ore more tags at once?) to item.--Rupert 13:29, 21 August 2008 (UTC)

• Local tags can be provided during full submission or as part of the modification of an item.
• Local tags are freely choosen text strings. No controlled vocabulary is necessary.

Rupert: They might soon call for a tag list. Once they start tagging there will be a need to keep track what tags have been given so far. --Rupert 13:29, 21 August 2008 (UTC)

Jacquelijn: I think Rupert is right. So, even though no c.v. is not necessary, we (at institute level) need to think about accepted values for our MPI. Maybe there is a task for the library to check the values of this field, but I do not know how Karin will feel about this!!

• The order of the local tags entered is not relevant.(ie. one or more local tags can be entered in one field, in any order)(???)

Jacquelijn: should there be any agreement on separator? Or is this not necessary since the query will search for a string anyway?

• Local tags can be modified, the history of modifications does not have to be tracked.
• Local tags are provided on item level, not on component(i.e. fulltext) level
• Local tags have to be indexed to be searchable via Search&Output Interface
• Local tags will be added/edited only on PubMan (???)

Jacquelijn: I guess so.

• Local tags are displayed at least to users with editing privileges, on the full item view.

Jacquelijn: I think we agreed that the content of the element would indeed only be visible to users with editing rights, so even when the item is released, the content of the element is not visible for read-only users.

• Restrict searching for local tags on the PubMan Search interface (administrative search) should be possible (???)

Assumptions

• using the dc:subject metadata is not useful, as it is used for clear content-specific classifications/keywords.
• although the scenario tends to be similar to the process of compiling the yearbook, we would like to solve this requirement by a quick and simple solution. The functionality of a catalog, needed for advanced selection, grouping, sorting and publishing of a compilation of items, is scheduled for later releases.

Solution proposal

• to use content model specific properties (i.e. pubitem specific properties) to store local tags such as:
  • local-tag: MyBest
  • local-tag: MyBest, MyRecent
  • local-tag: MyBest, MyAwarded, MyRecent
• Therefore recommendation: even if there is not a controlled vocabulary developed it would be nice to have local (institute-wide) agreement on values of local tags wherever possible. --Natasa 12:10, 21 August 2008 (UTC)

• Consequences if item properties are used:
  • Properties are indexed, are therefore searchable (note: only in case when item is released--Natasa 12:05, 21 August 2008 (UTC))
  • Modifications of properties (i.e. editing local tags) leads to new version of item. Updated items are therefore included in scheduled update of local website (based on system-specific <last modification date> of item.). Note: updated items are included only in case if they are released (i.e. re-released again).--Natasa 12:05, 21 August 2008 (UTC)
  • Local tags are part of regular export of items
  • Item properties can be displayed to any user (or restricted to users with editing privileges, if needed). Note: restricting display of local tags may lead to non-privileged users find accidentaly items that contain same value in local tags, but can not see the local tag. Proposal: to display local tags, but maybe not too prominent on view item to all users. --Natasa 12:05, 21 August 2008 (UTC)

We agree with Natasa's proposal to put the local tags on a not too prominent position. [Karin & Jos, 9 sept. 2008].

Future requirements

• Evaluation of PubMan solution for activity tracking/institutional memory aspects
  • Definition new genres "events", "press", "awards", "honors"("Software")
  • Definition of "institutional memory assets" = activities (e.g. membership editoria board, events organized, awards received)
  • PubMan application profile OR new application profile OR new solution
  • Create suitable Demo-collections for new genres_escidoc
  • see details under PubMan institutional activities
• Definition of local-specific labels and helptexts, incl. administration interface
• Offer catalogs for "manual selected publications" by individuals (including individual grouping and sorting)

Publication Management

Content Management System

Max-Planck-Institut

Graphical User Interface

Coordinated Universal Time