Re: New version of Popolo spec for legislative data published

An image property has now been added to the Organization class in Popolo. If anyone has a use case that requires a more specific "logo" property, please let me know.

On 2013-07-29, at 1:26 PM, Chad Robinson wrote:

> 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,
> 
> Chad
> 
> 
> 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
>>> 
>>> 
>> 
>> 
> 
>