Hardcode fdo profiles

[southeo]

Breaking changes! Need to see following PRs:

• Specimen Processor
• Annotation Processor
• Media Processor
• Orchestration Service

Purpose of this PR: to hardcode the names of the digital object types (PIDs) so we don't have to resolve them. And then some refactoring

Properties file or enum?

Originally, we discussed putting these type names and pids in a properties file that could be overwritten. Instead, I put the fields in a hardcoded enum because:

1. By having an enum, we can more easily couple type names and pids in one object. e.g. FdoType.ANNOTATION contains the name "Annotation" and its pid in one object. Handy.
2. Injecting a properties file in the enum was messy
3. Overwriting the type names/pids in application.properties might not be a good idea. if these object types' names or pids change, we shouldn't have the old values in the code at all.

Why do some of the digital object names have capitals or spaces?

Yeah that's the name of the object when you resolve it, so I went with that. It's not a consistent pattern, but it seems to be unchangeable. Hopefully we can fix this when we move to production epic.

Changes to the request objects

Here's what the requests used to look like:

{
  "data": {
      "type":"digitalSpecimen", 
      "attributes": { 
         "digitalObjectType":"https://dtr-test.pidconsortium.net/objects/21.T11148/894b1e6cad57e921764e",
         "fdoProfile":"same as above..."
         "other attribute": "..."
     }
  }
}

It's redundant to have "type" on the higher level, then "digitalObjectType" in the request attributes. Now "type" will only accept the PID of the request type, and the field "digitalObjectType" is no longer accepted in the attribute body.

I also removed the "fdoProfile" attribute from the request. This is because the profile is determined by the Type. The processing services/other clients shouldn't need to provide this redundant info. Currently, the same PID is used for profiles and Types. We don't have separate pids for these yet. I will make separate entries in the type registry after we discuss with ePIC.

Obviously, these are breaking changes, and the processors are updated accordingly.

Changed request now looks like:

{
  "data": {
      "type":"https://hdl.handle.net/10.500....", 
      "attributes": { 
         "digitalObjectType":"https://dtr-test.pidconsortium.net/objects/21.T11148/894b1e6cad57e921764e",
         "other attribute": "..."
     }
  }
}

Other changes

• Refactored the tests a bit.

• "referentType" in DOIs and its inheritors is still poorly defined. The definition I have right now is:

A generic name for the type of object that the DOI refers to. This is different from digitalObjectType that points to a specific type, e.g. there can be different types of digital specimens that each have a slightly different metadata schema because they describe a different kind of specimen, like a botanical versus a geological specimen.

Anyway, there's no mapping for that term, so we just use digitalObjectName right now.

• removed unused classes and redundant functions
• aligned media object fdo profile with what is in opends

[samleeflang]

Looks good, no big things, just a couple of questions.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
2 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud