FEC ids aren't consistent for legislators #2

Closed
jsfenfen opened this Issue Nov 13, 2012 · 14 comments

Comments

Projects
None yet
4 participants
@jsfenfen
Contributor

jsfenfen commented Nov 13, 2012

Hey @konklone fec_ids should probably not go in the id section because they can change. (Candidate ids start with the chamber--house id's start with an 'H' and senate ids start with an 'S').

To complicate matters, a single lawmaker can have multiple ids at once; for the '12 cycle, Michelle Bachman has a presidential id P20002978 and a house id H6MN06074.

Another, more common, example: Martin Heinrich, in NM, just won a senate seat, with id S2NM00088 but he also has a house id for his old job H8NM01224; these are both valid FEC ids for the '12 cycle.

If one were being strict about this, fec_ids would have a many-to-many relationship with term (b/c the same id can be reused from one cycle to the next, I believe).

@JoshData

This comment has been minimized.

Show comment
Hide comment
@JoshData

JoshData Nov 13, 2012

Member

But at most one fec_id per term, right?

Member

JoshData commented Nov 13, 2012

But at most one fec_id per term, right?

@jsfenfen

This comment has been minimized.

Show comment
Hide comment
@jsfenfen

jsfenfen Nov 13, 2012

Contributor

Sadly no; bachman raised money both for her presidential bid and her house race this cycle. The campaign finance limits are applied per race, I think, so the system probably reflects that; one can max out to her as a house candidate and as a presidential candidate.

Contributor

jsfenfen commented Nov 13, 2012

Sadly no; bachman raised money both for her presidential bid and her house race this cycle. The campaign finance limits are applied per race, I think, so the system probably reflects that; one can max out to her as a house candidate and as a presidential candidate.

@konklone

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone Nov 13, 2012

Member

Sounds like the simplest solution is just to make this an array - all FEC IDs which can apply to this person. I don't think the complexity cost of doing many-to-many between FEC IDs and individual terms is going to be worth it, but we also clearly don't want to just exclude any FEC IDs from the system because they're weird sometimes.

Member

konklone commented Nov 13, 2012

Sounds like the simplest solution is just to make this an array - all FEC IDs which can apply to this person. I don't think the complexity cost of doing many-to-many between FEC IDs and individual terms is going to be worth it, but we also clearly don't want to just exclude any FEC IDs from the system because they're weird sometimes.

@JoshData

This comment has been minimized.

Show comment
Hide comment
@JoshData

JoshData Nov 13, 2012

Member

@jsfenfen, Oh er, sorry you said that the first time. :)

@konklone Sounds good. (An alternative would be to put the fec_id for House/Senate races only on the term, where it seems to be at-most-one (and the placement would also code the election cycle), and either ignore presidential fec_ids or put them as you're saying in a list on the person-level id node.)

Member

JoshData commented Nov 13, 2012

@jsfenfen, Oh er, sorry you said that the first time. :)

