Role of RDA in RDA Outputs Deployment and Evaluation Testbeds
Larry Lannom, Beth Plale, Fran Berman, Kathy Fontaine
The RDA community, which endorses outputs (sometimes called “recommendations”), is in
the fortunate position of having the first handful of outputs now published. There is a
general sense, from many quarters of the vast RDA membership, that the community needs
to capitalize on the existing momentum around these first recommendations to encourage
their adoption and create a virtuous cycle whereby adoption leads to increased
understanding of requirements that feed back into the RDA WG and IG processes to
improve that work which in turn leads to more useful outputs and so on.
There also appears to be general community agreement that for adoption of the outputs to
be widespread, more rigorous testing and evaluation is required: this includes integration
of RDA outputs with other technologies, both accepted and trending, in the real-world
environment of discipline specific research. The notion of deployment and testbeds to
enable RDA output testing and evaluation is thus seen as a necessary foundation to broader
adoption of RDA outputs.
Leading up to this concept paper we deliberated what role if any that RDA should have in
setting up testbeds and output evaluation, though it is clear that RDA has primary
responsibility for pre-published output products: by their inception, by enabling the
relevant WG, by their approval, and by any eventual correction, replacement, or
deprecation. The content of any recommended output, however, which ranges from general
recommended principles to running code, and potentially including independent
organizations to manage directories, federations, etc., are, by design of the organization, not
under the control of RDA. A recommended output once approved assumes a life of its own.
But were RDA to be simply the primordial swamp from which data interoperability ideas
and technologies emerge and leave, the rich feedback cycle to improved recommendations
would be lost.
The authors of this concept paper see a valuable lightweight role for RDA and its regional
organizations in providing mechanisms for coordination of testbeds and deployment, and
see experience based feedback emerging from the testbed experiences as extremely
valuable to strengthened RDA products. In this concept paper we lay out what RDA’s role
could look like both at the international level and the regional level.
Role of RDA/”international”:
The potential action for RDA/”international” would be to explore what construct might best
be used to support various testing and deployment efforts. The construct we endorse is
simply an RDA deployment and testbed coordination IG. Specifically, we feel that the Data
Fabric Interest Group, created to bring together RDA outputs and associated technologies, is
a valuable forum for planning and executing the testing and evaluation of the various RDA
outputs in concert with each other and with various other relevant technologies. We
envision the testing and evaluation of defined sets of RDA Output implementations and
associated relevant technologies in the context of a given domain or set of domains. See
below for more details.
As RDA is open and technology-neutral, multiple testbed and deployment efforts should be
encouraged. RDA/”international” should seek to coordinate these efforts when it makes
sense and is appropriate.
Role of RDA/”regionals”:
The role of the regionals would be to develop, deploy and support various testbed and
deployment efforts. Since the testbeds will need hardware, software, and human support,
each region may want to develop one or more proposals to provide funding for testbed and
deployment efforts. Some proposals may want to focus on particular domains or particular
hardware environments, some proposals may want to develop configurations closely
aligned with discipline needs.
RDA/”regions” testbed and deployment efforts should reflect RDA culture. It would be
useful if the projects subscribed to RDA principles, were willing to participate in the RDA
Deployment and Testbed Coordination group, and were seen as venues where RDA
deliverables could be tested and deployed on RDA and other domain communities and use
cases. It should also be clear to the community that support for each of the projects will
come from the regions and not from RDA/”international”.
Implementation:
How might RDA community activity support the deployment evaluation and encourage
testbed availability for the purposes of evaluation? We believe the most productive use of a
deployment evaluation is one that is carried out over a short timeframe (3-9 months) and in
the context of a specific use. We walk through an example to illustrate. The Data Fabric IG
of RDA “spawns” an interest group called “DFIG1” of knowledgeable deployment people
who work with a bio IG to define a driving use case and set of technologies to evaluate.
DFIG1 then “stands up” a Bio Testbed deployment instance in the US (BIO TB-US). The
testbed deployment instance is supported by a “US resource provider”. Similarly, DFIG2
“stands up” a Geo Testbed deployment instance in the EU, supported by an “EU resource
provider”. The resource providers coordinate with each other through membership in the
Data Fabric IG, and contribute to the conversations (“influences”) policies of use of the
deployment instance. A community may spawn a policy group (see Bio TB Policy IG) to give
feedback to the resource providers on experience gained from the individual deployment
evaluations. This feedback could strengthen the testbed resource, and make it a stronger
asset for the community (such as by promoting a tested piece of infrastructure to a standing
service for all deployment evaluations in a certain discipline.)
In this way, RDA could, without the overhead of a standardization process and without
saying that only certain DF configurations were acceptable, provide concrete advice to
practitioners regarding technology choices.
Figure 1 provides a diagrammatic view of this Data Fabric configurations idea. Figure 2
positions the diagrammatic view in the middle of a virtuous cycle of RDA Global generating
outputs for testing, providing feedback into RDA Global, and encouraging adoption which in
turn increases the value of RDA Regionals which then feed energy back into RDA Global.
Figure 1. Testbed deployment and evaluation: the actors and roles
Figure 2. Virtuous cycle