PubMan Func Spec Feeding local webpages

From MPDLMediaWiki
Revision as of 10:37, 25 April 2012 by Webers (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
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


To increase acceptance and usage of an institutional archive, local and individual 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[edit]

This use case is based on the requirements of 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[edit]

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 in easy submission, in full submission it can be changed) 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:



Local tags[edit]

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: implemented

Schedule: R4

Requirements[edit]

Please use the talk page for any comment or discussion

  • Users with editing privileges can provide and edit local tags, no specific "local tag-editing" privileges are needed.
  • Local tags can be provided during full submission or as part of the modification of an item.
  • Local tags are freely chosen text strings. No controlled vocabulary is necessary.
  • The order of the local tags entered is not relevant, i.e. one or more local tags can be entered in one field, in any order (???)
  • 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&Export Interface
  • Local tags will be added/edited only on PubMan (???)
  • Local tags are displayed at least to users with editing privileges, on the full item view.
  • Restrict searching for local tags on the PubMan Search interface (administrative search) should be possible (???)

Assumptions[edit]

  • 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[edit]

Please use the talk page for any comment or discussion

  • to use content model specific properties (i.e. item specific properties) to store local tags such as:
    • local-tag: MyBest
    • local-tag: MyBest, MyRecent
    • local-tag: MyBest, MyAwarded, MyRecent
  • 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.
  • Consequences if item properties are used:
    • Properties are indexed, and therefore can be searched for
      Note: only in case when item is released
    • 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)
    • 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 accidentally 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.
    • "Tagging users" require editing privileges for item, see PubMan Collaboration Scenario

Future requirements[edit]

  • 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 editorial 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)