Database Design Notes

(Henrik - July 29, 2009)

Here's the summary from our Trillium application:

to use existing published material, four public meetings, and interviews to create an online library cataloguing how laws, regulations and policies influence urban parks and public spaces without walls. The purpose is to increase the law literacy of people who use and work in public space, thus enriching public discussion

So this implies:

• upload and cataloging capability for existing material
• capturing data from meetings and interviews, probably in the form of cases, together with some wiki pages
• a catalog of laws, regulations, and policies

So at the core:

A table of cases A table of literature references, perhaps with summaries and descriptions A table of "authorities" (laws, regulations, policies)

To round out the core, perhaps a table of organizations (as involved with the cases), and a table of locations of cases.

Five tables. Maybe a good place to start.

(Henrik - July 29, 2009)

Here is a sketch of some ideas for the structure of the database for the regulatory database project.

This is very early, and we will no doubt have an iterative process of developing these ideas.

At its most basic, the idea would be to develop and maintain lists in three broad categories:

1. Public space
2. Community
3. Governance

1. Public space

• activities - like hockey, playgrounds, food
• places and facilites (locations) - like dufferin park
• materials and equipment - like hockey helmets, park benches, zambonis, flowers, hockey sticks
• constituents - like hockey players, children

2. Community

• projects - like develop a new playground, get a new shinny rink
• groups, contacts - like thorncliff folks, friends of dufferin park
• cases - like getting a curb cut. petitioning for a bazaar
• issues - patterns, like market regulation

3. Governance

• policies - like have to wear helmets to play hockey
• regulations - to give concrete form to laws
• laws - like the Occupational Health and Safety Act
• Jurisdictions - Like Toronto and Ontario

That seems fairly straightforward so far, but it gets trickier:

Links

Everything (every item in a list) can get linked to everything else (any item in any other list - more or less) - that can get confusing - not to mention technically tricky - but we would like to keep lists of links of certain things to certain others, and what those links mean

Events

Any combination of things, places, and people, at a given time, constitutes an event - also pretty open ended, but we would like to keep lists of certain events in addition to the above.

Context

Most of the lists above can be hierarchies: for example regulations are parts of laws (or sub-regulations can be parts of regulations can be parts of sub-sections of laws can be parts of laws -- you get the idea. Likewise open ended.

Challenges:

In some ways the connections and combinations of things are the interesting things here.

So in a way the challenge here is to LIMIT the richness of these ideas, to make the database easy to use.