figure out good way to handle two positions in the same jurisdiction (data-dot bug 3)

[paultag]

No description provided.

[paultag]

Yeah, so this is a WI blocker.

[paultag]

Potential ideas; using the label syntax (Role (clerk)) to be explicit, not unlike having multiple memberships in pupa raw.

[paultag]

Allowing it implicitly seems like a recipe for bad data.

[paultag]

Perhaps replace the Role / District split with a Role (district). That's actually a bit more interesting, and it'll map to role / label on the membership.

[jamesturk]

I don't think the district is usually the label on a membership is it?

On Wed, Sep 3, 2014 at 3:34 PM, Paul Tagliamonte notifications@github.com
wrote:

Perhaps replace the Role / District split with a Role (district). That's
actually a bit more interesting, and it'll map to role / label on the
membership.

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

[paultag]

Hurm, you're right, I think we usually set role to the same as label. I think I mean post. Let me double check if what I'm thinking makes sense

[paultag]

Right, got pretty into implementing that, turns out to be a bad idea, since you'd need a column per person.

Next idea is a Position (1), District (1) fallback (allowing for N alternative positions, strictly paired).

Really not the greatest, but we've got tons of these. We'll throw out the bit in the parens (since the useful data is the value)

[jamesturk]

Sounds good, I assume we can make the (1) optional for the first one?

On Wed, Sep 3, 2014 at 5:57 PM, Paul Tagliamonte notifications@github.com
wrote:

Right, got pretty into implementing that, turns out to be a bad idea,
since you'd need a column per person.

Next idea is a Position (1), District (1) fallback (allowing for N
alternative positions, strictly paired).

Really not the greatest, but we've got tons of these. We'll throw out the
bit in the parens (since the useful data is the value)

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

[paultag]

absolutely

On Wed, Sep 3, 2014 at 6:00 PM, James Turk notifications@github.com wrote:

Sounds good, I assume we can make the (1) optional for the first one?

On Wed, Sep 3, 2014 at 5:57 PM, Paul Tagliamonte notifications@github.com

wrote:

Right, got pretty into implementing that, turns out to be a bad idea,
since you'd need a column per person.

Next idea is a Position (1), District (1) fallback (allowing for N
alternative positions, strictly paired).

Really not the greatest, but we've got tons of these. We'll throw out
the
bit in the parens (since the useful data is the value)

—
Reply to this email directly or view it on GitHub
<
https://github.com/opencivicdata/opencivicdata.org/issues/5#issuecomment-54373992>

.

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

Paul Tagliamonte
Software Developer | Sunlight Foundation