Defining common relationship verbs

[fosterlynn]

Per discussion with @elf-pavlik we are thinking that we should define some core relationship type rdf:Properties. Like "member", .... Then if people want to add more, those can be sub-propertied. This will allow networks to define their own (which they do freely in NRP), as well as allow apps using the data to default to a known property if it matters to them. For example if they need to treat a "member" differently than a "supplier", or whatever we come up with for the core.

What do others think?

Here is an old issue where we discussed this: #2 . I thought there was another one too, but I can't find it. (@ahdinosaur EDIT: we discussed this in #26 as well)

Here is the gitter discussion:

@fosterlynn i commented on your PR looking at Relationship, I think around using role:member, role:mentor, role:steward as value of proposed vf:relationship this pattern very much relates to https://github.com/w3c-social/social-vocab/wiki/Verbs---owl:Class-vs.-rdf:Property and I experiment with it in https://github.com/hackers4peace/plp-test-data/blob/master/w3c-social.jsonld @elf-pavlik are you saying we should have both role and relationship, or use "role" instead of "relationship"? Or was my text confusing around relationship covering both concepts, which are very close? @elf-pavlik I am not trying to go away from using rdf:Property for the logical Relationship Type, just don't know how else to show it on a logical UML diagram I tried to explain that in the verbage I'm fine with it being a property, but still the property has properties..... so to speak my bad: "relationship": "vf:mentor" (I used role:mentor since for now I use https://w3id.org/role/ mapped to that prefix) ah ok

property has properties
let me see examples in your PR...

the properties of the verb are the labels and i think in holodex there are also some query patterns or something like that when i say properties of.... I am speaking logically, just that we need to group the properties, as you did in an example a long time ago... and also in the PR example but those properties stay on vocab level not data expressed with this vocab level oh, i got it when you define you own properties you consider it as part of your data... not part of your extension to the common vocab no well, maybe.... people have to be able to define their own agent subclasses and relationship verbs, true? to my understanding in RDF(S) properties are instances of rdf:Property class yes that is what i mean too so we would have vf:RelationshipType rdfs:subClassOf rdf:Property no need for RelationshipType as I understand it, at least you had persuaded me of that a while ago :smile: although that is a very interesting option!! in your example I see affiliate (looking for more) yes, that is creating new verbs so we provide software to networks and allow them to create their own types of agents and their own relationship verbs, we don't control that and member yes no matter how many verbs we define in our vocab, or other existing vocabs, which have a lot, networks will still want to define their own ~ https://schema.org/member & https://schema.org/affiliation yes, but our software doesn't know that i'm ok with defining or referencing a whole bunch of common verb relationships but still there will be more do you really need those particular ones defined in http://nrp.webfactional.com/accounting/agent-relationship-type/member namespace ? i would suggest picking something very uncommon if you want to put it in some very specific namespace http://nrp.webfactional.com/accounting/agent-relationship-type/my-snowflake-type-of-relationship @elf-pavlik - Lynn and I don't need them, but each network (so far) has been very picky about relationship names, as well as the names of a lot of other things. if you follow the ones i created, the link will work They become moral or religious issues. ha because many apps (eg. holodex) will understand semantics of properties defined in common vocabs eg. member, mentor etc. may need to gracefully degrade in some cases to deal with terms which semantics they don't understand @bhaugen semantics of those relationships or labels which people see in UI? yes, although i think @ahdinosaur is also in the user-defined verbs category (in holodex) one can also define wf:vip-member rdfs:subPropertyOf vf:member this way app can gracefully degrade to consider it a member but not understanding further specification in our app we also have a basic behavior flag (code) which says that kind of thing, because we do have to treat members differently than say suppliers (outside the network) for example. i see no problem with that, just if you don't define your 'user defined' terms as specifications of some common terms, you shouldn't expect apps using them to degrade gracefully, they may just show you the most raw form of data with no UI main benefit of using terms defined in common (shared) vocab comes to shared understanding but in a place like holodex (or NRP), it would want to be able to treat any verb in the same way, true? shouldn't matter if it comes from a stable vocab or some network made up their own I would suggest defining vf:member and you could use it in your system as long as you don't need something with different semantics so, the herbal network we work with uses "harvesting site", "harvester", "drying site", etc @fosterlynn I agree in such generic (very shallow semantics) UI like holodex we can do that yes for herbal network, the names are more practical than religious IMO most challenging part, which requires technological solution and social processes - https://www.w3.org/wiki/Socialwg/Social_syntax/User_Stories#Converging_vocabulary_terms maybe a way to go is for us to define a base set of verbs that exhibit a kind of behavior, and have networks subclass from them, what do you think? :thumbsup: to work on that you could define very generic ones (like member) on level of vf: ha i like "joker" yes over time things can converge and be stabilized and create you own namespace for some wf:snowflake-type-member but in the meantime, we in NRP have to let people define their own, even if it only works in shallow semantics type UIs but we also need our "behavior" flag, so i like defining the base set for that reason quite a lot ok, let's make a use case out of that and for now let's just add examples with wf:member ha u sure, it was good to push that envelope, no? yeah! i'll start an issue tho so you want vf:member to be added to the context? and fix the examples to use that? @fosterlynn let's leave it for later, capturing issue does it for now

