types of relationships

[ahdinosaur]

TODO: classify types of relationships

• unidirectional (followership)
• bidirectional (stewardship)
• multi-directional
• hierarchical (employership?)
• multi-level (various levels of membership, e.g. contributor / member)

[bhaugen]

Some bidirectional roles are symmetric (that is, the same on both ends, like friend or sibling).

Some are reciprocal but asymmetric (different on each end, like customer-supplier).

(P.S. @ahdinosaur I think I understand what you mean by multi-level, but fleshing it out with some more detailed examples and how the levels relate to the relationships would clarify.)

[fosterlynn]

Here are some relationship types that people have implemented in NRP, so we have something concrete to think about:

Sensorica:
-Exchange Firm
-Affiliate (used to be Member, they decided to loosen the concept)
-Supplier (note we have an open issue with Supplier and Customer being separate roles, while they really are different directions of the same role)
-Customer
-Child
-Custodian

DHEN:
-Member
-Responsibility
-Owner
-Admin
-Advisor
-Supplier
-Drying Site
-Storage Site
-Harvesting Site
-Trainer
-Harvester
-Customer
-Child

TIP:
-Observer
-Coordinator
-Sponsor
-Customer
-Supplier
-Member
-Child

GNLU (very much in process, org being set up now):
-Promoter
-Customer
-Supplier
-Member
-Coordinator
-Class Participant
-Moderator
-Child

[fosterlynn]

And (feel free to correct!), from Holodex:
-Member
-Steward
-Mentor

[ahdinosaur]

(P.S. @ahdinosaur I think I understand what you mean by multi-level, but fleshing it out with some more detailed examples and how the levels relate to the relationships would clarify.)

by multi-level relationship i mean relationship types that derive from a parent relationship type. for example, our membership system within Enspiral (and also within the Enspiral Craftworks team) has multiple levels of membership, namely "contributor" and "member". contributors participate in the group, members are the core locus of power within the group.

[fosterlynn]

@ahdinosaur What are some examples of multi-directional relationships?

[fosterlynn]

@ahdinosaur If we include some type of relationship of relationships (you mention parent) so you can see that multi-level relationships are related to each other in some way, how would you want to define that relationship? I'm mostly asking how would you use the information, what do you need to know and why? For example do you need to know that members are the core and contributors are outside of that?

[fosterlynn]

Taking our known list of relationship types and analyzing them to see how they shake out... conclusions in a separate post...

key:
O-O: organization related to organization
P-O: person related to organization
A-O: any agent related to organization
P-P: person related to person
CA: context agent needed in addition to the 2 sides of the relationship (if no CA, basically means that one side of the relationship, in my notation the second side, is the CA)

