Search

• Self-reporting data assets are introduced as an implementation of FAIR data. • Requirements for SRDAs are extracted from top pharma and biotech workflows. • A fit/gap analysis for Allotrope Data Format, AnIML, JCAMP-DX, and JSON is presented. • Allotrope Data Format is found to be the best representation for SRDAs. Standardizing data is crucial for preserving and exchanging scientific information. In particular, recording the context in which data were created ensures that information remains findable, accessible, interoperable, and reusable. Here, we introduce the concept of self-reporting data assets (SRDAs), which preserve data and contextual information. SRDAs are an abstract concept, which requires a suitable data format for implementation. Four promising data formats or languages are popularly used to represent data in pharma: JCAMP-DX, JSON, AnIML, and, more recently, the Allotrope Data Format (ADF). Here, we evaluate these four options in common use cases within the pharmaceutical industry using multiple criteria. The evaluation shows that ADF is the most suitable format for the implementation of SRDAs. [ABSTRACT FROM AUTHOR]

auto{API} is a web-based tool for the specification and management of API endpoints to online XML data sources. The APIs generated return the data in JSON format. The tool allows users to specify the field names to be used in the JSON data and to control which elements of the original data set are returned. Options are provided for the returned data to skip null values and to flatten the structure that is retrieved. auto{API} is written in Python/Flask and is available under the MIT licence. The software is available from GitHub ('https://github.com/aamoore/autoAPI') and can be seen deployed at 'https://autoapi-app.herokuapp.com/?http://apis.opendatani.gov.uk/translink/3042AA.xml'.

Copyright of Ordnance Industry Automation is the property of Editorial Board for Ordnance Industry Automation and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written permission. However, users may print, download, or email articles for individual use. This abstract may be abridged. No warranty is given about the accuracy of the copy. Users should refer to the original published version of the material for the full abstract. (Copyright applies to all Abstracts.)

Transmitting binary data across a network should generally avoid transmitting raw binary data over the medium for several reasons, one would be that the medium may be a textual one and may not accept or correctly handle raw bitstream, another would be that some protocols may misinterpret the meaning of the bits and causes a problem or even loss of the data. To make the data more readable and would avoid misinterpretation by different systems and environments, this paper introduces encoding two of the most broadly used data interchange formats, XML and JSON, into the Base64 which is an encoding scheme that converts binary data to an ASCII string format by using a radix-64 representation. This process, will, make the data more readable and would avoid misinterpretation by different systems and environments. The results reflect that encoding data in Base64 before the transmission will present many advantages including readability and integrity, it will also enable us to transmit binary data over textual mediums, 7 Bit protocols such as SMTP, and different network hardware without risking misinterpretation. [ABSTRACT FROM AUTHOR]

Human-motion data need to be stored and processed to manage wearable robots. Given the considerable data volume associated with sensor data, we designed a database that efficiently stores sensor data from human motion and can be used by intelligent wearable robots. We designed a database for sensor data from human motions for use in intelligent wearable robots. We used functions to preprocess and transform the data into JSON files. Additionally, we created a function to store and process data files in the database. A database of human-motion data is necessary to determine whether robot movements (e.g., by wearable robots or robot simulations) are similar to those of humans. The most common methods for collecting motion data from people have been markerless optical systems. However, these methods are less accurate than motion capture using a non-optical system. We designed and implemented a database to collect and store accurate human-motion data using a non-optical inertial motion-capture system. Our database can be applied to walking robots used for people with paraplegic disabilities who need walking assistance, and to robots and equipment that mimic human movements for people working in high-risk environments. Our system can also be applied to humanoid robotics. [ABSTRACT FROM AUTHOR]

Today, although there is an increasing interest in temporal JSON instance documents, since they allow tracking data changes, recovering past data versions, and executing temporal queries, there is no support (data model, modelling language, method, or tool) for conceptual modelling of temporal JSON data. Moreover, even though there are some graphical editors to build JSON Schemata (like JSON Schema Editor of Altova), they do not provide any built-in support for modelling temporal aspects of JSON data. Therefore, designers of JSON-based NoSQL data stores are proceeding in an ad hoc manner when they have to model some temporal requirements. To fill this theoretical and practical gap, we propose in this paper a graphical conceptual model for time-varying JSON data, named Temporal JSON Conceptual Model (TempoJCM). To this purpose, first we define a graphical conceptual model for conventional (i.e., non temporal) JSON data, called JSON Conceptual Model (JCM), and then we extend it to support modelling of temporal aspects of JSON data. TempoJCM facilitates conceptual modelling of both conventional and temporal JSON data, in a graphical and user-friendly manner. An editor supporting TempoJCM is planned to become the user interface for temporal JSON schema design in the τJSchema framework. [ABSTRACT FROM AUTHOR]

