Potentials for Citizen Dan Networks

Inherent in the design and architecture of Citizen Dan is the potential for each instance (single installation) to act as a node in a distributed network of nodes across the Web. Via the structWSF Web service endpoints and appropriate dataset permissions, it is possible for any city in the Citizen Dan network to share (or not) any or all of its data with other cities.

This collaboration aspect has been "baked into the cake" from Day One. The system also supports differential access, rights and roles by dataset and Web service. Thus, city staffs across multiple communities could share data differently than what is provided to the general public.

The structWSF design anticipates four possible deployment modes (or participation methods in a distributed network). These are:

  • Nodes (or portals) — these are standard collaboration environments that support a number of users via a common content management system configured as a community portal; portals may either be publishers or consumers of datasets. Citizen Dan, for example, is a node portal. Each of the next three modes only requires structWSF and not the entire Citizen Dan configuration
  • Gateways — connections to existing external content in the native data formats of the publisher, which are converted and made available to the network in compliant forms
  • Hubs — aggregate suppliers of useful datasets in compliant formats, and
  • Individual dataset contributors and clients, generally located on a desktop machine.

Each of these nodes exposes its data to the rest of the network via a structWSF Web services framework. Each structWSF installation provides an access point and endpoint to the network. Through these installations, data is converted to “canonical” form for use by other nodes on the network with common tools and services provided.

 A Conceptualized Network

In conceptual form, then, the network can be represented as follows:

Conceptualized structWSF Network

Each node has a structWSF instance, the common network denominator, shown in blue.

A key aspect of each structWSF installation is dataset registration and access authorization. Only users with proper authorization may access or exercise certain privileges such as write or updates for a given dataset.

The other core Web services provided with structWSF are the CRUD functional services (create – read – update – delete), import and export, browse and search, and a basic templating system.

A simple but elegant system guides access and use rights. First, every Web service is characterized as to whether it supports one or more of the CRUD actions. Second, each user is characterized as to whether they first have access rights to a dataset and, if they do, which of the CRUD permissions they have. Thereafter, a mapping of dataset access and CRUD rights determines whether users see a given dataset and what Web services (”tools”) are presented to them and how they might manipulate that data.

Because a CMS may employ its own access system and protocols, the potential combinations can become quite large. Let’s take for an example a portal example that layers Drupal (via the conStruct modules) over the structWSF framework. Iin this scenario, we theoretically have these potential access and rights combinations:

  • By dataset
  • By Web service (tool) and whether that tool can potentially support create, read (access), update or delete [CRUD] operations
  • By user role (for example, administrator, owner, curator, contributor, unregistered)
  • By group (for example, SuperWhizBangs, SortOfOKs, Clueless, RockStars).

As a general proposition, these access and rights dimensions can capture most any reasonable use case.

One way to ease the management of these choices at the UI level is to create a series of access patterns or templates — called profiles — to which a newly registered dataset can be assigned. While the Drupal site owner could go in and change or tweak any of the individual assignments, the use of these profiles simplifies the steps needed for the majority of newly registered datasets.

Since all data management aspects of each Citizen Dan instance is also oriented around datasets, expansion to a network mode is quite straightforward. See further the technical documentation on this distributed network and collaboration potential with structWSF (and, by extension, Citizen Dan).