Custom DataTypes for file based assays

LabKey Support Forum (Inactive)
Custom DataTypes for file based assays Anthony Corbett  2013-12-03 14:05
Status: Closed
 

Josh,

Thanks for your reply. Your implementation of the XML schema looks okay. Using your XML schema my example assay prodiver XML would be:

<provider xmlns:ap="http://labkey.org/study/assay/xml">
    <name>Gel Card</name>
    <description>Gel Card measures titers for anti-A and anti-B antibodies in blood.</description>
    <inputDataFile>
       <namespacePrefix>GelCardImage</namespacePrefix>
       <role>Gel Card Image</role>
       <fileSuffix default="true">.jpg</fileSuffix >
       <fileSuffix >.jpeg</fileSuffix >
       <fileSuffix >.tiff</fileSuffix >
   </inputDataFile>
</provider>

This example is an actual use case for #1 above. I have a file based module using AssayController.FileUploadAction to upload a image file from the user's desktop to labkey. In this case the LSID's namespace for the ExpData which is created is "RawAssayData". By implementing this feature I am looking for the following behavior based on the "primary" inputDataFile defiintion:

1. When uploading a file using this FileUploadAction for a specific assay provider the file extension would be checked against the suffixes defined and would error if it doesn't match. Thus, creating a layer of validation for uploading files as inputs to a file based assay module. Though this could be implemented client side on the file input's value before making the HTTP request to this upload Action, it would prevent business logic from being implemented in two places (once in the XML and again in javascript)

2. When a file is uploaded for a file-based module assay provider the ExpData objet that is created would contain the namespace defined for the "primary" inputDataFile defined, in this case "GelCardImage". After the ExpData was created the Run FK (which created it) would be null until the file was added as output to a run of that assay provider and saved using SaveAssayBatchAction, which during that the Run FK would be added to that ExpData record.

3. As an aside, adding this feature for the FileUploadAction would even allow custom DataHandlers/Parsers to be regesitered to handle some parsing/server side processing of these uploaded files. (maybe through a spring configuration?). This idea just came to me so it might need more fleshing out.


As for #2, the use case could be either a single related data files or multiple related data files, each with a different role. I think having a more generic solution. Having something like a "relatedDataFile" XML type/element that also as namespacePrefix, role, and a list of fileSuffix-es. For all output files attached to the run during a file-based assay module's call to SaveAssayBatchAction the code would loop through these dataFile defitions and apply the correct namespace. Maybe a little tweak to your XML schema would work:

<provider xmlns:ap="http://labkey.org/study/assay/xml">
    <name>Bioanalyzer</name>
    <dataFile type="output" primary="true">
       <namespacePrefix>BioanalyzerFile</namespacePrefix>
       <role>Results</role>
       <fileSuffix default="true">.xml</fileSuffix >
       <fileSuffix>.bioA.xml</fileSuffix >
   </dataFile>
   <dataFile type="output">
       <namespacePrefix>BioanalyzerReport</namespacePrefix>
       <role>Report</role>
       <fileSuffix default="true">.pdf</fileSuffix >
       <fileSuffix>.bioA.pdf</fileSuffix >
   </dataFile>
</provider>

In this use case the primary data file for the run is the XML file and a related data file is a pdf report.

How the files make it up on the server, either picked from the FileContent WebDav widget or uploaded through the FileUploadAction, hopefully won't matter as the definition of these dataFile XML elements would allow adding these files to a run and saving the run and still do the "correct" behavior of matching the corresponding file suffix and applying the correct namespacePreix to the LSID.

I hope this gives a more detailed account of what I am looking for and not sure what would be possible.


Regards,

Anthony Corbett