@konklone Sounds good. (An alternative would be to put the fec_id for House/Senate races only on the term, where it seems to be at-most-one (and the placement would also code the election cycle), and either ignore presidential fec_ids or put them as you're saying in a list on the person-level id node.)

@jsfenfen

This comment has been minimized.

Show comment
Hide comment
@jsfenfen

jsfenfen Nov 13, 2012

Contributor

One could apply it retrospectively to terms, and only give each legislator
the FEC_ID for the seat they won.

On Tue, Nov 13, 2012 at 5:30 PM, Eric Mill notifications@github.com wrote:

Sounds like the simplest solution is just to make this an array - all FEC
IDs which can apply to this person. I don't think the complexity cost of
doing many-to-many between FEC IDs and individual terms is going to be
worth it, but we also clearly don't want to just exclude any FEC IDs from
the system because they're weird sometimes.


Reply to this email directly or view it on GitHubhttps://github.com/unitedstates/congress-legislators/issues/2#issuecomment-10346829.

Contributor

jsfenfen commented Nov 13, 2012

One could apply it retrospectively to terms, and only give each legislator
the FEC_ID for the seat they won.

On Tue, Nov 13, 2012 at 5:30 PM, Eric Mill notifications@github.com wrote:

Sounds like the simplest solution is just to make this an array - all FEC
IDs which can apply to this person. I don't think the complexity cost of
doing many-to-many between FEC IDs and individual terms is going to be
worth it, but we also clearly don't want to just exclude any FEC IDs from
the system because they're weird sometimes.


Reply to this email directly or view it on GitHubhttps://github.com/unitedstates/congress-legislators/issues/2#issuecomment-10346829.

@konklone

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone Nov 13, 2012

Member

We could do both? In the main "id" node, have an array of all FEC IDs, and then on each term, put all FEC IDs that were valid for them during that term. I actually wouldn't be bothered if a presidential FEC ID appeared on either their top-level or per-term lists.

Member

konklone commented Nov 13, 2012

We could do both? In the main "id" node, have an array of all FEC IDs, and then on each term, put all FEC IDs that were valid for them during that term. I actually wouldn't be bothered if a presidential FEC ID appeared on either their top-level or per-term lists.

@dwillis

This comment has been minimized.

Show comment
Hide comment
@dwillis

dwillis Nov 14, 2012

Member

Couple of thoughts - if we do an array of FEC ids, would we update historic legislator files to include new IDs if they happen to win election after a period of not being in Congress? I agree that some kind of look-up is useful, but I wonder if that's a separate file or whether we need to have FEC history in the "id" node.

Member

dwillis commented Nov 14, 2012

Couple of thoughts - if we do an array of FEC ids, would we update historic legislator files to include new IDs if they happen to win election after a period of not being in Congress? I agree that some kind of look-up is useful, but I wonder if that's a separate file or whether we need to have FEC history in the "id" node.

@konklone

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone Nov 14, 2012

Member

Yeah, we would go back and update the historical legislator file with a new ID. My proposal clearly jettisons history, so if it's a vital thing to keep, we'd need to have a separate file.

Member

konklone commented Nov 14, 2012

Yeah, we would go back and update the historical legislator file with a new ID. My proposal clearly jettisons history, so if it's a vital thing to keep, we'd need to have a separate file.

@konklone

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone Nov 15, 2012

Member

So I think we've proposed 3 solutions - let's pick one:

  1. Keep a separate file that maps FEC IDs to people per-term
  2. Store a top-level array of all FEC IDs that ever applied, and store an array on each term of all FEC IDs applied during that term
  3. Store a top-level array of all FEC IDs that ever applied

I do nothing with FEC IDs myself, so my preference is the simplest, #3 - since it seems like you could always answer the most common question (given this FEC ID, who does it refer to?) with that top level array. But you guys know the field better, so if you think #1 or #2 is worthwhile, we can do that, assuming you feel like doing the work to populate the extra fields and/or file.

Member

konklone commented Nov 15, 2012

So I think we've proposed 3 solutions - let's pick one:

  1. Keep a separate file that maps FEC IDs to people per-term
  2. Store a top-level array of all FEC IDs that ever applied, and store an array on each term of all FEC IDs applied during that term
  3. Store a top-level array of all FEC IDs that ever applied

I do nothing with FEC IDs myself, so my preference is the simplest, #3 - since it seems like you could always answer the most common question (given this FEC ID, who does it refer to?) with that top level array. But you guys know the field better, so if you think #1 or #2 is worthwhile, we can do that, assuming you feel like doing the work to populate the extra fields and/or file.

@JoshData

This comment has been minimized.

Show comment
Hide comment
@JoshData

JoshData Nov 15, 2012

Member

I vote #3!

http://razor.occams.info

On 11/15/2012 06:07 PM, Eric Mill wrote:

So I think we've proposed 3 solutions - let's pick one:

  1. Keep a separate file that maps FEC IDs to people per-term
  2. Store a top-level array of all FEC IDs that ever applied, and store
    an array on each term of all FEC IDs applied during that term
  3. Store a top-level array of all FEC IDs that ever applied

I do nothing with FEC IDs myself, so my preference is the simplest, #3

  • since it seems like you could always answer the most common question
    (given this FEC ID, who does it refer to?) with that top level array.
    But you guys know the field better, so if you think #1
    #1 or #2
    #2 is
    worthwhile, we can do that, assuming you feel like doing the work to
    populate the extra fields and/or file.


Reply to this email directly or view it on GitHub
#2 (comment).

Member

JoshData commented Nov 15, 2012

I vote #3!

http://razor.occams.info

On 11/15/2012 06:07 PM, Eric Mill wrote:

So I think we've proposed 3 solutions - let's pick one:

  1. Keep a separate file that maps FEC IDs to people per-term
  2. Store a top-level array of all FEC IDs that ever applied, and store
    an array on each term of all FEC IDs applied during that term
  3. Store a top-level array of all FEC IDs that ever applied

I do nothing with FEC IDs myself, so my preference is the simplest, #3

  • since it seems like you could always answer the most common question
    (given this FEC ID, who does it refer to?) with that top level array.
    But you guys know the field better, so if you think #1
    #1 or #2
    #2 is
    worthwhile, we can do that, assuming you feel like doing the work to
    populate the extra fields and/or file.


Reply to this email directly or view it on GitHub
#2 (comment).

@dwillis

This comment has been minimized.

Show comment
Hide comment
@dwillis

dwillis Nov 16, 2012

Member

I also vote #3.

Member

dwillis commented Nov 16, 2012

I also vote #3.

@jsfenfen

This comment has been minimized.

Show comment
Hide comment
@jsfenfen

jsfenfen Nov 16, 2012

Contributor

Don't have strong preference. Am officially voting "present".

On Fri, Nov 16, 2012 at 3:45 PM, Derek Willis notifications@github.comwrote:

I also vote #3.


Reply to this email directly or view it on GitHubhttps://github.com/unitedstates/congress-legislators/issues/2#issuecomment-10461521.

Contributor

jsfenfen commented Nov 16, 2012

Don't have strong preference. Am officially voting "present".

On Fri, Nov 16, 2012 at 3:45 PM, Derek Willis notifications@github.comwrote:

I also vote #3.


Reply to this email directly or view it on GitHubhttps://github.com/unitedstates/congress-legislators/issues/2#issuecomment-10461521.

@konklone

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone Nov 16, 2012

Member

Done!

Member

konklone commented Nov 16, 2012

Done!

@konklone konklone closed this Nov 16, 2012

@konklone

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone Nov 16, 2012

Member

The commit:
4c5664e

Member

konklone commented Nov 16, 2012

The commit:
4c5664e

konklone pushed a commit that referenced this issue Oct 25, 2017

Merge pull request #2 from msimonborg/master
incorrect zip code for Fischer F000463 Omaha address
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment