You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, a Committee can be linked to a Jurisdiction in at least two ways:
A Committee references a CommitteeType which references a Jurisdiction.
By subclassing Organization, Committee also inherits an optional reference to a Jurisdiction.
Feels redundant. Looking back at our earlier convo, seems like Committee Type was defined as its own data type because we believe the available types and their regulatory meanings will vary across jurisdictions.
I don't doubt this, but I wonder how much bearing it should have on the specification. Why does it matter if "candidate" type committees in WA file at a different frequency, disclose different transactions or otherwise have different rules from "candidate" type filing committees in IL? What's wrong with allowing the filings, transactions, etc. associated with these committees to differ depending on the committee's jurisdiction, even while they're all grouped under the same label?
This of course wouldn't rule out jurisdiction-specific ETL code for integrating the committees and filings into the jurisdictionally agnostic models. I'm just saying the rules surrounding committee types might not need to be reflected in the schema.
For now, I've left the .jurisdiction field off of the Committee model. But my proposal would be:
Not include a Committee Type as it's own data type and, instead, have an open text .type or .classification field on Committee
Just use the .jurisdiction field Committee inherits from Organization.
The text was updated successfully, but these errors were encountered:
I vote for 1 (which, on reflection, isn't mutually exclusive with 2, and perhaps that was your point all along). I think Committee Type is a genuine thing that ought to be represented by this spec, but I also don't want the perfect to be the enemy of the good - it's certainly not the most important thing for the spec to describe.
There are a variety of rules at different jurisdictional levels that apply to certain Committee types and not others, way beyond just filing frequency. Contribution limits is the big one that occurs to me offhand.
That said, it's hard to see what wouldn't be accomplished by just allowing a free-text field for type attached to a Committee and then using Committee.jurisdiction to disambiguate between, say, Ohio and Florida PACs or whatever. As long as one ETL system is running for a given jurisdiction, it's easy to enforce consistency, and there's no expectation of cross-jurisdictional consistency in the committee types since no such thing exists in the real world. (Well, ok, it kinda exists but technically doesn't).
I'm working on filling out @aepton's implementation of the Campaign Finance enhancement proposal, and I've got a few questions regarding the spec.
Currently, a
Committee
can be linked to aJurisdiction
in at least two ways:Committee
references aCommitteeType
which references aJurisdiction
.Organization
,Committee
also inherits an optional reference to aJurisdiction
.Feels redundant. Looking back at our earlier convo, seems like Committee Type was defined as its own data type because we believe the available types and their regulatory meanings will vary across jurisdictions.
I don't doubt this, but I wonder how much bearing it should have on the specification. Why does it matter if "candidate" type committees in WA file at a different frequency, disclose different transactions or otherwise have different rules from "candidate" type filing committees in IL? What's wrong with allowing the filings, transactions, etc. associated with these committees to differ depending on the committee's jurisdiction, even while they're all grouped under the same label?
This of course wouldn't rule out jurisdiction-specific ETL code for integrating the committees and filings into the jurisdictionally agnostic models. I'm just saying the rules surrounding committee types might not need to be reflected in the schema.
For now, I've left the
.jurisdiction
field off of theCommittee
model. But my proposal would be:Committee Type
as it's own data type and, instead, have an open text.type
or.classification
field onCommittee
.jurisdiction
fieldCommittee
inherits fromOrganization
.The text was updated successfully, but these errors were encountered: