The extensive use of LSIDs in LabKey Server requires a system for generating unique LSIDs for new objects. LSIDs must be unique because they are used as keys to identify records in the database. These generated LSIDs should not inadvertently clash for two different users working in separate contexts such as different folders. On the other hand, if the generated LSIDs are too complex – if, for example, they guarantee uniqueness by incorporating large random numbers – then they become difficult to remember and difficult to share among users working on the same project.
LabKey Server allows authors of experiment description files (xar.xml files) to specify LSIDs which include substitution template values. Substitution templates are strings of the form
${<substitution_string>}
where <substitution_string> is one of the context-dependent values listed in the table below. When an experiment description file is loaded into the LabKey Server database, the substitution template values are resolved into final LSID values. The actual values are dependent on the context in which the load occurs.
Unless otherwise noted, LSID substitution templates are supported in a xar.xml file wherever LSIDs are used. This includes the following places in a xar.xml file:
A limited subset of the substitution templates are also supported in generating object Name values when using the ExperimentLog format (ApplicationName, OutputMaterialName, and OutputDataName). These same templates are available for generating file names and file directories (OutputDataFile and OutputDataDir). Collectively these uses are listed as the Name/File ProtocolApplication templates in the table below.
Note: The following table lists the primitive, single component substitution templates first. The most powerful and useful substitution templates are compound substitutions of the simple templates. These templates are listed at the bottom of the table.
${LSIDAuthority} |
||
|
Expands to |
Server-wide value set on the Customize Site page under Site Administration. The default value is localhost. |
|
Where valid |
|
|
||
${LSIDNamespace.prefix} |
||
|
Expands to |
Base object name of object being identified by the LSID; e.g., Material, Data, Protocol, ProtocolApplication, Experiment, or ExperimentRun |
|
Where valid |
|
|
||
${Container.RowId} |
||
|
Expands to |
Unique integer or path of project or folder into which the xar.xml is loaded. Path starts at the project and uses periods to separate folders in the hierarchy. |
|
Where valid |
|
|
||
${XarFileId} |
||
|
Expands to |
Xar- + unique integer for xar.xml file being loaded |
|
Where valid |
|
|
||
${UserEmail},${UserName} |
||
|
Expands to |
Identifiers for the logged-on user initiating the xar.xml load |
|
Where valid |
|
|
||
${ExperimentLSID} |
||
|
Expands to |
rdf:about value of the Experiment node at the top of the xar.xml being loaded |
|
Where valid |
|
|
||
${ExperimentRun.RowId} |
||
|
Expands to |
The unque integer, LSID, and Name of the ExperimentRun being loaded |
|
Where valid |
|
|
||
${InputName},${InputLSID} |
||
|
Expands to |
The name and lsid of the Material or Data object that is the input to a ProtocolApplication being generated using ExperimentLog format. Undefined if there is not exactly one Material or Data object that is input. |
|
Where valid |
|
|
||
${InputLSID.authority} |
||
|
Expands to |
The individual parts of an InputLSID, as defined above. The namespacePrefix is defined as the namespace portion up to but not including the first period, if any. The namepsaceSuffix is the remaining portion of the namespace after the first period. |
|
Where valid |
|
|
||
${InputInstance},${OutputInstance} |
||
|
Expands to |
The 0-based integer number of the ProtocolApplication instance within an ActionSequence. Useful for any ProtocolApplication template that includes a fractionation step. Note that InputInstance is > 0 whenever the same Protocol is applied multiple times in parallel. OutputInstance is only > 0 in a fractionation step in which multiple outputs are generated for a single input. |
|
Where valid |
|
|
||
${FolderLSIDBase} |
||
|
Expands to |
urn:lsid:${LSIDAuthority}: |
|
Where valid |
|
|
|
|
${RunLSIDBase} |
||
|
Expands to |
urn:lsid:${LSIDAuthority}:${LSIDNamespace.Prefix} |
|
Where valid |
|
|
||
${AutoFileLSID} |
||
|
Expands to |
urn:lsid:${LSIDAuthority} See Data object in next section for behavior and usage |
|
Where valid |
|
In general, the primary object types in a Xar file use the following LSID patterns:
These three object types typically use folder-scoped LSIDs that look like
${FolderLSIDBase}:Name_without_spaces
In these LSIDs the object name and the LSID’s objectId are the same except for the omission of characters (like spaces) that would get encoded in the LSID.
A ProtocolApplication is always part of one and only one ExperimentRun, and is loaded or deleted with the run. For ProtocolApplications, a run-scoped LSID is most appropriate, because it allows multiple runs using the same protocol to be loaded into a single folder. A run-scoped LSID uses a pattern like
${RunLSIDBase}:Name_without_spaces
Material objects can be divided into two types: starting Materials and Materials that are created by a ProtocolApplication. If the Material is a starting material and is not the output of any ProtocolApplication, its scope is outside of any run. This type of Material would normally have a folder-scoped LSID using ${FolderLSIDBase}. On the other hand, if the Material is an output of a ProtocolApplication, it is scoped to the run and would get deleted with the run. In this case using a run-scoped LSID with ${RunLSIDBase} would be more appropriate.
Like Material objects, Data objects can exist before any run is created, or they can be products of a run. Data objects are also commonly associated with physical files that are on the same file share as the xar.xml being loaded. For these data objects associated with real existing files, it is important that multiple references to the same file all use the same LSID. For this purpose, LabKey Server provides the ${AutoFileLSID} substitution template, which works somewhat differently from the other substitution templates. An ${AutoFileLSID} always has an associated file name on the same object in the xar.xml file:
When the xar.xml loader finds an ${AutoFileLSID}, it first calculates the full path to the specified file. It then looks in the database to see if there are any Data objects in the same folder that already point to that file. If an existing object is found, that object’s LSID is used in the xar.xml load. If no existing object is found, a new LSID is created.