adr for conceptual view

[JimFuller-RedHat]

Rendered version: https://github.com/trustification/trustify/blob/adr-analysis-conceptual/docs/adrs/00002-analysis-graph.md

[chirino]

I like it. We should consider if there are better terms to use than ancestor and descendant as these could get associated with the AncestorOf relationship. Maybe:

• relationship - reverse-relationship
• forward - reverse
• normal and inverse

If the ancestor and descendant fields found in the response are optional then the same return type can be used for all these API endpoints. If that's the case then I think we could consolidate to a single api/v2/analysis/relationships endpoint if it accepts arg filters like:

• ancestors bool
• descendants bool
• depth: int
• realtionshipType: string

[JimFuller-RedHat]

I like it. We should consider if there are better terms to use than ancestor and descendant as these could get associated with the AncestorOf relationship. Maybe:

* `relationship` - `reverse-relationship`

* `forward` - `reverse`

* `normal` and `inverse`

In the graph world this conversation comes up regularly ... I always settle on anc/desc (for DAG) as most people agree what it means.

If the ancestor and descendant fields found in the response are optional then the same return type can be used for all these API endpoints. If that's the case then I think we could consolidate to a single api/v2/analysis/relationships endpoint if it accepts arg filters like:

* ancestors bool

* descendants bool

* depth: int

* realtionshipType: string

I am all for simplifying and/or having less 'moving parts' ... even better when parameterised ... in this case I suggested separation because it was easier to puzzle out ... lets discuss this in meeting.

[ctron]

I like it. We should consider if there are better terms to use than ancestor and descendant as these could get associated with the AncestorOf relationship. Maybe:

* `relationship` - `reverse-relationship`

* `forward` - `reverse`

* `normal` and `inverse`

In the graph world this conversation comes up regularly ... I always settle on anc/desc as most people agree what it means.

If the ancestor and descendant fields found in the response are optional then the same return type can be used for all these API endpoints. If that's the case then I think we could consolidate to a single api/v2/analysis/relationships endpoint if it accepts arg filters like:

* ancestors bool

* descendants bool

* depth: int

* realtionshipType: string

I am all for simplifying and/or having less 'moving parts' ... even better when parameterised ... in this case I suggested separation because it was easier to puzzle out ... lets discuss this in meeting.

Maybe, we can have both? A generalized endpoint, with the options described. And opinionated versions, which simply set defaults.

[ctron]

One idea, when it comes to relationships. Why not use the following serialization:

{
  "sbom_id": "",
  "node_id": "",
  "ancestors": [
    {
      "relationship": "AncestorOf",
      "node": {
         "sbom_id": "",
         "node_id": "",
         …
      }
    }
  ]
}

Taking out the relationship of the actual node data.

IMO, this would separate the node from the relationship and might it a bit clearer when to expect which fields.

One alternative to this could be to have all relationships group in a map:

{
   "node_id": "",
   "ancestors": {
     "AncestorOf": [
       { "node_id": "anc1", … }
       { "node_id": "anc2", … }
      ]
   }
}

[JimFuller-RedHat]

One idea, when it comes to relationships. Why not use the following serialization:

I can see why this might be useful, though it also complexifies things - for what significant benefit ? if we can have a response payload that is amenable directly to visualisation I think that is the best goal to drive towards.

The biggest/last issue we need to define is conceptual view relationships - will try to get something proposed there before our meeting today.

[JimFuller-RedHat]

@chirino, @ctron and @jcrossley3 please re review