More Like this

1. An Exploratory Interface for Dataset Repositories Using Cell-Centric Indexing

   https://doi.org/10.1109/BigData50022.2020.9378057  

   Johnson, Drake ; Register, Keith ; Davison, Brian D. ; Heflin, Jeff ( December 2020 , IEEE International Conference on Big Data (IEEE BigData 2020))

   Large collections of datasets are being published on the Web at an increasing rate. This poses a problem to researchers and data journalists who must sift through these large quantities of data to find datasets that meet their needs. Our solution to this problem is cell-centric indexing, a novel approach which considers the individual cell of a dataset to be the fundamental unit of search, indexing the corresponding metadata to each individual cell. This facilitates a new style of user interface that allows users to explore the collection via histograms that show the distributions of various terms organized by how they are used in the dataset.
2. Software Environments in Binder Containers

   https://doi.org/10.5281/zenodo.4891790  

   Shaffer, Tim ; Chard, Kyle ; Thain, Douglas ( January 2021 )

   Abstract

   <p>Binder is a publicly accessible online service for executing interactive notebooks based on Git repositories. Binder dynamically builds and deploys containers following a recipe stored in the repository, then gives the user a browser-based notebook interface. The Binder group periodically releases a log of container launches from the public Binder service. Archives of launch records are available here. These records do not include identifiable information like IP addresses, but do give the source repo being launched along with some other metadata. The main content of this dataset is in the <code>binder.sqlite</code> file. This SQLite database includes launch records from 2018-11-03 to 2021-06-06 in the <code>events</code> table, which has the following schema.</p> <code>CREATE TABLE events( version INTEGER, timestamp TEXT, provider TEXT, spec TEXT, origin TEXT, ref TEXT, guessed_ref TEXT ); CREATE INDEX idx_timestamp ON events(timestamp); </code> <ul><li><code>version</code> indicates the version of the record as assigned by Binder. The <code>origin</code> field became available with version 3, and the <code>ref</code> field with version 4. Older records where this information was not recorded will have the corresponding fields set to null.</li><li><code>timestamp</code> is the ISO timestamp of the launch</li><li><code>provider</code> gives the type of source repo being launched (&#34;GitHub&#34; is by far the most common). The rest of the explanations assume GitHub, other providers may differ.</li><li><code>spec</code> gives the particular branch/release/commit being built. It consists of <code>&lt;github-id&gt;/&lt;repo&gt;/&lt;branch&gt;</code>.</li><li><code>origin</code> indicates which backend was used. Each has its own storage, compute, etc. so this info might be important for evaluating caching and performance. Note that only recent records include this field. May be null.</li><li><code>ref</code> specifies the git commit that was actually used, rather than the named branch referenced by <code>spec</code>. Note that this was not recorded from the beginning, so only the more recent entries include it. May be null.</li><li>For records where <code>ref</code> is not available, we attempted to clone the named reference given by <code>spec</code> rather than the specific commit (see below). The <code>guessed_ref</code> field records the commit found at the time of cloning. If the branch was updated since the container was launched, this will not be the exact version that was used, and instead will refer to whatever was available at the time (early 2021). Depending on the application, this might still be useful information. Selecting only records with version 4 (or non-null <code>ref</code>) will exclude these guessed commits. May be null.</li></ul> <p>The Binder launch dataset identifies the source repos that were used, but doesn&#39;t give any indication of their contents. We crawled GitHub to get the actual specification files in the repos which were fed into repo2docker when preparing the notebook environments, as well as filesystem metadata of the repos. Some repos were deleted/made private at some point, and were thus skipped. This is indicated by the absence of any row for the given commit (or absence of both <code>ref</code> and <code>guessed_ref</code> in the <code>events</code> table). The schema is as follows.</p> <code>CREATE TABLE spec_files ( ref TEXT NOT NULL PRIMARY KEY, ls TEXT, runtime BLOB, apt BLOB, conda BLOB, pip BLOB, pipfile BLOB, julia BLOB, r BLOB, nix BLOB, docker BLOB, setup BLOB, postbuild BLOB, start BLOB );</code> <p>Here <code>ref</code> corresponds to <code>ref</code> and/or <code>guessed_ref</code> from the <code>events</code> table. For each repo, we collected spec files into the following fields (see the repo2docker docs for details on what these are). The records in the database are simply the verbatim file contents, with no parsing or further processing performed.</p> <ul><li><code>runtime</code>: <code>runtime.txt</code></li><li><code>apt</code>: <code>apt.txt</code></li><li><code>conda</code>: <code>environment.yml</code></li><li><code>pip</code>: <code>requirements.txt</code></li><li><code>pipfile</code>: <code>Pipfile.lock</code> or <code>Pipfile</code></li><li><code>julia</code>: <code>Project.toml</code> or <code>REQUIRE</code></li><li><code>r</code>: <code>install.R</code></li><li><code>nix</code>: <code>default.nix</code></li><li><code>docker</code>: <code>Dockerfile</code></li><li><code>setup</code>: <code>setup.py</code></li><li><code>postbuild</code>: <code>postBuild</code></li><li><code>start</code>: <code>start</code></li></ul> <p>The <code>ls</code> field gives a metadata listing of the repo contents (excluding the <code>.git</code> directory). This field is JSON encoded with the following structure based on JSON types:</p> <ul><li>Object: filesystem directory. Keys are file names within it. Values are the contents, which can be regular files, symlinks, or subdirectories.</li><li>String: symlink. The string value gives the link target.</li><li>Number: regular file. The number value gives the file size in bytes.</li></ul> <code>CREATE TABLE clean_specs ( ref TEXT NOT NULL PRIMARY KEY, conda_channels TEXT, conda_packages TEXT, pip_packages TEXT, apt_packages TEXT );</code> <p>The <code>clean_specs</code> table provides parsed and validated specifications for some of the specification files (currently Pip, Conda, and APT packages). Each column gives either a JSON encoded list of package requirements, or null. APT packages have been validated using a regex adapted from the repo2docker source. Pip packages have been parsed and normalized using the Requirement class from the pkg_resources package of setuptools. Conda packages have been parsed and normalized using the <code>conda.models.match_spec.MatchSpec</code> class included with the library form of Conda (distinct from the command line tool). Users might want to use these parsers when working with the package data, as the specifications can become fairly complex.</p> <p>The <code>missing</code> table gives the repos that were not accessible, and <code>event_logs</code> records which log files have already been added. These tables are used for updating the dataset and should not be of interest to users.</p>
   More>>
3. Exploring Datasets via Cell-Centric Indexing

   Heflin, Jeff ; Davison, Brian D. ; Jia, Haiyan ( September 2021 , Proceedings of DESIRES 2021: Design of Experimental Search and Information REtrieval Systems, CEUR Workshop Proceedings)

   Alonso, Omar ; Marchesin, Stefano ; Najork, Mark ; Silvello, Gianmaria (Ed.)

   We present a novel approach to dataset search and exploration. Cell-centric indexing is a unique indexing strategy that enables a powerful, new interface. The strategy treats individual cells of a table as the indexed unit, and combining this with a number of structure-specific fields enables queries that cannot be answered by a traditional indexing approach. Our interface provides users with an overview of a dataset repository, and allows them to efficiently use various facets to explore the collection and identify datasets that match their interests.
4. Deep learning tackles single-cell analysis—a survey of deep learning for scRNA-seq analysis

   https://doi.org/https://doi.org/10.1093/bib/bbab531  

   Mario Flores, Zhentao Liu ( January 2022 , Briefings in bioinformatics)

   Since its selection as the method of the year in 2013, single-cell technologies have become mature enough to provide answers to complex research questions. With the growth of single-cell profiling technologies, there has also been a significant increase in data collected from single-cell profilings, resulting in computational challenges to process these massive and complicated datasets. To address these challenges, deep learning (DL) is positioned as a competitive alternative for single-cell analyses besides the traditional machine learning approaches. Here, we survey a total of 25 DL algorithms and their applicability for a specific step in the single cell RNA-seq processing pipeline. Specifically, we establish a unified mathematical representation of variational autoencoder, autoencoder, generative adversarial network and supervised DL models, compare the training strategies and loss functions for these models, and relate the loss functions of these models to specific objectives of the data processing step. Such a presentation will allow readers to choose suitable algorithms for their particular objective at each step in the pipeline. We envision that this survey will serve as an important information portal for learning the application of DL for scRNA-seq analysis and inspire innovative uses of DL to address a broader range of new challenges inmore »emerging multi-omics and spatial single-cell sequencing.« less
5. A Large Open Dataset from the Parler Social Network

   Aliapoulios, Max ; Bevensee, Emmi ; Blackburn, Jeremy ; Bradlyn, Barry ; De Cristofaro, Emiliano ; Stringhini, Gianluca ; Zannettou, Savvas ( June 2021 , Proceedings of the International AAAI Conference on Weblogs and Social Media)

   Budak, Ceren ; Cha, Meeyoung ; Quercia, Daniele ; Xie, Lexing (Ed.)

   Parler is as an ``alternative'' social network promoting itself as a service that allows to ``speak freely and express yourself openly, without fear of being deplatformed for your views.'' Because of this promise, the platform become popular among users who were suspended on mainstream social networks for violating their terms of service, as well as those fearing censorship. In particular, the service was endorsed by several conservative public figures, encouraging people to migrate from traditional social networks. After the storming of the US Capitol on January 6, 2021, Parler has been progressively deplatformed, as its app was removed from Apple/Google Play stores and the website taken down by the hosting provider. This paper presents a dataset of 183M Parler posts made by 4M users between August 2018 and January 2021, as well as metadata from 13.25M user profiles. We also present a basic characterization of the dataset, which shows that the platform has witnessed large influxes of new users after being endorsed by popular figures, as well as a reaction to the 2020 US Presidential Election. We also show that discussion on the platform is dominated by conservative topics, President Trump, as well as conspiracy theories like QAnon.