Agents and their relationships vocab

[fosterlynn]

I'm wondering if we can/should move ahead with a proposal on this soon? I think Holodex is getting settled into their agent model, which closely matches NRP's model. We can also bring in what we learn from the people involved with the Mutual Aid Network in Madison, who is looking to create interoperability between WeZer and Community Forge time bank software, and later with other time bank software platforms. And the discussion so far in the Social IG at W3C. Then see if it makes sense to others: PLP groups; W3C?; ?.

Proposed steps:

• Agree on a logical model.
• Research and list relevant existing vocabs.
• Assess what existing vocab should be used for what pieces.
• Create a complete definition using existing and new, including JSON-LD examples. [edited]
• Test it. (At least syntax testing, but a real test would be awesome.)

@ahdinosaur this doesn't mean I don't want to send you csv data for holodex, I need to do that....

The reason I'm thinking about this is it is a relatively simple piece that everyone will need and I feel like we might be closing in on it. If not, no problem waiting. Also @elf-pavlik is on fire, I can't even keep up with him, and I want to take advantage of that. 😄

Another way to approach is to continue with the 1:1 experiments and see what emerges. The ones I know about are: NRP-Holodex; NRP-Pixel Humaine (I owe some data to @oceatoon); and this Madison use case. I'll continue working on those anyway.

[ahdinosaur]

keen. i'll draft up my proposal for the logical model, which is basically #1 (comment) plus #5 (comment).

[elf-pavlik]

@ahdinosaur please make sure to have examples for all used constructs, preferably in JSON-LD. Similar to http://www.w3.org/TR/activitystreams-vocabulary/

[fosterlynn]

Definitely we need to end up with examples in JSON-LD, good suggestion to use the AS doc as an example. If @ahdinosaur wants to do those up front, that's cool. @elf-pavlik I don't need those for initial discussion, do you? If so, let's go that direction, if not, let's get the basic model out there first, which I'm hoping we can quickly agree on at this point. The harder part will be in the implementation.

I can do the model if you like, I think this morning. This would get me back into the holodex data too, which would be good. [EDIT: Oops, this is included in latest pull request, will study. Ignore this.]

[fosterlynn]

@ahdinosaur Sorry, please ignore what I said re. the model. See edit.

[ahdinosaur]

👍 for examples in JSON-LD, #somebodyshould. (i'm a bit flooded with other work at the moment so not sure how much i'm able to do.)

[ahdinosaur]

so to tick off the first box, how we do feel about my logical model proposal?

[fosterlynn]

@ahdinosaur Love getting back to the simpler model! And thanks for drawing it up! Questions for discussion:

1. Should we model Agent as superclass of Person and Organization, which seems to be the most common out in LOD land? Then we would end up with a fairly small number of subclasses, like people might want to add Group or Circle or Network. Or not.
2. Connected to 1., are you thinking that AgentType is there to be able to define constraints for the RelationshipType? If so, I'm thinking how to make that work with the subclass model....
3. What is your thinking on the obverse on RelationshipType and Relationship? You would actually have 2 instances when there is a bi-directional relationship, like say membership? I'm thinking this is overkill for all the use cases I know of, let's say in NRP and Enspiral. Maybe it is fitting for like in a social network? And I know there has been a lot of discussion with @elf-pavlik on the confirmation from each party, which I figured would be an add-on kind of thing, although I haven't studied it thoroughly. Again, that seems like it will be useful in some situations, but not in NRP or Enspiral? [Edit: Or are you thinking that mostly in the cases of relationships inside a network, there would be only one instance? For example would the steward - stewardee relationship type be one or two instances? Would member be one or two instances?]
4. Do we need contextAgentType on RelationshipType? [Edit: I get this more, in terms of constraints, withdraw the question.]

My next steps: study the properties more carefully, see if I see anything missing; pull together existing vocabs. Should have time today, yesterday completely got away from me.

[fosterlynn]

