Re: New version of Popolo spec for legislative data published

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