Semantic queries allow for queries and analytics of associative and contextual nature. Semantic queries enable the retrieval of both explicitly and implicitly derived information based on syntactic, semantic and structural information contained in data. They are designed to deliver precise results (possibly the distinctive selection of one single piece of information) or to answer more fuzzy and wide open questions through pattern matching and digital reasoning. Semantic queries work on named graphs, linked data or triples. This enables the query to process the actual relationships between information and infer the answers from the network of data. This is in contrast to semantic search, which uses semantics (meaning of language constructs) in unstructured text to produce a better search result. (See natural language processing.) From a technical point of view, semantic queries are precise relational-type operations much like a database query. They work on structured data and therefore have the possibility to utilize comprehensive features like operators (e.g. >, < and =), namespaces, pattern matching, subclassing, transitive relations, semantic rules and contextual full text search. The semantic web technology stack of the W3C is offering SPARQL to formulate semantic queries in a syntax similar to SQL. Semantic queries are used in triplestores, graph databases, semantic wikis, natural language and artificial intelligence systems. == Background == Relational databases represent all relationships between data in an implicit manner only. For example, the relationships between customers and products (stored in two content-tables and connected with an additional link-table) only come into existence in a query statement (SQL in the case of relational databases) written by a developer. Writing the query demands exact knowledge of the database schema. Linked-Data represent all relationships between data in an explicit manner. In the above example, no query code needs to be written. The correct product for each customer can be fetched automatically. Whereas this simple example is trivial, the real power of linked-data comes into play when a network of information is created (customers with their geo-spatial information like city, state and country; products with their categories within sub- and super-categories). Now the system can automatically answer more complex queries and analytics that look for the connection of a particular location with a product category. The development effort for this query is omitted. Executing a semantic query is conducted by walking the network of information and finding matches (also called Data Graph Traversal). Another important aspect of semantic queries is that the type of the relationship can be used to incorporate intelligence into the system. The relationship between a customer and a product has a fundamentally different nature than the relationship between a neighbourhood and its city. The latter enables the semantic query engine to infer that a customer living in Manhattan is also living in New York City whereas other relationships might have more complicated patterns and "contextual analytics". This process is called inference or reasoning and is the ability of the software to derive new information based on given facts. == Articles == Velez, Golda (2008). "Semantics Help Wall Street Cope With Data Overload". Wall Street & Technology. wallstreetandtech.com. Zhifeng, Xiao (2009). "Spatial information semantic query based on SPARQL". In Liu, Yaolin; Tang, Xinming (eds.). International Symposium on Spatial Analysis, Spatial-Temporal Data Modeling, and Data Mining. Vol. 7492. SPIE. pp. 74921P. Bibcode:2009SPIE.7492E..60X. doi:10.1117/12.838556. S2CID 62191842. Aquin, Mathieu (2010). "Watson, more than a Semantic Web search engine" (PDF). Semantic Web Journal. Dworetzky, Tom (2011). "How Siri Works: iPhone's 'Brain' Comes from Natural Language Processing". International Business Times. Horwitt, Elisabeth (2011). "The semantic Web gets down to business". computerworld.com. Rodriguez, Marko (2011). "Graph Pattern Matching with Gremlin". Marko A. Rodriguez. markorodriguez.com on Graph Computing. Sequeda, Juan (2011). "SPARQL Nuts & Bolts". Cambridge Semantics. Freitas, Andre (2012). "Querying Heterogeneous Datasets on the Linked Data Web" (PDF). IEEE Internet Computing. Kauppinen, Tomi (2012). "Using the SPARQL Package in R to handle Spatial Linked Data". linkedscience.org. Lorentz, Alissa (2013). "With Big Data, Context is a Big Issue". Wired.
Flok (company)
Flok (formerly Loyalblocks) was an American tech startup based in New York City that provides marketing services such as chatbots/AI, customer loyalty programs, mobile apps and CRM services to local businesses. In January 2017, the company was acquired by Wix.com. Around March 2017, Flok ceased regular communication. At some point in 2019 Flok communicated to its customers that it would shut down in March 2020. == Background == Flok was founded in 2011 by Ido Gaver and Eran Kirshenboim and has offices in Tel Aviv, Israel. In May 2013, Flok secured a $9 million Series A Round from General Catalyst Partners with participation from Founder Collective and existing investor Gemini Israel Ventures. In total, Flok has raised over $18 million in venture capital in three rounds. In May 2014, Flok announced a self-service loyalty platform for SMBs to build their own programs with beacon integration. At that time, approximately 40,000 businesses were using the service. In 2016, Flok released a turnkey chatbot service for local businesses, and was featured in AdWeek for developing the first weed bot chatbot for a California cannabis business. == Services == Flok offered an eponymous customer-facing app, that consumers use to receive rewards and deals from partner businesses, and a Flok business app for merchants to manage the platform.
TRAME
TRAME (TRAnsmission of MEssages) was the name of the second computer network in the world similar to the internet to be used in an electric utility. Like the internet, the base technology was packet switching; it was developed by the electric utility ENHER in Barcelona. It was deployed by the same utility, first in Catalonia and Aragón, Spain, and later in other places. Its development started in 1974 and the first routers, called nodes at that time, were deployed by 1978. The network was in operation until 2016 (38 years) with successive technological software and hardware updates. == Beginnings == In 1974, packet switching was a technology known only in research circles. The concept began in 1968 in association with the United States' Advanced Research Projects Agency (ARPA) research project ARPANET. The idea of applying the packet switching concept to electric utilities control communication networks first appeared in 1974 when the Swedish power utility Vattenfall started to create its TIDAS packet-switching network and was followed by the Spanish electric utility ENHER, which aimed to telecontrol and automate its high-voltage power grid. For this purpose, ENHER created a specific team of people to develop both the packet-switching network and the supervisory control and data acquisition (SCADA) system, also called the telecontrol system. By 1978 the first four TRAME routers were available and by 1980, eight of them were deployed and operating. The printed circuit boards (PCBs) controlling the communication lines were connected to a shared memory PCB allowing them to exchange data and messages. The project was developed together with its main initial application, the Telecontrol or SCADA system SICL (Sistema Integral de Control Local) with which initially they shared a very similar hardware. The maximum link capacity was 9600 bit/s, which in 1980 was the maximum possible on a 4 kHz wide voice channel at the time. These channels were the basic unit of the then-analog communication systems in use. By that time power utilities used either telephone calls or low speed (below 1200bit/s) dedicated links for telecontrol, typically shared among ten high-voltage electrical substations. == Services == The basic service provided by the TRAME network was SCADA or Telecontrol to automate the high-voltage power grid, thus improving operational efficiency, which was until then operated manually with telephone communication between human operators. Each TRAME router was associated with one or more remote terminal units (RTUs) of the SICL telecontrol system. It also had connected screens, and later PCs, located in electrical substations to interchange messages between them and with the Control Center located in the well-known Casa Fuster in Barcelona. It was a kind of predecessor to today's e-mail. Later, in the 1990s, other protocols (X.25, IP) were developed to include corporate information technology (IT) terminals, company physical surveillance systems and other services. Additionally, applications and terminals were developed for the transmission of voice and video over the TRAME network. == Protocols == The TRAME routing system, like that of the original ARPANET, was based on the Bellman-Ford algorithm but with "split-horizon" as in the Swedish TIDAS network, but with an original improvement. This protocol allows optimal paths to be found in meshed networks for each packet to be transmitted, allowing the shared use of the same network by multiple services. In contrast, traditional circuit-switched technology used to establish dedicated circuits for each service or communication. The addressing of routers and terminals used a proprietary system with a 16-bit address; it would be the equivalent of the well-known IP (Internet Protocol) version 4 (IPv4), still in use on the internet today, which uses 32-bit addresses. It is necessary to take into account that in 1978, the IPv4 protocol did not yet exist since the IPv4 version used on the internet did not appear until 1981, and in fact, did not reach the general public until much later. The line protocols were also proprietary and were called UCL (Unidad de Control de Línea, 'line control unit'), which linked the routers together, and UTR (Unión TRAME-Remotas), the access protocol. They were designed to offer the highest quality of service required by the telecontrol/SCADA function in terms of data integrity and availability set by the International Electrotechnical Commission (IEC) IEC-870-5-1 and ANSI C37.1. standards, and because the protocol used at the time in corporate computer networks, HDLC (high-level data link control), did not offer enough quality for critical industrial applications. Later on, other protocols like X.25 and IP were also made compatible with the aforementioned TRAME protocols. In 2000, the UTR protocol was replaced by the international standard IEC 60870- 5-101/104. Initially network flow control was based on the management of eight data priorities in head-of-the-line (HOL) waiting queues. Later and after some experimentation, a flow control method based on a bit indicating route congestion and management of the gap between packets when accessing the network was adopted. This required measuring the capacity of the route bottleneck. An end-to-end protocol was also added for some flows requiring order preservation like X.25. == Evolution == To last for 38 years, the technology had to endure intense evolution. There were essentially four TRAME generations which are summarized in the table. A description of the four generations of TRAME is provided below. === TRAME 1 === The project began in 1974 and in 1978 a first network with four routers was already installed and in operation at the electric utility ENHER. In 1980, the network had eight nodes in operation (see Figure I). The hardware was based on the Zilog Z80 processor and had a multiprocessor structure with 16 processors sharing a common memory. The software was developed at ENHER's headquarters located in the well-known Casa Fuster, Passeig de Gràcia, 132, Barcelona, using the Z80 assembly language. Beyond 1980 the software began to be written in C programming language and an HP64000 Logic Development System emulator was used for the purpose. The hardware was produced by ISEL, an INI (Instituto Nacional de Indústria) company. The routing system was a variant of Bellman-Ford with split-horizon. It was an improvement of the original ARPA network routing system consisting of an original update procedure which allowed for a faster reaction to changes. The distance function was the number of packets in the output waiting queues plus one. The line protocols (UCL for internal lines linking routers and UTR for accessing the network) were designed to meet the stringent requirements set for telecontrol (SCADA) of high-voltage power networks (IEC-870-5-1 and ANSI C37.1 standards). At the OSI transport layer, windows with a width of 1 to 8, depending on the required service, residing in the terminals were used. Initially, addresses were only 14 bits long to address both the routers (called nodes by then) and the devices connected to them. They were made up of two fields, an 8-bit field to address the router and a 6-bit sub-address to address the terminals connected to it. The node address was assigned to the nodes and not to the ends of the links as in the internet. The basic advantages of TRAME over other technologies used in electric utilities at the time were in part due to the packet technology itself: ability to manage any network topology, automatic adaptability to topological and traffic changes, integration of different link technologies (digital or analog) and capacities in a single network, open and decentralized intercommunicability between users and devices, simultaneous communication with several users and locations from a single physical connection, and integrated network supervision. In fact, the network was provided from its inception with a supervision center consisting of a computer and a synoptic board located at the company's headquarters (see Figure II). But other advantages were due to the specific design of TRAME: high data integrity, priority support for packets, and ease of including special protocols such as the many SCADA protocols in use at that time. All of the above resulted in improved quality of service, especially with respect to data availability and data integrity, and in the integration of services in a single network. Part of the evolution of its deployment can be seen in Figures II to IV. === TRAME 2 === In 1990, TRAME 2 was fully deployed and TRAME 1 was replaced. The processor of the new hardware was Intel 80286 and the hardware structure and external appearance of the routers was very similar to that of TRAME 1. The software was written in C and the above-mentioned emulator continued to be used. Improvements over TRAME 1 were the introduction of the standardized X.25 access protocol
WYSIWYS
In cryptography, What You See Is What You Sign (WYSIWYS) is a property of digital signature systems that ensures the semantic content of signed messages can not be changed, either by accident or intent. == Mechanism of WYSIWYS == When digitally signing a document, the integrity of the signature relies not just on the soundness of the digital signature algorithms that are used, but also on the security of the computing platform used to sign the document. The WYSIWYS property of digital signature systems aims to tackle this problem by defining a desirable property that the visual representation of a digital document should be consistent across computing systems, particularly at the points of digital signature and digital signature verification. It is relatively easy to change the interpretation of a digital document by implementing changes on the computer system where the document is being processed, and the greater the semantic distance, the easier it gets. From a semantic perspective this creates uncertainty about what exactly has been signed. WYSIWYS is a property of a digital signature system that ensures that the semantic interpretation of a digitally signed message cannot be changed, either by accident or by intent. This property also ensures that a digital document to be signed can not contain hidden semantic content that can be revealed after the signature has been applied. Though a WYSIWYS implementation is only as secure as the computing platform it is running on, various methods have been proposed to make WYSIWYS more robust. The term WYSIWYS was coined by Peter Landrock and Torben Pedersen to describe some of the principles in delivering secure and legally binding digital signatures for Pan-European projects.
Electronic lab notebook
An electronic lab notebook or electronic laboratory notebook (ELN) is a computer program designed to replace paper laboratory notebooks. Lab notebooks in general are used by scientists, engineers, and technicians to document research, experiments, and procedures performed in a laboratory. A lab notebook is often maintained to be a legal document and may be used in a court of law as evidence. Similar to an inventor's notebook, the lab notebook is also often referred to in patent prosecution and intellectual property litigation. Electronic lab notebooks offer many benefits to the user as well as organizations; they are easier to search upon, simplify data copying and backups, and support collaboration amongst many users. ELNs can have fine-grained access controls, and can be more secure than their paper counterparts. They also allow the direct incorporation of data from instruments, replacing the practice of printing out data to be stapled into a paper notebook. == Types == ELNs can be divided into two categories: "Specific ELNs" contain features designed to work with specific applications, scientific instrumentation or data types. "Cross-disciplinary ELNs" or "Generic ELNs" are designed to support access to all data and information that needs to be recorded in a lab notebook. Lab Platforms that combine an ELN, LIMS, and scientific data management together, all-in-one configurable software environment. Solutions range from specialized programs designed from the ground up for use as an ELN, to modifications or direct use of more general programs. Examples of using more general software as an ELN include using OpenWetWare, a MediaWiki install (running the same software that Wikipedia uses), WordPress, or the use of general note taking software such as OneNote as an ELN. ELN's come in many different forms. They can be standalone programs, use a client-server model, or be entirely web-based. Some use a lab-notebook approach, others resemble a blog. ELNs are embracing artificial intelligence and LLM technology to provide scientific AI chat assistants. A good many variations on the "ELN" acronym have appeared. Differences between systems with different names are often subtle, with considerable functional overlap between them. Examples include "ERN" (Electronic Research Notebook), "ERMS" (Electronic Resource (or Research or Records) Management System (or Software) and SDMS (Scientific Data (or Document) Management System (or Software). Ultimately, these types of systems all strive to do the same thing: Capture, record, centralize and protect scientific data in a way that is highly searchable, historically accurate, and legally stringent, and which also promotes secure collaboration, greater efficiency, reduced mistakes and lowered total research costs. == Objectives == A good electronic laboratory notebook should offer a secure environment to protect the integrity of both data and process, whilst also affording the flexibility to adopt new processes or changes to existing processes without recourse to further software development. The package architecture should be a modular design, so as to offer the benefit of minimizing validation costs of any subsequent changes that you may wish to make in the future as your needs change. A good electronic laboratory notebook should be an "out of the box" solution that, as standard, has fully configurable forms to comply with the requirements of regulated analytical groups through to a sophisticated ELN for inclusion of structures, spectra, chromatograms, pictures, text, etc. where a preconfigured form is less appropriate. All data within the system may be stored in a database (e.g. MySQL, MS-SQL, Oracle) and be fully searchable. The system should enable data to be collected, stored and retrieved through any combination of forms or ELN that best meets the requirements of the user. The application should enable secure forms to be generated that accept laboratory data input via PCs and/or laptops / palmtops, and should be directly linked to electronic devices such as laboratory balances, pH meters, etc. Networked or wireless communications should be accommodated for by the package which will allow data to be interrogated, tabulated, checked, approved, stored and archived to comply with the latest regulatory guidance and legislation. A system should also include a scheduling option for routine procedures such as equipment qualification and study related timelines. It should include configurable qualification requirements to automatically verify that instruments have been cleaned and calibrated within a specified time period, that reagents have been quality-checked and have not expired, and that workers are trained and authorized to use the equipment and perform the procedures. == Regulatory and legal aspects == The laboratory accreditation criteria found in the ISO 17025 standard needs to be considered for the protection and computer backup of electronic records. These criteria can be found specifically in clause 4.13.1.4 of the standard. Electronic lab notebooks used for development or research in regulated industries, such as medical devices or pharmaceuticals, are expected to comply with FDA regulations related to software validation. The purpose of the regulations is to ensure the integrity of the entries in terms of time, authorship, and content. Unlike ELNs for patent protection, FDA is not concerned with patent interference proceedings, but is concerned with avoidance of falsification. Typical provisions related to software validation are included in the medical device regulations at 21 CFR 820 (et seq.) and Title 21 CFR Part 11. Essentially, the requirements are that the software has been designed and implemented to be suitable for its intended purposes. Evidence to show that this is the case is often provided by a Software Requirements Specification (SRS) setting forth the intended uses and the needs that the ELN will meet; one or more testing protocols that, when followed, demonstrate that the ELN meets the requirements of the specification and that the requirements are satisfied under worst-case conditions. Security, audit trails, prevention of unauthorized changes without substantial collusion of otherwise independent personnel (i.e., those having no interest in the content of the ELN such as independent quality unit personnel) and similar tests are fundamental. Finally, one or more reports demonstrating the results of the testing in accordance with the predefined protocols are required prior to release of the ELN software for use. If the reports show that the software failed to satisfy any of the SRS requirements, then corrective and preventive action ("CAPA") must be undertaken and documented. Such CAPA may extend to minor software revisions, or changes in architecture or major revisions. CAPA activities need to be documented as well. Aside from the requirements to follow such steps for regulated industry, such an approach is generally a good practice in terms of development and release of any software to assure its quality and fitness for use. There are standards related to software development and testing that can be applied (see ref.).
Adobe GoLive
Adobe GoLive was a WYSIWYG HTML editor and web site management application from Adobe Systems. It replaced Adobe PageMill as Adobe's primary HTML editor and was itself discontinued in favor of Dreamweaver. The last version of GoLive that Adobe released was GoLive 9. == History == GoLive originated as the flagship product of a company named GoNet Communication, Inc. then based in Menlo Park, California, and the development company GoNet Communications GmbH in Hamburg, Germany, in 1996. Later GoNet changed its name to GoLive Systems, Inc, and the name of its product to GoLive CyberStudio. Adobe acquired GoLive in 1999 and re-branded the GoLive CyberStudio product to what became Adobe GoLive. Adobe took over the Hamburg office as an Adobe development site to continue to develop the product. At the time of the acquisition, CyberStudio was a Macintosh-only application. In the spring of 1999 Adobe released Adobe GoLive for both Macintosh and Microsoft Windows. The first versions of Dreamweaver and CyberStudio were released in a similar timeframe. However, Dreamweaver eventually became the dominant WYSIWYG HTML editor in market share. After the Adobe acquisition of Macromedia (the company that had owned Dreamweaver), GoLive was progressively re-targeted toward Adobe's traditional design market, and the product became better integrated with Adobe's existing suite of design-oriented software products and less focused on the professional web development market. The Adobe CS2 Premium suite contained GoLive CS2. With the release of Creative Suite 3, Adobe integrated Dreamweaver as a replacement for GoLive and released GoLive 9 as a standalone product. In April 2008, Adobe announced that sales and development of GoLive would cease in favor of Dreamweaver. == General description and distinctive aspects == GoLive incorporated a largely modeless workflow that relied heavily on drag-and-drop. Most user interaction was done via a contextual inspector rather than the modal workflow found in Dreamweaver. Among its features were a separate editor for tables that supported nesting, and a two-dimensional panel for applying CSS styles to elements. GoLive supported drag-and-drop of native Adobe Photoshop and Adobe Illustrator files via what the company called "Smart Objects", which then automatically guided the user through saving those files in web-supported formats. Updates to the original Photoshop or Illustrator assets were automatically tracked by GoLive. It also implemented a tool called "Components" which allowed updates to interface elements throughout a site to be updated globally by changing one single file. As a website management tool, GoLive allowed users to transfer and publish content directly from within the application, and allowed individual files to be excluded from uploading. == Features == One of the new features of GoLive version 5 was Dynamic Link, which was a method of creating dynamic, database-driven web content without the need to know a server-side language and with full WYSIWYG support in the GoLive user interface. GoLive had a powerful set of extensibility API which could be used to add additional functionality to the product. The GoLive SDK provided interfaces which allowed developers to use a combination of XML, JavaScript and C/C++ to create plugins for the product. The extensibility API allowed developers access to custom drawing and event handling using JavaScript, as well as a full JavaScript debugger and command line interpreter. This allowed intermediate-level developers using interpreted JavaScript to create sophisticated user interfaces. == Language and framework structure == Adobe GoLive is coded in the C++ programming language. It uses a custom C++ framework called SCL (Simple Class Library) which was initially built from scratch by the engineers at GoLive Systems Inc. The SCL framework was also used in the short-lived Adobe Atmosphere 3D software. == Release history == As the final version, GoLive 9 was discontinued in April 2008.
Experimental SAGE Subsector
The Experimental Semi-Automatic Ground Environment (SAGE) Sector (ESS, Experimental SAGE Subsector until planned Sectors/Subsectors were renamed NORAD Regions, Divisions, and Sectors) was a prototype Cold War Air Defense Sector for developing the Semi Automatic Ground Environment. The Lincoln Laboratory control center in a new building was at Lexington, Massachusetts. == ESS Computer System == The network's Direction Center was completed in a new 1954 building (Building F, 42°27′37″N 071°16′04″W) with prototype peripherals and a single IBM XD-1 computer, a successor to Lincoln Lab's Whirlwind I computer (WWI). In 1955, Air Force personnel began IBM training at the Kingston, New York, prototype facility, and the "4620th Air Defense Wing (experimental SAGE) was established at Lincoln Laboratory"—its "primary mission was computer programming". ESS had a capacity of 48 tracks and used a pre-SAGE ground environment in a "prototype intercept monitor room [at] MIT's Barta building" with "track situation displays, which geographically showed Air Defense Identification Zone lines and antiaircraft circles [and] each console also had a 5-inch CRT for digital information display. Audible alert signals were used, with a different signal for each symbol on a situation display." == Radar stations == Initial service test models of the Burroughs AN/FST-2 Coordinate Data Transmitting Set were placed with radars at South Truro and West Bath, Maine; followed by Texas Tower#2 (TT2) in the Atlantic Ocean, which provided a "triangular pattern with overlap" radar coverage (TT2 later had a connection from the XD-1 via the GE G/A Data Link Output Subsystem through North Truro Air Force Station.) By August 1955, 13 radar stations were networked by the subsector, e.g.: Chatham Clinton, Massachusetts with gap-filler radar Great Boars Head Halibut Point Killingly, Connecticut (41.865734°N 71.820958°W / 41.865734; -71.820958).with gap-filler radar Rockport Air Force Station Scituate, Massachusetts South Truro West Bath, Maine (43°54′7″N 69°50′43″W) with AN/FPS-31 on Jug Handle Hill: ("Lincoln Laboratories experimental radar station") Required by 21 November 1955 were 44 consoles: 38 for the operations floor, 3 on the computer floor for display maintenance, and 3 near the maintenance console (program checkout). WWI was connected to the Experimental SAGE Subsector to verify crosstelling (collateral communication) with the ESS DC, and WWI was also used for a Ground-to-Air (G/A) experiment using a transmitter of the GE G/A Data Link Output Subsystem on Prospect Hill, Waltham, MA sending data to simulated airborne equipment at Lexington. Transmissions from the WWI SAGE Evaluation (WISE) computer system to XD-1 and back were without error by December 1955 when operational software specifications were frozen. Operating procedures for the ESS external sites were complete in March 1956, and == System Operation Testing == From November 15, 1955, to November 7, 1956, three System Operation Tests were conducted which used voice "Ground-to-Air" communication from the Barta control room to aircraft outfitted with SAGE receivers (F-86 interceptors modified to F-86L models in "Project FOLLOW-ON".) Test teams included employees of Bell Telephone Laboratories, Western Electric-ADES, IBM, the RAND Corporation, and Lincoln Labs' Division 6, Division 3, & Division 2 (Division 6 had been created for ESS support.) The North Truro P-10 AN/FST-2 was moved to Almaden Air Force Station (M-96)c. 1957-8 and on August 7, 1958, control of an airborne BOMARC missile that had malfunctioned transferred from the "Experimental SAGE Sector" to a Westinghouse AN/GPA-35 Ground Environment system and the missile crashed into the Atlantic Ocean. By December 31, 1958, ADC Manual 55-28 described the Model 3 SAGE System. == 1959 Experimental Testing == "To prove out the revised SAGE computer program" for Automatic Targeting and Battery Evaluation and ADDC-AADCP crosstelling, a "SAGE/Missile Master" test was conducted beginning in September 1959 with communications between the ESS XD-1 and Martin AN/FSG-1 Antiaircraft Defense System equipment at Fort Banks planned for the CONAD Joint Control Center at Fort Heath—a "SAGE ATABE Simulation Study" (SASS) was also completed 1959–60 by MITRE Corporation.