@ahdinosaur Here are some possible property additions to consider, nothing a showstopper, all optional:

Agent.primaryLocation -- would help us connect to mapping apps. Might come in with existing vocab.

Relationship.status (active, inactive, potential)
Relationship.startDate
Relationship.endDate
(Or if we think LOD, maybe everything provided is active, current, etc.?)

And then something to cover labeling or naming on AssociationType. (Seems less optional. I'll take a look at holodex's latest data structure.)

And a naming question: Should it be AgentRelationshipType and AgentRelationship? Otherwise there are lots of things it could refer to. Although I notice vocabs do this all the time.

[fosterlynn]

Some existing vocabs:

Vcard: http://www.w3.org/TR/vcard-rdf/

• Organization: http://www.w3.org/TR/vcard-rdf/#d4e2121
• Individual: http://www.w3.org/TR/vcard-rdf/#d4e1749
• Group: http://www.w3.org/TR/vcard-rdf/#d4e1667
• Kind: http://www.w3.org/TR/vcard-rdf/#d4e1819 (superclass of Person, Organization, Location, Group)

FOAF: http://xmlns.com/foaf/spec/

• Agent: http://xmlns.com/foaf/spec/#term_Agent (the superclass, includes bots etc.)
• Person: http://xmlns.com/foaf/spec/#term_Person
• Organization: http://xmlns.com/foaf/spec/#term_Organization
• Group: http://xmlns.com/foaf/spec/#term_Group

AS: http://www.w3.org/TR/activitystreams-vocabulary/

• Actor: http://www.w3.org/TR/activitystreams-vocabulary/#dfn-actor (superclass of Application, Person, Group, Process, Service)
• Person: http://www.w3.org/TR/activitystreams-vocabulary/#dfn-person
• Group: http://www.w3.org/TR/activitystreams-vocabulary/#dfn-group
  AS unlike others has a definable relationship type and flexible relationships -
• Relationship: http://www.w3.org/TR/activitystreams-vocabulary/#dfn-relationship
  ** has a property called relationship that references a relationship type definition

Schema.org: http://schema.org/docs/schemas.html

• Organization: http://schema.org/Organization
• Person: http://schema.org/Person

@elf-pavlik You are much more familiar than I am - please add to this list if you know of other vocabs that should be considered for agents and their relationships! (I can do the detail work.) And also your perspective if you can! Thanks!

[fosterlynn]

Also, I looked at the Activity Stream context: http://www.w3.org/ns/activitystreams. It has lots of references. Some things that might be relevant:

Org: http://www.w3.org/TR/vocab-org/#overview-of-ontology, we looked at this early on

Prov: http://www.w3.org/TR/2013/REC-prov-dm-20130430/#component3

Good Relations: http://www.heppnetz.de/ontologies/goodrelations/v1#uml - very business-y but thorough

[fosterlynn]

Looking around and thinking about Agent subclasses vs AgentType, I see an interesting example in the Prov link above.

Can we do it this way? Define Agent with subclasses. Define a property called agentType, which is limited to the values of the subclasses of Agent. Use that property when we need an agent type, like in RelationshipType for sourceAgentType, targetAgentType, and contextAgentType.

Or is that too many layers?

[ahdinosaur]

Should we model Agent as superclass of Person and Organization, which seems to be the most common out in LOD land? Then we would end up with a fairly small number of subclasses, like people might want to add Group or Circle or Network. Or not.

i've come back to the position that we should do what is best rather than what is most common, so in this case i think flexible AgentType objects are more powerful than restricted subclasses. being compatible with existing LOD is not a huge priority for me.

Connected to 1., are you thinking that AgentType is there to be able to define constraints for the RelationshipType? If so, I'm thinking how to make that work with the subclass model....

yes.

What is your thinking on the obverse on RelationshipType and Relationship? You would actually have 2 instances when there is a bi-directional relationship, like say membership? I'm thinking this is overkill for all the use cases I know of, let's say in NRP and Enspiral.

