Data integration is the process of combining, sharing, or synchronizing data from multiple sources to provide users with a unified view. There are a wide range of possible applications for data integration, from commercial (such as when a business merges multiple databases) to scientific (combining research data from different bioinformatics repositories). The decision to integrate data tends to arise when the volume, complexity (that is, big data) and need to share existing data explodes. It has become the focus of extensive theoretical work, and numerous open problems remain unsolved. Data integration encourages collaboration between internal as well as external users. The data being integrated must be received from a heterogeneous database system and transformed to a single coherent data store that provides synchronous data across a network of files for clients. A common use of data integration is in data mining when analyzing and extracting information from existing databases that can be useful for Business information. == History == Issues with combining heterogeneous data sources, often referred to as information silos, under a single query interface have existed for some time. In the early 1980s, computer scientists began designing systems for interoperability of heterogeneous databases. The first data integration system driven by structured metadata was designed in 1991 at the University of Minnesota for the Integrated Public Use Microdata Series (IPUMS). IPUMS used a data warehousing approach, which extracts, transforms, and loads data from heterogeneous sources into a unique view schema so data from different sources become compatible. By making thousands of population databases interoperable, IPUMS demonstrated the feasibility of large-scale data integration. The data warehouse approach offers a tightly coupled architecture because the data are already physically reconciled in a single queryable repository, so it usually takes little time to resolve queries. The data warehouse approach is less feasible for data sets that are frequently updated, requiring the extract, transform, load (ETL) process to be continuously re-executed for synchronization. Difficulties also arise in constructing data warehouses when one has only a query interface to summary data sources and no access to the full data. This problem frequently emerges when integrating several commercial query services like travel or classified advertisement web applications. A trend began in 2009 favoring the loose coupling of data and providing a unified query-interface to access real time data over a mediated schema (see Figure 2), which allows information to be retrieved directly from original databases. This is consistent with the SOA approach popular in that era. This approach relies on mappings between the mediated schema and the schema of original sources, and translating a query into decomposed queries to match the schema of the original databases. Such mappings can be specified in two ways: as a mapping from entities in the mediated schema to entities in the original sources (the "Global-as-View" (GAV) approach), or as a mapping from entities in the original sources to the mediated schema (the "Local-as-View" (LAV) approach). The latter approach requires more sophisticated inferences to resolve a query on the mediated schema, but makes it easier to add new data sources to a (stable) mediated schema. As of 2010, some of the work in data integration research concerns the semantic integration problem. This problem addresses not the structuring of the architecture of the integration, but how to resolve semantic conflicts between heterogeneous data sources. For example, if two companies merge their databases, certain concepts and definitions in their respective schemas like "earnings" inevitably have different meanings. In one database it may mean profits in dollars (a floating-point number), while in the other it might represent the number of sales (an integer). A common strategy for the resolution of such problems involves the use of ontologies which explicitly define schema terms and thus help to resolve semantic conflicts. This approach represents ontology-based data integration. On the other hand, the problem of combining research results from different bioinformatics repositories requires bench-marking of the similarities, computed from different data sources, on a single criterion such as positive predictive value. This enables the data sources to be directly comparable and can be integrated even when the natures of experiments are distinct. As of 2011, it was determined that current data modeling methods were imparting data isolation into every data architecture in the form of islands of disparate data and information silos. This data isolation is an unintended artifact of the data modeling methodology that results in the development of disparate data models. Disparate data models, when instantiated as databases, form disparate databases. Enhanced data model methodologies have been developed to eliminate the data isolation artifact and to promote the development of integrated data models. One enhanced data modeling method recasts data models by augmenting them with structural metadata in the form of standardized data entities. As a result of recasting multiple data models, the set of recast data models will now share one or more commonality relationships that relate the structural metadata now common to these data models. Commonality relationships are a peer-to-peer type of entity relationships that relate the standardized data entities of multiple data models. Multiple data models that contain the same standard data entity may participate in the same commonality relationship. When integrated data models are instantiated as databases and are properly populated from a common set of master data, then these databases are integrated. Since 2011, data hub approaches have been of greater interest than fully structured (typically relational) Enterprise Data Warehouses. Since 2013, data lake approaches have risen to the level of Data Hubs. (See all three search terms popularity on Google Trends.) These approaches combine unstructured or varied data into one location, but do not necessarily require an (often complex) master relational schema to structure and define all data in the Hub. In recent times, as the number of applications being used have increased many fold and application to application integration have become critical and this has given rise to [Unified APIs] that help application developers integrate their apps with other apps and more recently with [MCP - Model Context Protocol] taking it a step further for AI Agents. Data integration plays a big role in business regarding data collection used for studying the market. Converting the raw data retrieved from consumers into coherent data is something businesses try to do when considering what steps they should take next. Organizations are more frequently using data mining for collecting information and patterns from their databases, and this process helps them develop new business strategies to increase business performance and perform economic analyses more efficiently. Compiling the large amount of data they collect to be stored in their system is a form of data integration adapted for Business intelligence to improve their chances of success. == Example == Consider a web application where a user can query a variety of information about cities (such as crime statistics, weather, hotels, demographics, etc.). Traditionally, the information must be stored in a single database with a single schema. But any single enterprise would find information of this breadth somewhat difficult and expensive to collect. Even if the resources exist to gather the data, it would likely duplicate data in existing crime databases, weather websites, and census data. A data-integration solution may address this problem by considering these external resources as materialized views over a virtual mediated schema, resulting in "virtual data integration". This means application-developers construct a virtual schema—the mediated schema—to best model the kinds of answers their users want. Next, they design "wrappers" or adapters for each data source, such as the crime database and weather website. These adapters simply transform the local query results (those returned by the respective websites or databases) into an easily processed form for the data integration solution (see figure 2). When an application-user queries the mediated schema, the data-integration solution transforms this query into appropriate queries over the respective data sources. Finally, the virtual database combines the results of these queries into the answer to the user's query. This solution offers the convenience of adding new sources by simply constructing an adapter or an application software blade for them. It contrasts with ETL systems or with a si
ELMo
ELMo (embeddings from language model) is a word embedding method for representing a sequence of words as a corresponding sequence of vectors. It was created by researchers at the Allen Institute for Artificial Intelligence, and University of Washington and first released in February 2018. It is a bidirectional LSTM which takes character-level as inputs and produces word-level embeddings, trained on a corpus of about 30 million sentences and 1 billion words. The architecture of ELMo accomplishes a contextual understanding of tokens. Deep contextualized word representation is useful for many natural language processing tasks, such as coreference resolution and polysemy resolution. ELMo was historically important as a pioneer of self-supervised generative pretraining followed by fine-tuning, where a large model is trained to reproduce a large corpus, then the large model is augmented with additional task-specific weights and fine-tuned on supervised task data. It was an instrumental step in the evolution towards transformer-based language modelling. == Architecture == ELMo is a multilayered bidirectional LSTM on top of a token embedding layer. The output of all LSTMs concatenated together consists of the token embedding. The input text sequence is first mapped by an embedding layer into a sequence of vectors. Then two parts are run in parallel over it. The forward part is a 2-layered LSTM with 4096 units and 512 dimension projections, and a residual connection from the first to second layer. The backward part has the same architecture, but processes the sequence back-to-front. The outputs from all 5 components (embedding layer, two forward LSTM layers, and two backward LSTM layers) are concatenated and multiplied by a linear matrix ("projection matrix") to produce a 512-dimensional representation per input token. ELMo was pretrained on a text corpus of 1 billion words. The forward part is trained by repeatedly predicting the next token, and the backward part is trained by repeatedly predicting the previous token. After the ELMo model is pretrained, its parameters are frozen, except for the projection matrix, which can be fine-tuned to minimize loss on specific language tasks. This is an early example of the pretraining-fine-tune paradigm. The original paper demonstrated this by improving state of the art on six benchmark NLP tasks. === Contextual word representation === The architecture of ELMo accomplishes a contextual understanding of tokens. For example, the first forward LSTM of ELMo would process each input token in the context of all previous tokens, and the first backward LSTM would process each token in the context of all subsequent tokens. The second forward LSTM would then incorporate those to further contextualize each token. Deep contextualized word representation is useful for many natural language processing tasks, such as coreference resolution and polysemy resolution. For example, consider the sentenceShe went to the bank to withdraw money.In order to represent the token "bank", the model must resolve its polysemy in context. The first forward LSTM would process "bank" in the context of "She went to the", which would allow it to represent the word to be a location that the subject is going towards. The first backward LSTM would process "bank" in the context of "to withdraw money", which would allow it to disambiguate the word as referring to a financial institution. The second forward LSTM can then process "bank" using the representation vector provided by the first backward LSTM, thus allowing it to represent it to be a financial institution that the subject is going towards. == Historical context == ELMo is one link in a historical evolution of language modelling. Consider a simple problem of document classification, where we want to assign a label (e.g., "spam", "not spam", "politics", "sports") to a given piece of text. The simplest approach is the "bag of words" approach, where each word in the document is treated independently, and its frequency is used as a feature for classification. This was computationally cheap but ignored the order of words and their context within the sentence. GloVe and Word2Vec built upon this by learning fixed vector representations (embeddings) for words based on their co-occurrence patterns in large text corpora. Like BERT (but unlike "bag of words" such as Word2Vec and GloVe), ELMo word embeddings are context-sensitive, producing different representations for words that share the same spelling. It was trained on a corpus of about 30 million sentences and 1 billion words. Previously, bidirectional LSTM was used for contextualized word representation. ELMo applied the idea to a large scale, achieving state of the art performance. After the 2017 publication of Transformer architecture, the architecture of ELMo was changed from a multilayered bidirectional LSTM to a Transformer encoder, giving rise to BERT. BERT has a similar pretrain-fine-tune workflow, but uses a Transformer with implications for more parallelizable training.
Block swap algorithms
In computer algorithms, block swap algorithms swap two regions of elements of an array. It is simple to swap two non-overlapping regions of an array of equal size. However, it is not as simple to swap two contiguous regions of an array of unequal sizes (algorithms that perform such swapping are called rotation algorithms). A few well-known algorithms can accomplish this: Bentley's juggling (also known as the dolphin algorithm), Gries-Mills rotation, triple reversal algorithm, conjoined triple reversal algorithm (also known as the trinity rotation) and Successive rotation. == Triple reversal algorithm == The triple reversal algorithm is the simplest to explain, using rotations. A rotation is an in-place reversal of array elements. This method swaps two elements of an array from outside in within a range. The rotation works for an even or odd number of array elements. The reversal algorithm uses three in-place rotations to accomplish an in-place block swap: Rotate region A Rotate region B Rotate region AB Where A and B are adjacent regions of an array that together form the region AB. Gries-Mills and reversal algorithms perform better than Bentley's juggling, because of their cache-friendly memory access pattern behavior. The triple reversal algorithm parallelizes well, because rotations can be split into sub-regions, which can be rotated independently of others.
Operational data store
An operational data store (ODS) is used for operational reporting and as a source of data for the enterprise data warehouse (EDW). It is a complementary element to an EDW in a decision support environment, and is used for operational reporting, controls, and decision making, as opposed to the EDW, which is used for tactical and strategic decision support. An ODS is a database designed to integrate data from multiple sources for additional operations on the data, for reporting, controls and operational decision support. Unlike a production master data store, the data is not passed back to operational systems. It may be passed for further operations and to the data warehouse for reporting. An ODS should not be confused with an enterprise data hub (EDH). An operational data store will take transactional data from one or more production systems and loosely integrate it, in some respects it is still subject oriented, integrated and time variant, but without the volatility constraints. This integration is mainly achieved through the use of EDW structures and content. An ODS is not an intrinsic part of an EDH solution, although an EDH may be used to subsume some of the processing performed by an ODS and the EDW. An EDH is a broker of data. An ODS is certainly not. Because the data originates from multiple sources, the integration often involves cleaning, resolving redundancy and checking against business rules for integrity. An ODS is usually designed to contain low-level or atomic (indivisible) data (such as transactions and prices) with limited history that is captured "real time" or "near real time" as opposed to the much greater volumes of data stored in the data warehouse generally on a less-frequent basis. == General use == The general purpose of an ODS is to integrate data from disparate source systems in a single structure, using data integration technologies like data virtualization, data federation, or extract, transform, and load (ETL). This will allow operational access to the data for operational reporting, master data or reference data management. An ODS is not a replacement or substitute for a data warehouse or for a data hub but in turn could become a source.
Data janitor
A data janitor is a person who works to take big data and condense it into useful amounts of information. Also known as a "data wrangler", a data janitor sifts through data for companies in the information technology industry. A multitude of start-ups rely on large amounts of data, so a data janitor works to help these businesses with this basic, but difficult process of interpreting data. While it is a commonly held belief that data janitor work is fully automated, many data scientists are employed primarily as data janitors. The information technology industry has been increasingly turning towards new sources of data gathered on consumers, so data janitors have become more commonplace in recent years.
Web Intents
Web Intents was an experimental framework for web-based inter-application communication and service discovery. Web Intents consists of a discovery mechanism and a very light-weight RPC system between web applications, modelled after the Intents system in Android. In the context of the framework an Intent equals an action to be performed by a provider. Web Intents allow two web applications to communicate with each other, without either of them having to actually know what the other one is. == Support == === Client === Google Chrome versions 18 to 23 natively supported Web Intents. This support was disabled in version 24, citing the existence of a "number of areas for development in both the API and specific user experience in Chrome". There is a JavaScript shim with support for IE 8, IE 9, Opera, Safari, Firefox 3+ and Chrome 3+. === Server === There are some Web Intents proxy pages that make available some real services that don't yet support intents. AddThis supports Web Intents by their sharing tools regardless of browser support. == History == Paul Kinlan of Google announced the Web Intents project in December 2010. He soon released a prototype API to GitHub. In August 2011 Google announced that Chrome would support Web Intents. Google and Mozilla have started co-operating to unify Web Intents and Mozilla's Web Activities (which tries to solve the same problem) into one proposal. In November 2012, Greg Billock of Google announced that experimental support of Web Intents had been removed from Chrome.
Brian Deer Classification System
The Brian Deer Classification System (BDC) is a library classification system used to organize materials in libraries with specialized Indigenous collections. The system was created in the mid-1970s by Canadian librarian A. Brian Deer, a Kahnawake Mohawk. It has been adapted for use in a British Columbia version, and also by a small number of First Nations libraries in Canada. == History and usage == Deer designed his classification system while working in the library of the National Indian Brotherhood (now the Assembly of First Nations) from 1974 to 1976. Instead of using a standard library classification scheme, such as that of the Library of Congress, he created a new system to organize the library's historic indigenous research materials and papers. He later worked at the library of the Union of British Columbia Indian Chiefs, where he developed a system for its holdings. He returned to Kahnawake, working at its Cultural Centre at Kahnawake and the Kahnawake Branch branch of the Mohawk Nation Office. His system was flexible, and he created new forms for their collections. The new systems Deer created were designed specifically for the materials in each collection according to the concerns of local Indigenous people at the time (for example, categories included land claims, treaty rights, resource management, and Elders' stories). Between 1978 and 1980, the system was adapted for use in British Columbia by Gene Joseph and Keltie McCall while they were working at the Union of British Columbia Indian Chiefs, becoming known as BDC-BC. Joseph later adapted it further for use in the Xwi7xwa Library at University of British Columbia, Vancouver. Though the Brian Deer Classification was not created as a universal classification solution for Indigenous resources, the system has provided a foundation for specialized libraries to create their own localized classification schemes. Variations of the Brian Deer Classification System are used in a small number of Canadian libraries. One prominent library using BDC is the X̱wi7x̱wa Library at the University of British Columbia, which uses a British Columbia-focused version of BDC along with First Nations House of Learning subject headings. The Union of British Columbia Indian Chiefs Resource Centre issued a revised BDC-BC in 2014, with the goal of providing users with a more flexible and culturally appropriate approach to organizing their resources. The Aanischaaukamikw Cree Cultural Institute in Oujé-Bougoumou, Quebec, implemented a local adaptation of BDC when they opened in 2012. In 2020 the Carrier Sekani Tribal Council in Prince George, British Columbia, shifted from organizing its library with the Dewey Decimal Classification to using a version of the BDC. They added new subject heading categories for topics of local interest such as the crisis of Missing and murdered Indigenous women. Simon Fraser University Library began developing the Indigenous Curriculum Resource Centre (ICRC) in 2020, with the physical space opening in 2023. The ICRC is Call to Action 21 of SFU's Aboriginal Reconciliation Council's final report, Walk This Path With Us. Through its collection, the ICRC supports those interested in learning about how and why decolonizing pedagogy and teaching practices are important. The physical items in the collection are catalogued using a modified Brian Deer Classification system. In 2022 Kwantlen Polytechnic University’s χʷəχʷéy̓əm Indigenous Collection released a revised BDC-BC System. This BDC contains works exclusively with Indigenous authored materials and expands the cuttering systems of previous BDC, with the result that much of the collection reflects a spatial relationality. The implementation of this BDC was possible due to the tireless work at Xwi7xwa Library, Union of British Columbia Indian Chiefs Resource Centre, and Simon Fraser University Library's Indigenous Curriculum Resource Centre. == Structure == The high-level organizational structure of BDC reflects a First Nations worldview, with an emphasis on relationships between and among people, animals, and the land. Subcategories demonstrate the relationships among First Nations by grouping them geographically as opposed to alphabetically; the latter is a practice frequently used for specific topics in the Library of Congress Classification. The top-level hierarchy of the X̱wi7x̱wa Library adaptation of BDC-BC demonstrates the emphasis on access to subjects prioritized by a First Nation collection: Reference Materials Local History History International Education Economic Development Housing and Community Development Criminal Justice System Constitution (Canada) and First Nations Self Government Rights and Title Natural Resources Community Resources Health World View Fine Arts Languages Literature The system is not designed to provide a comprehensive description of all topics of interest to North American Indigenous peoples; in addition, its use is limited in scope, being intended for small and specialized libraries. While English is used in the classification scheme as a common language among First Nations peoples and non-Indigenous library users, Indigenous spellings and terminology that local library users would expect to find are used to provide access. Short and easily remembered call numbers are used to facilitate use by both library workers and patrons, with the recognition that Indigenous libraries often have a small staff and limited resources to devote to cataloging. Beyond its simplicity, one potential drawback of the system is its shortage of clear guidelines for application, which provides flexibility but can also result in inconsistencies within and between library catalogs. Because few libraries use the BDC and there are limited examples for use as case studies, implementing the system and keeping it up-to-date can prove a challenge for libraries with limited resources. However, X̱wi7x̱wa Library head librarian Ann Doyle describes the system as "an important part of the body of Indigenous scholarship" that should be retained as a reflection of Indigenous worldviews, as well as for ease of access for Indigenous library users.