In this paper, the mathematical models of a solar thermal system which governs the solar thermal collector, the heat storage system, and the pump are presented. It has been shown that it is possible to connect a Simulink-based model to a meteorological database server using standard communication protocols by a C language-based component in order to import real-life weather information into the simulation. The setup of the model predictive control of this solar thermal system and the results of the simulation are also presented. This computationally heavy control method is possible to use on today's personal computers, and it can be expanded. [ABSTRACT FROM AUTHOR]

The Molecular Entities in Linked Data (MEiLD) dataset comprises data of distinct atoms, molecules, ions, ion pairs, radicals, radical ions, and others that can be identifiable as separately distinguishable chemical entities. The dataset is provided in a JSON-LD format and was generated by the SDFEater, a tool that allows parsing atoms, bonds, and other molecule data. MEiLD contains 349,960 of ‘small’ chemical entities. Our dataset is based on the SDF files and is enriched with additional ontologies and line notation data. As a basis, the Molecular Entities in Linked Data dataset uses the Resource Description Framework (RDF) data model. Saving the data in such a model allows preserving the semantic relations, like hierarchical and associative, between them. To describe chemical molecules, vocabularies such as Chemical Vocabulary for Molecular Entities (CVME) and Simple Knowledge Organization System (SKOS) are used. The dataset can be beneficial, among others, for people concerned with research and development tools for cheminformatics and bioinformatics. In this paper, we describe various methods of access to our dataset. In addition to the MEiLD dataset, we publish the Shapes Constraint Language (SHACL) schema of our dataset and the CVME ontology. The data is available in Mendeley Data.

Semi-structural data tend to be problematic due to the sparsity of their attributes and due to the fact that, regardless of their type, they are immensely diverse. This means that data storage is a challenge, especially when the data contained within a relational database – often a strict requirement defined in advance. In this paper, we present a thoroughly described concept of a repository that is capable of storing and processing semi-structural data. Based on this concept, we establish a database model comprising the architecture and the tools needed to search the data and build relevant processors. The processor described may assign roles and dispatch tasks between the users. We demonstrate how the capacities of this repository are capable of overcoming current limitations by creating a system for facilitated digitization of scientific resources. In addition, we show that the repository in question is suitable for general use, and, as such, may be adapted to any domains in which semi-structural data are processed, without any additional work required

Ada 2022 introduces new features that enable more natural-looking initializations. On the one hand, it is now possible to use universal numbers and strings to initialize any private type; on the other hand, containers can be initialized directly without the explicit use of converting functions. Both features are enabled through new aspects that associate user-defined subprograms with the necessary initialization calls. In this work, the possibility of using these new features is explored to define a container type that allows initializations using heterogeneous types, as is usual in textual formats for structured data such as JSON, TOML and YAML, and still without the need to resort to explicit conversion calls or "crutch" functions like the oftenseen trick of overloading the "+" operator. Although this has proven ultimately avoidable, there is still the need to use qualifications in certain circumstances. [ABSTRACT FROM AUTHOR]