2 instances (one for each direction) of a relationship is the proper way to model it, but what's most important is the user experience with the data, so while it's still group admins entering data for the group it doesn't make sense to duplicate while once we have a proper API and UI it shouldn't matter that there are 2 instances under the hood.

Agent.primaryLocation -- would help us connect to mapping apps. Might come in with existing vocab.
Relationship.status (active, inactive, potential)
Relationship.startDate
Relationship.endDate

yes to Agent.primaryLocation (or locations?), Relationship.startDate, Relationship.endDate. want more time to think about Relationship.status as i think it's another key part of the vocab, i'm thinking it could be done similar to how y'all did resource facets.

[ahdinosaur]

i've come back to the position that we should do what is best rather than what is most common, so in this case i think flexible AgentType objects are more powerful than restricted subclasses. being compatible with existing LOD is not a huge priority for me.

i should rephrase this as: i don't want us to give up functionality for the sake of compatibility, but i'm happy to alias to existing LOD property names where appropriate.

[bhaugen]

I'll be interested in how @elf-pavlik and the LOD enthusiasts work with this set of issues.

In other words, how do the LOD conventions work with common programmer conventions? Can everybody work together?

Or if I get my head around LOD conventions, will I like them better?

[fosterlynn]

i should rephrase this as: i don't want us to give up functionality for the sake of compatibility, but i'm happy to alias to existing LOD property names where appropriate.

@ahdinosaur I can totally get behind this thought.

Question: In Enspiral (or other Holodex data you know about) what are the agent types? In networks we work with, I keep coming back to the thought that there aren't really any besides what people tend to use as standard subtypes. If one shows up, it tends to be a role in a relationship, not an actual type of agent. But I have a limited set of examples.

If there are useful user defined agent types, maybe the way to model it is to have a property of AgentType that references the subtypes. In NRP, we have the equivalent of that, because we need to know what AgentTypes are people, organizations, etc.

[fosterlynn]

2 instances (one for each direction) of a relationship is the proper way to model it

@ahdinosaur How so? Is there different data when it goes the other direction? Or more a question of source of the data?

[ahdinosaur]

Question: In Enspiral (or other Holodex data you know about) what are the agent types? In networks we work with, I keep coming back to the thought that there aren't really any besides what people tend to use as standard subtypes. If one shows up, it tends to be a role in a relationship, not an actual type of agent. But I have a limited set of examples.

the Enspiral use case i'm basing this on is "Open OS", where there are 4 agent types: Person, Pod, Community, and Network.

If there are useful user defined agent types, maybe the way to model it is to have a property of AgentType that references the subtypes. In NRP, we have the equivalent of that, because we need to know what AgentTypes are people, organizations, etc.

yeah, i could see there being a property which says whether the agent could have sub-agents (members), but i'm holding off on that until i know for sure it's necessary, as it might not be.

2 instances (one for each direction) of a relationship is the proper way to model it

@ahdinosaur How so? Is there different data when it goes the other direction? Or more a question of source of the data?

"proper" is the wrong word, i have an intuition it is better: hackers4peace/plp-docs#12 (comment) and #7.

[fosterlynn]

OK cool. I'm going to attempt to document what we have so far with more-or-less agreement, with some questions or notes interspersed. Once we get a minimal model agreed to, I'll update the readme and issue a pull request; and could start other issues for the specifics we are still discussing while we continue on the check box steps for the basic model.

AgentType:

• id: required url
• name: optional string
• description: optional string
• class: optional -Organization, Person- *others? Group? bots or programs? *required?

Agent:

• id: required url
• type: required AgentType *should be optional? *or could refer to our AgentType OR Organization, Person, etc class?
• name: optional string
• image: optional url
• *** will have some form of location(s), still needs definition

RelationshipType:

• id: required url
• description: optional string
• *** taking out obverse for now pending more discussion
• source: optional AgentType *I changed to optional, not everyone has this
• target: optional AgentType *I changed to optional, not everyone has this
• context: optional AgentType

