Difference between revisions of "PubMan Func Spec Feeding local webpages"

From MPDLMediaWiki
Jump to navigation Jump to search
 
(26 intermediate revisions by 11 users not shown)
Line 1: Line 1:
{{PubMan_Funtional_Specification}}
{{PubMan_Funtional_Specification}}


==General Scenario==
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.
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.
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==
==Use case Early Adopter MPI Psycholinguistics==
Based on requirements for the Early Adopter MPI-PL, for downloading PubMan data to their local CMS ([http://plone.org/ PLONE CMS] based on ZOPE).  
This use case is based on the requirements of the Early Adopter MPI-PL, for downloading PubMan data to their local CMS ([http://plone.org/ PLONE CMS] based on ZOPE).  


PubMan has to provide adequate interface and deliver the relevant record in the output format needed.
PubMan has to provide adequate interface and deliver the relevant record in the output format needed.
Line 12: Line 11:
The interface to PLONE is provided by the institute.  
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 [https://zim01.gwdg.de/repos/smc/tags/public/PubMan/pubman_contenttypesforwebsite_040208-_forMPDLandZest.pdf here] (provided by Jos van Berkum)
An initial specification for the output needed, as well as first presentation of their local web pages structure and content, can be found [https://subversion.mpdl.mpg.de/repos/smc/tags/public/PubMan/pubman_contenttypesforwebsite_040208-_forMPDLandZest.pdf here] (provided by Jos van Berkum)


Mappping for MPI-PL can be found  
Mappping for MPI-PL can be found  
[https://zim01.gwdg.de/repos/smc/tags/public/PubMan/mapping_pub_status_mpipl.doc here.]
[https://subversion.mpdl.mpg.de/repos/smc/tags/public/PubMan/mapping_pub_status_mpipl.doc here.]


===Feed PubMan items into local website - basics===
===Feed PubMan items into local website - basics===
Line 33: Line 32:
'''Output''':
'''Output''':
* List of items (items.xsd), plus an additional element (dcterms:bibilographicCitation) including the citation in [http://library.osu.edu/sites/guides/apagd.php APA style]
* List of items (items.xsd), plus an additional element (dcterms:bibilographicCitation) including the citation in [http://library.osu.edu/sites/guides/apagd.php 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 | PubMan File Properties, Locator]])
* 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 | PubMan File Properties, Locator]])
*No sorting/grouping needed on PubMan side. Grouping of items (expand/collapse) will be done on Plone side.
*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.  
*Configuration of Jasper report needed => citation style output should be pure html, without style classes.  


Line 44: Line 48:


'''Related pages''':
'''Related pages''':
*[[ESciDoc_Services_Search%26Export | Search&Export Interface]]
*[[PubMan_Func_Spec_Export/APA| Rules for APA citation ]]


[[PubMan_Feeding_local_webpages/Search_and_Output | Search and Output Interface]]


[[PubMan_Feeding_local_webpages/APA_citation | Rules for APA citation ]]
----
===Local tags===
===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.  
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'''
'''Status: implemented'''


'''Schedule: R4'''
'''Schedule: R4'''


====Requirements====
====Requirements====
Please use the [[talk:PubMan_Feeding_local_webpages|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.
*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 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.  
*Local tags are freely chosen 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)(???)
*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 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 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 have to be indexed to be searchable via Search&Export Interface
*Local tags will be added/edited only on PubMan (???)
*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.
*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====
====Assumptions====
*using the dc:subject metadata is not useful, as it is used for clear content-specific classifications/keywords.
*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.
*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  
 
====Solution proposal====
Please use the [[talk:PubMan_Feeding_local_webpages|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:  
*Consequences if item properties are used:  
**Properties are indexed, are therefore searchable
**Properties are indexed, and therefore can be searched for <br>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.)
**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) <br> 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
**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)
**Item properties can be displayed to any user (or restricted to users with editing privileges, if needed).<br>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. <br>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===
===Future requirements===
*Evaluation of PubMan solution for activity tracking/institutional memory aspects
*Evaluation of PubMan solution for activity tracking/institutional memory aspects
**Definition new genres "events", "press", "awards", "honors"("Software")
**Definition new genres "events", "press", "awards", "honors"("Software")
**Definition of "institutional memory assets" = activities (e.g. membership editoria board, events organized, awards received)
**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
**PubMan application profile OR new application profile OR new solution
**Create suitable Demo-collections for new genres_escidoc
**Create suitable Demo-collections for new genres_escidoc
Line 87: Line 103:




 
[[Category:PubMan_Functional_Specification|Feeding_local_webpages]]
 
[[Category:PubMan|Feeding_local_webpages]]
[[Category:Functional_specification]]

Latest revision as of 10:37, 25 April 2012

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)