auto{API} is a web-based tool for the specification and management of API endpoints to online XML data sources. The APIs generated return the data in JSON format. The tool allows users to specify the field names to be used in the JSON data and to control which elements of the original data set are returned. Options are provided for the returned data to skip null values and to flatten the structure that is retrieved. auto{API} is written in Python/Flask and is available under the MIT licence. The software is available from GitHub (https://github.com/aamoore/autoAPI) and can be seen deployed at https://autoapi-app.herokuapp.com/?http://apis.opendatani.gov.uk/translink/3042AA.xml. [ABSTRACT FROM AUTHOR]

The work examines the current problems of the spread of use of logical programming in the development of commercial multi-platform software applications, tools for convenient development of a modern graphical interface to the logical programs. Libraries with similar concepts of use have been analyzed and described. The purpose of the proposed concept, which is implemented as an open source library, is described, and the advantages of the proposed tools over similar existing tools are indicated. The main feature and advantage of the proposed concept is the implementation of Prolog business logic and interface by means of JavaScript usage of child processes. The proposed concept of interface to Prolog takes full advantage of the possibilities provided by async await. A framework library has been created for the use of Logic Programming in graphical interface development without losses in the application performance. The paper describes the proposed concept and the developed framework (library). The ways to further improve the possibilities for expanding the purpose of the implemented library were identified. The directions of further simplification for programmers of integration of the graphic interface to logical programs have been de- fined. A significant advantage of the proposed tool is the easy-to-use functions to wrap and control the correctness of requests to the Prolog. The main goal of the library is to create an environment for the Prolog developers where they can create any type of software, which is meant to be user friendly, fast, and cross platform using modern and flexible. This concept also tries to solve disadvantages and architectural problems that were found in other libraries. The safety of library functionality has been analyzed. The concept of potential horizontal application scalability is described. Conclusions and future of libraries were introduced, in which the usage of TypeScript for type-safety and avoidance of run-time errors is mentioned. Overall, the library extends the use of Prolog beyond logical programming and takes a leap forward in its progress. [ABSTRACT FROM AUTHOR]

RESTful APIs (REpresentational State Transfer Application Programming Interfaces) are the most commonly used mechanism for biodiversity informatics databases to provide open access to their content. In its simplest form an API provides an interface based on the HTTP protocol whereby any client can perform an action on a data resource identified by a URL using an HTTP verb (GET, POST, PUT, DELETE) to specify the intended action. For example, a GET request to a particular URL (informally called an endpoint) will return data to the client, typically in JSON format, which the client converts to the format it needs. A client can either be custom written software or commonly used programs for data analysis such as R (programming language), Microsoft Excel (everybody's favorite data management tool), OpenRefine, or business intelligence software. APIs are therefore a valuable mechanism for making biodiversity data FAIR (findable, accessible, interoperable, reusable). There is currently no standard specifying how RESTful APIs should be designed, resulting in a variety of URL and response data formats for different APIs. This presents a challenge for API users who are not technically proficient or familiar with programming if they have to work with many different and inconsistent data sources. We undertook a brief review of eight existing APIs that provide data about taxa to assess consistency and the extent to which the Darwin Core standard (Wieczorek et al. 2021) for data exchange is applied. We assessed each API based on aspects of URL construction and the format of the response data (Fig. 1). While only cursory and limited in scope, our survey suggests that consistency across APIs is low. For example, some APIs use nouns for their endpoints (e.g. 'taxon' or 'species'), emphasising their content, whereas others use verbs (e.g. 'search'), emphasising their functionality. Response data seldom use Darwin Core terms (two out of eight examples) and a wide range of terms can be used to represent the same concept (e.g. six different terms are used for dwc:scientificNameAuthorship). Terms that can be considered metadata for a response, such as pagination details, also vary considerably. Interestingly, the public interfaces for the majority of APIs assessed do not provide POST, PUT or DELETE endpoints that modify the database. POST is only used for providing more detailed request bodies to retrieve data than possible with GET. This indicates the primary use of APIs by biodiversity informatics platforms for data sharing. An API design guideline is a document that provides a set of rules or recommendations for how APIs should be designed in order to improve their consistency and useability. API design guidelines are typically created by particular organizations to standardize API development within the organization, or as a guideline for programmers using an organization's software to build APIs (e.g., Microsoft and Google). The API Stylebook is an online resource that provides access to a wide range of existing design guidelines, and there is an abundance of other resources available online. This presentation will cover some of the general concepts of API design, demonstrate some examples of how existing APIs vary, and discuss potential options to encourage standardization. We hope our analysis, the available body of knowledge on API design, and the collective experience of the biodiversity informatics community working with APIs may help answer the question "Does TDWG need an API design guideline?" [ABSTRACT FROM AUTHOR]

Copyright of Journal of Mine Automation is the property of Industry & Mine Automation Editorial Department and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written permission. However, users may print, download, or email articles for individual use. This abstract may be abridged. No warranty is given about the accuracy of the copy. Users should refer to the original published version of the material for the full abstract. (Copyright applies to all Abstracts.)

The large volume and variety of data produced in the current Big Data era lead companies to seek solutions for the efficient data management. Within this context, NoSQL databases rise as a better alternative to the traditional relational databases, mainly in terms of scalability and availability of data. A usual feature of NoSQL databases is to be schemaless, i.e., they do not impose a schema or have a flexible schema. This is interesting for systems that deal with complex data, such as GIS. However, the lack of a schema becomes a problem when applications need to perform processes such as data validation, data integration, or data interoperability, as there is no pattern for schema representation in NoSQL databases. On the other hand, the JSON language stands out as a standard for representing and exchanging data in document NoSQL databases, and JSON Schema is a schema representation language for JSON documents that it is also leading to become a standard. However, it does not include spatial data types. From this limitation, this paper proposes an extension to JSON Schema, called JS4Geo, that allows the definition of schemas for geographic data. We demonstrate that JS4Geo is able to represent schemas of any NoSQL data model, as well as other standards for geographic data, like GML and KML. We also present a case study that shows how a data integration system can benefit of JS4Geo to define local schemas for geographic datasets and generate an integrated global schema. [ABSTRACT FROM AUTHOR]

The development of the next-generation sequencing (NGS) technologies has led to massive amounts of VCF (Variant Call Format) files, which have been the standard formats developed with 1000 Genomes Project. At the same time, with the widespread use of biomedical ontologies in the biomedical community, more and more applications have accepted the Web Ontology Language (OWL) as the dominant data format for the specifications of biomedical ontology descriptions, leading to the rapid growth of OWL-based biomedical ontology scale. In this paper, we seek to explore an effective method for the management of VCF-based genetic variants and OWL-based biological ontologies using the MongoDB database. Considering many current applications (such as the short genetic variations database dbSNP, etc.) are transitioning to the new design by using JSON (JavaScript Object Notation) to support future massive data expansion and interchanges. We firstly propose a series of rules for the mapping from VCF and OWL files to JSON files, and then present rule-based algorithms for transforming VCF-based genetic variants and OWL-based biological ontologies into JSON objects. On this basis, we introduce effective approaches of integrating the mapped JSON files in MongoDB. Finally, we complement this work with a set of experiments to show the performance of our proposed approaches. The source code of the proposed approaches could be freely available at https://github.com/lyotvincent/AJIA. [ABSTRACT FROM AUTHOR]

JSON is probably one of the most popular data formats in the Internet of Things (IoT). It has gained popularity among developers due to its easy readability. The disadvantage of this format is the size of the resulting document and the associated bandwidth requirements. In order for us to be able to transfer such data securely, it is necessary to secure it before transferring it. Often, this data is compressed before it is encrypted. This article deals with a non-standard method of data compression, which reduces the computational demands on the device side. It should be noted that many of these devices are powered by batteries with limited capacity. [ABSTRACT FROM AUTHOR]

One of the biggest challenges in IoT-forensics is the analysis and correlation of heterogeneous digital evidence, to enable an effective understanding of complex scenarios. This paper defines a methodology for extracting unique objects (e.g., representing users or devices) from the files of a case, defining the context of the digital investigation and increasing the knowledge progressively, using additional files from the case (e.g. network captures). The solution includes external searches using open source intelligence (OSINT) sources when needed. In order to illustrate this approach, the proposed methodology is implemented in the JSON Users and Devices analysis (JUDAS) tool, which is able to generate the context from JSON files, complete it, and show the whole context using dynamic graphs. The approach is validated using the files in an IoT-Forensic digital investigation where an important set of potential digital evidence extracted from Amazon’s Alexa Cloud is analysed. [ABSTRACT FROM AUTHOR]

Copyright of Techno.com is the property of Universitas Dian Nuswantoro, Fakultas Ilmu Komputer and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written permission. However, users may print, download, or email articles for individual use. This abstract may be abridged. No warranty is given about the accuracy of the copy. Users should refer to the original published version of the material for the full abstract. (Copyright applies to all Abstracts.)

Semi-structural data tend to be problematic due to the sparsity of their attributes and due to the fact that, re- gardless of their type, they are immensely diverse. This means that data storage is a challenge, especially when the data contained within a relational database - often a strict requirement defined in advance. In this paper, we present a thoroughly described concept of a repository that is capable of storing and processing semi-structural data. Based on this concept, we es- tablish a database model comprising the architecture and the tools needed to search the data and build relevant processors. The processor described may assign roles and dispatch tasks between the users. We demonstrate how the capacities of this repository are capable of overcoming current limitations by creating a system for facilitated digitization of scientific re- sources. In addition, we show that the repository in question is suitable for general use, and, as such, may be adapted to any domains in which semi-structural data are processed, without any additional work required. [ABSTRACT FROM AUTHOR]

• The Allotrope Simple Model enables rapid standardization of the digital laboratory. • Multiple companies are currently rolling out Allotrope based technologies. • The Allotrope Foundation persisted throughout the COVID-19 pandemic and penetrates vertical industries. • A How-To guide to develop Allotrope Simple Models is provided. The Allotrope Foundation (AF) started as a group of pharmaceutical companies, instrument, and software vendors that set out to simplify the exchange of data in the laboratory. After a decade of work, they released products that have found adoption in various companies. Most recently, the Allotrope Simple Model (ASM) was developed to speed up and widen the adoption. As a result, the Foundation has recently added chemical companies and, importantly, is reworking its business model to lower the entry barrier for smaller companies. Here, we present the proceedings from the Allotrope Connect Fall 2023 conference and summarize the technical and organizational developments at the Foundation since 2020. [ABSTRACT FROM AUTHOR]