[fosterlynn]

Here is a suggested list of fairly standard relationship types, for starters:

• member
• child/parent
• supplier/customer (usually an interface out of the network or group into the existing economy)

[bhaugen]

Thinking about this on our walk: a couple of comments:

Relationships can roughly (with some ragged edge cases) be divided into super-properties like EconomicRelationship, SocialRelationship and FamilyRelationship. (If I got the right "super" term...)

Supplier/customer might be an EconomicRelationship called tradingpartner, where one end is supplier or provider and the other end is customer or recipient.

[elf-pavlik]

@fosterlynn would you like to make PR with some concrete real world examples? I would suggest to keep supplier/customer for next round and start with simpler ones like member, child/parent @bhaugen do you have a concrete real world example where we need it? Unless we have one I would propose to document this thought but start with simpler things which we can back by mentioned examples.

[bhaugen]

Got lots of examples, but I'm not in a hurry. We can wait for the examples to emerge from the actual relationships that Lynn's code will be emitting over time.

[fosterlynn]

@elf-pavlik Yes we don't need customer/supplier (trading partner) now, as long as we are just using ourselves. When we get to the networks using NRP, they will have customer/supplier. We won't need parent/child until we get into layers of network structure. Let's put if off as long as possible. I think right now we can get away with just vf:member.

I will say this is one reason we just let people define their own..... lots of organizational experimenting going on... :)

[fosterlynn]

@elf-pavlik Just to give you an idea, I actually didn't make up "affiliate", that is what Sensorica calls their members, and they actually changed the term a while back because they wanted to convey something slightly different than "member". When I get my jsonld pull working, I'll get out some real examples.

In the meantime, I'll change our examples to all "member".

[elf-pavlik]

@fosterlynn can you please document in .md files all the known variations which you encounter? so member.md could mention affiliate.md and at some point we may decide to give it dedicated vf: property

We will have child/parent examples very soon, If we talk about organizations I would suggest starting with terms which have matches in eg. http://www.w3.org/TR/vocab-org/#org:hasSubOrganization

Workflow focusing on concrete real world examples, which we want to support ASAP can help us with more commits and as many discussions as possible around there (trying to keep tracker focused). Maybe we can have more free form discussions on chat and capture out of it only when we see benefit in documenting it more permanently?

[fosterlynn]

