-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why require a Jurisdiction for each Event? #79
Comments
I think the main reason is for scoping Events & deduplication. At present, I believe everyone using these models have a single DB that is multi-jurisdiction- as such there needs to be an easy way to separate Jurisdiction's organizations/events/etc. https://github.com/opencivicdata/pupa/blob/master/pupa/importers/events.py#L40 is an example of where this is done, we consider the unique set of attributes for an Event to be {name,description,start,end,timezone,jurisdiction} & because participants aren't stored on the Event object we can't easily use them like this (for a single-jurisdiction instance Jurisdiction is likely to be an implementation detail that can be essentially ignored) |
How about having an |
Would we do that for all models that depend on Jurisdiction?
…On Thu, Mar 16, 2017 at 5:10 PM, Forest Gregg ***@***.***> wrote:
How about having an Event class without this attribute, and then having a
LegislativeEvent subclass with this attribute that pupa would use?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#79 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAfYmWaHKB0g74TrnO9Im5C5vbJbn2Fks5rmaU0gaJpZM4Mflb8>
.
|
I don't think I understand your question. The |
Would we want do the same for Organization/etc?
…On Thu, Mar 16, 2017 at 5:15 PM, Forest Gregg ***@***.***> wrote:
I don't think I understand your question. The LegislativeEvent would be
the exact same thing as the current Event. The new Event would be
compliant with the OCD spec and ready to be used for non pupa purposes.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#79 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAfYu031jnSlmdXfy4pqx-MfkHT0o2Yks5rmaZqgaJpZM4Mflb8>
.
|
Also, I think we should choose a better name that Legislative* if we do
this, there's nothing specifically Legislative about needing a Jurisdiction
…On Thu, Mar 16, 2017 at 5:23 PM, James Turk ***@***.***> wrote:
Would we want do the same for Organization/etc?
On Thu, Mar 16, 2017 at 5:15 PM, Forest Gregg ***@***.***>
wrote:
> I don't think I understand your question. The LegislativeEvent would be
> the exact same thing as the current Event. The new Event would be
> compliant with the OCD spec and ready to be used for non pupa purposes.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#79 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAAfYu031jnSlmdXfy4pqx-MfkHT0o2Yks5rmaZqgaJpZM4Mflb8>
> .
>
|
Hmm.. interesting. Political campaigns organizations don't really have jurisdictions and we are going to want to model those. I can't think of a governmental organization that doesn't have a jurisdiction. I think we will need to have a conversation of jurisdiction-less organizations, but that should probably happen on https://github.com/opencivicdata/docs.opencivicdata.org/, since the current OCD spec does require jurisdictions. In any case, as you have said, the case for |
FWIW, I feel like Event missing Jurisdiction on docs.opencivicdata.org was an accident, not an intentional choice. If you had an Event that wasn't tied to a Jurisdiction how would you deduplicate it? |
Well, the spec is the spec. We should go through OCDEP process either way. Right now pupa uses name, description, start_time, end_time, timezone, and jurisdiction_id. I think if you added location and removed jurisdiction, you would have something just as deduplicable. If that's not sufficient, we can create a subclass with an appropriate scoping value. Also, for pupa, you can continue to use jurisdiction_id. You'll just use a subclass of an |
location makes sense, forgot that was already required. I'd be open to an
OCDEP
It'll be trickier to implement because it isn't a key on the top level
object, but should be doable if someone is up for tackling it.
…On Thu, Mar 16, 2017 at 5:45 PM, Forest Gregg ***@***.***> wrote:
Well, the spec is the spec. We should go through OCDEP process either way.
Right now pupa uses name, description, start_time, end_time, timezone, and
jurisdiction_id. I think if you added location and removed jurisdiction,
you would have something just as deduplicable.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#79 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAfYlO-F4s1PuXnV2X4r0oUg9Zv04i4ks5rma1jgaJpZM4Mflb8>
.
|
Conversation has moved here. |
The
Event
Django model currently has ajurisdiction
foreign key field with a not null constraint. However, this field is not mentioned in the OCD Event format or in the Event OCDEP.Assuming the typical use case is to model meetings of various public agencies (e.g., a state legislative committee or city council), couldn't that be handled via an
Organization
as an event participant?The text was updated successfully, but these errors were encountered: