diff --git a/2-mission.tex b/2-mission.tex
index ad47193ece38af4f57588523eacb362f65a4a481..8045f56a2118bf137125cf4cede83f2ad7460665 100644
--- a/2-mission.tex
+++ b/2-mission.tex
@@ -18,7 +18,7 @@ The \gls{SKA} has adopted a model in which end users access data, and accompanyi
Over the next several years, the \gls{SKAO} will lead an effort to define the overall architecture and requirements of the \gls{SRC} network: it is a core part of the \gls{SDC} mission to engage with and participate in that process, with the ultimate expectation that the \gls{SDC} service portfolio will include providing the Netherlands \gls{SRC}.
Finally, in addition to the user-facing capabilities described by the above, the ASTRON \gls{MT} has issued specific guidance for the relationship between the \gls{SDC} and \gls{LOFAR} \autocite{2020-Kruithof-Vision}.
-This guidance positions the \gls{SDC} as the ``single point of contact and support'' for external astronomy customers using \gls{LOFAR}.
+This guidance positions the \gls{SDC} as the ``single point of contact and support'' for external customers using \gls{LOFAR}.
For the purpose of developing this vision, this implies further requirements for the \gls{SDC} system, in addition to servicing the user goals described above.
\gls{LOFAR}2.0 and \gls{SDC} leadership have developed a detailed technical description of the relationship between the two facilities \autocite{2020-Gunst-SDC-L2-Architecture}.
diff --git a/3-analysis.tex b/3-analysis.tex
index 3a4ed8cb02c3fdd1c9020161030df4a60e1d1ada..7400acfbb25e16e3921cd2b3f1740e31195805b4 100644
--- a/3-analysis.tex
+++ b/3-analysis.tex
@@ -40,10 +40,10 @@ The complete mapping between user profiles and the associated capabilities is su
\NewDocumentCommand{\rot}{O{60} O{1em} m}{\makebox[#2][l]{\rotatebox{#1}{#3}}}%
\begin{table}
+\begin{center}
\begin{tabular}{l|ccccccccccc}
& \rot{Non-expert radio (\cref{sec:goals:users:nonexpert})}
& \rot{Expert radio (\cref{sec:goals:users:expert})}
- & \rot{Non-radio astronomer (\cref{sec:goals:users:nonexpert})}
& \rot{Multi-$\lambda$ and messenger (\cref{sec:goals:users:multilambda})}
& \rot{Transient (\cref{sec:goals:users:transient})}
& \rot{Operators (\cref{sec:goals:users:operator})}
@@ -53,33 +53,30 @@ The complete mapping between user profiles and the associated capabilities is su
& \rot{Education (\cref{sec:goals:users:education})}
& \rot{Public (\cref{sec:goals:users:public})} \\
\midrule
- Use Case Priority & H & H & M & M & L & H & H & H & M & L & L \\
- \midrule
- Data Discovery (\cref{sec:features:discovery}) & X & X & X & X & & & & & & X & X \\
- Instrument Data (\cref{sec:features:raw}) & & X & & & & X & & & & & \\
- Science-Ready Data (\cref{sec:features:srdp}) & X & & X & X & & & & & & X & \\
- Simple Data (\cref{sec:features:simple}) & & & & & & & & & & X & X \\
- Sharing (\cref{sec:features:sharing}) & X & X & X & X & & & & & & X & \\
- \Acrshort{VO} Interfaces (\cref{sec:features:vo}) & X & X & X & X & X & & & & X & & \\
- Data Rights & X & X & X & X & & & X & & & & \\
- Standard Tooling (\cref{sec:features:standardtooling}) & X & X & X & X & & X & & & & & \\
- Standard Pipelines (\cref{sec:features:standardpipes}) & X & X & X & X & & X & & & & & \\
- Custom Pipelines (\cref{sec:features:custompipes}) & & X & & & X & X & & & & & \\
- Interactive Analysis (\cref{sec:features:interactive}) & X & X & X & X & & X & & & & X & \\
- Spec. Hardware (\cref{sec:features:hardware}) & & X & & & & & & & & & \\
- Real-Time Processing (\cref{sec:features:realtime}) & & & & & X & X & & & & & \\
- Basic Docs (\cref{sec:features:basicdocs}) & X & & X & X & & & X & & & X & X \\
- Tech Docs (\cref{sec:features:techdocs}) & X & X & & & & X & & X & X & & \\
- Source Code (\cref{sec:features:software}) & X & X & X & X & & X & & X & X & & \\
- Handle Alerts (\cref{sec:features:alerts}) & & & & & X & & & & & & \\
- Proposal Management (\cref{sec:features:proposal}) & & & & & & & X & & & & \\
+ Data Discovery (\cref{sec:features:discovery}) & X & X & X & & & & & & X & X \\
+ Instrument Data (\cref{sec:features:raw}) & & X & & & X & & & & & \\
+ Science-Ready Data (\cref{sec:features:srdp}) & X & & X & & & & & & X & \\
+ Simple Data (\cref{sec:features:simple}) & & & & & & & & & X & X \\
+ Sharing (\cref{sec:features:sharing}) & X & X & X & & & & & & X & \\
+ \Acrshort{VO} Interfaces (\cref{sec:features:vo}) & X & X & X & X & & & & X & & \\
+ Data Rights & X & X & X & & & X & & & & \\
+ Standard Tooling (\cref{sec:features:standardtooling}) & X & X & X & & X & & & & & \\
+ Standard Pipelines (\cref{sec:features:standardpipes}) & X & X & X & & X & & & & & \\
+ Custom Pipelines (\cref{sec:features:custompipes}) & & X & & X & X & & & & & \\
+ Interactive Analysis (\cref{sec:features:interactive}) & X & X & X & & X & & & & X & \\
+ Spec. Hardware (\cref{sec:features:hardware}) & & X & & & & & & & & \\
+ Real-Time Processing (\cref{sec:features:realtime}) & & & & X & X & & & & & \\
+ Basic Docs (\cref{sec:features:basicdocs}) & X & & X & & & X & & & X & X \\
+ Tech Docs (\cref{sec:features:techdocs}) & X & X & & & X & & X & X & & \\
+ Source Code (\cref{sec:features:software}) & X & X & X & & X & & X & X & & \\
+ Handle Alerts (\cref{sec:features:alerts}) & & & & X & & & & & & \\
+ Proposal Management (\cref{sec:features:proposal}) & & & & & & X & & & & \\
\bottomrule
\end{tabular}
+\end{center}
\caption{Mapping of user profiles, as described in \Cref{sec:users}, to supporting capabilities, described in \Cref{sec:features}.
An ``X'' in a table cell indicates that we regard the functionality listed in the corresponding row of being important to the user listed in the corresponding column.
-This mapping is indicative: it illustrates the range of users being considered and the range of functionality needed to support them; an empty table cell is not intended to indicate that users of this type could never access or benefit from the relevant functionality.
-The ``Priority'' row gives an indication of the priority we assign to each class of users on a three point scale (High, Medium, Low).
-Prioritization, as discussed in the text, is intended to guide initial development goals for the \gls{SDC}, not to indicate a lack of willingness to engage with or serve particular sections of the community.}
+This mapping is indicative: it illustrates the range of users being considered and the range of functionality needed to support them; an empty table cell is not intended to indicate that users of this type could never access or benefit from the relevant functionality.}
\label{tab:userfnmap}
\end{table}
diff --git a/4-product.tex b/4-product.tex
index 283adb933cbf0fa06045c80611807d2a1684108c..6bfd7c24e6a2353b27a3f55cccebd5c42c8c1259 100644
--- a/4-product.tex
+++ b/4-product.tex
@@ -102,7 +102,7 @@ In future, the Data Processing Service will evolve to remain current with best-p
As discussed in \cref{sec:product:services:repo}, the physical infrastructure may be distributed over multiple physical locations.
In so far as it is practical, this should be abstracted away from the end user.
-The Data Processing Service will cooperate with the Data Product Repository to ensure that, wherever possible, computing is scheduled close to the data, to minimize latency and data transport costs.
+The Data Processing Service will cooperate with the Data Product Repository to ensure that, where appropriate, computing is scheduled close to the data, to minimize latency and data transport costs.
The underlying infrastructure will likely be heterogeneous: it will provide a mixture of high- and low-memory per core systems as well as accelerators like \glspl{GPU}, with the detailed mix of hardware to be determined by the \gls{SDCO} team based on their assessment of user needs.
Pipeline definitions will describe the sorts of resources which are needed to properly run the processing, and the Service will take this into account when scheduling work.
diff --git a/6-governance.tex b/6-governance.tex
index 6e72f9a5c62f00dd6e35fd8930af4c542342d103..7e2927d584e83a11a1acdf8a8c10918dbf6f254b 100644
--- a/6-governance.tex
+++ b/6-governance.tex
@@ -12,7 +12,7 @@ The ASTRON \gls{MT} has established two bodies to construct and operate the \gls
\begin{itemize}
\item{The \emph{\acrlong{SDCP}} (\acrshort{SDCP}) is responsible for developing the software and services that are necessary to operate the \gls{SDC}.}
- \item{\emph{\acrlong{SDCO}} (\acrshort{SDCO}) is responsible for operating the \gls{SDC} and interfacing with the community.}
+ \item{\emph{\acrlong{SDCO}} (\acrshort{SDCO}) is responsible for operating the \gls{SDC}, defining and prioritizing a service offering to meet community needs, and providing support to members of the community.}
\end{itemize}
@@ -35,21 +35,25 @@ Arrows indicate expected exchanges of information, expertise, and effort, rather
\label{fig:sdc-hierarchy}
\end{figure}
-
The \gls{SDCP} is envisioned as a \emph{development programme} within ASTRON.
As such, it is formally a temporary organization which exists to develop certain defined functionality; in this case, the software required to operate the \gls{SDC}.
+The \gls{SDCP} is jointly responsible with \gls{SDCO} for developing the overall architecture of the \gls{SDC} facility.
+It is expected that the \gls{SDCP} will bring software development and architectural expertise to this discussion, which will be used to design the overall system based on the available infrastructure and operational needs of \gls{SDCO}.
+
The \gls{SDCP} is responsible for the delivery of operable \emph{software products} to the \gls{SDCO} team.
These products are combined with infrastructure --- provided by the \gls{SDCO} team --- and appropriate configuration to deploy and operate the services which comprise the \gls{SDC}.
+The \gls{SDCP} has ultimate responsibility for the software used to implement all core and ancillary (but not support; \cref{sec:product:arch}) services deployed within the \gls{SDC} facility\footnote{It does not follow that the \gls{SDCP} must implement this software in-house; indeed, it is expected that much of the \gls{SDC} software infrastructure will be based on third-party tooling.}.
-The \gls{SDCP} is jointly responsible with \gls{SDCO} for developing the overall architecture of the \gls{SDC} facility.
-It is expected that the \gls{SDCP} will bring software development and architectural expertise to this discussion, which will be used to design the overall system based on the available infrastructure and operational needs of \gls{SDCO}.
+The \gls{SDCP} is further responsible for the delivery of the scientific pipelines which are used as part of regular facility operations to generate the core \glspl{SRDP} (\cref{sec:product:science:pipelines}), as well as any other pipelines which are identified as strategically important by the \gls{SDCO} team \emph{and} which are agreed as within scope by \gls{SDCP} management.
-The \gls{SDCP} is expected to be responsible to scientific and operational requirements expressed by \gls{SDCO}, and to arrange its work to best address the priorities identified by \gls{SDCO}.
+The \gls{SDCP} is expected to arrange its work to address the scientific and operational requirements, and their relative priorities, expressed by \gls{SDCO}.
Detailed scheduling of work will remain the domain of \gls{SDCP}, and it is acknowledged that development or management considerations must be accounted for in parallel with \gls{SDCO} needs.
-The \gls{SDCP} is responsible for performing maintenance and support of the software products it delivers.
-This will certainly include emergency help resolving problems that prevent the correct operation of the \gls{SDC} facility; other requests for maintenance will be prioritized relative to new development in conjunction with the \gls{SDCO} team.
+The \gls{SDCP} is responsible for defining the working methods around the software products it delivers.
+This includes, for example, adopting appropriate agile team working practices, software release methodologies and the like.
+These methods will make it possible for the \gls{SDCP} to provide appropriate support to the \gls{SDCO} team when necessary.
+Wherever possible, these methods will be aligned with approaches adopted across ASTRON more generally.
The \gls{SDCP} is responsible for delivering software products of high quality.
That is, the products are appropriately tested, suitably documented, and packaged adequately for distribution.
@@ -62,19 +66,6 @@ Projects will be chosen, and the work will be managed, such that project deliver
Some level of additional funding to support integration and oversight activities will also be required; this will be drawn from the ASTRON base budget and in-kind contributions as appropriate.
This structure is illustrated in \cref{fig:sdc-organization}.
-%\begin{inlineComment}
-%There remains a lot of uncertainty here.
-%For example:
-%
-%\begin{itemize}
-%
-% \item{Is the \gls{SDCP} responsible for all software deployed to the \gls{SDC} facility, or will software be soured from elsewhere --- either within ASTRON, or purely external sources --- as well?}
-% \item{Is the \gls{SDCP} responsible for coordinating all sponsored projects which may contribute to writing software which will be deployed to the \gls{SDC} facility?}
-%
-%\end{itemize}
-%
-%\end{inlineComment}
-
According to the ``ASTRON 2.0'' organizational model, as a programme the \gls{SDCP} does not have any permanent staff.
Rather, these are sourced from Competence and Focus Groups.
Additional effort may be drawn from in-kind contributions to the \gls{ILT} or other projects, with the agreement of the \gls{ILT} Board where appropriate.
@@ -119,8 +110,13 @@ Infrastructure will be consistent with the agreed-upon \gls{SDC} system architec
\gls{SDCO} is jointly responsible with the \gls{SDCP} for developing the overall architecture of the \gls{SDC} facility.
It is expected that this architecture will reflect current and likely future infrastructure available to the \gls{SDCO} team, as well as their operational requirements.
+\gls{SDCO} will provide resources for maintenance of the software products delivered by \gls{SDCP} on which the \gls{SDC} facility relies, with the ultimate aim of ensuring that both the software itself and the associated developer expertise is sustainable beyond the duration of the \gls{SDCP} itself.
+Even when funded by \gls{SDCO}, developers working on \gls{SDCP} products will follow the working practices, norms, policies, and procedures established by \gls{SDCP}.
+
\gls{SDCO} will work with the community and other stakeholders to identify both long- and short-term scientific and functional priorities for the \gls{SDC}.
-These will be communicated to the \gls{SDCP}, and form the basis of a collaborative process of defining and prioritizing work.
+These will be communicated to the \gls{SDCP}, and form the basis of a collaborative process of defining detailed requirements and prioritizing work.
+
+\gls{SDCO} is responsible for acceptance testing and commissioning of the products delivered by \gls{SDCP}.
\gls{SDCO} is responsible for using the functionality provided by the \gls{SDC} facility to generate a set of standardized data products and to make them available to end users.
diff --git a/SDC-006.tex b/SDC-006.tex
index 8aa6719888a4bc582fe7be677e336385e88a8b6b..7d52a07aa4d572b8f2dfe6da2562a455925e4513 100644
--- a/SDC-006.tex
+++ b/SDC-006.tex
@@ -11,6 +11,7 @@
\setDocProgram{SDC}
\setDocChangeRecord{
+ \addChangeRecord{0.3}{2021-05-07}{Detailed response to comments from Pizzo}
\addChangeRecord{0.2}{2021-04-16}{Revised draft for distribution to A\&O}
\addChangeRecord{0.1}{2021-02-18}{Initial draft for distribution}
}
diff --git a/a-users.tex b/a-users.tex
index 47dad634d6e5d22a00ddb50e3ca4d0111f9ba1b3..f25e83282fa32eecaf4ae5a247050edb54c65fe1 100644
--- a/a-users.tex
+++ b/a-users.tex
@@ -17,7 +17,7 @@ Ultimately, it is our aim to address all user needs wherever possible.
\paragraph{Profile}
-The non-expert radio astronomer is a user who has a basic understanding of the principles of radio astronomy and who is active in academic astronomy research using radio data, but who is not a specialist in the types of data or instrumentation supported by ASTRON.
+The non-expert radio astronomer is a user who has a basic understanding of the principles of radio astronomy and who is active in academic astronomy research using radio data, but who is not a specialist in the types of data or instrumentation provided by ASTRON.
They want to easily find and quickly access data products which they can use to get to scientific results with the minimum of overhead.
In general, they are happy with well-accepted ``best practice'' data reduction techniques; they are not interested in developing or applying exotic calibration or imaging techniques.
They might need help in understanding the details of how a particular instrument works, or the subtleties of some data products.
@@ -46,33 +46,20 @@ Experts will often produce novel data products which it may be valuable to share
This class of user is influential within the community, and may produce results and developing processing techniques that are both exceptionally scientifically interesting and of wide applicability.
Supporting them is regarded as high priority.
-\subsubsection{The Non-Radio Astronomer}
-\label{sec:goals:users:nonradio}
-
-\paragraph{Profile}
-
-Some astronomers have no background or expertise in working with radio data, but still find it useful in support of a particular science case.
-They will likely be content with standardized data products, without custom processing, but they need plenty of support in working with them: the terminology, the form of the data products, the tools used to work with them, and so on may be unfamiliar.
-They may be reluctant to invest time in installing radio-specific software or learning new workflows: they want to get the results they need and move on quickly.
-
-\paragraph{Prioritization}
-
-We regard it as important to engage with this class of user to extend ASTRON's community and enable a wide range of science cases.
-Supporting them is regarded as medium priority.
-
\subsubsection{The Multi-Wavelength or Multi-Messenger Astronomer}
\label{sec:goals:users:multilambda}
\paragraph{Profile}
For some science cases, the best results will be achieved by combining measurement made across a variety of different wavelength regimes.
-These astronomers are primarily interested in accessing standardized, science-ready data products from ASTRON's instrumentation, but, crucially, they need to combine it with information from other facilities.
+These astronomers are primarily interested in accessing standardized, science-ready data products from ASTRON's instrumentation, and may need support in working with them: the terminology, the form of the data products, the tools used to work with them, and so on may be unfamiliar.
+In addition, they will often seek to combine radio data with information from other wavelengths or other messengers.
This combination may be performed either in catalogue-space (by directly comparing or correlating source lists), or by processing and visualizing images from a variety of different instrumentation.
\paragraph{Prioritization}
-We regard it as important to engage with this class of user to extend ASTRON's community and enable a wide range of science cases.
-Supporting them is regarded as medium priority.
+We regard it as important to provide first-class support to as wide as possible a community of practising astronomers.
+In addition, we believe that multi-wavelength and -messenger support has the potential to generate some of the biggest science impacts from the \gls{SDC}.
\subsubsection{The Transient \& Time-Sensitive Astronomer}
\label{sec:goals:users:transient}
@@ -152,7 +139,7 @@ It is important both to the \gls{SRC} itself and to our partners to interoperate
\paragraph{Profile}
-Members of the educational community --- broadly defined, but excluding professional astronomy students who likely fall into the categories described in \cref{sec:goals:users:nonexpert,sec:goals:users:nonradio} above --- may wish to use documentation and services available from the \gls{SDC} in their work.
+Members of the educational community --- broadly defined, but excluding professional astronomy students who likely fall into the category described in \cref{sec:goals:users:nonexpert} above --- may wish to use documentation and services available from the \gls{SDC} in their work.
One could also imagine a professional \gls{SDC} \gls{EPO} programme.
\paragraph{Prioritization}
diff --git a/b-features.tex b/b-features.tex
index 645ab39a2e29fbc80df425a41345136174557a25..7324237c1b586ba8885ef74ec1b3c26717b4a981 100644
--- a/b-features.tex
+++ b/b-features.tex
@@ -65,10 +65,10 @@ User requests are submitted, and data is provided for download through, the \por
\glspl{SRDP} data products that the end user can immediately apply to address particular science questions without the need for further calibration or other processing.
In the context of the \gls{SDC}, they are the results of processing instrumental data (\cref{sec:features:raw}) through standardized data reduction pipelines produced and operated by ASTRON and its collaborators.
For example, these might include the results of processing LOFAR data through a standard imaging pipeline.
-\gls{SRDP} must be accompanied by metadata that describe how they were produced (i.e., ``provenance''), and an assessment of the data quality.
+\glspl{SRDP} must be accompanied by metadata that describe how they were produced (i.e., ``provenance''), and an assessment of the data quality.
They should be made available for download or on-line interactive analysis.
-\gls{SRDP} exist at level 2 or higher on the \gls{IVOA} ObsCore classification scale \autocite{2017ivoa.spec.0509L}.
+\glspl{SRDP} exist at level 2 or higher on the \gls{IVOA} ObsCore classification scale \autocite{2017ivoa.spec.0509L}.
\paragraph{Prioritization}
@@ -78,6 +78,7 @@ This functionality is essential to successful \gls{SDC} operations, and must be
Instrumental data is stored as per \cref{sec:features:raw}.
\gls{SDC} staff are responsible for using the \dps{} to process this data through a range of pre-defined pipelines (\cref{sec:product:science:pipelines}; the level of automation of this process is to be determined).
+Data products generated as a result of custom processing by advanced or expert users may optionally be shared and used as \glspl{SRDP} by others; potentially, \gls{SDC} staff could work with experts to identify useful products and flag them to other users.
Processed data products are archived in the \repo{} and made available in the same way as instrumental data (\cref{sec:features:raw}).
\subsubsection{Access to Simplified Data Products}
@@ -139,8 +140,8 @@ Adopting \gls{VO} interfaces early in \gls{SDC} development will capitalize on e
\paragraph{Overview}
\gls{SDC} systems should track the ownership of data products.
-For example, facilities may claim ownership of their instrumental and science-ready data products (\cref{sec:features:raw,sec:features:srdp}), while scientists or other end users own data products produced by custom pipelines (\cref{sec:features:custompipes}) or their own interactive analysis (\cref{sec:features:interactive}).
-It is understood that policies around ownership may vary from facility to facility (for example, the \gls{ILT} Board may take a different attitude to the \gls{SKAO}); \gls{SDC} systems must be flexible enough to accommodate all reasonable policies.
+For example, facilities may claim ownership of their instrumental and science-ready data products (\cref{sec:features:raw,sec:features:srdp}), while scientists or other end users might own data products produced by custom pipelines (\cref{sec:features:custompipes}) or their own interactive analysis (\cref{sec:features:interactive}).
+It is understood that policies around ownership may vary from facility to facility (for example, the \Acrshort{ILT} Board may take a different attitude to the \gls{SKAO}); \gls{SDC} systems must be flexible enough to accommodate all reasonable policies.
The owners of data products must be able to define access rights to the data.
This would include, for example, limiting access to certain individuals during a proprietary period.
@@ -183,7 +184,7 @@ This must be properly integrated with both the \portal{} and the \dps{}, where t
Standardized data reduction pipelines provide algorithms, configuration, and an execution framework which is capable of ingesting instrumental data (\cref{sec:features:raw}) and producing \glspl{SRDP} (\cref{sec:features:srdp}).
Access to these pipelines means that users will be able to trigger reprocessing of instrumental data with a modified configuration to generated data products that are more closely aligned with their scientific needs.
-It follows that the products of user-requested pipeline processing will need to be stored for future reference.
+It follows that the products of user-requested pipeline processing may need to be stored for future reference.
Note that pipeline products may consist of binary ``blobs'' (e.g. image files) or tabular data (database entries); it should be possible for users to generate and store both.
\paragraph{Prioritization}
@@ -252,13 +253,14 @@ The current \gls{SDC} architecture makes no specific provision for this capabili
Ultimately, it could be supported by the \dps{}.
Care will therefore be taken to ensure this service provides an abstraction layer over the underlying hardware which can easily be extended to cover additional hardware types.
-\subsubsection{Real-Time Pipeline Processing}
+\subsubsection{Real-Time Processing of Streaming Data}
\label{sec:features:realtime}
\paragraph{Overview}
-Streaming data is processed in (near) real-time as it is received at the \gls{SDC}, without manual intervention from operators.
-Users can access a stream of images or other data products coming from the telescope at low latency (e.g. seconds).
+Rather than writing data to persistent storage and then (manually or automatically) scheduling a pipeline to process it, this mode would process data in real-time as it streams to the \gls{SDC}.
+For example, a real-time imaging pipeline might enable monitoring of ongoing observations for transients.
+Users would be able to access a stream of images or other data products coming from the telescope at low latency (e.g. seconds).
\paragraph{Prioritization}
@@ -279,7 +281,7 @@ This may be included in a future \gls{SDC} extension, but not in early developme
\paragraph{Overview}
To fully engage the community with the \gls{SDC} and ASTRON's data holdings, substantial educational resources must be provided.
-These will run the gamut from introductory material on the \gls{SDC} itself, through explanations of the available data and capabilities, to tutorials on data processing.
+These will run the gamut from introductory material on instrumentation and the \gls{SDC} itself, through explanations of the available data and capabilities, to tutorials on data processing.
There will also be support available to users with questions, and a range of in-person and online workshops available to users.
Finally, peer-to-peer support and community development will be facilitated by discussion forums and similar tools.
diff --git a/figures/sdc-hierarchy.graffle b/figures/sdc-hierarchy.graffle
index 306d961fc8cd18f463472c78a1199e07fb870071..b4a76882c3c3a6266012fd1d8e1ef60f62b7f9d0 100644
Binary files a/figures/sdc-hierarchy.graffle and b/figures/sdc-hierarchy.graffle differ
diff --git a/figures/sdc-hierarchy.pdf b/figures/sdc-hierarchy.pdf
index 781febf85580c1b96a2f308dbf8921edf5c5dcff..a8c0f6009718885c50bdeb94fb37a24bec4fec33 100644
Binary files a/figures/sdc-hierarchy.pdf and b/figures/sdc-hierarchy.pdf differ