Add Employers Field To Person

[raysuelzer]

Union clients store information about an employer for every person. We should figure out where this belongs.

[mpaquette1]

Political donations require an Employer and Occupation... should we add Occupation as well?

[raysuelzer]

This is actually quiet a complex schema. I think the van has over 50 fields for each employer... On Oct 24, 2013 2:56 PM, "mpaquette1" notifications@github.com wrote:

Political donations require an Employer and Occupation... should we add Occupation as well?

— Reply to this email directly or view it on GitHub.

[tobowers]

I think the right way to do this is to have an organization schema and an employment schema that links to the organization and the person.

[raysuelzer]

I draft up what we use at the ufcw On Oct 24, 2013 6:45 PM, "Topper Bowers" notifications@github.com wrote:

I think the right way to do this is to have an organization schema and an employment schema that links to the organization and the person.

— Reply to this email directly or view it on GitHubhttps://github.com/wufm/osdi-docs/issues/42#issuecomment-27039056 .

[raysuelzer]

I suggest something like this as a jumping off point:

{
   "employer":{
      "id": "guid",
      "name":"Safeway",      
      "worksites":[{
         "id":"guid",
         "name":"Store 10",
         "location":"same as address spec",
         "buildings":[
            {
               "id":"guid",
               "name":"Infant Care"
            },
            {
               "id":"guid",
               "name":"geriatic care"
            }
         ],
         "departments":[
            {
               "id":"guid",
               "name":"Produce"
            },
            {
               "id":"guid",
               "name":"Deli"
            }
         ],
         "bargaining_units":[
            {
               "name":"Meat Cutters",
               "id":"guid",
               "union_local":{
                  "name":"Local 1",
                  "id":"guid"
               }
            }
         ]
      }
   ]
}
}

[raysuelzer]

The other things that the unions need to be able to do is to know exactly where an employee works, their employment status (terminated, current), their union membership status (in right to work4less states), and their union local. I'm sure I am missing a lot here.

[raysuelzer]

The other thing to consider, is that if I were to pull the "Walmart" organization from my DB in the format I suggested above, it would be about a 50 megabyte json file and close to a million rows of sql data...

[mpaquette1]

I would argue for the 80/20 rule on required data structures, in this case sticking with election-law requirements by providing one field for employer and one field for occupation. Future OSDI extensions (or independent APIs) can cover such detailed and industry-specific data needs as a fully relational employment history, worker training and certifications, section 3 eligibility, union membership, etc. These types of structures seem to be outside of our scope, at least in the first release.

Mark Paquette Co-founder & CTO thedatabank, inc 612-455-3502 mark@thedatabank.com

http://www.thedatabank.com/

https://www.facebook.com/thedatabank http://twitter.com/#!/thedatabank http://www.linkedin.com/company/thedatabank

On Fri, Nov 8, 2013 at 12:36 PM, soozler notifications@github.com wrote:

The other thing to consider, is that if I were to pull the "Walmart" organization from my DB in the format I suggested above, it would be about a 50 megabyte json file and close to a million rows of sql data...

— Reply to this email directly or view it on GitHubhttps://github.com/wufm/osdi-docs/issues/42#issuecomment-28086269 .

[raysuelzer]

I don't think that is has to be in this release, but for this to get serious traction with union clients and them to push for its adoption with vendors (whom we spend 10's of millions a year on) that some sort of way to transfer information about union membership and employment between databases is a must have at some point.

Perhaps it is a separate API that eventually gets adopted by OSDI as it matures.

Ray Suelzer Mobile: (202) 714-8676

On Fri, Nov 8, 2013 at 2:00 PM, mpaquette1 notifications@github.com wrote:

I would argue for the 80/20 rule on required data structures, in this case sticking with election-law requirements by providing one field for employer and one field for occupation. Future OSDI extensions (or independent APIs) can cover such detailed and industry-specific data needs as a fully relational employment history, worker training and certifications, section 3 eligibility, union membership, etc. These types of structures seem to be outside of our scope, at least in the first release.

Mark Paquette Co-founder & CTO thedatabank, inc 612-455-3502 mark@thedatabank.com

http://www.thedatabank.com/

https://www.facebook.com/thedatabank http://twitter.com/#!/thedatabank http://www.linkedin.com/company/thedatabank

On Fri, Nov 8, 2013 at 12:36 PM, soozler notifications@github.com wrote:

The other thing to consider, is that if I were to pull the "Walmart" organization from my DB in the format I suggested above, it would be about a 50 megabyte json file and close to a million rows of sql data...

— Reply to this email directly or view it on GitHub< https://github.com/wufm/osdi-docs/issues/42#issuecomment-28086269> .

— Reply to this email directly or view it on GitHubhttps://github.com/wufm/osdi-docs/issues/42#issuecomment-28093234 .

[joshco]

First off, there's a question of if we handle a single employer or multiple, but I think that's orthogonal to the extended information issue.

For the extended information issue I think we can find a middle ground here. If we change Ray's proposal to rename his top level attribute name from "employer" to "employer_details", won't it smoothly sit side by side to Mark Paquette's "employer" and "occupation" attributes? Of course, the specification would make it optional, so that products that don't capture that kind of information wouldn't have a problem.

employer_details could also be a link with it's own resource collection, since it looks like the actual employer details don't vary by person. Do the parameters like bargaining_units for employer "acme" change depending on if it is associated to josh or ray?

[joshco]

Created feature/employers

• Adds basic employer info to person, employer name and occupation
• Created new resource collection for employer details

[joshco]

MOTION to merge feature/employers This merges in a new resource collection that has employer details, based on Ray's schema proposal

Raise objections by Tuesday 5pm eastern

[joshco]

The complex proposal failed. Proposal: Add employer and occupation as simple text fields