Metacat

-----------------------------

------------

------------------

--------------------

To configure Metacat as a node in the DataONE network, configure the properties shown

in the figure above.  The Node Name should be a short name for the node that can

be used in user interface displays that list the node.  For example, one node in

DataONE is the 'Knowledge Network for Biocomplexity'.  Also provide a brief sentence

or two describing the node, including its intended scope and purpose.  

The Node Identifier field is a unique identifer assigned by DataONE to identify

this node even when the node changes physical locations over time.  When Metacat

registers with the DataONE Coordinating Nodes (when you click 'Register' at the

bottom of this form), the Node Identifier is automatically set.  **It is critical that

you not change the Node Identifier**, as that will break the connection with the

DataONE network.  The ability to edit this field is only provided for the rare case

in which a new Metacat instance is being established to act as the provider for an 

existing DataONE Member Node, in which case the field can be edited to set it to

the value of a valid, existing Node Identifier.

The Node Subject and Node Certificate Path are linked fields that are critical for

proper operation of the node.  To act as a Member Node in DataONE, you must obtain

an X.509 certificate that can be used to identify this node and allow it to securely

communicate using SSL with other nodes and client applications.  This certificate can 

either be obtained from the DataONE Certificate Authority, or from a commercial 

provider of certificates. Once you have the certificate in hand, use a tool such 

as ``openssl`` to determine the exact subject distinguished name in the 

certificate, and use that to set the Node Subject field.  Set the Node 

Certificate Path to the location on the system in which you stored the 

certificate file.

The ``Synchronize`` checkbox allows the administrator to decide whether to turn on

synchronization with the DataONE network.  When this box is unchecked, the DataONE

Coordinating Nodes will not attempt to synchronize at all, but when checked, then

DataONE will periodically contact the node to synchrnize all metadata content.

To be part of the DataONE network, this box must be checked as that allows 

DataONE to receive a copy of the metadata associated with each object in the Metacat

system.  The switch is provided for those rare cases when a node needs to be disconnected

from DataONE for maintenance or service outages.  When the box is checked, DataONE

contacts the node using the schedule provided in the ``Synchronization Schedule``

fields.  The example in the dialog above has synchronization occurring once every third

minutes at the 10 second mark of those minutes.  The syntax for these schedules

follows the Quartz Crontab Entry syntax, which provides for many flexible schedule 

configurations.  If the administrator desires a less frequent schedule, such as daily, 

that can be configured by changing the ``*`` in the ``Hours`` field to be a concrete 

hour (such as ``11``) and the ``Minutes`` field to a concrete value like``15``, 

which would change the schedule to synchronize at 11:15 am daily.  

Once these parameters have been properly set, us the ``Register`` button to

request to register with the DataONE Coordinating Node.  This will generate a

registration document describing this Metacat instance and send it to the 

Coordinating Node registration service, which will return a unique Node Identifier

which will be recorded by Metacat.  At that point, all that remains is to wait for

the DataONE administrators to approve the node registration.  Details of the approval

process can be found on the `DataONE web site`_.

.. _DataONE web site: http://www.dataone.org

Metacat has supported fine grained access control for objects in the system since

its inception.  DataONE has devised a simple but effective access control system

that is compatible with the prior system in Metacat.  For each object in the DataONE

system (including data objects, scientific metadata objects, and resource maps), 

a SystemMetadata_ document describes the critical metadata needed to manage that

object in the system.  This metadata includes a ``RightsHolder`` field and an

``AuthoritativeMemberNode`` field that are used to list the people and node that

have ultimate control over the disposition of the object.  In addition, a separate

AccessPolicy_ can be included in the ``SystemMetadata`` for the object.  This ``AccessPolicy``

consists of a set of rules that grant additional permissions to other people, 

groups, and systems in DataONE.  For example, for one data file, two users 

(Alice and Bob) may be able make changes to the object, and the general public may

be allowed to read the object.  In the absence of explicit rules extending these permissions,

Metacat enforces the rule that only the ``RightsHolder`` and ``AuthoritativeMemberNode`` have

rights to the object, and that the Coordinating Node can manage ``SystemMetadata``

for the object.  An example AccessPolicy that might be submitted with a dataset

(giving Alice and Bob permission to read and write the object) follows:

::

  ...

  <accessPolicy>

      <allow>

        <subject>/C=US/O=SomeIdP/CN=Alice</subject>

        <subject>/C=US/O=SomeIdP/CN=Bob</subject>

        <permission>read</permission>

        <permission>write</permission>

      </allow>

  </accessPolicy>

  ...

These AccessPolicies can be embedded inside of the ``SystemMetadata`` that accompany

submission of an object through the `MNStorage.create`_ and `MNStorage.update`_ services, 

or can be set using the `CNAuthorization.setAccessPolicy`_ service.

.. _SystemMetadata: http://releases.dataone.org/online/d1-architecture-1.0.0/apis/Types.html#Types.AccessPolicy

.. _AccessPolicy: http://releases.dataone.org/online/d1-architecture-1.0.0/apis/Types.html#Types.AccessPolicy

.. _MNStorage.create: http://releases.dataone.org/online/d1-architecture-1.0.0/apis/MN_APIs.html#MNStorage.create

.. _MNStorage.update: http://releases.dataone.org/online/d1-architecture-1.0.0/apis/MN_APIs.html#MNStorage.update

.. _CNAuthorization.setAccessPolicy: http://releases.dataone.org/online/d1-architecture-1.0.0/apis/CN_APIs.html#CNAuthorization.setAccessPolicy

Configuration as a replication target

-------------------------------------

DataONE is designed to enable a robust preservation environment through replication

of digital objects at multiple Member Nodes.  Any Member Node in DataONE that implements

the Tier 4 Service interface can offer to act as a target for object replication.  

Currently, Metacat configuration supports turning this replication function on or off.

When the 'Act as a replication target' checkbox is checked, then Metacat will notify

the Coordinating Nodes in DataONE that it is available to house replicas of objects

from other nodes.  Shortly thereafter, the Coordinating Nodes may notify Metacat to

replicate objects from throughout the system, which it will start to do.  There objects

will begin to be listed in the Metacat catalog.

.. Note:: 

  Future versions of Metacat will allow finer specification of the Node

  Replication Policy, which determines the set of objects

  that it is willing to replicate, using constraints on object size, total objects, 

  source nodes, and object format types.

Object Replication Policies

---------------------------

In addition to access control, each object also can have a ``ReplicationPolicy``

associated with it that determines whether DataONE should attempt to replicate the

object for failover and backup purposes to other Member Nodes in the federation. 

Both the ``RightsHolder`` and ``AuthoritativeMemberNode`` for an object can set the

``ReplicationPolicy``, which consists of fields that describe how many replicas 

should be maintained, and any nodes that are preferred for housing those replicas, or

that should be blocked from housing replicas.  

These ReplicationPolicies can be embedded inside of the ``SystemMetadata`` that accompany

submission of an object through the `MNStorage.create`_ and `MNStorage.update`_ services, 

or can be set using the `CNReplication.setReplicationPolicy`_ service.

.. _CNReplication.setReplicationPolicy: http://releases.dataone.org/online/d1-architecture-1.0.0/apis/CN_APIs.html#CNReplication.setReplicationPolicy