Fixed links.

Author: chrisgorgo

doc/users/grabbing_and_sinking.rst

@@ -5,7 +5,7 @@ DataGrabber and DataSink explained
 ==================================
 
 In this chapter we will try to explain the concepts behind DataGrabber and
-DataSink.
+:ref:`DataSink <nipype.interfaces.io.DataSink>`.
 
 Why do we need these interfaces?
 ================================
@@ -39,7 +39,7 @@ However, in the context of complex workflows and given that users typically
 arrange their imaging and other data in a semantically hierarchical data store,
 an alternative mechanism for reading and writing the data generated by a workflow
 is often necessary. As the names suggest DataGrabber is used to get at data
-stored in a shared file system while DataSink is used to store the data
+stored in a shared file system while :ref:`DataSink <nipype.interfaces.io.DataSink>` is used to store the data
 generated by a workflow into a hierarchical structure on disk.
 
 
@@ -145,15 +145,15 @@ information such as execution reports, hashfiles determining the input state of
 processes. All of this is embedded in a hierarchical structure that reflects the
 iterables that have been used in the workflow. This makes navigating the working
 directory a not so pleasant experience. And typically the user is interested in
-preserving only a small percentage of these outputs. The DataSink interface can
+preserving only a small percentage of these outputs. The :ref:`DataSink <nipype.interfaces.io.DataSink>` interface can
 be used to extract components from this `cache` and store it at a different
-location. For XNAT-based storage, see :ref:`nipype.interfaces.io.XNATSink` .
+location. For XNAT-based storage, see :ref:`XNATSink <nipype.interfaces.io.XNATSink>` .
 
 .. note:: 
 
-   Unlike other interfaces, a DataSink's inputs are defined and created by using
+   Unlike other interfaces, a :ref:`DataSink <nipype.interfaces.io.DataSink>`'s inputs are defined and created by using
    the workflow connect statement. Currently disconnecting an input from the
-   datasink does not remove that connection port.
+   :ref:`DataSink <nipype.interfaces.io.DataSink>` does not remove that connection port.
 
 Let's assume we have the following workflow.
 
@@ -162,7 +162,7 @@ Let's assume we have the following workflow.
    "InputNode" -> "Realign" -> "DataSink";
    "InputNode" -> "DataSink";
 
-The following code segment defines the DataSink node and sets the `base_directory`
+The following code segment defines the :ref:`DataSink <nipype.interfaces.io.DataSink>` node and sets the `base_directory`
 in which all outputs will be stored. The `container` input creates a
 subdirectory within the `base_directory`. If you are iterating a workflow over
 subjects, it may be useful to save it within a folder with the subject id. 
@@ -191,16 +191,16 @@ we need to create a second port. We can store the files in a separate folder.
 
 The period (.) indicates that a subfolder called par should be created. But if
 we wanted to store it in the same folder as the realigned files, we would use
-the `.@` syntax. The @ tells the datasink interface to not create the
-subfolder. This will allow us to create different named input ports for datasink
+the `.@` syntax. The @ tells the :ref:`DataSink <nipype.interfaces.io.DataSink>` interface to not create the
+subfolder. This will allow us to create different named input ports for :ref:`DataSink <nipype.interfaces.io.DataSink>`
 and allow the user to store the files in the same folder.
 
 ::
 
   workflow.connect(realigner, 'realigned_files', datasink, 'motion')
   workflow.connect(realigner, 'realignment_parameters', datasink, 'motion.@par')
 
-The syntax for the input port of DataSink takes the following form:
+The syntax for the input port of :ref:`DataSink <nipype.interfaces.io.DataSink>` takes the following form:
 
 ::
 
@@ -210,7 +210,7 @@ The syntax for the input port of DataSink takes the following form:
 MapNode
 -------
 
-In order to use :ref:`nipype.interfaces.io.DataSink` inside a MapNode, it's
+In order to use :ref:`DataSink <nipype.interfaces.io.DataSink>` inside a MapNode, it's
 inputs have to be defined inside the constructor using the `infields` keyword
 arg.
 
@@ -222,7 +222,7 @@ over various inputs using the iterables attribute of nodes. This means that a
 given workflow can have multiple outputs depending on how many iterables are
 there. Iterables create working directory subfolders such as
 `_iterable_name_value`.  The `parameterization` input parameter controls whether
-the data stored using DataSink is in a folder structure that contains this
+the data stored using :ref:`DataSink <nipype.interfaces.io.DataSink>` is in a folder structure that contains this
 iterable information or not. It is generally recommended to set this to `True`
 when using multiple nested iterables.
 

doc/users/mapnode_and_iterables.rst

@@ -142,6 +142,6 @@ Iterables are commonly used to execute the same workflow for many subjects.
 Usually one parametrises DataGrabber node with subject ID. This is achieved by
 connecting an IdentityInterface in front of DataGrabber. When you set iterables of the
 IdentityInterface to the list of subjects IDs, the same workflow will be executed
-for every subject. See :doc:`examples/spm_tutorial` to see this pattern in action.
+for every subject. See :doc:`examples/fmri_spm` to see this pattern in action.
 
 .. include:: ../links_names.txt