@elf-pavlik I think the examples we encounter are pretty random and subject to change, I'm not sure I would put them in the md file. And really the problem is that we don't want to monitor what people decide to do in NRP, figure out how it should get normalized against what other people are doing, etc. And if we wanted to, it is I think just too early in the development of these economic networks. They don't know or care about LOD. Someday they probably will, when they need to interoperate with other networks. And then a process will need to be set up. And even then, it will probably be between small groups of related networks for a while before it gets to be in the stage of w3c type vetted vocabulary. Thus "relationship types".

Here's a list in this old issue: https://github.com/valueflows/agent/issues/2#issuecomment-78288779 (Two of those networks don't exist any more.)

I think I understand your mindset, which lives in the LOD vocab world, where things including relationships do get defined. And for say the relationship "like" or "follow" it has probably developed to the stage where the vocab can be defined, and people do need to know what it is globally. I think our economic networks are too experimental, with the exception of defining a set of super-properties, and even there we are doing some guessing.

[ahdinosaur]

before reading this, made comments https://github.com/valueflows/agent/pull/40#issuecomment-146714338 and https://github.com/valueflows/agent/commit/99717a62805d2ac45d287ff21cf63a17aa286f0c#commitcomment-13676132, after reading i still feel the same way.

i'm keen with adding a few "standard" relationships like member to our vocab (as per #26), but i don't want this to mean we add special cases for how we represent relationships (as far as i can tell, this new property vf:member introduces a special case), since i feel that goes against our simple abstract model powered by user-defined type objects (in my opinion one of our core design principles).

.

i'd prefer we practice using user-defined types > "standard" types, if anything the "standard" types should be something to subclass from, but your data is losing information by using them directly. said another way, "standard" types are like globalization, "everybody must conform to our singular understanding of the world!", which i'm not keen for, it's better that we all have different names and labels for our own things but they can interoperate.

my understanding for how to define common relationship verbs is how @bhaugen and @fosterlynn did it in their example, except we add this to our base vocabulary context. how @elf-pavlik did it seems to be a different way entirely, which seems to diverge from the Relationship object and RelationshipType object pattern we developed, but please correct me if this is not the case.

to recap, my feelings are:

• :+1: to "standard" types that others can subtype
• :-1: to special cases (there should only be one way to do something, e.g. represent a relationship), users can add their own sugar as they wish but i want to keep the core as minimal, abstract, and powerful as possible
• :-1: to "standard" types being recommended for usage over user-defined types

[fosterlynn]

@ahdinosaur I basically agree with you, and you expressed it well. And I note that my short list of super-properties did not include something that will work for person to person relationships within a network, like steward or mentor. Not sure what that would be?

I'm trying to think if introducing vf:member makes it a special case. It introduces a bit of complexity into the data feeds, in the same way that using existing Agent superclasses does. Although maybe we don't say anything about creating new verb relationship types without sub-propertying them? I would be in favor of letting people have a choice to use them as super-properties or not. Or if people want to define their own "member" that's fine too.

my understanding for how to define common relationship verbs is how @bhaugen and @fosterlynn did it in their example, except we add this to our base vocabulary context. how @elf-pavlik did it seems to be a different way entirely

I don't think these are different methods, they are just different examples. @elf-pavlik was doing the context, so that is where the vf:member labels would live, in our vocab definition. An actual data feed not using vf:member would need to create its own properties the way I did, at least in previous versions of my example. They would look the same, but be in a different place. @elf-pavlik does this make sense to you?

I guess the way I think about it is that we want to support graphs of relationships between agents. I don't think it matters much to us what the relationships are, as long as they can be travelled in a graph, and as long as we have human readable labels so as people track through the linkages, they can see what they are. I don't see we need to support more meta knowledge than that. (Except I do like the sub-propertying since we do need some meta info and there probably are a handful of consistently defined relationship types. But I could live without that too.)

But @elf-pavlik you might disagree, given you have worked in the agent area to more depth? To me the agent piece is a corner of the vocabulary, foundational and necessary to value flows, but not the center of the vocabulary where I think we will be adding real value to the vocab world with processes, exchanges, events, resource flows.

