W3C home > Mailing lists > Public > public-opengov@w3.org > July 2013

Re: New version of Popolo spec for legislative data published

From: Chad Robinson <mr.chad.robinson@gmail.com>
Date: Mon, 29 Jul 2013 13:26:48 -0400
Message-ID: <CAPEFF0ksZpXTuCk-+17B2WyqWpmBAeanoa3N=HK2J9qiZF2KjA@mail.gmail.com>
To: James McKinney <james@opennorth.ca>
Cc: public-opengov@w3.org
I totally understood that you didn't want Popolo to try to be everything to
everyone. I was interested specifically because I want to build some state
government org charts and wanted to make sure others could easily reference
all the information for other purposes. This seemed like a natural choice
to implement it using this data standard, should I be able to include on
the information I require.

I'll be use to use the schema:image property and alternate name property
and I believe that should address my primary concerns.

Thank you,


On Sun, Jul 28, 2013 at 11:03 AM, James McKinney <james@opennorth.ca> wrote:

> The "alternate name" property can be used for an abbreviated name. In
> Canada, each federal program and service is given an abbreviation through
> the Federal identity Program (FIP), in which case the "identifier" property
> may be an option, since the abbreviation is part of a specific naming
> scheme (FIP in this case). In most cases, though, "alternate name" is best.
> For the logo, you can certainly use the "logo" property from
> http://schema.org/GovernmentOrganization, or you can use the more general
> "image" property, which is common to all Schema.org classes, notably the
> Person class. I've added an issue to add this property:
> https://github.com/opennorth/popolo-spec/issues/34
> I should note that Popolo's goal is not to cover 100% of use cases, so it
> won't define every property everyone needs. You are free to add new
> properties to your data as you see fit, or mix-in other data
> specifications. Properties will be added to Popolo for common use cases.
> For example, using an image to identify an object is a common use case, so
> adding schema:image makes sense. On the other hand, adding a property for a
> person's saliva (which NIEM does, for its law enforcement use cases) will
> probably forever be out of scope for Popolo.
> James
> On 2013-07-26, at 1:25 PM, Chad Robinson wrote:
> 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
Received on Monday, 29 July 2013 17:27:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:54 UTC