Relation class

[jpmckinney]

Organization-organization relationships of control/ownership have come up in #65. There may be some properties in common across both types of relationships, though the concepts of control/ownership will be unique to org-org.

• [x] LittleSis
• [x] OpenCorporates
  • Part 1: control via equity
  • Part 2: control without voting
  • Part 3: data sources
  • Part 4: data modeling
• [x] PoplusCon
  • pre-PoplusCon
  • PoplusCon
  • Summary

    Person-person

• [x] Poderopedia RDF: discussion
• [x] bio
• [x] relationship
• [x] proton

  Stakeholders

• [x] Social Network Analysis Project Survey

[lfalvarez]

Hey there! This would be two different classes? like a PersonPersonRelationship and OrganizationOrganizationRelationship? How do we explain the fields? I think that for PersonPersonRelationship it would be good to have person1, person2, kind and explanation (this the simplest thing that I could come up with). If the relationship is reversible could be part of the "kind" description as Relationship does. If this doesn't make sense please let me know.

[jpmckinney]

There can also be person-organization relationships, e.g. "customer", so I would try to stick to one class, "Relationship".

As you acknowledge, some relationships are non-symmetric, e.g. "Bob is the parent of Alice", so the fields should indicate the direction. One option is subject and object to make an analogy to syntax, e.g. "Bob (subject) is the parent of (predicate) Alice (object)", instead of person1 and person2, where you'd have to read the docs to figure it out.

[lfalvarez]

Cool! makes total sense. And regarding symmetrical relationships, should there be an symmetrical attribute?. At this point I can recognize the following attributes: subject, object, kind (I think that this isn't a really good name but I cannot think of any better) and symmetrical.

So, with these attributes we can model:

• "Bob (subject) is the parent (kind) of Alice (object)".
• "Bob (subject) is friend (kind) of Alice (object)". And this relationship is symmetrical as we can also say "Alice is friend of Bob".

[jpmckinney]

If we stick to the syntax analogy, kind would be predicate. However, we can hold off on picking the specific terms until we've figured out all the use cases and requirements (e.g. we'll want start and end dates, an indication of how strong the relation is, provenance, trust, etc.)

In RDF, it's possible to mark relations as symmetric using OWL. In JSON, I'm not sure what the best practice is. All "friend" relations are symmetric whether or not the Relation sets a symmetric property; it's information that exists outside the specific relation. So, I'm not sure I would add a symmetric property.

[lfalvarez]

Hey there, what do you think of this use case?

Describe family relations:

• "He and she are siblings"
• "Mary is the mother of Jesus"
• "He and she are cousins"
• "He is the brother-in-law of another person"
• "He is the father-in-law of someone"
• "Bob is the husband of Alice"

It is important to note that there is a time frame for a marriage relationship like "Bob was the husband of Alice during 1/1/2001 and 25/12/2002"

[jpmckinney]

I think Relationship should cover those use cases! I may be able to work on this more seriously in early 2015, depending on a grant.

[lfalvarez]

:smile: :+1:

[jpmckinney]

Just adding a note to myself that I've reviewed the discussion up to this point and made notes.

I'll have more to share on this research soon!

[kaerumy]

Just adding an example use case of organizations for Malaysia:

• ValueCap http://www.valuecap.com.my
• Putrajaya Holdings http://www.pjh.com.my

These companies are owned by 2-3 government entities, which eventually are owned by a proper gov department as we work our way up. Sometimes there might be a private partner in ownership of the equity. This is important for governance, Putrajaya Holdings which was initially 100% owned by gov entities now has private investors.

Info we would need to store:

• equity relationship of organizations, they have parents by virtue of equity not direct hierarchy like gov depts
• financial transfers
  • how much money put into by each gov owned entity
  • how much money in turn divested by these entities and to who

Financial flows probably something for another issue, but it's a relationship that we're interested in modeling but can't track or show right now between organizations.

[tmtmtmtm]

