dataesr/scientific-paragraphs-categorization huggingface dataset:
Such a cross-lingual discourse analysis can provide some insights for improving the quality of (machine) translation  (Meyer and Webber, 2013; Meyer and Poláková, 2013; Guzmán et al. , 2014; Iruskieta et al. , 2015; Chen et al. , 2020). This paper presents an interactive system that visualizes the cross-lingual discourse relations using two human-annotated multilingual discourse datasets 1 It is implicit because these sentences are not connected with an explicit discourse marker such as "Because". (Zeyrek et al. , 2019; Long et al. , 2020)  derived from TED talks following the Penn Discourse Treebank (PDTB)  (Prasad et al. , 2008)  framework. Our interactive data dashboard provides users with an overview of relation preservation among all language pairs. We also display a graph network depicting the cross-lingual discourse relations between a pair of languages for a given TED talk, and provide a search function to find sentences with specific query or relation types.
Preprocessing Datasets We abbreviate the two discourse-annotated datasets,  Zeyrek et al. (2019)  and  Long et al. (2020) , as TED-Mult and TED-ZH, respectively. TED-Mult involves seven languages (English, German, Lithuanian, Polish, Portuguese, Russian, and Turkish); and TED-ZH, two languages (English and Chinese). Thus, our analysis is conducted across the 28 possible language pairs. In order to facilitate cross-lingual analysis, we first performed sentence level alignment using a sentence segmentation tool 2  based on conditional random fields and a set of heuristic rules. We note that the reason for using this particular tool is that it guarantees the reconstruction of original texts when segmented sentences are joined together; and that it supports custom regex-based rules to add to allowlist or denylist if need be.
We note that the manual correction was seldom required. In total, we used seven cross-lingual talks from  TED-Mult and four talks from TED-ZH, which are aligned with other languages. Overall, there are about 400 sentences per language, and Table  1  shows more details on the corpora statistics. 3 System Description Our system is implemented using Streamlit 3 which is an open-source web application framework in Python. The aligned dataset with codes 4 and the demo system 5 are available online. The system is organized into three sections, "Overall Patterns", "Pairwise Talks", and "Search", where each section can be accessed via a navigation panel on the left-hand side. 3 https://streamlit. io/ 4 https://github. com/zaemyung/ Visualizing-Cross-Lingual-Discourse-Relations 5 https://share. streamlit.
0). For each TED talk and a pair of source and target languages, an interactive graph network is rendered to show cross-lingual discourse relations (Figure  2 ). A node in the graph represents a sentence, while an edge depicts inter-sentential discourse relation between two nodes. In the graph of the screenshot, the orange graph represents the discourse graph for the first five sentences the Russian document, while the blue one shows that of the English counterpart. The vertical line between the two discourse graphs indicates cross-lingual sentence alignment. We note that the context window of the generated graph can be adjusted by the Lower index and Upper index sliders, in the case of really long TED talks where, otherwise, the resulting graph would be too large to render efficiently. With this graph representation, we can easily view which nodes share similar cross-lingual 8 These kinds of issues were resolved via majority voting or discussion when creating the annotated datasets by their respective authors.
Here, the input-to-output delay δ(T ) depends on a single parameter, the previous-output-to-input delay T (see This research was partially funded by the Austrian Science Fund (FWF) projects DMAC (P32431) and ADynNet (P28182), the Centre National de la Recheche Scientifique projects ABIDE and BACON, the Agence Nationale de la Recherche project FREDDA (ANR-17-CE40-0013), and by the DigiCosme working group HicDiesMeus under ANR grant agreements ANR-11-LABEX-0045-DIGICOSME and ANR-11-IDEX-0003-02 in(t) t out(t) t T δ ↑ (T ) Fig. 1. The delay δ ↑ as function of T. Taken from  [8]. Fig. 1 ). Still, Függer et al. [5]  showed that none of the existing delay models, including DDM, is faithful, as they fail to correctly predict the behavior of circuits solving the canonical short-pulse filtration (SPF) problem.
Validation of the local-gradient evaporation model In order to validate our implementation of the local-gradient evaporation model in CONVERGE, we use Desoutter et al. [4]  DNS of an evaporating film in a turbulent channel flow as a reference. They used the AVBP  [13]  code with a third-order time and space Taylor-Galerkin scheme  [14] , along with an evaporation model based on the local-gradient approach (Eq. (  1 )). In this case the mixture is air/n-heptane. The film surface temperature is set to 309. 4 K, the target temperature and fuel mass fraction at the center of the channel are T target = 400 K and Y F,target = 0. 1. For a given case conditions, the fuel mass fraction at the film surface Y F,s (ex- 2) is constant in time and space and it is highly dependent on the case pressure and on the used P v,F.
Modern imaging devices provide a wealth of data often organized as images with many dimensions, such as 2D/3D, time and channel. Matlab is an efficient software solution for image processing, but it lacks many features facilitating the interactive interpretation of image data, such as a user-friendly image visualization, or the management of image meta-data (e. g. spatial calibration), thus limiting its application to bio-image analysis. The ImageM application proposes an integrated user interface that facilitates the processing and the analysis of multi-dimensional images within the Matlab environment. It provides a user-friendly visualization of multi-dimensional images, a collection of image processing algorithms and methods for analysis of images, the management of spatial calibration, and facilities for the analysis of multi-variate images.
g. spatial calibration), thus limiting its application to bio-image analysis. The ImageJ/Fiji software  (Schneider et al. , 2012)  is an alternative that provides an intuitive graphical user interface for image exploration, and many image processing functions that take into account spatial or channel calibration. The basic functionalities can by extended by a large collection of plugins. The integration of custom developments is possible via macros or plugins, but this often requires advanced programming skills. The ImageM software aims at providing a user-friendly interface for the interactive exploration, processing and analysis of multi-dimensional imaging data within the Matlab environment, while taking into account meta-data and facilitating the integration with custom algorithm developments.
Implementation ImageM strongly relies on Matlab's Object-Oriented Programming. The core feature is an "Image" class that handles arrays up to five dimensions, corresponding to three spatial dimensions, the channels, and the time. It also encapsulates image meta-data such as spatial calibration, image name, or channel names. The user interface relies on various image viewers adapted to the type (grayscale, color, label, multivariate) and the dimensionality of the image (Figure  1a ). Interactive tools allow for quick image exploration, for example histograms, line profiles and 3D visualization. The architecture was kept modular to facilitate the inclusion of new features. d, g ). Analysis of the image results in table frame (f). Menu actions are transcripted into runnable Matlab commands (e).
Operation To have the whole functionalities, Matlab (v2020a) is required, as well as the Image Processing and the Statistics toolboxes. The Gui Layout Toolbox  (Sampson, 2021)  is required to benefit from flexible image viewers. ImageM runs on a typical workstation. The application is launched by typing "ImageM" from the command line. Menus provide quick access to common image processing operators, organized in a way to make them easily discoverable by a non-expert user. When necessary, intuitive dialogs allow for setting up parameters. Preview of the results facilitates the choice of relevant settings. Region of interest may be defined interactively to perform interactive measurements. To facilitate usage during scripting and integration with custom developments, images can be easily imported from and exported to the workspace.
Use case We present here a use case describing image segmentation and region analysis of the 3D image presented in Figure  1. The Extended data  (Legland & Devaux, 2021)  contains the sample files, and more detailed use cases. • First, run the application by typing "ImageM" from Matlab command line. • In the menu, select "File->Open Image …" and choose the file "arabidopsis-embryo. tif". This opens an image viewer for the 3D image. • Reduce the noise in the image, by selecting "Process->Gaussian Filter …". This opens a dialog. • Choose value 1 for each of the "sigma" values, and click "OK". The filtered image appears in a new viewer. • Perform 3D segmentation of the cells. Select menu entry "Process->Extended Min Watershed …". Choose a basin dynamic equal to 6, the "C6" connectivity, and result type as "basins".
Software availability Packaged application available for direction download from: https://www. mathworks. com/matlabcentral/fileexchange/ 45847-imagem Source code available from: https://github. com/mattools/ImageM Archived source code as at time of publication: http://doi. org/10. 5281/zenodo. 4674326  (Legland, 2021). License: BSD 2-Clause "Simplified" License The use cases do a nice job of quickly showcasing some of the great things you can do with ImageM. However, the article's introduction and rationale needs work, and the program needs to be better documented and tested. Nonetheless, this software is certainly worth advertising to the scientific community. > Is the rationale for developing the new software tool clearly explained? Partly. I have two problems with the rationale as written: The claim that ImageM addresses novel visualization challenges: > Modern imaging devices provide a wealth of data often organized as images with many dimensions, for instance 2D/3D, time and channel.
This leads to new challenges in the exploration, visualization and processing of multi-dimensional data. In particular, multispectral images require the application of methods at the intersection of spectroscopy and image processing. Challenges in visualization of 3D, time and channel are not "new". ImageJ's core gained 5D support in 2007 with version 1. 39l, and there were many earlier programs with >=5D support as well (e. g. BioImageXD, VisBio, ImageJ via the Image5D plugins, OME Server). related challenge of scientific imaging. Multiple angles? Fields of view? Fluorescence lifetime? ImageM is limited to 3D+time+channel. Therefore, it does not facilitate handling of any "new challenges" in dimensionality beyond this paradigm. Rather than argue that ImageM addresses new challenges in scientific imaging, the article would be better served explaining that ImageM builds on the wealth of functionality available in MATLAB, enabling more seamless integration of other MATLAB-based tools with its 5D image paradigm.
The two use cases, especially use case 2, illustrate this fact well. The lack of discussion of the technical merit of a MATLAB-based implementation of an ImageJ-like program: While this is a short article, it would be ideal-if sufficient space-to mention ImageJ's MATLAB integrations ImageJ-MATLAB (https://imagej. net/scripting/matlab) and MIJ/Miji ( https://imagej. net/plugins/miji), and how ImageM compares to them. This is an important part of the justification for essentially reimplementing ImageJ in MATLAB: what are the downsides of using the existing ImageJ within MATLAB via its built-in JVM? How does ImageM overcome those downsides? I do believe there is technical merit to ImageM. But the article needs to do a clearer job explaining the benefits. > it lacks many features for facilitating the interactive interpretation of image data, such as a user-friendly visualization of multidimensional images or the management of image metadata (e.
g. spatial calibration), thus limiting its application to bio-image analysis. I am not well versed in the ecosystem of MATLAB add-ons, so I cannot evaluate whether this statement is really true, but I am skeptical. Consider rewording to frame things more positively, saying that ImageM provides user-friendly capabilities that build upon, enhance, and complement MATLAB's existing image processing offerings. > The integration of custom developments is possible via macros or plugins, but this often requires advanced programming skills. I disagree about MATLAB programming being easier than ImageJ macro programming. Both are designed to be as accessible as possible, while still being powerful. Instead of arguing that extending ImageJ is too hard, why not instead argue that extending ImageM via MATLAB code enables scripters to easily harness MATLAB's power, flexibility, and extensive suite of toolboxes and add-ons? ○ > Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? Yes.
○ From the ImageM manual: ○ > An element of an image is usually associated to a square region centered on its coordinates. > Its bounds are therefore ±0. 5 around each dimension. A Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? Yes Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Yes Competing Interests: No competing interests were disclosed. Reviewer Expertise: Software engineering, software architecture, image visualization, image processing, image analysis. I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however I have significant reservations, as outlined above.
Extended data Zenodo: Extended data for the manuscript "ImageM: a user-friendly interface for the processing of multi-dimensional images with Matlab", http://doi. org/10. 5281/zenodo. 4705240  (Legland & Devaux, 2021). This project contains the following extended data: -User manual -Octave compatibility notice -Two detailed use cases -Images used in use cases Data are available under the terms of the Creative Commons Attribution 4. 0 International license (CC-BY 4. 0).
rationale for developing the new software tool clearly explained? Partly Is the description of the software tool technically sound? Yes Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? Yes pixel is not a little square. http://alvyray. com/Memos/CG/Microsoft/6_pixel. pdf As mentioned above, I had a hard time getting ImageM installed. Here are the issues I filed on GitHub to give some technical detail:MATLAB Online -https://github. com/mattools/ImageM/issues/1 ○ Octave -https://github. com/mattools/ImageM/issues/2 ○ MATLAB R2021a -https://github. com/mattools/ImageM/issues/3 ○ Is the.
The growing web of data warrants better data management strategies. Data silos are single points of failure and they face availability problems which lead to broken links. Furthermore the dynamic nature of some datasets increases the need for a versioning scheme. In this work, we propose a novel architecture for a linked open data infrastructure, built on open decentralized technologies. IPFS is used for storage and retrieval of data, and the public Ethereum blockchain is used for naming, versioning and storing metadata of datasets. We furthermore exploit two mechanisms for maintaining a collection of relevant, high-quality datasets in a distributed manner in which participants are incentivized. The platform is shown to have a low barrier to entry and censorship-resistance. It benefits from the fault-tolerance of its underlying technologies.
Introduction Over the last decade, as more and more linked data in the form of RDF  [7]  triples were published, a set of data management practices  [18]  were proposed and adopted which aimed to improve integration and reuse among datasets, forming the web of data, which can be seen as a global namespace connecting individual graphs and statements. From a logical point of view, linked data is inherently decentralized. However, from a practical point of view, the actual data reside on data silos which suffer from low availability  [10] , leading to broken links. Furthermore, when considering dynamic datasets  [19] , a lack of robust versioning scheme can lead to inconsistencies when an external linked dataset is modified. But versioning datasets using HTTP has so far proven difficult  [27].
Another implication of the unprecedented volume of data being published in web of data is the varying quality of datasets. Expert quality assessment  [33]  and curation produces the best result, but in large scale incurs high costs in terms of expert time and labor. The contributions of this work include a novel architecture for a decentralized linked open data infrastructure, based on IPFS  [4]  and the public Ethereum blockchain  [32]. The design includes an indexing scheme suitable for linked data, and a mechanism for retrieval of data by performing triple pattern or SPARQL queries. It further outlines how smart contracts can be employed to provide a persistent identifier for data objects stored on IPFS, to describe and version datasets, to control write access and to ensure source of provenance.
A prototype of the aforementioned architecture has been implemented, and is available under an open license  1. Moreover, on this foundation, and to further explore crowdsourcing data curation in scale, we exploit two mechanisms, first proposed by Ethereum community members  [5, 14] , which facilitate distributed, truthful, incentivized consensus on a curated list of datasets. The mechanisms are agnostic to the domain and the actual quality metrics. The rest of this article is divided as follows. First we provide some necessary presentation about the considered technologies in Section 2. In Section 3, we present the decentralized architecture we propose to store data; and the Ethereum smart contract solutions we set up to manage the knowledge graphs (KG) in Section 4; before presenting data curation strategies in Section 5.
Background IPFS  [4]  is a peer-to-peer protocol for content-addressable storage and retrieval of data. It is a peer-to-peer network, with no difference between the participating nodes. It utilizes routing mechanisms to keep track of data storage, and block exchange mechanisms to facilitate the transfer of data. Every node stores IPFS objects in their local storage. These objects could be published by the node, or retrieved from other nodes and replicated locally. Objects in IPFS are comprised of immutable content-addressed data structures (such as files), that are connected with links, forming a Merkle DAG (directed acyclic graph). Addressing is done using cryptographic hashes. Content can be identified uniquely by its hash, and after retrieval, the integrity of it can be verified against the hash that was used to address it.
IPFS, however, does not guarantee persistence, only permanence. A piece of content can always be referred by its hash, but it doesn't necessarily exist in the nodes of the network at all times. IPLD 2 is a data model that aims to provide a unified address space for hashlinked data structures, such as IPFS objects, git objects, Ethereum transaction data, etc. , which would allow traversing data regardless of the exact underlying protocol. The benefits of such a data model include protocol-independent resolution and cross-protocol integration, upgradability, self-descriptive data models that map to a deterministic wire encoding, backward-compatibility and formatindependence. A key aspect of IPLD, is a self-describing content-addressed identifier format, called CID 3 which describes an address along with its base, version of the CID format, format of the data being addressed, hash function, hash size and finally the hash (address).
A fully decentralized storage system Our proposed architecture relies on two open technologies. First, IPFS for the actual storage and retrieval of raw data (see Section 6), and Ethereum, for tracking ownership, versioning and other metadata belonging to the KG (more details in Section 4), and later on, as will be discussed, for decentralized curation of datasets (cf. Section 5). Permissioned, centralized triplestores often store all inserted triples in a single index. However, this is not desirable in a permissionless setting where any entity has write access to the same store, meaning, entities can even publish triples that are in conflict with others already in the triplestore. Hence, in our effort, KGs are not only conceptual, but they are actually stored in separate indices, that are managed by their corresponding publishing entity.
The KGs are still connected by the URI scheme, and it is possible to do federated queries across multiple KGs. One can imagine KGs to be the counterpart of servers which contain a single dataset as opposed to multi-dataset repositories. The access control mechanism is controlled on the blockchain level (Section 4), and the P2P storage layer is agnostic to access. Due to the immutable nature of IPFS, this introduces no conflict, as each modification to an existing object results in a totally new object with a new address, regardless of who has published the modified dataset. Each KG is indexed as a Hexastore  [31]  on IPFS. However, the Hexastore is not stored as a single data object, but is rather broken into smaller data nodes, which are connected via links, forming an IPLD merkle-dag. Practically, each KG has a root object, with 6 keys, namely spo, sop, pso, pos, osp, ops where the value of each key is a link to another object containing the triples for that subindex.
Graph The Graph smart contract is meant to represent a single dataset, maintained by a single entity. It tracks the history of the graph, stores relevant information such as version, and points to additional metadata that the author wishes to attach to their dataset. When creating a new KG, the publisher must publish the RDF triples on IPFS, as outlined in the previous section, and deploy an instance of the Graph contract, providing the root hash of the index as input. The deployed instance has a permanent address, which they can distribute to data consumers. Consumers can then query the Ethereum blockchain to fetch the state of the aforementioned contract instance, find the current root hash which they can use to perform queries. To update the KG, they update the index on IPFS, and make a transaction to the contract, providing the new hash as input.
Furthermore, versions of G are automatically tagged by an auto-increment version field, which can be used to query specific versions of G without referring to the full IPFS hash in SPARQL, as will be discussed in the next section. Metadata & Attribution -The smart contract also keeps an optional metadata field, which is an IPFS hash. The IPFS object identified by metadata could contain additional information about the knowledge graph such as details about the authors, citations to other graphs or a website link.