POC: Register DetailedCircuit / Simulation

[joni-herttuainen]

Proof-of-Concept of how registering could work.

• Currently data passed as yaml/json files, should also add cfg format
• Idea is that the parts resource should be already registered and passed only as IDs
• Simulation and DetailedCircuit cases work
  • Similarity to other circuit/simulation is based on checking on config files
  • AnalysisClasses need further inspection on my part
  • should likely register the main Analysis class and it's derivatives (AnalysisReport, ...)
• Most of the core functionality implemented in a common abstract class
• Left bunch of comments on ideas/questions/improvements
• added a default_parameters.yaml
  • idea is to define default entities ('species', 'brainRegion', etc.) here
  • Currently more like a collection of different entity types' definitions

[joni-herttuainen]

@jdcourcol , @mgeplf , @eleftherioszisis

[mgeplf]

Direction looks good so far.

I think there are two things that need to be figured out: 1) How we 'upload' files: ie, the 3 (!?) ways to add files: attaching/distribution/linking I'm thinking something like:

     foo: "$distribute -> $path/to/file"
     bar: "$link -> $path/to/file"

2) How we reference cross things - ie: can we generate whatever the KG needs such that we can do something like:

      baz: $some-nexus-id

[mgeplf]

Other thing I forgot to mention, but it would be nice if we could pull info about the schemas, but that's a strech goal for now.

[joni-herttuainen]

@GianlucaFicarelli , this is the POC

[eleftherioszisis]

Direction looks good so far.

I think there are two things that need to be figured out:

1. How we 'upload' files: ie, the 3 (!?) ways to add files: attaching/distribution/linking
   I'm thinking something like:

   foo: "$distribute -> $path/to/file"
   bar: "$link -> $path/to/file"

2. How we reference cross things - ie: can we generate whatever the KG needs such that we can do something like:
   ```
      baz: $some-nexus-id
   ```

Adding a distribution uses the same functionality as attaching a file in forge: https://github.com/BlueBrain/nexus-forge/blob/3af1de0f9772f088d7293641a40f57a9dc529602/kgforge/specializations/resources/datasets.py#L48-L52

Cross-referencing things is a bit of a mystery to me. If the resolvers are going to resolve an ontological id (e.g brain region or species) to the correct resource, then in principle adding a resource with just the id should create the correct cross-reference.

[joni-herttuainen]

After a bunch of trial and errors, I think we're finally getting there. I think modeling the data with pydantic really is the key here both clarity and functionality wise.

Please take a look at the last commit's additions and comments further describing the idea. If no objections, I'll take another look after the vacation when I'm a little less fever delirious and if it still makes sense, I'll add rest of the functionality. Then we'll have properly working examples of successful and successful registrations with different data types that should be way cleaner than the previous implementation was.