I agree with the need of this functionality and that it is best supported by a function in Camtrap DP. The implementation details are to be discussed, but I'd prefer to tackle this after https://github.com/inbo/camtraptor/milestone/3

A logic request, definitely. I agree with @peterdesmet: it's better to add this functionality after the big refactoring.

Just to have an idea (and planning the next analyses) -- what would be the timing for this new feature ?

Agreed with @peterdesmet to add this functionality to v1 and to give it a higher priority.

Suggested in camtraptor July 2023 coding sprint

• Call this function merge()
• Limit it to two packages merge(package, package2) to avoid complex operations, testing and error handling. Users can add additional packages using pipe: package1 %>% merge(package2) %>% merge(package3)

A package that is the result of a merge() #75 should combine its metadata (not sure how)

From #74

I have described the functionality in more detail at tdwg/camtrap-dp#380. I think the function should be called merge_camtrapdp().

Task list by @sannegovaert:

• Deployments: combination of deployments (but check that deploymentID remains unique)
• Media: combination of media (but check that mediaID remains unique)
• Observations: combination of media (but check that observationID remains unique)
• name: a new name is created (old values are not retained)
• id: a new ID is created. The original ids are stored in relatedIdentifiers
• created: reset to current timestamp (old values are not retained)
• title: a new title (old values are not retained)
• contributors: a combination is made, duplicates (on some or all fields) are removed and roles are combined (in Frictionless v2). The order is not retained.
• description: a new one is generated, potentially still listing the previous descriptions
• version: is reset to 1.0 (old values are not retained)
• keywords: a combination is made, duplicates are removed
• image: is removed (old values are not retained)
• homepage: is removed (old values are not retained)
• sources: a combination is made, duplicates are removed
• licenses: a combination is made, duplicates are removed. If e.g. two different license with scope: media are listed, it won't be clear which one applies to which media.
• bibliographicCitation: is removed (old values are not retained)
• project: ideally this becomes an array of projects and deployments have a projectID to link to the correct project info.
• coordinatePrecision: is reset to least precise precision (old values are not retained)
• spatial: is reset based on new deployments (old values are not retained)
• temporal: is reset based on new deployments (old vales are not retained)
• taxonomic: a combination is made, duplicates are removed.
• relatedIdentifiers: a combination is made, duplicates are removed
• references: a combination is made, duplicates are removed

Merge should also handle "additional resources". Currently only the additional resource of x are kept

• Keeping both makes sense, but if they are named the same, we don't know what to do
• Even if we keep them, they might contain identifiers that refer to dep, med, obs which become invalid

I think that the cleanest solution is therefore to remove additional resources, with a warning that lists which ones are removed, see this code to find them:

In the tests, I would remove individuals from x so you don't have to deal with suppressWarnings() all the time.

Could you prompt the user if they are named the same?

As in, ask for a decision? What options do you provide them?

One alternative is to rename the additional resources by prefixes the dataset identifier (cf. the deployments). I would then do this for all resources, so you see where they came from). This doesn't prompt user and shouldn't trigger a warning.

If they are named the same, ask the user to name the tables.

I think there is value in being consistent with the deployments.