John Lewis wrote:
I want to start a project to document my local government starting at the municipal level and going upwards from there. I want to build an interface to allow people to look up their representatives and their public servants by issue and geographic area or issue and get their contact information back.
I want it to to have fast lookups so community organizers will come to my site first they want to find out who does what. I would also like it to be able to scale geographically so I can get local activist could have their own copy of the database on a local server that they can also delegate access to. I would like to delegate updates to a development version of the database to other people similar to Open Street Map, but I would still like to verify changes so there won't be a flood of bad data. The presentation and the data storage will be separate components.
Knowing this information could you tell me what data management engine would be more appropriate for the task?
I have a strong suspicion that OpenLDAP will be the superior solution for this problem, but you can't say definitively, based on a brief description. I would suggest you start to draw out on paper the types of information you plan to store, and group the related items together. This will give you some idea of what your basic DB records will contain. Then draw out what kinds of search operations you plan to support, or what kinds of data you expect users to be able to retrieve. Figure out what natural interconnections and relationships exist between your records.
Most real world problem sets don't break down into 100% pure tabular data structures, nor do they break down into 100% pure hierarchical structures. But if you find there's a natural hierarchy like geographic area county municipality
as I said before, I would suspect that the hierarchical structure will be a more natural fit. Also, given your requirement to scale out geographically - this is trivial to do with OpenLDAP; it is quite cumbersome to do with SQL servers.
You might also consider a Linked Open Data format. A lot of governments are publishing information using these standards eg. https://www.data.gov/ https://www.denvergov.org/opendata It will allow you to link together data represented by a variety of schema and there are several platforms available, http://ckan.org/instances/# seems to be used by a lot of governments, there's also http://marmotta.apache.org/
-----Original Message----- From: openldap-technical [mailto:openldap-technical-bounces@openldap.org] On Behalf Of Howard Chu Sent: Friday, August 19, 2016 5:24 PM To: John Lewis; openldap-technical@openldap.org Subject: Re: Should I use OpenLDAP or PostgreSQL for this?
John Lewis wrote:
I want to start a project to document my local government starting at the municipal level and going upwards from there. I want to build an interface to allow people to look up their representatives and their public servants by issue and geographic area or issue and get their contact information back.
I want it to to have fast lookups so community organizers will come to my site first they want to find out who does what. I would also like it to be able to scale geographically so I can get local activist could have their own copy of the database on a local server that they can also delegate access to. I would like to delegate updates to a development version of the database to other people similar to Open Street Map, but I would still like to verify changes so there won't be a flood of bad data. The presentation and the data storage will be separate components.
Knowing this information could you tell me what data management engine would be more appropriate for the task?
I have a strong suspicion that OpenLDAP will be the superior solution for this problem, but you can't say definitively, based on a brief description. I would suggest you start to draw out on paper the types of information you plan to store, and group the related items together. This will give you some idea of what your basic DB records will contain. Then draw out what kinds of search operations you plan to support, or what kinds of data you expect users to be able to retrieve. Figure out what natural interconnections and relationships exist between your records.
Most real world problem sets don't break down into 100% pure tabular data structures, nor do they break down into 100% pure hierarchical structures. But if you find there's a natural hierarchy like geographic area county municipality
as I said before, I would suspect that the hierarchical structure will be a more natural fit. Also, given your requirement to scale out geographically - this is trivial to do with OpenLDAP; it is quite cumbersome to do with SQL servers.
http://www.co.washington.pa.us/ArchiveCenter/ViewFile/Item/515
http://www.co.butler.pa.us/Files/Admin/Commissioners/2016-Budget-FINAL.pdf
http://www.beavercountypa.gov/sites/beavercountypa.gov/files/Approved-Rev-De...
I can pull the names of every county office and board from the budget. I suspect that a majority of things are going to be in the executive branch of government.
I will have to get contact information for each and every one of the offices somewhere else. There is a slight chance that the county commissioners will give me that information the easy way, but my friend Mark Howe didn't get the Police to change their format from PDF to CSV until a year and a half into the project being publicly running, so I am not holding my breath.
On 08/19/2016 09:52 PM, Robson, Alan wrote:
You might also consider a Linked Open Data format. A lot of governments are publishing information using these standards eg. https://www.data.gov/ https://www.denvergov.org/opendata It will allow you to link together data represented by a variety of schema and there are several platforms available, http://ckan.org/instances/# seems to be used by a lot of governments, there's also http://marmotta.apache.org/
-----Original Message----- From: openldap-technical [mailto:openldap-technical-bounces@openldap.org] On Behalf Of Howard Chu Sent: Friday, August 19, 2016 5:24 PM To: John Lewis; openldap-technical@openldap.org Subject: Re: Should I use OpenLDAP or PostgreSQL for this?
John Lewis wrote:
I want to start a project to document my local government starting at the municipal level and going upwards from there. I want to build an interface to allow people to look up their representatives and their public servants by issue and geographic area or issue and get their contact information back.
I want it to to have fast lookups so community organizers will come to my site first they want to find out who does what. I would also like it to be able to scale geographically so I can get local activist could have their own copy of the database on a local server that they can also delegate access to. I would like to delegate updates to a development version of the database to other people similar to Open Street Map, but I would still like to verify changes so there won't be a flood of bad data. The presentation and the data storage will be separate components.
Knowing this information could you tell me what data management engine would be more appropriate for the task?
I have a strong suspicion that OpenLDAP will be the superior solution for this problem, but you can't say definitively, based on a brief description. I would suggest you start to draw out on paper the types of information you plan to store, and group the related items together. This will give you some idea of what your basic DB records will contain. Then draw out what kinds of search operations you plan to support, or what kinds of data you expect users to be able to retrieve. Figure out what natural interconnections and relationships exist between your records.
Most real world problem sets don't break down into 100% pure tabular data structures, nor do they break down into 100% pure hierarchical structures. But if you find there's a natural hierarchy like geographic area county municipality
as I said before, I would suspect that the hierarchical structure will be a more natural fit. Also, given your requirement to scale out geographically - this is trivial to do with OpenLDAP; it is quite cumbersome to do with SQL servers.
openldap-technical@openldap.org
-
Howard Chu -
John Lewis -
Robson, Alan