PubMan File Properties
File/Component properties extend the information stored in the metadata record of the item by some file specific technical and administrative data.
See also: ESciDoc Application Profile File
Content Category for Files[edit]
Type: text (value list)
Mandatory: yes
Application profile metadata uri: http://purl.org/escidoc/metadata/terms/contentcategory
Description: In general, the user needs to tag each attached file as full text, as supplementary material and/or as administrative file. This information will be used, e.g. to decide which files should be included in the full text search, or which files are bound to specific access restrictions. Currently following values are defined for the content category:
full text[edit]
- any fulltext: Text of a publication which won't be submitted for peer-reviewed publications
- pre-print: Pre-peer-review version of an article that is to be submitted for peer-reviewed publication
- post-print: The postprint is the creator's peer-reviewed final draft, accepted for publication
- publisher version: The published version of the article. Regarding the content, the publisher version is identical to the post-print.
Notes/alternatives:
- The above definition is in accordance to the Sherpa recommendation
- The definition does not incorporate all possible nuances, e.g. it does not differ between the publisher's proof copy from the final printed version
- The VERSIONS project toolkit recommends following five terms: draft, submitted version, accepted version, published version, updated version
- Alternatives for "any fulltext": "unrefereed preprint/fulltext", "not peer reviewed", "draft"
- Alternative definition suggested by ePrints: "postprint" may refer either to the author's final, peer-reviewed, accepted draft or to the publisher's PDF.
additional material[edit]
- abstract: Provides only the summary of the article
- table of contents: The overview of the article content
- supplementary material
administrative files[edit]
- copyright transfer agreement
- correspondence
Visibility/Access Level for Files[edit]
Type: text (value list)
Mandatory: yes
Description: Each file uploaded as part of an publication item might have a different copyright situation or target group, e.g. the author might want to share the pdf version with the whole world while the source version should be only accessible to other members of your project group. In addition, the OA community recommends to deposit a post-print version of each publication as soon as the article is accepted for publication because the deposit does not depend on publisher policy, only the access setting does, see ePrints FAQ for self-archiving.
Thus there are very good reasons to restrict the distribution of files on various level.
Currently, only two access levels are defined for files in the eSciDoc framework:
- public: access is free to everybody
- private: access is restricted to selected users, i.e. the owner of the publication item and service administrator
In addition, we consider following two levels might be of interest:
- selected organisational units: access is free to anybody associated with the selected affiliations. This association can come via user account (and at a later stage via IP recognition).
This feature has highest priority to be implemented.
- selected accounts/user groups: might be an abstraction of "private"
Note: This feature should support the scenario of a file access to a user group, which consists of eSciDoc users and/or external co-authors. In this context, we have to find a solution for species "external co-authors". Currently, each registered account user is "beheimatet" at a certain orgunit. If an external co-author is registered as user, belonging to a specific orgunit, he is at the same time able to view *all* files with access level "selected affiliation", and not only the specific file he was co-author of.
Note: We currently only consider visibility levels for components and not for complete items, but this might be changed with future applications
Name[edit]
Type: text
Mandatory: yes
Description: the name of the file including the extension.
Application profile metadata uri: http://purl.org/dc/terms/title
Description[edit]
Type: text
Mandatory: no
Description: A short description of the file
Application profile metadata uri: http://purl.org/dc/terms/description
Identifier[edit]
Type: text
Mandatory: yes
Description: An unique identifier of the file within the system, assigned during creation of item.
Application profile metadata uri: http://purl.org/escidoc/metadata/terms/identifier
PID[edit]
Type: text
Mandatory: no
Description: The persistent identifier of the file if the item is released. Handle prefix +item ID+fileID
Application profile metadata uri: http://purl.org/dc/terms/identifier
Content[edit]
Type: binary
Mandatory: no
Description: The data of the file
Application profile metadata URI: http://purl.org/escidoc/metadata/terms/content
Size[edit]
Type: integer
Mandatory: yes
Description: The size of the file in Bytes. If no content is provided, size is zero.
Application profile metadata uri: http://purl.org/dc/terms/extent
Locator[edit]
Type: URI
Mandatory: no
Description: The external location from which the data of the file can be retrieved.
Application profile metadata uri: http://purl.org/escidoc/metadata/terms/locator
MIME-Type[edit]
Type: text (value list)
Mandatory: no
Description: The MIME-Type of the uploaded format. Valid values see list of Mime types
Application profile metadata uri: http://purl.org/dc/terms/format