[ahdinosaur]

I don't think these are different methods, they are just different examples

i think they actually are different methods (using member as a property on the Agent object versus using member as the value of the relationship property on the Relationship object), so i'm seeking clarity on whether or not the different methods have the same semantic meaning.

To me the agent piece is a corner of the vocabulary, foundational and necessary to value flows, but not the center of the vocabulary where I think we will be adding real value to the vocab world with processes, exchanges, events, resource flows.

yes, although i want our agent and relationship vocabulary to be as powerful as the NRP data model that attracted me here in the first place, e.g. using type objects consistently throughout the data model to create an abstract vocabulary where it's expected that users define their own semantic meaning within the abstract structure.

[fosterlynn]

@ahdinosaur I'm really glad you appreciate the NRP model, and in fact the agent piece has worked very well for us, the flexibility is quite useful. That is with some additions, like context agent on the relationship, etc..... :smile:

i think they actually are different methods (using member as a property on the Agent object versus using member as the value of the relationship property on the Relationship object

You are right, I missed the property on an Agent, was just looking at the context vs the stuff created from user data.

[fosterlynn]

OK some research:

@elf-pavlik mentioned this: http://www.w3.org/TR/vocab-org/#org:hasSubOrganization, and here's the inverse or reverse: http://www.w3.org/TR/vocab-org/#org:subOrganizationOf.

Thoughts: I like this better than parent/child, which in many vocabularies actually mean a human parent and child. The only trouble is it applies to Organization, which we don't know if we will support or not. And would it apply to other types of agents? Do groups have parent/child relationships? If we want to broaden it beyond Organization, I'd be good with doing our own and naming it something similar to the org name.

http://xmlns.com/foaf/spec/#term_member - Agent is member of Group. Too narrow?

http://d-nb.info/standards/elementset/agrelon.owl#isMemberOf - this vocab pretty obscure

Hmmm, not finding a lot on this. Seems like people just make their lists, I'm not finding much attempt to structure them. There is sub-propertying, but I don't see much that tries to generalize for behavior or some higher level differences, as suggested by @bhaugen above.

This is leading me to think about maybe defining our own super-properties....... ??????

[fosterlynn]

@ahdinosaur question: Can we do this as just an rdf:Property? Holedex has the types of agents for subject, object, and context defined as constraints, I believe. I'm tentatively thinking those don't want to be in the vocab, since mostly the types of relationships will be user defined. So others won't need to implement that as it won't be shared vocab. (Doesn't mean that Holodex doesn't want to define this for themselves!)

Any other properties that we are thinking might need to be there? Or can we just use the directional label for the property, one for each direction?

[ahdinosaur]

org:hasSubOrganization... foaf/spec/#term_member ... Agent is member of Group. Too narrow?

Holodex plans to remove the separation between member and parent / child, since in most literature on holons it's the same relationship type, and that way things are simpler.

Do groups have parent/child relationships? If we want to broaden it beyond Organization

i still don't understand the difference between a group and an organization.

Can we do this as just an rdf:Property?

if by "this" you mean relationship types, yeah i think rdf:Property seems to fit our needs well.

Holedex has the types of agents for subject, object, and context defined as constraints, I believe. I'm tentatively thinking those don't want to be in the vocab, since mostly the types of relationships will be user defined.

we haven't used these constraints yet, mostly just a cool idea so far.

Any other properties that we are thinking might need to be there? Or can we just use the directional label for the property, one for each direction?

we can always add more if we feel it's a good idea.

[fosterlynn]

i still don't understand the difference between a group and an organization.

Well, would you consider Alibaba or your local gas station to be a group? It has to do with the formality and tightness I think. In practice in our networks, organization is mostly used for agents outside the network, like with relationship type supplier.

[ahdinosaur]

cool, that makes sense. back to https://github.com/valueflows/agent/issues/51#issuecomment-149072983, i still feel Organization is a subclass of Group, since the primary behavior of an Organization (having member or parent / child relationships) which makes it different from say Person is also present in Group.

[fosterlynn]

oh yeah, I guess we have strayed..... I'm moving this to #51.

[fosterlynn]

Holodex plans to remove the separation between member and parent / child, since in most literature on holons it's the same relationship type, and that way things are simpler.

Very interesting! I can see it is very similar. Do you have a name or label for that? Or does the literature on holons have one?

One difference: You can be a member of lots of groups, but probably a child of only one parent (in the organizational sense).

[ahdinosaur]

One difference: You can be a member of lots of groups, but probably a child of only one parent (in the organizational sense).

really? i know a few groups (orgs) that have multiple parents, e.g. Cherubi is a pod in both the Enspiral Services and Enspiral Academy communities. also Enspiral ventures can be within other networks if they wish. although i agree there are different flavors of membership, on a spectrum from loose to strict.

Or does the literature on holons have one?

my resources on this material:

• https://blog.dinosaur.is/holon-dynamics/
• https://blog.dinosaur.is/holonic-systems/

which is taken from "Multiagent Robustness: Autonomy vs. Organisation", starting at chapter 6.

[elf-pavlik]

One difference: You can be a member of lots of groups, but probably a child of only one parent (in the organizational sense).

really? i know a few groups (orgs) that have multiple parents, e.g. Cherubi is a pod in both the Enspiral Services and Enspiral Academy communities.

I would consider adding a very generic sub property (same meaning as child) which one can use in reverse direction for 'super' (parent) meaning. We would just need to clarify that we don't build tree structures but graph - so we have many2many sub based relationships.

See also: https://lists.w3.org/Archives/Public/public-vocabs/2015Mar/0182.html ( + replies)

[fosterlynn]

One difference: You can be a member of lots of groups, but probably a child of only one parent (in the organizational sense).

really? i know a few groups (orgs) that have multiple parents, e.g. Cherubi is a pod in both the Enspiral Services and Enspiral Academy communities.

I would consider adding a very generic sub property (same meaning as child) which one can use in reverse direction for 'super' (parent) meaning. We would just need to clarify that we don't build tree structures but graph - so we have many2many sub based relationships.

@ahdinosaur thanks for the example, I get it now I think. Love the organizational experimentation and nuances! And also thanks for the holon links, very interesting! :smile:

@elf-pavlik your suggestion makes sense to me! Naming will be tricky.....

[fosterlynn]

Just thinking out loud, sorry for stream of consciousness:

partOf nodeOf

both are kind of a subOf, but have different meanings to me, although I'm not sure it matters.... maybe partOf will do if it implies the ability to be partOf many agents? I think I like it better than subOf, although I don't know what the inverse is.

supplierOf, customerOf (inverses) tradingPartnerOf doesn't work because the inverse meanings are needed

still nothing coming to me to be a generic of things like mentor or steward... peerOf? not the best...

[ahdinosaur]

Just thinking out loud, sorry for stream of consciousness

yes to stream of consciousness! or at least, i hope y'all realize that's all i ever do. :cat:

[elf-pavlik]

@ahdinosaur how do you plan to describe (ownership) transfers (later also part of exchanges) without shared concept of 'owner' based relation between Agent and Resource? https://github.com/valueflows/valueflows/pull/65 eg. schema:owns or role:owns or anything other than trying to handle it with all kind of: snowflake:claimsRightsInSomeVeryVeryUniqueWayFromSomeSuperSubjectivePerspective

[ahdinosaur]

how do you plan to describe (ownership) transfers (later also part of exchanges) without shared concept

the event / exchange types needs to be shared amongst the agents involved, but no more. i see local vocabulary based on subjective perspective as something to embrace not extinguish. if some local vocabulary happen to be really successful, then an agent can host them for external agents to use, as we're trying to do more of within Enspiral.

[elf-pavlik]

the event / exchange types needs to be shared amongst the agents involved, but no more. i see local vocabulary based on subjective perspective as something to embrace not extinguish.

I don't talk about some more specific types of events, transfers or exchanges!

If we define vf:Transfer (not the physical one - sth:Transport) as "An vf:Agent (individual or group), who have ownership over a resource, passes this ownership onto another agent". I don't see a way to define shared concept of Transfer without first defining shared concept of ownership. In other worlds, unless we agree on shared generic owns/owner relation between agent and resource, it seems to me that we can forget about defining shared generic concept of Transfer ( and later Exchange dependent on definition of Transfer ) @bhaugen

[bhaugen]

Agree about defining ownership, and possibly other common Agent:Resource relationships. E.g. custodian.

Also relates to rights to use resources. Ownership = all rights.

[fosterlynn]

@bhaugen @elf-pavlik It is possible that transfers always involve a change of ownership, but I would want to think about it more. There might be other less absolute changes or relationships involved in a transfer. Or maybe those are another type of economic event (value flow), I don't know. There has been some work done on this in the REA world too, Bob keeps in touch there.

Just fyi, I want to get as soon as possible back to some NRP re-design involving our re-thinking of exchanges, which I started a while ago and is sitting neglected in a branch. For me, it helps to think about it in the context of doing some coding, since we do have real world examples who will use the code.

[bhaugen]

@fosterlynn - [some new kind of event type] does not always involve a change of ownership. E.g. vendor-managed inventory: VMI agent for manufacturer moves goods from warehouse to store. Location and custodian changes, but not owner.

Oops, I forgot: I think we just today defined Transfer to mean change of ownership...

[fosterlynn]

@bhaugen is that a transfer or is that a process?

[fosterlynn]

oops just replied before I saw your edit I think.....

[fosterlynn]

...and I think we are still thinking about all of this..... I'm not ready to define Transfer yet..... although the discussion is all good.... :smile:

[bhaugen]

@elf-pavlik and I were discussing transporting resources and thought it was a process, that involved some transport service as an input.

[elf-pavlik]

I propose moving free form conversation on transfer to: https://github.com/valueflows/exchange/issues/11 Or another issue in that repo.

Here I just wanted to point out, that for IMO simplest possible definition of vf:Transfer as "transfer of ownership over resource between agents", we need to define concept of ownership first - which seems to make sense as Agent - Resource 'relationship'

If someone can offer even simpler definition of vf:Transfer, I would like to hear it. Otherwise I would propose to see if we can agree on modeling the simplest possible definition before we get into thinking on how we could make it more complex. Of course we can use different name for "change of ownership over a resource between agents", vf:Transfer seems most relevant from what I understand so far about current approach to modeling exchanges and ownership.

[fosterlynn]

@elf-pavlik makes sense to move. (Sorry, I mostly don't check the issue name when responding, since it isn't visible from down in the thread.)

To note, I don't consider agent - resource relationships to be part of Agent deliverables. So I've been putting off thinking about them. Might make sense as a next step after agent round trip works, involving moving along to defining Resource?

[elf-pavlik]

Makes sense @fosterlynn, to focus on possible common Agent-Agent relationship, we could focus on what makes Group a group. As started in https://github.com/valueflows/agent/issues/51#issuecomment-150240833

In similar way as finding it hard o define vf:Transfer without concept of ownership relation. It seems hard to define Group without some concept of membership or inclusion or participation or affiliation or property/d2ea2490-7d8b-4f0b-bb0a-3a0963e539d6 relation

[elf-pavlik]

https://github.com/holodex/enspiral-data/pull/21#issuecomment-118821003

i'm hoping to use these link type ids within the spreadsheet interface, so friendly ids are important for link types

@ahdinosaur I would right away propose to consider naming of properties and classes which we use as an internal plumbing, for developer eyes only strings, and people who use apps should see friendly labels/names, which one can easily customize to fit particular cultural context and which one can translate into any number of human languages. I start more and more appreciating how wikidata uses non meaningful names for properties, eg. P34242

[bhaugen]

@elf-pavlik I would hate to code using P34242, but have not problem with internal-plumbing names and external-friendly names.

As I said before, I think our first audience here is programmers. (I could be wrong, maybe it's LOD fans.)

[elf-pavlik]

@bhaugen If we don't have something that we agree on to commonly use, you very unlikely will have reasons to write it in your code. Do you plan to write in your code any of below?

• dhen:accounting/agent-relationship-type/isOwnerOf/
• dex:relationshipTypes/owns

or

• dhen:accounting/agent-relationship-type/isMemberOf
• dex:relationshipTypes/belongs-to

[bhaugen]

@elf-pavlik - not sure I understand the question.

I am very likely to write in code something that means owner and something that means member. I don't care what it is, as long as I can understand it without looking up P34242.

So, for example, I will need to create and find Transfers in code, and when creating them, will need to know that Transfer means I take the owner relationship from one agent and switch it to the other agent. Or something like that. That could be known to the programmer (me) in a variety of different ways. I await the examples. After we nail down agent and their relationships - just reassuring @fosterlynn that I am not digging too deep into this hole now.

[elf-pavlik]

I am very likely to write in code something that means owner and something that means member. I don't care what it is, as long as I can understand it without looking up P34242.

I agree and for that reason I brought some of the previous arguments. Actually by looking at what we need to write in various source code, we may get some more clarity on what shared understanding we may need to agree on and what concepts we can leave out, even up to various frivolous definitions.

[fosterlynn]

I'm reviving this issue, because I'm working on an api for a new UI for NRP (forks), that wants to eventually be able to get data from other apps than NRP, and wants to be VF compliant.

I'd like to define some standard kinds of agent relationships that can be understood to have certain structure and behavior and general meaning to people. They tend to show up in different UI places.

What I've come up with, which I think covers all the use cases we know about:

• member
• part [this is child/parent relationships of organizations - possibly could be org:subOrganization, except that has a more specific structure]
• peer
• trading partner [or maybe transfer partner is better to not limit to exchanges?]
• legal partner

So: do people generally still agree that we want to have some base defined kinds of agent relationships? I think we had general agreement earlier on that, but it was a while ago, and I don't think we could agree on the particulars.

Then, what do people think of this list, and of these names?

Then, what is the preferred implementation? Since we are not in rdf, I would implement as AgentRelationshipRole in some way. I'm thinking a property "category" or similar of AgentRelationshipRole. In rdf, would we want to implement as sub-properties? Or would skos:Concept and skos:ConceptScheme come in here somewhere?

ping @elf-pavlik @djodjoni especially, hope you have a little time for this one... :)

After a little discussion, I'd like to do a PR.

[gcassel]

This is a deeply important topic so thanks for reviving it.

Agents have an unlimited variety of relationship-types/ "roles" with organizations. An unlimited variety could be defined by (potentially assymmetrical) agreements. With such "locally defined diversity" in mind, I doubt that VF will need to define more than a few generic types of relationships between agents and organizations.

Anyway, here's my current personal description of "peer" in my slowly developing Modular Organization Terminology:

Peers are agents who have the same rights within a specific social context.

I think that this is a broadly accurate and properly flexible definition. However, perhaps it seems too specific in some ways, and seems to straddle the potential lines between "peer", "member" and "partner"?

At any rate, "member" is used more specifically than "peer" within organizations. I'd currently define member roughly like this: Members are peers within a governing group agent within a specific organization.

Note however that such a governing group agent may not be the only governing authority for a specific organization. For instance, some rights and responsibilities may be reserved to a board of directors, trustees or stewards. (Of course, such complex organizations can be defined by relationships between group agents.)

To me, "member" is definitely the key term, with "peer" being a more general descriptor for unofficial relationships.

I find it desirable to focus on a few key terms, so that organizations can clearly define generic non-member types such as "guest" or "contributor" according to locally-defined sets of (media reading & writing) rights and responsibilities.

[gcassel]

Sorry about the brief accidental issue-closing: jumpy bluetooth mouse

[fosterlynn]

Thanks @gcassel - good push to actually define these terms! I'll use your definitions as starters when I do a PR for the doc, got any more?

Agents have an unlimited variety of relationship-types/ "roles" with organizations. An unlimited variety could be defined by (potentially assymmetrical) agreements. With such "locally defined diversity" in mind, I doubt that VF will need to define more than a few generic types of relationships between agents and organizations.

Yes, that is what I'm trying to accomplish, well stated. Except not just agents and organizations, could be between people too.

To me, "member" is definitely the key term, with "peer" being a more general descriptor for unofficial relationships.

Makes sense, I am using "peer" somewhat as a backup catchall for people for less specific relationships. Brought on by the @ahdinosaur example from Enspiral where they have mentors.

[gcassel]

I'll use your definitions as starters when I do a PR for the doc, got any more?

@fosterlynn I think there are over 100 terms now in Modular Organization Terminology . (Recent push to start building that repository.) Some of them are half-baked at best, though, and I'll need to work (and collaborate) hard to iron out some reasonably clear and valuable relationships between the terms.

I feel relatively comfortable now with some of the most basic terms including agent, role and relationship.

I haven't gotten to the point yet where I desire to make a direct request for comments to VF or (later) the general public. However, feel free of course to consider, adopt or adapt any of the current terms.

[fosterlynn]

I think there are over 100 terms now in Modular Organization Terminology

awesome @gcassel i'll feel free to make use of them :)

[djodjoni]

@fosterlynn I actually recently thought about this and re-read a bit this thread https://github.com/valueflows/valueflows/pull/219 as I already forgot some of the discussions. So what he have been talking is generally 2 types of relationships:

1) memebership-like role, belonging to something