Being able to model all the different ownership/control structures between corporations is VERY complex, and I'm far from convinced that it should be Popolo's place to do so. It seems to me that there should be a separate standard for this (I don't know what work may already be going on in that area). The vast majority of usage of such a standard would be outside the field of government or legislative work.

[jpmckinney]

OpenCorporates probably has the best equity relationship model: http://blog.opencorporates.com/2014/01/08/understanding-corporate-networks-part-4-how-we-record-the-data/

[sweemeng]

The reason we are looking at equity and stuff is because we have a number of members of parliament in company and we have government agency owning company, with politician/minister/civil servant running those agency. Equity is a very strong indicator of influence.

Now to measure influence/relationship between 2 person which is most probably politician, if would be great if we don't have to run through multiple service with multiple validation outside popolo.

Yes Malaysia is that kind of a mess, having properties make our life a lot easier.

[kaerumy]

We're looking at a subset following Popolo principles. I don't think there is anything wrong with some of these in Popolo if it helps countries with constrained and non-transparent governments like Malaysia model the reality of how governments work in their respective countries.

Countries that don't need it because they have "normal" democratic government systems don't have to use some of these standards.

One of the advantages of Popolo is that it lowers barrier to entry in adopting standards by using a subset of much more complicated/complete standards for open government. This is really important for inclusiveness in countries with people new to open data standards or lack resources to deal with complete complex standards, but still need to model how their governments work.

[tmtmtmtm]

@sweemeng / @kaerumy I get why it's useful and important for you to track this stuff. And I get why you'd prefer to use only Popolo, rather than multiple standards, where there's a choice. But I don't get at all why it's critical for you that this is part of Popolo. If there isn't a suitable standard to use, why not just model it locally in whatever way it makes most sense for you?

[kaerumy]

Another use case here for "control" relationship, but for responsibility.

• Finance Minister (Post) is member of Cabinet (org)
• Finance Minister (Post) is also responsible for Ministry of Finance (org)

Head of Ministry of Finance is usually a public servant, someone with a a post named Director General, Chief Secretary and such. However in Malaysian Parliament, answers from that Ministry is referred to the Minister in charge, not the public servant.

What's the proper way to handle this? In the following diagram, the Prime Minister who is also holding the post of the Finance Minister, has no relationship at the moment with the Ministry of Finance which he heads.

[kaerumy]

@tmtmtmtm we're working with and adopting the other standards, like IATI, OCDS and Open Corporates. When they work in similar way to Popolo like OCDS, it works well, we can see where one ends and where one starts.

OCDS Organisations doesn't have Members/Posts and that's where we have identifier link to Popolo for state, state owned, or state linked organizations and committees. If we don't have these state organizations because we're only supposed to have legislative orgs in Popolo we would have no link and no info to people/agencies in gov who are accountable. Since politicians are holding posts in state orgs, it makes sense that we have state orgs in Popolo.

We are not implementing OCDS in Popolo. Should OCDS include members/posts/relations for their org std? We don't know, but probably not. Maybe just sub-contracts/PPPs, then again the same could be argued that equity relationships for PPPs should be in Open Corporates, cause it's too "complex" for contracting. But then we have that in our contracts.. but not enough data for full company structure.

We're not focused just on legislature but also on the boundaries between these other standards to be able to build the connections to build a complete picture of what the gov is doing. Because we're also working at the boundaries, there will be overlaps, but we believe working in this overlapping/connecting space of open data standards where government is involved is important, especially if we want to the standards to be inclusive for countries where the lines between government and business are blurred.

[jpmckinney]

@kaerumy I'm reviewing the last comments. Are there some specific changes that will make your use cases easier to fulfill, or are you just explaining your use cases? What extensions or changes did you need to make to Popolo for things to work?

[kaerumy]

@jpmckinney just sharing use cases, but we think that some sort of Relationship property to map different types of relationships between people should probably be in Popolo.

The first type that I think should be in Popolo would Relation property for immediate family members and associates. I haven't found good type definitions for close associates yet. Close associates for finance/gov institutions usually mean someone who can do transfers on the PEP's behalf such as accountant, financial manager etc.

Class Relationship:
type: family
relationship: child, spouse

Class Relationship:
type: associate
relationship: accountant

References:

"The requirements for all types of PEP should also apply to family members or close associates of such PEPs."

"http://www.fatf-gafi.org/media/fatf/documents/recommendations/pdfs/FATF_Recommendations.pdf

[jpmckinney]

Ok, thanks. My work on the InfluenceMapping project can be imported here. I haven't written up the schema yet, but it's composed of at least:

• subject(s)
• object(s)
• classification(s)
• start_date
• end_date
• name (if the relation itself is named)
• description
• identifiers
• links
• sources

[pudo]

For what it's worth, I've recently been digging through a lot of sanctions lists which are apparently commonly used as source material for PEP databases, and they indicate that there's a fairly broad consensus in the industry as to what the schema for a PEP looks like.

Here's a JSON schema of what looks to me like the minimum viable schema for sanctions/PEP data: https://github.com/pudo/opennames/blob/master/pepparser/schema/entity.json Here's the links to source data: https://github.com/pudo/opennames/blob/master/README.md And the resulting data: http://pudo.org/material/opennames/

[jpmckinney]

Thanks for links. For specific feedback, we can move the discussion to email, but property names like first_name are absolutely not international concensus. There are loads of ways in which those terms can be brought in line with the most common terms used across all schema. Simply reusing Popolo's terms is a good shortcut to redoing all that research into what is actually the most common term for things like name components.

[jpmckinney]

It looks like you're mixing in a bunch of properties relating to sanctions onto a model for a Person. A sane data model would hive off all the person-related properties into a Person object, which would be referenced from the Sanction object via a person property.

And once you've done that, you can avoid reinventing the wheel and just use Popolo's Person model (with maybe a few extra properties) for that Person model.

[pudo]

Thanks for the feedback, @jpmckinney! To be clear: the point of this wasn't for me to come up with the ideal sanctions data model, but rather to find a basic common denominator between the XML files which serve as an input to this.

They are very similar in their layout, so I wonder if there's an international agreement somewhere that they all go back to (or whether it's just a community that name-checks each other). One thing I did take out was multiple places of birth and birth dates, going to have to add that back in later.

As for name parts, you're right about first_name. The US and EU databases have it, but it's obvs. BS. I found the swiss model particularly charming:

set(['tribal-name', 'suffix', 'title', 'maiden-name', 'family-name', 'father-name', 'given-name', 'whole-name', 'further-given-name', 'other', 'grand-father-name'])

[jpmckinney]

Reminds me of OASIS CIQ which has the example:

<n:PersonName>
  <n:NameElement ElementType="Title">Mr.</n:NameElement>
  <n:NameElement ElementType="Birth Street Name">William Street</n:NameElement>
  <n:NameElement ElementType="Father Name">Rajan</n:NameElement>
  <n:NameElement ElementType="Country Of Birth">United States</n:NameElement>
  <n:NameElement ElementType="State Of Birth">Virginia</n:NameElement>
  <n:NameElement ElementType="Country Of Origin">Indian</n:NameElement>
</n:PersonName>

[jpmckinney]

Noting a good blog post on identified needs: http://influencemapping.org/user-needs-on-influence-mapping-around-latin-america/

[kaerumy]

An interesting use case from Myanmar. Open Hluttaw (Parliament) they collect parents names for all MPs, apparently it's just a cultural interest there that when people want to know about their MP, they're curious to know who the person's parents are too.