Computational Intelligence Journal is a peer-reviewed scientific journal covering research on artificial intelligence and computer science. The journal published novel research as well as innovative applications in a broad range of AI, covering Computational Intelligence is an artificial intelligence journal publishing novel research on a broad range of experimental and theoretical topics in AI and computer science. With a broad scope, the journal covers machine learning, knowledge mining, web intelligence, AI language, and philosophical implications. The journal was established in 1985 and is published by Wiley-Blackwell. Currently, the editors-in-chief is Diane Inkpen. The quality of the journal as an academic publishing venue is evaluated according to public citation impact metrics. in 2022, the Computational Intelligence Journal CiteScore of Scopus was 5.3, while Clarivate's Web of Science gives it 0.39 in the Journal Citation Indicator and 2,8 in the Journal Impact Factor.
Document mosaicing
Document mosaicing is a process that stitches multiple, overlapping snapshot images of a document together to produce one large, high resolution composite. The document is slid under a stationary, over-the-desk camera by hand until all parts of the document are snapshotted by the camera's field of view. As the document slid under the camera, all motion of the document is coarsely tracked by the vision system. The document is periodically snapshotted such that the successive snapshots are overlap by about 50%. The system then finds the overlapped pairs and stitches them together repeatedly until all pairs are stitched together as one piece of document. The document mosaicing can be divided into four main processes. Tracking Feature detecting Correspondences establishing Images mosaicing. == Tracking (simple correlation process) == In this process, the motion of the document slid under the camera is coarsely tracked by the system. Tracking is performed by a process called simple correlation process. In the first frame of snapshots, a small patch is extracted from the center of the image as a correlation template. The correlation process is performed in the four times size of the patch area of the next frame. The motion of the paper is indicated by the peak in the correlation function. The peak in the correlation function indicates the motion of the paper. The template is resampled from this frame and the tracking continues until the template reaches the edge of the document. After the template reaches the edge of the document, another snapshot is taken and the tracking process performs repeatedly until the whole document is imaged. The snapshots are stored in an ordered list to facilitate pairing the overlapped images in later processes. == Feature detecting for efficient matching == Feature detection is the process of finding the transformation that aligns one image with another. There are two main approaches for feature detection. Feature-based approach : Motion parameters are estimated from point correspondences. This approach is suitable for the case that there is plenty supply of stable and detectable features. Featureless approach : When the motion between the two images is small, the motion parameters are estimated using optical flow. On the other hand, when the motion between the two images is large, the motion parameters are estimated using generalised cross-correlation. However, this approach requires a computationally expensive resources. Each image is segmented into a hierarchy of columns, lines, and words to match the organised sets of features across images. Skew angle estimation and columns, lines and words finding are the examples of feature detection operations. === Skew angle estimation === Firstly, the angle that the rows of text make with the image raster lines (skew angle) is estimated. It is assumed to lie in the range of ±20°. A small patch of text in the image is selected randomly and then rotated in the range of ±20° until the variance of the pixel intensities of the patch summed along the raster lines is maximised. To ensure that the found skew angle is accurate, the document mosaic system performs calculation at many image patches and derive the final estimation by finding the average of the individual angles weighted by the variance of the pixel intensities of each patch. === Columns, lines and words finding === In this operation, the de-skewed document is intuitively segmented into a hierarchy of columns, lines and words. The sensitivity to illumination and page coloration of the de-skewed document can be removed by applying a Sobel operator to the de-skewed image and thresholding the output to obtain the binary gradient, de-skewed image. The operation can be roughly separated into 3 steps: column segmentation, line segmentation and word segmentation. Columns are easily segmented from the binary gradient, de-skewed images by summing pixels vertically. Baselines of each row are segmented in the same way as the column segmentation process but horizontally. Finally, individual words are segmented by applying the vertical process at each segmented row. These segmentations are important because the document mosaic is created by matching the lower right corners of words in overlapping images pair. Moreover, the segmentation operation can organize the list of images in the context of a hierarchy of rows and column reliably. The segmentation operation involves a considerable amount of summing in the binary gradient, de-skewed images, which done by construct a matrix of partial sums whose elements are given by p i y = ∑ u = 1 i ∑ v = 1 j b u v {\displaystyle p_{iy}=\sum _{u=1}^{i}\sum _{v=1}^{j}b_{uv}} The matrix of partial sums is calculated in one pass through the binary gradient, de-skewed image. ∑ u = u 1 u 2 ∑ v = v 1 v 2 b u v = p u 2 v 2 + p u 1 v 1 − p u 1 v 2 − p u 2 v 1 {\displaystyle \sum _{u=u_{1}}^{u_{2}}\sum _{v=v_{1}}^{v_{2}}b_{uv}=p_{u_{2}v_{2}}+p_{u_{1}v_{1}}-p_{u_{1}v_{2}}-p_{u_{2}v_{1}}} == Correspondences establishing == The two images are now organized in hierarchy of linked lists in following structure : image=list of columns row=list of words column=list of row word=length (in pixels) At the bottom of the structure, the length of each word is recorded for establishing correspondence between two images to reduce to search only the corresponding structures for the groups of words with the matching lengths. === Seed match finding === A seed match finding is done by comparing each row in image1 with each row in image2. The two rows are then compared to each other by every word. If the length (in pixel) of the two words (one from image1 and one from image2) and their immediate neighbours agree with each other within a predefined tolerance threshold (5 pixels, for example), then they are assumed to match. The row of each image is assumed a match if there are three or more word matches between the two rows. The seed match finding operation is terminated when two pairs of consecutive row match are found. === Match list building === After finishing a seed match finding operation, the next process is to build the match list to generate the correspondences points of the two images. The process is done by searching the matching pairs of rows away from the seed row. == Images mosaicing == Given the list of corresponding points of the two images, finding the transformation of the overlapping portion of the images is the next process. Assuming a pinhole camera model, the transformation between pixels (u,v) of image 1 and pixels (u0, v0) of image 2 is demonstrated by a plane-to-plane projectivity. [ s u ′ s v ′ s ] = [ p 11 p 12 p 13 p 21 p 22 p 23 p 31 p 32 1 ] [ u v 1 ] E q .1 {\displaystyle \left[{\begin{array}{c}su'\\sv'\\s\end{array}}\right]=\left[{\begin{array}{ccc}p_{11}&p_{12}&p_{13}\\p_{21}&p_{22}&p_{23}\\p_{31}&p_{32}&1\end{array}}\right]\left[{\begin{array}{c}u\\v\\1\end{array}}\right]\qquad Eq.1} The parameters of the projectivity is found from four pairs of matching points. RANSAC regression technique is used to reject outlying matches and estimate the projectivity from the remaining good matches. The projectivity is fine-tuned using correlation at the corners of the overlapping portion to obtain four correspondences to sub-pixel accuracy. Therefore, image1 is then transformed into image2's coordinate system using Eq.1. The typical result of the process is shown in Figure 5. === Many images coping === Finally, the whole page composition is built up by mapping all the images into the coordinate system of an "anchor" image, which is normally the one nearest the page center. The transformations to the anchor frame are calculated by concatenating the pair-wise transformations found earlier. The raw document mosaic is shown in Figure 6. However, there might be a problem of non-consecutive images that are overlap. This problem can be solved by performing Hierarchical sub-mosaics. As shown in Figure 7, image1 and image2 are registered, as are image3 and image4, creating two sub-mosaics. These two sub-mosaics are later stitched together in another mosaicing process. == Applied areas == There are various areas that the technique of document mosaicing can be applied to such as : Text segmentation of images of documents Document Recognition Interaction with paper on the digital desk Video mosaics for virtual environments Image registration techniques == Relevant research papers == Huang, T.S.; Netravali, A.N. (1994). "Motion and structure from feature correspondences: A review". Proceedings of the IEEE. 82 (2): 252–268. doi:10.1109/5.265351. D.G. Lowe. [1] Perceptual Organization and Visual Recognition. Kluwer Academic Publishers, Boston, 1985. Irani, M.; Peleg, S. (1991). "Improving resolution by image registration". CVGIP: Graphical Models and Image Processing. 53 (3): 231–239. doi:10.1016/1049-9652(91)90045-L. S2CID 4834546. Shivakumara, P.; Kumar, G. Hemantha; Guru, D. S.; Nagabhushan, P. (2006). "
XRX (web application architecture)
In software development XRX is a web application architecture based on XForms, REST and XQuery. XRX applications store data on both the web client and on the web server in XML format and do not require a translation between data formats. XRX is considered a simple and elegant application architecture due to the minimal number of translations needed to transport data between client and server systems. The XRX architecture is also tightly coupled to W3C standards (CSS, XHTML 2.0, XPath, XML Schema) to ensure XRX applications will be robust in the future. Because XRX applications leverage modern declarative languages on the client and functional languages on the server they are designed to empower non-developers who are not familiar with traditional imperative languages such as JavaScript, Java or .Net. == Overview of XRX == XRX is a zero translation application architecture that uses XML to store data in the client web browser, on the application server and in the database server. It is because each of these layers uses XML as the same structural data model that XRX applications do not have to translate data structures to and from both object and relational data structures. Because of the lack of need for translation, XRX is considered to have a clean and elegant design. The XRX web application architecture allows developers to focus on the business problem and not the translation problem. XRX benefits from several advances in software technology: === Client Architectural Features === A model–view–controller (MVC) architecture that separates the data from its presentation and business logic. A single element (xf:submission) for all server submissions. This replaces much of the JavaScript code required in most AJAX applications. An advanced event model (XML Events) consistent with W3C standards that frees applications from having to deal with vendor-specific and browser-specific event handling. A Dependency graph that is used to store the dependency structure of the client controllers. This frees the developer from having to manually update either the model or the views when data changes in an application. This allows spreadsheet-like applications to be created on the client with very little effort. A declarative programming style that allows most client XForms applications to be created using a small set of approximately 20 elements. This allows rich client applications to be created without knowledge of JavaScript or other procedural scripting languages. An easy-to-extend system for creating new user interface controls using the EXtensible Bindings Language. This allows developers to add new controls at any time without fear of incompatibilities with W3C standards. === Server Architecture Features === Many native XML databases have built-in REST interfaces making each XQuery inherently a RESTful web service. A functional programming model that promotes side-effect free systems that are easier to debug and easier to run on multiple processors. An easy-to-extend system using XQuery function and modules. === Both Client and Server === Both XRX client and server components support a wide range of XML related standards such as XPath, XML Schema and XML Namespaces. Consistent use of REST interfaces to exchange data between the client and server for all transfers of data including as-you-type data checking and suggest functions. Consistent integration of W3C standards including use of XPath and XML Schema data types. A large library of standard of functions used on both the client and server. == Overall Benefits of XRX == One of the principal benefits of the XRX architecture is that it avoids the requirement to "shred" complex data structures into relational structures and then reconstitute the data back into structures when a record is edited on the client. Another benefits of the XRX Web application architecture is that it avoids most of the problems around the object-relational impedance mismatch. Another advantage is that the client developer does not have to learn JavaScript on the client. == Comparison with Traditional Object/Relational Web Application Architectures == Many traditional web application architectures created in the late 1990 were based on middle object tiers and persistence layers that used tabular data streams and relational database systems. Because each of these layers used different structures to store the models the systems required much additional complexity to translate between layers. == History of XRX == Early examples of using a zero-translation architecture in multi-tier systems can be traced back to the rise of object-oriented databases in the 1990s. See OODBMS History Mark Birbeck suggested that the combination of XForms, XQuery with REST interfaces between the two had many advantages in a meeting to the UK XML User Group in September 2006 . His presentation was one of the first to specifically suggest that the combination of three technologies: XForms and XQuery with REST interfaces would have surprisingly beneficial effects. Mark termed this process "Skimming" but that term did not seem to be contagious. Erik Bruchez of Orbeon spoke at the XML 2007 conference on Boston in December 2007. In his presentation "XForms and the eXist XML database: a perfect couple", Bruchez showed that many people were discovering synergistic benefits of XForms on the client and XQuery on the server. The label for XRX was suggested by a blog posting by Dan McCreary on December 14, 2007. It was in this article that Dan suggested the need for a contagious meme for the ideas behind the XRX architecture. == Generalizations of XRX == Although XRX was originally intended to connote the use of XForms on the client, REST as an interface and XQuery on the server, other proponents of the symmetrical use of XML on the client and server have generalized the term to encompass any XML-centric web client and any server that can store and query XML documents. This use of XRX is generally referred to as "shallow XRX". These generalizations do benefit from a simplified zero-translation architecture but many do not benefit from REST interfaces, XPath for consistent data selection, declarative systems in the client, and functional languages on the server (one of the key aspects of XRX). Use of all three technologies (XForms, REST and XQuery) is referred to as "deep XRX". Although XRX architecture is centred on XForms and XQuery, it does not preclude the use of other technologies that manipulate XML natively, such as XSLT, XProc, and XSL-FO.
Community cloud
A community cloud in computing is a collaborative effort in which infrastructure is shared between several organizations from a specific community with common concerns (security, compliance, jurisdiction, etc.), whether managed internally or by a third party and hosted internally or externally. This is controlled and used by a group of organizations that have shared interests. The costs are spread over fewer users than a public cloud (but more than a private cloud), so only some of the cost savings potential of cloud computing are realized. The community cloud is provisioned for use by a group of consumers from different organizations who share the same concerns (e.g., application, security, policy, and efficiency demands).
WikiTok
WikiTok is a web application that shows random Wikipedia articles in an infinite scrolling format similar to TikTok. Created by New York-based civil and software engineer Isaac Gemal in February 2025, the application aims to provide an "anti-algorithmic" alternative to traditional social media platforms while combating doomscrolling. == Development == WikiTok was developed on February 3, 2025, after Gemal saw a viral tweet from developer Tyler Angert proposing "all of wikipedia on a single, scrollable page". Gemal created the initial prototype in approximately two hours, using the Claude LLM and Cursor coding editor, completing it by 2 a.m. that same night. The application was built with React 18, TypeScript, Tailwind CSS, and Vite, consisting of only a few hundred lines of code with no backend infrastructure. Gemal has made the project open-source, with the code publicly available on GitHub. == Functionality == WikiTok serves users completely random Wikipedia article snippets from Wikipedia's nearly 9.5 million entries. Each article preview includes a full-screen image from Wikipedia and a short text excerpt. Users can click "Read More" to access the full Wikipedia article, or continue scrolling to see the next random entry. The application functions as a progressive web app that can be downloaded as a hybrid between an app and a website. It works on both mobile and desktop browsers, and is designed to be responsive whether users scroll with their thumb on mobile devices or use a cursor on desktop computers. As of 2025, WikiTok supports 14 different languages for article translation. == Philosophy == Gemal has explicitly positioned WikiTok as "anti-algorithmic," resisting numerous requests to implement personalized content algorithms. In an interview with Business Insider, Gemal stated: "I have had plenty of people message me and even make issues on my GitHub asking for some insane crazy WikiTok algorithm... we're already ruled by ruthless, opaque algorithms in our everyday life; why can't we just have one little corner in the world without them?" The application aims to combat "doomscrolling" – the practice of mindlessly consuming negative news online that can cause anxiety, helplessness, and anger. Unlike traditional social media platforms, WikiTok deliberately excludes algorithms, advertisements, and user tracking.
Kinematic chain
In mechanical engineering, a kinematic chain is an assembly of rigid bodies connected by joints to provide constrained motion that is the mathematical model for a mechanical system. As the word chain suggests, the rigid bodies, or links, are constrained by their connections to other links. An example is the simple open chain formed by links connected in series, like the usual chain, which is the kinematic model for a typical robot manipulator. Mathematical models of the connections, or joints, between two links are termed kinematic pairs. Kinematic pairs model the hinged and sliding joints fundamental to robotics, often called lower pairs and the surface contact joints critical to cams and gearing, called higher pairs. These joints are generally modeled as holonomic constraints. A kinematic diagram is a schematic of the mechanical system that shows the kinematic chain. The modern use of kinematic chains includes analysis of Linkages (mechanical), compliance that arises from flexure joints in precision mechanisms, link compliance in compliant mechanisms and micro-electro-mechanical systems, and cable compliance in cable robotic and tensegrity systems. == Mobility formula == The degrees of freedom, or mobility, of a kinematic chain is the number of parameters that define the configuration of the chain. A system of n rigid bodies moving in space has 6n degrees of freedom measured relative to a fixed frame. This frame is included in the count of bodies, so that mobility does not depend on link that forms the fixed frame. This means the degree-of-freedom of this system is M = 6(N − 1), where N = n + 1 is the number of moving bodies plus the fixed body. Joints that connect bodies impose constraints. Specifically, hinges and sliders each impose five constraints and therefore remove five degrees of freedom. It is convenient to define the number of constraints c that a joint imposes in terms of the joint's freedom f, where c = 6 − f. In the case of a hinge or slider, which are one-degree-of-freedom joints, have f = 1 and therefore c = 6 − 1 = 5. The result in general where d {\displaystyle d} is the degrees of freedom for the mobility of a kinematic chain formed from n moving links and j joints each with freedom fi, i = 1, 2, …, j, is given by M = d n − ∑ i = 1 j ( d − f i ) = d ( N − 1 − j ) + ∑ i = 1 j f i {\displaystyle M=dn-\sum _{i=1}^{j}(d-f_{i})=d(N-1-j)+\sum _{i=1}^{j}f_{i}} Where N is the total number of links and includes the fixed link. Spacial linkages used d = 6 {\displaystyle d=6} and planar linkages use d = 3 {\displaystyle d=3} . This result is known as the Chebychev–Grübler–Kutzbach criterion. == Analysis of kinematic chains == The constraint equations of a kinematic chain couple the range of movement allowed at each joint to the dimensions of the links in the chain, and form algebraic equations that are solved to determine the configuration of the chain associated with specific values of input parameters, called degrees of freedom. The constraint equations for a kinematic chain are obtained using rigid transformations [Z] to characterize the relative movement allowed at each joint and separate rigid transformations [X] to define the dimensions of each link. In the case of a serial open chain, the result is a sequence of rigid transformations alternating joint and link transformations from the base of the chain to its end link, which is equated to the specified position for the end link. A chain of n links connected in series has the kinematic equations, [ T ] = [ Z 1 ] [ X 1 ] [ Z 2 ] [ X 2 ] ⋯ [ X n − 1 ] [ Z n ] , {\displaystyle [T]=[Z_{1}][X_{1}][Z_{2}][X_{2}]\cdots [X_{n-1}][Z_{n}],\!} where [T] is the transformation locating the end-link—notice that the chain includes a "zeroth" link consisting of the ground frame to which it is attached. These equations are called the forward kinematics equations of the serial chain. Kinematic chains of a wide range of complexity are analyzed by equating the kinematics equations of serial chains that form loops within the kinematic chain. These equations are often called loop equations. The complexity (in terms of calculating the forward and inverse kinematics) of the chain is determined by the following factors: Its topology: a serial chain, a parallel manipulator, a tree structure, or a graph. Its geometrical form: how are neighbouring joints spatially connected to each other? Explanation Two or more rigid bodies in space are collectively called a rigid body system. We can hinder the motion of these independent rigid bodies with kinematic constraints. Kinematic constraints are constraints between rigid bodies that result in the decrease of the degrees of freedom of rigid body system. == Synthesis of kinematic chains == The constraint equations of a kinematic chain can be used in reverse to determine the dimensions of the links from a specification of the desired movement of the system. This is termed kinematic synthesis. Perhaps the most developed formulation of kinematic synthesis is for four-bar linkages, which is known as Burmester theory. Ferdinand Freudenstein is often called the father of modern kinematics for his contributions to the kinematic synthesis of linkages beginning in the 1950s. His use of the newly developed computer to solve Freudenstein's equation became the prototype of computer-aided design systems. This work has been generalized to the synthesis of spherical and spatial mechanisms.
Distributed Common Ground System
The Distributed Common Ground System (DCGS) is a system which produces military intelligence for multiple branches of the American military. == DCGS Programs == DCGS-N - DCGS for the United States Navy DCGS-A - DCGS for the United States Army AF DCGS - DCGS for the United States Air Force DCGS-MC - DCGS for the United States Marine Corps DCGS-SOF - DCGS for the United States Special Operations Forces IS&A Support Center - DCGS-A Help Desk for the United States Army - https://dcgsahelp.max.gov/ - Max.gov sunset 15 December 2023 == Description == While in U.S. Air Force use, the system produces intelligence collected by the U-2 Dragonlady, RQ-4 Global Hawk, MQ-9 Reaper and MQ-1 Predator. The previous system of similar use was the Deployable Ground Station (DGS), which was first deployed in July 1994. Subsequent version of DGS were developed from 1995 through 2009. Although officially designated a "weapons system", it consists of computer hardware and software connected together in a computer network, devoted to processing and dissemination of information such as images. The 480th Intelligence, Surveillance and Reconnaissance Wing of the Air Combat Command operates and maintains the USAF system. A plan envisioned in 1998 was to develop interoperable systems for the Army and Navy, in addition to the Air Force. By 2006, version 10.6 was deployed by the Air Force, and a version known as DCGS-A was developed for the Army. After a 2010 report by General Michael T. Flynn, the program was intended to use cloud computing and be as easy to use as an iPad, which soldiers over a few years were commonly using. By April 2011, project manager Colonel Charles Wells announced version 3 of the Army system (code named "Griffin") was being deployed in the US war in Afghanistan. In January 2012, the United States Army Communications-Electronics Research, Development and Engineering Center hosted a meeting based on the DCGS-A early experience. It brought together technology providers in the hope of developing more integrated systems using cloud computing with open architectures, compared to previously specialized custom-built systems. A major contractor was Lockheed Martin, with computers supplied by Silicon Graphics International out of its Chippewa Falls, Wisconsin office. Software known as the Analyst's Notebook, originally developed by i2 Limited, was included in DCGS-A. IBM acquired i2 in 2011. Some US Army personnel reported using a Palantir Technologies product to improve their ability to predict locations of improvised explosive devices. An April 2012 report recommending further study after initial success. Palantir software was rated easy to use, but did not have the flexibility and wide number of data sources of DCGS-A. In July 2012, Congressman Duncan D. Hunter (from California, the state where Palantir is based) complained of US DoD obstacles to its wider use. Although a limited test in August 2011 by the Test and Evaluation Command had recommended deployment, operation problems of DCGS-A included the baseline system was "not operationally effective" with reboots on average about every 8 hours. A set of improvements was identified in November 2012. The press reported some of the shortcomings uncovered by General Genaro Dellarocco in the tests. The ambitious goal of integrating 473 data sources for 75 million reports proved to be challenging, after spending an estimated $2.3 billion on the Army system alone. In May 2013 Politico reported that Palantir lobbyists and some anonymous returning veterans continued to advocate the use of its software, despite its interoperability limits. In particular, members of special forces and US Marines were not required to use the official Army system. Similar stories appeared in other publications, with Army representatives (such as Major General Mary A. Legere) citing the limitations of various systems. Congressman Hunter was a member of the House Armed Services Committee which required a review of the program, after two other members of congress sent an open letter to Secretary of Defense Leon Panetta. The Senate Defense Appropriations Subcommittee included testimony from Army Chief of Staff General Ray Odierno. The 130th Engineer Brigade (United States) has found the system to be "unstable, slow, not friendly and a major hindrance to operations". The equivalent system for the United States Navy was planned for initial deployment by 2015, and within a shipboard network called Consolidated Afloat Networks and Enterprise Services (CANES) by 2016. Some early testing was announced in 2009 aboard the aircraft carrier USS Harry Truman. A portion of the software, a distributed data framework for the DCGS integration backbone (DIB) version 4, was submitted to an open-source software repository of the Codice Foundation on GitHub. The framework was new for DIB version 4, replacing the legacy DIB portal with an Ozone Widget Framework interface. It was written in the Java programming language. == DCGS-A == Distributed Common Ground System-Army (DCGS-A) is the United States Army's primary system to post data, process information, and disseminate Intelligence, Surveillance and Reconnaissance (ISR) information about the threat, weather, and terrain to echelons. DCGS-A provides commanders the ability to task battle-space sensors and receive intelligence information from multiple sources. === Promotion === An August 17, 2011, UPI article quoted i2 Chief Executive Officer Robert Griffin who commented on DCGS-A's best-of-breed approach to development. The article detailed the Army contracting with i2 for Analyst's Notebook software. "With its open architecture, Analyst's Notebook supports the Army's strategy to employ and integrate best-of-breed solutions from across the industry to meet the dynamic needs users face in the field on a daily basis." A February 1, 2012, article in the Army web page quoted Mark Kitz, DCGS-A technical director. DCGS-A "uses the latest in cloud technology to rapidly gather, collaborate and share intelligence data from multiple sources to deliver a common operating picture. DCGS-A is able to rapidly adapt to changing operational environments by leveraging an iterative development model and open architecture allowing for collaboration with multiple government, industry and academic partners." A July 2012 article in SIGNAL Magazine, monthly publication of the Armed Forces Communications and Electronics Association, promoted DCGS-A as taking advantage of technological environments with which young soldiers are familiar. The article quoted the DCGS-A program manager, Col. Charles Wells on the systems benefits. The article also included Lockheed Martin's DCGS-A program manager. The Milwaukee Journal Sentinel published an article May 4, 2012, about Wisconsin-located companies helping DCGS-A with cloud computing technology. The article promoted the speed when cloud computing processes intelligence and cost savings by analyzing data in the field. === The U.S. Army's 2011 Posture Statement === The U.S. Army released its 2011 Army Posture Statement March 2. It included a statement on DCGS-A: “The Distributed Common Ground System-Army (DCGS-A) is the Army's premier intelligence, surveillance, and reconnaissance (ISR) enterprise for the tasking of sensors, analysis and processing of data, exploitation of data, and dissemination of intelligence (TPED) across all echelons. It is the Army component of the larger Defense Intelligence Information Enterprise (DI2E) and interoperable with other Service DCGS programs. Under the DI2E framework, USD (I) hopes to provide COCOM Joint Intelligence Operations Centers (JIOCs) capabilities interoperable with DCGS-A through a Cloud/widget approach. DCGS-A connects tactical, operational, and theater-level commanders to hundreds of intelligence and intelligence-related data sources at all classification levels and allows them to focus efforts of the entire ISR community on their information requirements. === Comparisons === Some Ground Commanders who describe DCGS-A as "unwieldy and unreliable, hard to learn and difficult to use," supporting alternative software from Palantir Technologies. Palantir software supports small unit situational awareness, but is not sufficiently funded to support the broader role that DCGS-A fulfills. == Operators == 480th Intelligence, Surveillance and Reconnaissance Wing 9th Intelligence Squadron 13th Intelligence Squadron 548th Intelligence, Surveillance and Reconnaissance Group 548 Operational Support Squadron 48th Intelligence Squadron 101st Intelligence Squadron 113th Air Support Operations Squadron 127th Command and Control Squadron 161st Intelligence Squadron