Relationship:

• id: required url
• type: required RelationshipType
• description: optional string
• *** taking out obverse for now pending more discussion
• source: required Agent
• target: required Agent
• context: optional Agent
• start: optional date
• end: optional date
• *** status needs more discussion
• *** also could consider a collection of activities or events that caused dates and status

[fosterlynn]

@ahdinosaur @elf-pavlik

Mikey, elf was talking about thinking about the relationships in a higher level of abstractions. One example is to think of a relationship like a rdf triple, subject-predicate-object.

I don't think I actually want to step up to a higher level of abstraction generally, maybe topic for a whole other discussion. But I do like the terms subject and object perhaps better than source and target. I also noticed that the Activity Streams vocab used those terms in its Relationship class. It uses relationship in place of predicate, which also makes sense to me. (Except I wish it were relationshipType, but hey....) I could see using the AS Relationship for our AgentRelationship piece. We could add properties as needed. What do you think?

[fosterlynn]

Another note about the obverse relationship question: I left off the labels until this is resolved. Probably an open question what labels to use, we and holodex have a different set.

[ahdinosaur]

yeah, i agree that relationships are akin to rdf triples (subject, predicate, object), as rdf triples are akin to graph nodes and edges. the names source and target come from existing language around graph edges, i'm fine with subject and object as well though.

[bhaugen]

http://english.stackexchange.com/questions/22621/what-are-the-differences-between-inverse-reverse-and-converse
That seems to somewhat contradict the previous links about obverse that I posted above, but confirms my opinion that obverse is seldom used.

So I guess I would go with inverse or reverse. But I don't care that much. I didn't like obverse because I had never encountered it before and I do not have a small vocab, so I figured it would not communicate well.

[fosterlynn]

Reading the definitions from above, I like reverse the best. But I also don't care that much and will go with whatever people want.

BTW, we will need the name whether there are pairs of RelationshipTypes or pairs of labels as properties of one RelationshipType.

[elf-pavlik]

@fosterlynn @ahdinosaur in terms of predicate/property (or its sub property relationship as used in AS2.0), please note distinction between defining and using instances of owl:Class and rdf:Property which I attempt to explain in https://github.com/w3c-social/social-vocab/wiki/Verbs---owl:Class-vs.-rdf:Property (you can replace follow with member, not a verb, but used in reverse direction as hasMember rather that isMemberOf) ... i'll try to make an equivalent page for such case sometimes soon!

[ahdinosaur]

@elf-pavlik looks awesome. 😄 are there any changes we need to make here in order to support that logical model?

[fosterlynn]

@elf-pavlik I think I follow your train of thought: The way to get the 2 labels in addition to the relationship name (which is the property) is to name a collection (which the agents will contain) with the label name in the proper direction. So I have a collection of organizations which I am a member of, and each organization will have me in its hasMember collection. (Correct me if I am wrong!)

Where then is the fact that "follow", "isFollowing", and "hasFollower" (or "member", "isMemberOf", "hasMember") are part of the same concept without connecting them in a class? Specifically, how do you know that Lynn-isMemberOf-Sensorica is the reverse of Sensorica-hasMember-Lynn?

And why are you so anxious to keep it a property rather than a class? I gather some of this is ease of querying, which I have no experience with, and which would definitely be important. @ahdinosaur will be experimenting with this I assume when he implements this in holodex, so that might provide some useful info too.

[elf-pavlik]

I argue that by defining a verb follow as an instance of rdf:Property you don't need Follow (a sub class of as:Activity), don't need Following (a sub class of as:Relationship), also don't need to define reverse/inverse properties for each verb on vocabulary level - so follow == isFollowing and you get hasFollower simply by reusing follow and swapping values of object and subject. Similar schema:member == hasMember and you get isMemberOf again by swapping values of object and subject. You can't do the same if you define verbs and types of relationships as instances of owl:Class. At the same time you can always do it in addition to defining an instance of rdf:Propery. If you need explicit Membership you can do that (for example if you need it for rdfs:range and rdfs:domain) but if not you can simply use Relationship with member as value of relationship (sub property of rdf:predicate)

