Implement AgentRelationship & AgentRelationshipRole classes: zomes + resolvers + tests

[Connoropolous]

All of this should simply be added to the agent Dna

https://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/blob/sprout/lib/schemas/agent.gql#L104-125

• add AgentRelationship zome, including index
• add AgentRelationshipRole zome, including index
• add all the graphql stuff in modules/vf-graphql-holochain that is outlined below
• add tests under test/agent

Don't do: AgentRelationship.inScopeOf that can be done in #297

Graphql

queries

• agentRelationship
• agentRelationships
• agentRelationshipRole
• agentRelationshipRoles

mutations

• createAgentRelationship
• updateAgentRelationship
• deleteAgentRelationship
• createAgentRelationshipRole
• updateAgentRelationshipRole
• deleteAgentRelationshipRole

edge resolvers

• AgentRelationship.subject
• AgentRelationship.object
• AgentRelationship.relationship
• Agent.relationships (union of AgentRelationship.subject and AgentRelationship.object)
• Agent.relationshipsAsSubject (inverse of AgentRelationship.subject)
• Agent.relationshipsAsObject (inverse of AgentRelationship.object)
• AgentRelationshipRole.agentRelationships (inverse of AgentRelationship.relationship)

[Connoropolous]

hi @pospi and @fosterlynn I have defined a scope of work for AgentRelationship and AgentRelationshipRole here.

It looked pretty clear, but I have one question:

how does this Agent.roles work? It's signature looks a little outdated
https://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/blob/sprout/lib/schemas/agent.gql#L99

[pospi]

I think it's just meant to list all the roles that have been assigned as relationships to that agent. But it might not be that necessary for an MVP, I struggle to think of cases where this is useful whilst querying the relationships of an Agent is obviously an important thing.

[fosterlynn]

how does this Agent.roles work?

I struggle to think of cases where this is useful whilst querying the relationships of an Agent is obviously an important thing

Yeah, can't even remember why that might be particularly useful. I would take it out of MMR or maybe out of hREA.

[pospi]

I guess it may be useful to know "in what types of roles does this entity participate"?

[fosterlynn]

I guess it may be useful to know "in what types of roles does this entity participate"?

We can wait to find out if anyone needs it, there are lots of unimplemented and probably-never-to-be-implemented queries. Just imo.

[fosterlynn]

I want to describe what RoleBehavior is for, so you can decide if you want to leave it out or add it back in.

Since the AgentRelationshipRoles are totally user defined, it is helpful for UI apps to have an understanding of what roles go where in an app. Like these roles are all members, or these are suppliers, or these are parts of the organization. Of course, these apps can also check the roles explicitly, but then it works only for that network or organization.

If you decide to use RoleBehavior, we'll need to make a more complete and better thought through list and update the VF vocab.

[pospi]

I'm mostly avoiding it and leaving it out, since it is such an unstable part of the spec. I would rather domain-specific app logic is dealing with conditions based on AgentRelationshipRole for now, and could be updated later if those checks ever become too complicated or verbose.