Re: Popolo draft comments

Hi Robert,

Thanks for your feedback! Replies inline.


On 2013-05-04, at 5:04 PM, Robert Cheetham wrote:

> Popolo Folks,
> 
> I just recently joined so I've been sifting through some of the previous comments as I tried to assemble some thoughts, so this might be a little scattered, but comments follow: 
> 
> General
>  * I agree with some of the previous comments regarding the mixing of the data with the implementation details (references to MongoDB)

Yes, this will be corrected in the next version.


>  * I like the support of reduced dates - we've found this to be pretty important
> 
> 2.1/5.1 Person
>  * Email - From the sample, I can't quite tell if this will support multiple email addresses for each person, but I think it's important

We will be restructuring contact details in such a way as to allow for multiple email addresses (see below). Out of curiosity, in what situations have you had multiple addresses? Was each address tied to a distinct context?


>  * Email part 2 - In the past few years, many legislatures are shifting from publishing email addresses to email forms - should this be handled as a URL in the Email field, as a link in the links node or as a different field?

I would put it under the "links" property.


>  * In addition to links, I think it is important to provide a node for identifiers used in other systems - these may be OpenStates id's, OCD paths, VoteSmart ids, etc. (this is already in the organization 

Yes, we will replicate the identifiers property from Organization onto Person.


>  * Some concept of Political Party is probably important

Couldn't you use Organization for that?


>  * The current spec seems to be missing some information about the provenance of the data - something like "last update date/time" and "last update user" is probably the bare minimum, but a node that would provide a place for reference citations and source information would be important

In the current version, this is left to each implementation to decide, but we can use dcterms:created and dcterms:modified for the RDF and perhaps settle on created_at and updated_at for the JSON. I think adding in user details may be too implementation-specific, but in RDF we can at least recommend dcterms:creator. Links to sources, etc. can go in the links property.


> 2.2/5.2 Organization
>  * Same point about metadata related to provenance of the information
>  * I would suggest adding a links node here that is similar to the Person - many legislatures and other government entities have their own YouTube, Twitter as well as their own web sites

Good idea.


>  * Is there a way to indicate upper/lower house

You can use the "classification" property to classify organizations as such.


>  * Is there a way to support judicial and executive offices?

Yes, through the Post class.


>  * Is there a way to indicate hierarchical relationships between organizations?  For example, a parliament contains an upper house and a lower house and a lower house contains several committees

Yes, through org:subOrganizationOf in RDF or through parent_id in JSON.


>  * Is there a way to record the geographic hierarchy of a legislative body?  For example, city government is located within a state government, which is located within a national system.

This is a priority for future classes to be added to Popolo: https://github.com/opennorth/popolo-standard/issues/21


>  * There is a lot of other structured information that could potentially be captured about legislative bodies..  For example, the number of seats, the electoral system (constituencies vs. proportional representation), number of years between elections, election rules, inauguration rules, etc.

The number of seats is communicated by using the Post class to define each seat.

If you can point to a controlled vocabulary for electoral systems, I would be happy to recommend it. As for the other properties, I am not familiar with systems with such properties. If you can point to some examples (or preferably some existing standards), that will help us choose a property that fits with the most existing implementations. Otherwise, for now, those properties are left to each implementation to define. Our priority is to cover the highest demand, most common properties.


> 2.3/5.3 Address
>  * this structure makes a lot of sense
>  * might be good to capture the country, though this may be something that can be captured at the Organization level
>  * Phone/Fax - there are often multiple phones assigned to a given address - I think this can be accommodated with this structure.  Is that the case?

Given reported challenges with the current proposal, we will switch to a more free-form structure. In JSON, a top-level "contact_details" property will be an array of objects, each of which has "type", "label", "value" and/or "note" properties, for example:

{
  "type": "voice",
  "label": "A human-readable label for this property",
  "value": "+1-800-555-0100;ext=555",
  "note": "Any additional notes about the property, e.g. grouping information"
}

In RDF, each contact detail will likely have an associated class, e.g. vcard:Voice. The properties would be rdfs:label, rdf:value, skos:note.


> 5.4 Post
>  * I think the array of addresses makes sense here
>  * Would membership in committees handled using the Membership or a committees node on the Post?

The soon-to-be-merged changes to Post/Membership will require a membership instance to express any person belonging to any organization: https://github.com/opennorth/popolo-standard/wiki/2013-02-28-Rework-Membership-and-Post

If there is a seat in a committee that exists without anyone holding it, you may want to create a Post for it. Posts are optional, however.


>  * It seems like there needs to be some sort of geographic id that would tie the office to a constituency or region - I'm guessing this would on the Post class.  Would it make sense to use an id system like the Open Civic Data (OCD) - https://github.com/opencivicdata/ocd-division-ids

Yes, we should recommend that ID system (among others) when working on this issue: https://github.com/opennorth/popolo-standard/issues/21

Thanks!

James


> 5.5 Membership
>  * No comments
> 
> 
> Best,
> 
> Robert
> 
> 
> ------------------
> Robert Cheetham
> 
> Azavea  |  340 N 12th St, Ste 402, Philadelphia, PA
> cheetham@azavea.com  | T 215.701.7713  | F 215.925.2663
> Web azavea.com  |  Blog azavea.com/blogs  |  Twitter @rcheetham  and @azavea
> 
> Azavea is a B Corporation - we apply geospatial technology to create better communities 
> while advancing the state-of-the-art through research. Join us in creating a better world.
>