Most of these functions are not available to all users, except viewing available datasets. Some of the remaining options require being at least at a 'curator' level or similar. Deleting entire datasets is generally reserved for the original owner (creator).

Create, update and delete actions on datasets are the most privileged functions within the system. As a result, most all dataset actions are accessed (if permissions exist) through the broad Datasets tool [] from the main tools listing, or from privileged positions on a few other screens.

Selecting the Dataset tool can make available a variety of functions.

View Datasets

The first screen you see after invoking the Dataset tool provides a listing of available (that is, access rights have been granted; some datasets might be private) to you:

A couple of aspects are worth noting from this screen:

• Note the 'structWSF #1' header. Each Web services framework available to the network (both here and remotely) is assigned a designator. The datasets listings are organized, then, by the host structWSF
• For each structWSF, there may be 1 to N datasets listed
• For datasets for which you have various enhanced permissions, the tools are then shown and these functions are accessed via the links and icons in the right column.

As an example, say, let's scroll down further to dataset #23 in this structWSF and see these tools:

We'll discuss these three functions in the sub-sections below.

Join Datasets

If we scroll to the end of all of the available datasets we see the two overall registry functions for datasets, Join or Create:

We'll discuss creating a new dataset in a moment, so let's first look at the Join function.

For most read actions (Browse, Search, View Record, List Databases) simple access is sufficient to access a public dataset. However, for any actions beyond reading (such as Create, Update or Delete), you must be a registered member of a given dataset and have appropriate CRUD rights.

This is achieved by Joining. The Join option [] brings up this screen, which is a similar listing to the one noted above:

A key difference is the Join link, which, if invoked, enables you to have higher-function access to that dataset. After a simple confirmation screen, your membership is complete.

"Joining" a dataset is necessary in order to effectuate the varied read-write permissions assignable to users. Once joined, now as a member you will likely see many more tools available to you throughout other aspects of conStruct.

Manage Permissions

To see how this operates, let's shift our perspective from a user of a dataset to its owner. As owners, we have the ability to set basic CRUD (create - read - update -delete) rights to individual users, groups or roles.

We begin this process by clicking on the Manage Permissions icon [] that occurs at various points throughout the application (including at the bottom of the dataset listing as described above). What next appears is a listing of roles, individuals, or groups, each of which may have differential rights and access to this dataset:

These assignments happen via CRUD rights (Create [], Read [], Update [], Delete [] ) at the dataset level as provided to other structWSF installations and internal users (by IP address). The instance level CRUD rights are governed by the standard Drupal user permissions framework for the datasets available to a given Drupal installation (not shown).

Since each tool (Web service) in the system is also characterized as to which of the CRUD actions it supports, this simple assignment then provides the basis for tools access and use rights.

Because there are potentially many combinations of datasets, tools, users, roles and permissions, these possible assignments are combined into a number of standard, pre-configured profiles (such as Public, Private, Curated and Collaborative) that make it easy to rapidly set these parameters. Of course, if more fine-grained control is needed or desirable, more profiles may be created or individual assignments to a tool-dataset-role-permission combo may be made.

The observant reader has perhaps noticed that much of this assignment and rights infrastructure builds from Drupal's existing Organic Groups (OG) contributed modules. While this framework provides our needed functionality, some of the terminology (groups v datasets, for one example) can be a bit confusing at times. Modifications are presently underway to cast some screen changes and overlays to the existing OG user interface to overcome these issues. Please stay tuned!

Create Dataset

One of the more important permissions is the right to create a dataset []. If allowed and when invoked, the following screen appears:

This is a fairly comprehensive screen and we will not cover all options. Basically, the key actions are to name the dataset, give it a good descriptor, and tell the system where it exists.

External datasets are referred to by URI (as are local ones, except they can be named with the 'localhost' convention). The registry of an external dataset requires a two-way handshake:

• First, the publishing site and its structWSF Web services framework must already have granted the remote (that is, our current) location access and other CRUD rights (or not)
• Second, we must register our access to that remote (to us) external Web services framework. So, the orignial dataset publisher posts its content and notifies others as to availability; then others acknowledge they indeed plan to access the dataset.

By the way, the above screen is also what is used for the Update description of the dataset [] tool as well.

Delete Dataset

Lastly, and a right that should be granted only rarely, is the permission to delete a dataset []. At time of creation, owners automatically get this right and they are the only ones who may assign it.

When external datasets are involved, there of course can be no deletion rights because that could adversely affect the publishing host. Rather, the delete function for a registered external dataset involves removing the link from the current location to the remote external dataset.