-Exchange Firm - O-O, no CA
-Affiliate - P-O, no CA
-Supplier - A-O, no CA
-Customer - A-O, no CA
-Child - O-O, no CA
-Custodian - O-O, no CA
-Member - A-O, no CA
-Responsibility - A-A, CA
-Owner - A-O, CA (this example is owner of a business or farm external to the network CA)
-Admin - P-O, no CA
-Advisor - P-O, no CA
-Drying Site - O-O, no CA
-Storage Site - O-O, no CA
-Harvesting Site - O-O, no CA
-Trainer - P-O, no CA (in this case, but could be P-P CA)
-Harvester - P-O, no CA
-Observer - don't know
-Coordinator - P-O, no CA
-Sponsor - A-O, no CA
-Member - P-O, no CA
-Promoter - P-O, no CA
-Class Participant - P-O, no CA (or doesn't have an agent relationship at all perhaps?)
-Moderator - P-O, no CA
-Steward - P-P, CA
-Mentor - P-P, CA

[fosterlynn]

Some thoughts from the above:

• All of our examples are bidirectional, although follower is definitely something we would want to support (unidirectional).
• Most of what we have has the context agent (or group in Holodex) as one of the agents in the relationship. But some do not.
• Multi-level we can support with a recursive "parent" relationship.
• I wonder if we want to separate out the parent-child (hierarchical) relationship? This would match the org: vocab. However, Custodian and Exchange Firm are similar in some ways, like both sides tend to be context agents just like parent-child networks/projects/companies.

[ahdinosaur]

relevant work in 'activitystreams' spec: w3c/activitystreams#180.

[ahdinosaur]

based on this comment and the emergence of relationships in the activity streams spec, i'm feeling more and more that we should throw out our current vocab of roles + relationships and instead move to relationships being more like graph links, similar to the vocab of when we started Holodex.

such as:

'@id': relationshipTypes/is-member-of
'@type': RelationshipType
obverse: relationshipTypes/has-member
labels: "{subject} is member of {object}"
queryLabels: "People in {subject},Groups that include {object}"

'@id': relationships/mikey-is-member-of-craftworks
'@type': Relationship
subject: people/mikey
relationship: relationshipTypes/is-member-of
object: groups/craftworks
obverse: relationships/craftworks-has-member-mikey
status: statuses/participating-craftworker
context: null

thrown in there is the idea that it would be useful to have relationship statuses similar to facets.

[bhaugen]

I put this comment in the wrong place originally. I think this is the right place. Sorry for the dup.

Re data structures: I don't agree with the comment above.

We spend a lot of time on them, but they are not the classic computer science structures that that comment is complaining about, they are semantic models, and we find them to be very important. I spent a year (1996) researching models for economic networks before arriving at REA, which was not even designed as an economic network model. I could go into all of the ins and outs of all the models I evaluated, but the short version was that REA was the only model that could correctly handle the interconnecting flows of all resources in all directions. And so far, it (with some extensions) has handled all of the crazy situations we've seen in several different co-op and alternative-economy experiments.

Likewise, Lynn spent a long time on her model for value equations (stealing an idea from Cobudget in the process). It's been really flexible so far, handling everything anybody wanted to throw at it. It's just:

• ValueEquation
  • Bucket
    • Rule

but those are the right structures in the right relationships to handle a lot of equations.

I am not totally sure where you are going with "we should throw out our current vocab of roles + relationships and instead move to relationships being more like graph links, similar to the vocab of when we started Holodex". We don't use roles and linkTypes as you've defined them, but need qualified relationshipTypes. We're thinking about roles and links and have been willing to follow you down that path to see how it works out.

But we think there are sweet spots in model design between too general (it's just a graph link) and too particular (it's a harvester for rose petals).

Lynn may have more to say, she is our model creator. I just know good models when I see them.

[fosterlynn]

@ahdinosaur I will study the AS spec today and respond later. This is a great time to revisit the vocab while you are in the thick of it! Note the vocab can influence your internal model or not, as long as you can generate the vocab from it.

I think Mikey you are saying that separating out the roles and links might be overkill. I agree with that. @bhaugen I don't think Mikey is saying to revert to a very generic graph model. Anyhow, I promise more later...

[fosterlynn]

@ahdinosaur

I like the AS spec for Relationship well enough. I like that it has the facility to quality the relationship with what you want, like with start date or status or context agent. One question I have is can we use anything for the relationship: ? Like we want to use a RelationshipType, others may not. It sounds like we could use a class (subclass) or a property or whatever we like, just so we define it in the context. So we could use something already defined in another vocabulary, or something defined by us, or something defined by our users. But I'm still not totally sure if that is how this stuff works. I probably need to do a review of my Working Ontologist book. 😄

Re. RelationshipType: I could give up the name as part of the vocab itself. Maybe the name and description become part of the vocab definition for the namespace and get blown out to a webpage that defines the vocabulary?

Another thing we need to make sure we have is that a relationship can be between persons and/or organizations. AS says "individuals" but then gives an example of person member of group. (In general, I'd like the AS spec to be a bit more careful and clear in its terminology and definitions, but I'm sure there is a history there...)

So short answer: I like it, let's pursue and see if we can get it completely defined. Your example was a very good start. I think the roles and links are too much normalization.

Then I'd like to run it by elf and the PLP gang, and maybe the w3c. It sure would be good to get some level of closure. As in closure for now kind of thing. 😄 But we don't have to wait for that, let's move!

I assume you are thinking this for your data store too. I'll wait on generating csv data for holodex.

[fosterlynn]

@ahdinosaur P.S. Another thing I don't like about the AS Relationship is that it inherits from AS Object, which is way too narrowly defined for us. Like it has bcc and cc as properties! It comes from the narrower scope of activity streams, which is way narrower than our agent relationships. I've noticed this before about the vocabularies that are out there - there is a tendency to start narrowly but then realize there are more universal concepts they need to represent, and to stuff those in. In fairness, there is lots of history and consensus creation and other reasons these things happen.

I don't think this is a reason to not move in the direction you suggest, and we could go ahead and use the AS Relationship or do a short broader exploration to see if there is something better defined when we actually get to the vocabulary. Don't need any of this to do our interface though, so nailing down the exact vocab references can proceed in parallel.

[bhaugen]

@fosterlynn - who, in practice, does not use something like RelationshipType? Do they just say, these (whatevers) are related in some generic unqualified way and that's it? Or do they assume "friend"? Or do they use something on the relationship that might say something about the nature of the relationship but it is not a type? That is, it's free-form, like a string: you can't reliably find a collection of instances of that kind of relationship because many will be spelled differently. Like free-form tags, where you could generate a tag cloud, but you'd have a lot of variations that probably wanted to be the same. Or what?

[fosterlynn]

@bhaugen True, most people use something like a Relationship Type. (But yes, sometimes it is just a string with no reference elsewhere. I've not seen an unnamed relationship that I can think of.)

Below is an example from AS, that refers to http://vocab.org/relationship/.html, where there is nothing more than a definition, so it is really more like a Relationship Type than the people who use subclasses. We could easily create such a vocabulary from our data and refer to it as they do below.

"@type": "Relationship",
"subject": {
"@type": "Person",
"displayName": "Sally"
},
"relationship": "http://purl.org/vocab/relationship/closeFriendOf",
"object": {
"@type": "Person",
"displayName": "Joe"
}

[almereyda]

We have moved the ValueFlows organization from GitHub to https://lab.allmende.io/valueflows.

This issue has been closed here, and all further discussion on this issue can be done at

https://lab.allmende.io/valueflows/agent/-/issues/2.

If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there.