2) economic-flow-like A delivers to B, B buys apples for A , etc.

the 1st one is common and some terms like "memberOf" there are also some ontologies that we know and referenced doing that to some extent: https://www.w3.org/TR/activitystreams-vocabulary/#dfn-relationship https://www.w3.org/TR/vocab-org/ http://vocab.org/relationship/

they are quite ok and can be reused and extend. as for the 2), which I think also @pmackay was after also, I see it as generic summary of valueflows recipe. I needed that as my first stage experiments but this info can be very well derived from VF based graph so I don't see any particular need to define it here and it may create confusion with the vf recipes and not only.

I have some data where I don't have enough info yet and I use terms like upstreamRel(closer to the source, i.e. producer) and downstreamRel(closer to the consumer, i.e. shop) from http://w3id.org/openfooddata/onto/core

there I define the Actor as the object of the relation and some extra metadata similar to RelationshipRole we have discussed. This works fine for the purpose of generic data about FoodActors as in https://github.com/openfooddata/actors

So in VF I would try to reuse some of the already existing vocabs for that and create extra terms or even the different apps can create their own terms and use them, they does not need to be in the VF. I would however have in VF some small generic set of those so users/apps can easily reuse.

[fosterlynn]

hey @djodjoni very glad to see you and thanks for the feedback !!

the 1st one is common and some terms like "memberOf" there are also some ontologies that we know and referenced doing that to some extent

yes, thanks, and these would be good to include in some of the doc (note to self)

as for the 2), which I think also @pmackay was after also, I see it as generic summary of valueflows recipe. I needed that as my first stage experiments but this info can be very well derived from VF based graph so I don't see any particular need to define it here and it may create confusion with the vf recipes and not only.

I'm actually fine with adding this to VF, but won't spend time if you think you want to do it another way, also totally fine. And @pmackay hasn't been around asking about it either, so I just let it sit. :)