Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
12
datasets available to search
ShareScore release 0.7.1
Dataset results
12 results for “Reference Architecture”
Fiware4Water Reference Architecture
<p>Fiware4Water Reference Architecture developed in the Fiware4Water EU Project founded by the European Union’s Horizon 2020 research and innovation programme under grant agreement No. 821036.</p>
Reference data and analysis software for "Four-color single-molecule imaging with engineered tags resolves the molecular architecture of signaling complexes in the plasma membrane"
<p>Reference data set for the single molecule co-tracking analysis presented in "Four-color single-molecule imaging with engineered tags resolves the molecular architecture of signaling complexes in the plasma membrane". Corresponding author for further inquiries:</p> <p>Prof. Dr. Jacob Piehler</p> <p>University of Osnabrück, Department of Biology/Chemistry, Division of Biophysics, Barbarastr. 11, 49076 Osnabrück, Germany</p> <p>https://www.biophysik.uni-osnabrueck.de/</p>
[opendc-sc18-dataset] A Reference Architecture for Datacenter Scheduling: Data Artifacts
<p>This release contains the data artifacts of the paper A Reference Architecture for Datacenter Scheduling presented at <a href="https://sc18.supercomputing.org/">Supercomputing 2018</a></p> <p>For the paper, experiments have been run on the following traces:</p> <ul> <li><strong>Askalon (W-Eng)</strong> - <code>askalon_workload_ee</code></li> <li><strong>Chronos (W-Ind)</strong> - <code>chronos_exp_noscaler_ca</code></li> </ul> <p>Each of the directories for the traces have the following structure:</p> <ul> <li><strong>/setup.txt</strong><br> This text file describes the trace used for the experiment in addition to the amount of times the experiment was repeated and the amount of warm-up experiments.</li> <li><strong>/setup.json</strong><br> This JSON file describes the topology of the datacenter used in the experiments. Each item represents the identifiers of the resource (here, CPU type) to use in the machine. The available CPU types are (1) Intel i7 (4 cores, 4100 MHz) and (2) Intel i5 (2 cores, 3500 MHz).</li> <li><strong>/trace</strong><br> This directory contains the trace used in the simulation. The trace is stored in the Grid Workload Format. See the <a href="http://gwa.ewi.tudelft.nl/">Grid Workload Archive</a> for more information.</li> <li><strong>/data/experiments.csv</strong><br> A CSV file containing information of all simulations that have been run on the OpenDC platform for this experiment.</li> <li><strong>/data/job_metrics.csv</strong><br> A CSV file containing metrics (NSL, JMS, etc.) for each job that ran during the simulations.</li> <li><strong>/data/stage_measurements.csv</strong><br> A CSV file containing timing measurements for the scheduling stages that ran during the simulations.</li> <li><strong>/data/task_metrics.csv</strong><br> A CSV file containing metrics for each task that ran during the simulations.</li> <li> <p><strong>/data/tasks.csv</strong><br> A CSV file containing information about the tasks (submit time, runtime, etc.) that ran during the simulations as extracted from the traces.</p> <p>Additionally, we describe the format of each data file in the associated metadata file.</p> </li> </ul> <p><strong>Hardware</strong></p> <p>The hardware used for running the experiments is a MacBook Pro with a 2,9 GHz Intel Core i7 processor and 16 GB 2133 MHz LPDDR3 internal memory.</p> <p><strong>Reproduction</strong></p> <p>This section describes the instructions for reproducing the paper results using a provided Docker image. Please make sure you have <a href="https://www.docker.com/">Docker</a> installed and running.</p> <p>For reproduction, you will run the following experiments:</p> <ul> <li><code>askalon_workload_ee</code><br> This is the large experiment of the paper and will take approximately 4 hours to complete similar hardware.</li> <li><code>chronos_exp_noscaler_ca</code><br> This is the smaller experiment of the paper and will take approximately 5 minutes to complete on similar hardware.</li> </ul> <p>The Docker image <a href="https://hub.docker.com/r/atlargeresearch/sc18-experiment-runner/"><code>atlargeresearch/sc18-experiment-runner</code></a> can be used for running the experiments. A volume can be attached to the directory <code>/home/gradle/simulator/data</code> to capture the results of the experiments.</p> <p>Make sure you have, in your current working directory, the following files:</p> <ul> <li><strong>/setup.json</strong><br> This JSON file describes the topology of the datacenter and can be found in this archive at <code>askalon_workload_ee/setup.json</code>.</li> <li><strong>/askalon_workload_ee.gwf</strong><br> This file contains the trace for the Askalon workload. This file can be found in the archive at <code>askalon_workload_ee/trace/askalon_workload_ee.gwf</code>.</li> <li><strong>/chronos_exp_noscaler_ca.gwf</strong><br> This file contains the trace for the Chronos workload. This file can be found in the archive at <code>chronos_exp_noscaler_ca/trace/chronos_exp_noscaler_ca.gwf</code>.</li> </ul> <p>Then, you can start the Askalon experiments as follows:</p> <pre><code>$ docker run -it --rm -v $(pwd):/home/gradle/simulator/data atlargeresearch/sc18-experiment-runner -r 32 -w 4 -s data/setup.json data/askalon_workload_ee.gwf </code></pre> <p>The experiment runner can be configured with the following options</p> <ul> <li><strong>-r</strong>, <strong>--repeat</strong><br> The amount of times to repeat an experiment for each scheduler.</li> <li><strong>-w</strong>, <strong>--warm-up</strong><br> The amount of times to warm-up the simulator for each scheduler.</li> <li><strong>-p</strong>, <strong>--parallelism</strong><br> The number of experiments to run in parallel.</li> <li><strong>--schedulers</strong><br> The list of schedulers to test, separated by spaces. The following schedulers are available: <code>SRTF-BESTFIT</code>, <code>SRTF-FIRSTFIT</code>, <code>SRTF-WORSTFIT</code>, <code>FIFO-BESTFIT</code>, <code>FIFO-FIRSTFIT</code>, <code>FIFO-WORSTFIT</code>, <code>RANDOM-BESTFIT</code>, <code>RANDOM-FIRSTFIT</code>, <code>RANDOM-WORSTFIT</code>.</li> </ul> <p>After the Askalon experiments have been finished, you can start the Chronos experiments. <strong>Make sure</strong> you have a copy of the result files in your directory as the result files will be overwritten.</p> <pre><code>$ docker run -it --rm -v $(pwd):/home/gradle/simulator/data atlargeresearch/sc18-experiment-runner -r 32 -w 4 -s data/setup.json data/chronos_exp_noscaler_ca.gwf </code></pre>
Network of reference tree-ring chronologies for forensic botanical (dendrochronological) examinations and dating of architectural structures in the Tyva Republic.
<p>The database consists of tables. First sheet - general description of tree-ring chronologies (general information: name of chronology, authors, data type, tree-ring parameter, notes, key words; description of sample collection site: site name, location, region, latitude, longitude, height; description of sample collection: collection code designation, number of series, year of first ring, year of last ring, maximum length of sample, average width of year ring; species affiliation - species; support - grant number). Second sheet, first column - years, second column - standardized growth value. The third sheet is a PDF document containing the results of independent testing in the program COFECA (the file is opened by the command: right-click/Acrobat Document object/open). The database is implemented in the OpenOffice.org Calc spreadsheet processor. The table file format is an internal OpenOffice.org Calc format, with the extension .ods. The data is accessed and structured using the standard tools "Sort", "Autofilter", etc. In the database, the integrity restriction control is not implemented, the user is invited to monitor the integrity of the database himself. Computer type: IBM PC. PC; OS: Windows 10.</p> <p>Type and version of the database management system: OpenOffice.org Calc.</p> <p>Database size: 5.6 MB</p>
Reference Architecture for Autonomy and Adaptivity in the Space Domain
<p>File 1 - <strong>Protocol SLR - Reference Architecture for autonomous and adaptive space systems.xlsx</strong>: This data extraction worksheet presents the relevant data from the identified studies and provides the selection process in this systematic literature review. The main information reported in this worksheet summarizes the followed protocol, containing an identifier (id) for each returned study. This catalog helped us in the data extraction and synthesis procedures and may be used by potentially interested, for example, for updating or replication. </p> <p>File 2 - <strong>Interview_Guide_Questionnaire.pdf</strong>: The questionnaire was used to guide the interviews and also to ensure consistency between responses. It covers key aspects of the proposed reference architecture, such as general applicability, autonomy and adaptability, scalability, and standards compliance. There is also space for interviewers to add comments in each section and at the end of the form.</p> <p>File 3 - <strong>Filled_Questionnaire_Interviewee_1.pdf</strong>: The questionnaire answered by the interviewee 1, with the scores and comments.</p> <p>FIle 4 - <strong>Expert 1 Transcription.docx</strong>: The transcripts of the interviewee 1. The original language was not English, so we used OpenAI to generate the English version.</p> <p>File 5 - <strong>Filled_Questionnaire_Interviewee_2.pdf</strong>: The questionnaire answered by the interviewee 2, with the scores and comments.</p> <p>FIle 6 - <strong>Expert 2 Transcription.docx</strong>: The transcripts of the interviewee 2. The original language was not English, so we used OpenAI to generate the English version.</p> <p>File 7 - <strong>Filled_Questionnaire_Interviewee_3.pdf</strong>: The questionnaire answered by the interviewee 3, with the scores and comments.</p> <p><strong>Expert 3</strong> did not authorize us to release the interviews, so we are not sending the transcripts.</p>
Reference Architecture for Autonomy and Adaptivity in the Space Domain
<p>File 1 - <strong>Protocol SLR - Reference Architecture for autonomous and adaptive space systems.xlsx</strong>: This data extraction worksheet presents the relevant data from the identified studies and provides the selection process in this systematic literature review. The main information reported in this worksheet summarizes the followed protocol, containing an identifier (id) for each returned study. This catalog helped us in the data extraction and synthesis procedures and may be used by potentially interested, for example, for updating or replication. </p> <p>File 2 - <strong>Interview_Guide_Questionnaire.pdf</strong>: The questionnaire was used to guide the interviews and also to ensure consistency between responses. It covers key aspects of the proposed reference architecture, such as general applicability, autonomy and adaptability, scalability, and standards compliance. There is also space for interviewers to add comments in each section and at the end of the form.</p> <p>File 3 - <strong>Filled_Questionnaire_Interviewee_1.pdf</strong>: The questionnaire answered by the interviewee 1, with the scores and comments.</p> <p>FIle 4 - <strong>Expert 1 Transcription.docx</strong>: The transcripts of the interviewee 1. The original language was not English, so we used OpenAI to generate the English version.</p> <p>File 5 - <strong>Filled_Questionnaire_Interviewee_2.pdf</strong>: The questionnaire answered by the interviewee 2, with the scores and comments.</p> <p>FIle 6 - <strong>Expert 2 Transcription.docx</strong>: The transcripts of the interviewee 2. The original language was not English, so we used OpenAI to generate the English version.</p> <p>File 7 - <strong>Filled_Questionnaire_Interviewee_3.pdf</strong>: The questionnaire answered by the interviewee 3, with the scores and comments.</p> <p><strong>Expert 3</strong> did not authorize us to release the interviews, so we are not sending the transcripts.</p>
Systematic literature review of reference architectures evaluation
<p>Systematic literature review of reference architectures evaluation</p>
Experiments data for "Reference Architecture for serverless Machine Learning"
<p>Data collected during experiments in my bachelor thesis.</p>
Reference Architecture for Trust-based Digital Ecosystems
<p>Pre-recording of the presentation for the paper "Reference Architecture for Trust-based Digital Ecosystems"</p>
3D chromatin architecture of drug-tolerant cancer cells at single-cell resolution (Reference dataset of population cells)
GEO Series GSE195810. Homo sapiens. 6 samples. Type: Genome binding/occupancy profiling by high throughput sequencing.
Analysis data for "Reference Architecture for Serverless Machine Learning"
<p>Data used for analysis in my bachelor thesis.</p>
An Overview of Selected Prognostic Technologies with Reference to an Integrated PHM Architecture
This chapter reviewed generic prognosis algorithmic approaches and introduced some of the basics associated with probabilistic predictions and a required architecture for performing prognostics on critical aerospace systems. Prognosis is a critical element of a HM system and has the promise to realize major benefits for cost avoidance and safety improvement for fielded systems. It also presents a number of challenges to the HM system designer, primarily due to the need to properly model damage progression and to deal with large-grain uncertainty. Long-term prediction of a fault’s evolution to the point thatmay result in a failure requires means to represent and manage the inherent uncertainty. Moreover, accurate and precise prognosis demands good models of the fault growth and statistically sufficient samples of failure data to assist in training, validating, and fine tuning prognostic algorithms. Prognosis performance metrics, robust algorithms, and test platforms that may provide needed data have been the target of HM researchers in the recent past. Many accomplishments have been reported but major challenges still remain to be addressed. To address the issue of inherent uncertainties that are the aggregate of many unknowns and can result in considerable prediction variability, the concept of adaptive prognosis was introduced. In that case, available, albeit imperfect, information is used to update elements of the prognostic model. Only one of many approaches for accomplishing this was briefly introduced, namely, the particle filter. Other statistical update techniques include Bayesian updating, constrained optimization, and Kalman filtering. The design process is not a trivial process by which features and models are chosen for integration such that the best possible prediction on RUL still is obtained. It takes substantial effort to design systems so that measured data can be fused and used in conjunction with physics-based models to estimate current and future damage states. This is exacerbated when multiple models are employed that may use different feature inputs. The prognosis system must also be capable of intelligently calibrating a priori initial conditions (e.g., humidity, strain, and temperature) and random variable characteristics in an automated yet lucid process.
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.