Difference between revisions of "PubMan Func Spec Feeding local webpages"
Line 74: | Line 74: | ||
**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.) | **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.) | ||
**Local tags are part of regular export of items | **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) | |||
===Future requirements=== | ===Future requirements=== |
Revision as of 10:54, 21 August 2008
|
General Scenario[edit]
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[edit]
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[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 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.
- 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: in specification
Schedule: R4
Requirements[edit]
- 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 choosen text strings. No controlled vocabulary is necessary.
- 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)(???)
- 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 (???)
- Local tags are displayed at least to users with editing privileges, on the full item view.
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.
- Proposal to use item properties to store local tags
- Consequences if item properties are used:
- Properties are indexed, are therefore searchable
- 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.)
- 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)
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 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)