search

valueflows / agent

agent has moved to https://lab.allmende.io/valueflows/agent
10 stars 4 forks source link

Agents and their relationships vocab #9

Closed fosterlynn closed 8 years ago

fosterlynn commented 9 years ago

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:

@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. :smile:

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 commented 9 years ago

keen. i'll draft up my proposal for the logical model, which is basically https://github.com/openvocab/agent/issues/1#issuecomment-131638813 plus https://github.com/openvocab/agent/issues/5#issuecomment-131821975.

elf-pavlik commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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

ahdinosaur commented 9 years ago

:+1: 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 commented 9 years ago

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

fosterlynn commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

Some existing vocabs:

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

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

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

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

@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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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: https://github.com/hackers4peace/plp-docs/issues/12#issuecomment-77993821 and https://github.com/openvocab/agent/issues/7.

fosterlynn commented 9 years ago

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:

Agent:

RelationshipType:

Relationship:

fosterlynn commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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

fosterlynn commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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

fosterlynn commented 8 years ago

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

ahdinosaur commented 8 years ago

@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 commented 8 years ago

@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..... :smile:

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 commented 8 years ago

@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 commented 8 years ago

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

ahdinosaur commented 8 years ago

@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 commented 8 years ago

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

elf-pavlik commented 8 years ago

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

UserAccount

fosterlynn commented 8 years ago

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