erights module - fieldmuseum/EMu-Documentation GitHub Wiki

FAQ | Q&A | ISSUES | LUTS | data cleanup | Workflows

What does an erights record represent?

A Rights record represents the legal or ethical documentation related to a given set of museum work or collections. For help with legal terms, consider this help doc. A rights record can represent one of the following:

  • Duty of Care - Information, possibly based on traditional or community knowledge, submitted to the Museum by makers, lineal descendants, or communities of origin regarding the Museum’s care of human remains and collection items. Care includes, but is not limited to, appropriate storage, treatment, handling, exhibition, access, and research (acquisition or preservation of information). For NAGPRA-eligible human remains and cultural items, the Museum must make a reasonable and good faith effort to incorporate and accommodate information regarding storage, treatment, and handling; and must obtain free, prior, and informed consent for exhibition, access, and research. notes
  • An Agreement - an MOU or non-copyright agreement
  • That something is copyrighted by someone, and accompanied by a usage-license including non-exclusive licenses. (e.g. irn 46 for “(c) Field Museum - CC BY-NC”)
  • A Permit - for permits that accompany transactions, exhibitions, projects, etc. (e.g., irn’s 678 - 699)
  • That something is Public Domain - for records in the public domain/not under copyright
  • Restrictions - to document cultural or other restrictions or specify internal use only.
  • TK Label - Traditional Knowledge Labels.

A Rights Template - is used for generating one of the other types of Rights records specified above.

Examples of Permission Types (for Permits & Agreements):

  • Collecting Permit
  • Contract
  • Controlled Permit
  • Copyright License
  • Import/Export/Transport Permit
  • MOU
  • MTA
  • Operator License
  • Possession Permit
  • Restricted Collecting Permit

Current Sub class Status

Subclassed?: Yes

Tab Switching:

  • Column Name: RigType
  • Lookup List: Rights Type
  • Tab switching: Yes

Record Types:

Agreement

  • an MOU or non-copyright agreement

Copyright

  • copyright accompanied by a license including non-exclusive licenses. (e.g. irn 46 for “(c) Field Museum - CC BY-NC”)

Permit

  • for permits that accompany transactions, exhibitions, projects, etc. (e.g., irn’s 678 - 699)

Public Domain

  • for records in the public domain/not under copyright

Restrictions

  • to document cultural or other restrictions or specify internal use only.

TK Label

  • Traditional Knowledge Labels.

Record Structure:

Flat. (There are no attachments to records of the same module.)

Fields

Mandatory

Unique

Ditto Skip

Insert Defaults

Query Defaults

Software Dependencies

Resources -> Tools

  • NONE

Summary String(s)

Default

[RigType] + RigOwner.NamFullName + ” - ” + RigOtherNumber + Year from RigDate

e.g. (irn 224):  [Public Domain] - URL

Rights Type (RigType)

= Copyright

“(c)” + RigOwner.NamFullName + “ - “ + RigOtherNumber + Year from RigDate

e.g. (irn 47):  (c) Field Museum of Natural History - CC BY-NC-SA

= Permit

[RigType] + “ - “ + [new Permit Title field] + “ : “ + “ : “ RigCommencementDate] + (if RigExpiryDate not null) “ - ” + RigExpiryDate

e.g. (irn 682):  [Permit] - Title : ( - 31 Dec 2015)

STRUCTURAL CHANGES: Rationale

Reason(s) for Change Request Community-wide consolidation

Status

  • Version v10+
  • Funded - [Axiell]
  • Axiell Community Engagement Working Group

Details

Collaborative proposal for changes to the Rights module to document community instructions for collections care

Multiple institutions have expanded how we can use the Rights module to detail instructions from community members for appropriate care for collections. Functionality in the Rights module lends itself well to being attached to one or many records, and for triggering icons that can alert users to potential issues.

We are requesting that the following changes be made available to all EMu clients. Our intention is for these changes to be generally additive and provided easily “out-of-the-box” for most users who have not majorly customized the module already.

Reason(s) for Change Request version 2(https://docs.google.com/document/d/1A9lYT0FQH7PJCzlzhwJbvjOK9Vu1RHx1NNd7Yx64sMY)]

Status

  • Version 5.1
  • Funded - [In live]
  • FMNH Specific customisation

Details

  • Minor tweaks and tidy up of tabs to streamline the module