[fosterlynn]

@elf-pavlik Sorry still don't get it.

so follow == isFollowing and you get hasFollower simply by reusing follow and swapping values of object and subject.

So where is the text isFollowing and hasFollower (for a label for example) documented? Where does it say follow == isFollowing?

[elf-pavlik]

http://richard.cyganiak.de/blog/2006/06/an-rdf-design-pattern-inverse-property-labels/

{
  "@context": {
    "ex": "http://vocab.example/#",
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "owl": "http://www.w3.org/2002/07/owl#"
  },
  "@id": "ex:follow",
  "@type": "rdf:Property",
  "rdfs:label": "is following",
  "owl:inverseOf": {
    "rdfs:label": "has follower"
  }
}

[fosterlynn]

@elf-pavlik Thanks! So basically you can define properties (labels in this case) of an rdf:Property..... ok cool.... looks just like our RelationshipType.... 😄

[fosterlynn]

Any objections to adding foaf:nick (nickname) to the Agent? We do have that in NRP, and it is useful.

[ahdinosaur]

@fosterlynn i'm unsure, i'm actually thinking profile information should be a separate object as activity streams does it, that way the agent object is purely to represent an identity, which in the future could include the cryptographic keys that are part of that identity (a la ssb), but this is still in my deep mind. even if we do want to put profile information in the agent object, is foaf:nick the best property to use for this?

[fosterlynn]

@ahdinosaur you are way deeper than I am. All those seem like valid considerations. I think I see where you are going, people call themselves lots of stuff on profiles they use as online personas. And there might be a use for profile or persona as a separate object. This has in fact been a discussion point in the W3C interest group that elf got me involved in. There is a woman named Amy Guy who did a very nice model that included that concept. (I think some of the EU OuiShare guys know her.) Then I heard there was a big discussion on it, with some people thinking it was overkill. (I don't have an opinion yet, it's a foreign concept to me.)

The nick I'm proposing is a nickname of the person or organization him/her/itself. Like you have name Michael Williams, and nick Mikey. All in real life. Same with location or other attributes of agents we might want to add. Unless..... hmmm....... you are really someone else..... I've never actually met you...... kidding, I hope..... 😄

All the objects we are dealing with so far I consider to be data about real things/people/etc. working together in a real situation. Not online based identities. I should be able to enter the Amish farmers around here who have no electricity using this vocab.

We will need something like UserAccount someday, and a Person could have more than one UserAccount. I don't know how the cryptographic keys fit in, above my pay grade.

If you are good, I'll research if foaf is the best vocab to use for it. If not, we can wait on it and I'll take it out, not urgent.

[ahdinosaur]

@fosterlynn one interesting example found in ssb land is someone else making a claim about your nickname, i.e. what name they call you by. e.g. my friends call me Mikey but my family call me Michael, some people have even more names for me that they make up.

[fosterlynn]

@ahdinosaur let's just leave it off for now then, other priorities....

[ahdinosaur]

@fosterlynn i'm happy to add something on to Agent for better labeling, we can punt on having a separate profile vocab. maybe i'm a bit relunctant about foaf:nick i suppose. i reckon nicknames are all part of something more general about labels, all our vocabs have labels, and i'm keen for our overall vocab to be minimal (i.e. share ontologies as much as possible). this might be a crazy idea, but what if we used skos labels for all our labeling across vocabs, including Agent. we could use skos again for describing relations between types and documentation.

[fosterlynn]

@ahdinosaur OK, let's pursue. Glad you are digging in. I can give it a deeper look in a few days.

[elf-pavlik]

http://sioc-project.org/node/341

[fosterlynn]

Closing this issue in favor of more specific issues, this one is now too general.