search

popolo-project / popolo-spec

International legislative data specifications
http://www.popoloproject.com/
99 stars 18 forks source link

Area class and properties #21

Closed evdb closed 10 years ago

evdb commented 11 years ago

New issue description: To close this issue (additional feedback would go in new issues):

Some posts (like "MP for Avalon", "UK's Ambassador to the USA" ) require an area. How should areas be represented and stored?

In PopIt we were going to use a string field which could either be the name of the area or a url to an external service that has an entry for an area (like MapIt). More details and a discussion at mysociety/popit#193

In the W3C org ontology they allow organisations to have sites (an office or a premise) and a location (an internal physical location, like where mail is delivered). Posts are a sub class of organisations so can have sites too. However neither of site or location would seem intended for an entire administrative area.

jpmckinney commented 11 years ago

I would like Popolo to eventually deoine an Area class and properties. If you want to help with that, you can create an inventory of terms and a survey of existing standards for areas, based on the following:

Area

<rdf:Property rdf:about="http://reference.data.gov.uk/def/parliament/represents">
  <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
  <rdfs:comment xml:lang="en">The constituency that the MP holding this seat in parliament represents.</rdfs:comment>
  <rdfs:domain rdf:resource="http://reference.data.gov.uk/def/parliament/Seat"/>
  <rdfs:isDefinedBy rdf:resource="http://reference.data.gov.uk/def/parliament"/>
  <rdfs:label xml:lang="en">Represents</rdfs:label>
  <skos:editorialNote xml:lang="en">No range set on this though for the House of Commons it will be a &lt;http://data.ordnancesurvey.co.uk/ontology/admingeo/WestminsterConstituency&gt;.</skos:editorialNote>
</rdf:Property>

Irrelevant to current spec:

We can postpone this work for now - we have enough to review with just people and orgs, and areas are distinct enough that our decisions about people/orgs shouldn't influence what happens with areas. Not all the above will be relevant, but it's important for the survey to document why an existing standard is unsuitable. Some, for example, may only provide canonical names for places (which is still important to document).

If you must have at least a property for linking posts/memberships to areas in the short term, then in the best case you would find an appropriate existing property for that link, and in the worst case you would come up with something yourself, which may not make it into Popolo once someone volunteers to review all the above standards. I would estimate maybe a week full-time to prepare something like the current Popolo spec for areas.

Coming up with standards goes against the usual hacker ethic of scrapping something together and seeing what works, so I would totally understand the feeling that this is a lot of "process". However, if you want people to adopt your standard, you either need to have a lot of power (dictator), or a lot of support (consensus). With Popolo, I think we have to content ourselves with consensus.

For what it's worth, Billy stores a path to the boundary stored in represent-boundaries.

I had started on an Area class before deciding that I should push out people/orgs to start and then work on areas later. I put my very bare beginnings on the wiki.

jpmckinney commented 11 years ago

Note: recommend open civic data division IDs.

jpmckinney commented 11 years ago

Note from call: ensure a distinction can be made between places and boundaries.

jpmckinney commented 11 years ago

Note from wiki: MapIt supports nested areas through a parent_area column on the mapit_area table. The boundary service used by Billy does not support nested areas.

jpmckinney commented 11 years ago

Adding link to https://github.com/mysociety/popit/issues/193#issuecomment-12362672

jpmckinney commented 11 years ago

See area property at https://github.com/mysociety/popit-api/blob/master/schemas/popolo%2Bmysociety/post.json

paultag commented 10 years ago

I did some rough work on this, here's a brain dump:

I tried a few conversions with the key name division_id. This seemed to work great. I stored the OCD Division ID for the geo-spatial area that it relates to.

It was also added to organizations, which was handy as well, under the same name, division_id.

The use case is two-fold:

I want to find all organizations that are stored for the city of Boston, MA (ocd-division/country:us/state:ma/place:boston), which includes such things as the Boston City Council, or other state-wide organizational entities.

In addition, since districts can be expressed as division IDs (ocd-division/country:us/state:ma/sldl:barnstable_dukes_and_nantucket), it's quite useful to see who holds office for that entity, adding a relation on membership called division_id would allow for this, which allows for finding people by a shape (such as district, city or ward)

Happy to elaborate on any of this!

jpmckinney commented 10 years ago

Thanks, @paultag ! What do you mean by conversions?

paultag commented 10 years ago

Ah, sorry, @jpmckinney - I was talking about the OpenStates => Popolo / OCD conversions -- I was playing with legislative district stuff (apropos our recent thread) for OCD-ized OpenStates data -- but this does apply to non-converted data too! :)

akuckartz commented 10 years ago

Also potentially relevant:

paultag commented 10 years ago

@jpmckinney Any chance we could add division_id (defined as an OCD division ID) to the spec? It'd be really great for the tooling we're building up - I was thinking of using it optionally both on orgs and posts (memberships seem awkward to me, but they might be cool for some situations as well)

jpmckinney commented 10 years ago

I'll add it to the spec when I have a moment, but feel free to use division_id in Pupa in the meantime. mySociety has been using area, but I think that should be reserved for the actual geographical boundary.

jpmckinney commented 10 years ago

@paultag Just thinking about possible implementation concerns. area is a term that can refer to a geographic region without a defined boundary (e.g. "the upscale area of town"), whereas division is more likely an area with a defined boundary. So, area is a superset of division. To reduce the number of terms, we might consider using area_id, which if it begins with ocd-division, is understood to be an OCD division. Any opinion on that?

akuckartz commented 10 years ago

I am having a look at some projects which attempt to adapt the European INSPIRE specifications to Linked Data. Some of them hopefully are also relevant outside Europe.

paultag commented 10 years ago

@jpmckinney - sorry, missed this -- I don't really mind what the name is (I've just been using division_id in my code so far), but it seems like any "area" could be issued a division ID (e.g. I can't think of areas that wouldn't be able to be issued a division ID (perhaps if you're talking about the earth on the whole, that might cause issues :) )

jpmckinney commented 10 years ago

@akuckartz Do you have any links? I know about this group: http://www.w3.org/community/locadd/ and this spec: http://www.w3.org/ns/locn

akuckartz commented 10 years ago

@jpmckinney So far I have compiled a small number of links on this page: https://github.com/OParl/specs/wiki/Geo-und-INSPIRE

Quite a few interesting papers were submitted for the W3C Workshop "Linking Geospatial Data" (link is on the Wiki page).

jpmckinney commented 10 years ago

@paultag I've added area_id and area properties to Membership, Organization, and Post, and added a first draft of an Area spec: http://popoloproject.com/specs/area.html

jpmckinney commented 10 years ago

Closing issue. Report feedback in new issues.