Re: New version of Popolo spec for legislative data published

James,

Going off of the GovernmentOrganization spec from schema.org, logo would be
one addition I'd want to see added. Also, would abbreviation best go under
"alternate name" or as its own property?


On Thu, Jul 25, 2013 at 8:06 PM, James McKinney <james@opennorth.ca> wrote:

> Hi Chad,
>
> Can you describe what sort of things are missing that you would need for
> your use case? It's quite possible that fulfilling your requirements may
> not require that many changes to the spec.
>
> Thanks,
>
> James
>
> On 2013-07-25, at 7:12 PM, Chad Robinson wrote:
>
> James,
>
> I know you said you initally were working on Popolo with legislative
> activity as the focus. I'm more interested in working with executive
> agencies, which right now the spec isn't best suited to. Do you have any
> plans on expanding Popolo to help it better address relevant agency
> metadata within the Organization class? Should I be looking to a different
> spec for executive agency information?
>
>
> On Tue, Jul 16, 2013 at 11:48 AM, James McKinney <james@opennorth.ca>wrote:
>
>> Hi Mike,
>>
>> Thanks for your comments. The current spec started with the classes for
>> which there would be the greatest agreement: people and orgs. As mentioned,
>> the current classes being considered for addition are: areas (like
>> electoral districts), events, documents and votes. There are issues for
>> each of them in the tracker:
>> https://github.com/opennorth/popolo-spec/issues?state=open Legislation
>> is very unlikely to be standardized in the details, so custom extensions
>> will almost always be required. For legislation, we would start with a
>> generic top-level "Document" class, and then subclass it to make classes
>> for legislation, agendas, minutes, etc. Elections would similarly be a
>> subclass of the more generic "Event" class.
>>
>> By the way, anyone can start writing the spec for a new class, following
>> the same process and style as other Popolo classes, and I would be happy to
>> edit and merge that work into the project.
>>
>> Re: id versus person_id: expansions like "person_id" or "organization_id"
>> are reserved for foreign keys, and "id" is always the current object's
>> identifier. Many users would be familiar with similar conventions from
>> popular ORMs. If you're actually looking for a way to flag the current
>> object as a Person object, I'll be adding a little more JSON-LD soon, in
>> which case you can use a "@type" property to communicate the current
>> object's class.
>>
>> Re: email, you can have that information as an email property on the
>> person and/or in a contact_details object. It's your choice. There seemed
>> to be an interest in keeping a primary/preferred email on the main object,
>> since it is such a common use case, instead of having users look up the
>> "email" contact detail every time. In some systems, no other contact
>> details are relevant besides the email. You are the second person to ask
>> though. Anyone else in favor of removing the email property from the Person
>> class, and instead requiring the use of contact_details?
>>
>> Cheers,
>>
>> James
>>
>> On 2013-07-16, at 11:10 AM, Mike Shultz wrote:
>>
>> I'm curious to know how far you intend to take this spec.  It seems good
>> for the general-level information on people and organizations, and we could
>> use the vast majority of it right now.  If we were to implement today, we
>> would have to extend it greatly for all of our various other data.
>>  However, in your description, you note that this spec is "focusing on
>> the legislative branch of government," but you don't have anything for
>> representing pieces of legislation or individual votes yet.  Do you intend
>> to expand into this area?
>>
>> Do you intend to expand into elections, or would that be the case of
>> something that would need to be extended by the implementation?
>>
>> I only have a couple comments on the published spec itself.  'email' of
>> the 'person' object should probably be moved into 'contact_details'.  There
>> are many cases where you don't see a single unique E-mail for all
>> individuals.
>>
>> And it's pretty much personal preference, but I'd like to see the 'id'
>> field expanded into it's full name.  So 'id' of the 'person' object would
>> instead be 'person_id'.  But that's really just personal preference and I
>> think might be a little clearer to end users.
>>
>> Good stuff, so far.
>>
>>
>> On Fri, Jul 12, 2013 at 2:37 PM, James McKinney <james@opennorth.ca>wrote:
>>
>>> Forgot link to GitHub tracker:
>>> https://github.com/opennorth/popolo-spec/issues
>>>
>>> On 2013-07-12, at 4:28 PM, James McKinney wrote:
>>>
>>> Back in March I announced Popolo, a project to develop open government
>>> data specifications, focusing on the legislative branch of government,
>>> while remaining useful to a broad set of use cases:
>>> http://popoloproject.com/ Since then, it's been used by mySociety in
>>> PopIt [1], by the Sunlight Foundation in its municipal data projects [2],
>>> and it's making its way into other projects by the Open Knowledge
>>> Foundation and others.
>>>
>>> Today, I am happy to announce a new version that incorporates the great
>>> feedback that I received from members of this list and others. Highlights:
>>>
>>> - re-worked memberships to make it easier to describe simple, complex
>>> and historical relationships between people and organizations
>>> - re-worked the contact information model to be more flexible and to
>>> support a wider variety of use cases
>>> - described more ways to serialize data as JSON, in particular how to
>>> embed, for example, memberships on a person object
>>> - added metadata fields to all classes (timestamps and attribution)
>>>
>>> In addition to improving the core spec, improvements have been made to
>>> the website and related docs:
>>>
>>> - significantly re-organized content to make it easier to find what's
>>> relevant to you
>>> - added appendices that include a collection of best practices and
>>> patterns discovered through the development process
>>>
>>> At this point, I would love to get more feedback and participation in
>>> the following questions:
>>>
>>> 1. Is the spec useful to you? For the classes it covers (people,
>>> organizations, memberships, contact info), is anything missing? Can you
>>> identify any barriers to adoption, or anything you would change?
>>> 2. Is it easy for you to find answers to questions you have about the
>>> spec? Is the language clear and easy to understand? Is the content
>>> presented in an order than makes sense?
>>> 3. What next class can be added to the spec to make it more interesting
>>> to adopt? Suggestions that have come up previously are: areas (like
>>> electoral districts), events, documents and votes.
>>>
>>> The current next steps for the project are more or less reflected in the
>>> GitHub issue tracker and are based on past comments and feedback, so there
>>> is definitely an opportunity for you to help determine the project's
>>> priorities.
>>>
>>> I'd especially like to thank: James Turk, Paul Tagliamonte, Thom Neale,
>>> Eric Mill, Tom Lee (Sunlight Foundation); Matthew Sommerville, Edmund von
>>> der Burg, Mark Longair, Tom Steinberg (mySociety); David Moore
>>> (Participatory Politics); Robert Cheetham (Azavea); Rufus Pollock (Open
>>> Knowledge Foundation); and Phil Ashlock for their feedback, support,
>>> promotion, and/or implementation of the specification.
>>>
>>> My hope is that, by increasing Popolo's adoption, different groups will
>>> not only publish data that is interoperable, but will more easily develop
>>> interoperable software components, making it easier for groups with fewer
>>> resources to launch websites like http://www.theyworkforyou.com/ or
>>> http://www.opencongress.org/.
>>>
>>> Link: http://popoloproject.com/
>>>
>>> Thanks!
>>>
>>> James
>>>
>>> [1] https://github.com/mysociety/popit-api
>>> [2] https://github.com/opencivicdata
>>>
>>>
>>>
>>
>>
>> --
>> Mike Shultz
>> Web Developer
>> Project Vote Smart
>>
>>
>>
>
>