PubMan File Properties

From MPDLMediaWiki
Jump to: navigation, search

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

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

  • 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 PDFPortable Document Format.

additional material

  • abstract: Provides only the summary of the article
  • table of contents: The overview of the article content
  • supplementary material

administrative files

  • copyright transfer agreement
  • correspondence

Visibility/Access Level for Files

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 pdfPortable Document Format version with the whole world while the source version should be only accessible to other members of your project group. In addition, the OAOpen Access 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 eSciDocEnhanced Scientific Documentation 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 IPInternet Protocol 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 eSciDocEnhanced Scientific Documentation 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

Type: text

Mandatory: yes

Description: the name of the file including the extension.

Application profile metadata uri: http://purl.org/dc/terms/title

Description

Type: text

Mandatory: no

Description: A short description of the file

Application profile metadata uri: http://purl.org/dc/terms/description

Identifier

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

PIDPersistent Identifer or Identification

Type: text

Mandatory: no

Description: The persistent identifier of the file if the item is released. Handle prefix +item IDIdentifier+fileID

Application profile metadata uri: http://purl.org/dc/terms/identifier

Content

Type: binary

Mandatory: no

Description: The data of the file

Application profile metadata URIUniform Resource Identifier: http://purl.org/escidoc/metadata/terms/content

Size

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

Type: URIUniform Resource Identifier

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

MIMEMultipurpose Internet Mail Extensions-Type

Type: text (value list)

Mandatory: no

Description: The MIMEMultipurpose Internet Mail Extensions-Type of the uploaded format. Valid values see list of Mime types

Application profile metadata uri: http://purl.org/dc/terms/format