Deprecate rightsHolder

[peterdesmet]

We currently have:

• rightsHolder: Person or organization owning the rights over the Data Package.
• organizations: List of organizations related to the Data Package.

I think we need to be more clear on these terms to facilitate mapping of

dcterms: rightsHolder (of dataset)

A person or organization owning or managing rights over the resource.

This maps well to camtrap:rightsHolder

dwc: institutionCode (of dataset)

The name (or acronym) in use by the institution having custody of the object(s) or information referred to in the record.

Would this be camtrap:rightsHolder or the first camtrap:organization?

ac: creator (of media file)

The person or organization responsible for creating the media resource. See also http://rs.tdwg.org/ac/doc/termlist/#dc_creator

Would this be camtrap:rightsHolder or the first camtrap:organization or something else? Note it is not one of the camtrap:contributors with a role creator, because that role is not supported.

ac: providerLiteral (of media file)

Person or organization responsible for presenting the media resource. If no separate Metadata Provider is given, this also attributes the metadata. See also http://rs.tdwg.org/ac/doc/termlist/#ac_providerLiteral

Would this be the camtrap:rightsHolder or the first camtrap:organization or something else?

ac: owner (of media file)

A list of the names of the owners of the copyright. 'Unknown' is an acceptable value, but 'Public Domain' is not. See also http://rs.tdwg.org/ac/doc/termlist/#xmpRights_Owner

This maps well to camtrap:rightsHolder

I suggest to

• Assign roles to organizations
• Map owner role to rightsHolder (rights) and institutionCode (custody) and media owner (copyright owner)
• Map creator role to ac: creator or default back to owner
• Map publisher role to ac: provider or default back to owner
• In case of multiple owners, creators, providers, use the first listed one. Alternative is concatenating, but that could get messy
• Remove rightsHolder as a separate term

Minimal:

"organizations": [
    {
      "title": "Research Institute for Nature and Forest (INBO)",
      "path": "https://inbo.be",
      "role": "owner"
    }
]

Elaborate;

"organizations": [
    {
      "title": "Research Institute for Nature and Forest (INBO)",
      "path": "https://inbo.be",
      "role": "owner"
    },
    {
      "title": "Natuurpunt", <-- e.g. collected data as part of contract
      "role": "creator"
    },
   {
      "title": "Wagening University", <-- e.g. hosts the files
      "role": "publisher"
    }
  ],

What do you think @baskaufs @tucotuco @ben-norton ?

[baskaufs]

This is related to tdwg/ac#173, which is languishing because we couldn't decide what to do about it.

I am going to have to defer on this. I don't know enough about the details of how this works on a practical level to know what's best. @edwbaker opened and commented on the issue I referenced above and may have a clearer understanding.

The "Elaborate:" JSON looks sensible to me, but I'm not sure about the exact mappings. I would note that creator isn't an AC term, it's imported from dc:/dcterms:.

[ben-norton]

I'm speaking mainly from a collections perspective, which is the context from which many of these terms are being adopted.
rightsHolder can be tricky. If you're an institution that is hosting a collection on behalf of someone as a permanent loan (which happens a lot in mineralogy) then you, the institution, would be the creator and rightsHolder of the data, but not the owner of the collection. Camera trap data is obviously a bit different. You would never report the owner of the camera. So I think it's safe to map rightsHolder to owner, but that most likely differs from the original intent of the term.
InstitutionCode - This is another way to represent the name of an organization as it might be used in other identifiers. For example, our institution code is NCSM. All of our collections codes begin with NCSM. This creates a linkage between the two identifiers. This is important for my institution because our acronym differs from the name of the institution in the context of published datasets. Our official acronym in the Research and Collections space is NCSM and our formal institution name is North Carolina Museum of Natural Sciences. The institution code field allows me to make this distinction. I know we are not the only organization that falls into this category. In summary, it enriches the information provided about an organization. Therefore, I don't think either scenario applies (camtrap:rightsHolder or the first camtrap:organization).

[edwbaker]

In my view there is a distinction between provider and publisher - but in this case provider seems appropriate.

[peterdesmet]

Currently the Data Package specs don't allow it, but I would prefer if rightsHolder was a role of a contributor.

[peterdesmet]

Since rightsHolder is not a valid role of contributor, I would be tempted to map any license holders under sources, in which case I could need more than one.

I'm driven to this by the documentation:

use of the “author” property does not imply that that person was the original creator of the data in the data package - merely that they created and/or maintain the data package. It is common for data packages to “package” up data from elsewhere. The original origin of the data can be indicated with the sources property

Ideally I'd like to place license holders under contributor, perhaps with role contributor, but that does seem a bit vague.

Currently, I don't see a clear solution if you are packaging from more than one rightsHolder (eg both institutional and privately owned machine observations during a bioblitz)

Maybe the solution is to split these sets up in seperate datapackages?

Originally posted by @PietrH in #27 (comment)

[peterdesmet]

Discussed with @kbubnicki, once frictionlessdata/datapackage#805 is accepted an rights holder is a valid role for contributors we should deprecated our package$rightsHolder in favour of a contributor with role rights holder.