- What is conStruct?
- Individual Tools
- Installation Guide
- Datasets & Access
- Endpoints Access
- Web Services Tutorial
- Individual WS Documentation
- WS: Auth Registrar: Access
- WS: Auth Registrar: WS
- WS: Auth: Lister
- WS: Auth: Validator
- WS: Ontology: Create
- WS: Dataset: Create
- WS: Dataset: Read
- WS: Dataset: Update
- WS: Dataset: Delete
- WS: CRUD: Create
- WS: CRUD: Read
- WS: CRUD: Update
- WS: CRUD: Delete
- WS: Search
- WS: Browse
- WS: Converter: irJSON
- WS: SPARQL
- WS: Converter: BibTeX
- WS: Converter: TSV
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.
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.
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.
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.
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.
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.