AUTINDEX is a commercial text mining software package based on sophisticated linguistics. AUTINDEX, resulting from research in information extraction, is a product of the Institute of Applied Information Sciences (IAI) which is a non-profit institute that has been researching and developing language technology since its foundation in 1985. IAI is an institute affiliated to Saarland University in Saarbrücken, Germany. AUTINDEX is the result of a number of research projects funded by the EU (Project BINDEX), by Deutsche Forschungsgemeinschaft and the German Ministry for Economy. Amongst the latter there are the projects LinSearch, and WISSMER, see also the reference to IAI-Website. The basic functionality of AUTINDEX is the extraction of key words from a document to represent the semantics of the document. Ideally the system is integrated with a thesaurus that defines the standardised terms to be used for key word assignment. AUTINDEX is used in library applications (e.g. integrated in dandelon.com) as well as in high quality (expert) information systems, and in document management and content management environments. Together with AUTINDEX a number of additional software comes along such as an integration with Apache Solr / Lucene to provide a complete information retrieval environment, a classification and categorisation system on the basis of a machine learning software that assigns domains to the document, and a system for searching with semantically similar terms that are collected in so called tag clouds.
Automation engineering
Automation engineering is a branch of engineering that deals with the development of methods and facilities that replace, in whole or in part, manual labour related to the control and monitoring of systems and processes. == Automation engineer == Automation engineers are experts who have the knowledge and ability to design, create, develop and manage machines and systems, for example, factory automation, process automation and warehouse automation. Automation technicians are also involved. == Scope == Automation engineering is the integration of standard engineering fields. Automatic control of various control systems for operating various systems or machines to reduce human efforts & time to increase accuracy. Automation engineers design and service electromechanical devices and systems for high-speed robotics and programmable logic controllers (PLCs). == Work and career after graduation == Graduates can work for both government and private sector entities such as industrial production, and companies that create and use automation systems, for example, the paper industry, automotive industry, metallurgical industry, food and agricultural industry, water treatment, and oil & gas sectors such as refineries, rolling mills, and power plants. == Job description == Automation engineers can design, program, simulate and test automated machinery and processes, and are usually employed in industries such as the energy sector in plants, car manufacturing facilities, food processing plants, and robots. Automation engineers are responsible for creating detailed design specifications and other documents, developing automation based on specific requirements for the process involved, and conforming to international standards like IEC-61508, local standards, and other process-specific guidelines and specifications, simulating, testing, and commissioning electronic equipment for automation.
NAPLPS
NAPLPS (North American Presentation Layer Protocol Syntax) is a graphics language for use originally with videotex and teletext services. NAPLPS was developed from the Telidon system developed in Canada, with a small number of additions from AT&T Corporation. The basics of NAPLPS were later used as the basis for several other microcomputer-based graphics systems. == History == The Canadian Communications Research Centre (CRC), based in Ottawa, had been working on various graphics systems since the late 1960s, much of it led by Herb Bown. Through the 1970s they turned their attention to building out a system of "picture description instructions", which encoded graphics commands as a text stream. Graphics were encoded as a series of instructions (graphics primitives) each represented by a single ASCII character. Graphic coordinates were encoded in multiple 6-bit strings of XY coordinate data, flagged to place them in the printable ASCII range so that they could be transmitted with conventional text transmission techniques. ASCII SI/SO characters were used to differentiate the text from graphic portions of a transmitted "page". These instructions were decoded by separate programs to produce graphics output, on a plotter for instance. Other work produced a fully interactive version. In 1975, the CRC gave a contract to Norpak to develop an interactive graphics terminal that could decode the instructions and display them on a color display. During this period, a number of companies were developing the first teletext systems, notably the BBC's Ceefax system. Ceefax encoded character data into the lines in the vertical blanking interval of normal television signals where they could not be seen on-screen, and then used a buffer and decoder in the user's television to convert these into "pages" of text on the display. The Independent Broadcasting Authority quickly introduced their own ORACLE system, and the two organizations subsequently agreed to use a single standard, the "Broadcast Teletext Specification". This later became World System Teletext. At about the same time, other organizations were developing videotex systems, similar to teletext except they used modems to transmit their data instead of television signals. This was potentially slower and used up a telephone line, but had the major advantage of allowing the user to transmit data back to the sender. The UK's General Post Office developed a system using the Ceefax/ORACLE standard, launching it as Prestel, while France prepared the first steps for its ultimately very successful Minitel system, using a rival display standard called Antiope. By 1977, the Norpak system was running, and from this work the CRC decided to create their own teletext/videotext system. Unlike the systems being rolled out in Europe, the CRC decided from the start that the system should be able to run on any combination of communications links. For instance, it could use the vertical blanking interval to send data to the user, and a modem to return selections to the servers. It could be used in a one-way or two-way system. In teletext mode, character codes were sent to users' televisions by encoding them as dot patterns in the vertical blanking interval of the video signal. Various technical "tweaks" and details of the NTSC signals used by North American televisions allowed the downstream videotex channel to increase to 600 bit/s, about twice that used in the European systems. In videotext mode, Bell 202 modems were typical, offering a 1,200 bit/s download rate. A set top box attached to the TV decoded these signals back into text and graphics pages, which the user could select among. The system was publicly launched as Telidon on August 15, 1978. Compared to the European standards, the CRC system was faster, bi-directional, and offered real graphics as opposed to simple character graphics. The downside of the system was that it required much more advanced decoders, typically featuring Zilog Z80 or Motorola 6809 processors with RGB and/or RF output. The Innovation, Science and Economic Development Canada (then Department of Communications) launched a four-year plan to fund public roll-outs of the technology in an effort to spur the development of a commercial Telidon system. AT&T Corporation was so impressed by Telidon that they decided to join the project. They added a number of useful extensions, notably the ability to define original graphics commands (macro) and character sets (DRCS). They also tabled algorithms for proportionally spaced text, which greatly improved the quality of the displayed pages. A joint CSA/ANSI working group (X3L2.1) revised the specifications, which were submitted for standardization. In 1983, they became CSA T500 and ANSI X3.110, or NAPLPS. The data encoding system was also standardized as the NABTS (North American Broadcast Teletext Specification) protocol. Business models for Telidon services were poorly developed. Unlike the UK, where teletext was supported by one of only two large companies whose whole revenue model was based on a read-only medium (television), in North America Telidon was being offered by companies who worked on a subscriber basis. == One-way systems == Telidon-based teletext was tested in a few North American trials in the early 1980s — CBC IRIS, TVOntario, MTS-sponsored Project IDA, to name a few. NAPLPS was also part of the NABTS teletext standard, for the encoding and display of teletext pages. In the late 1980s and early 1990s, affiliates of the regional sports network group SportsChannel ran a service called Sports Plus Network, which ran sports news and scores while SportsChannel was not otherwise on the air. The screens, which frequently featured team logos or likenesses of players in addition to text, were drawn entirely with NAPLPS graphics and resembled the loading of Prodigy pages over a modem, though slightly faster. == Two-way systems == Various two-way systems using NAPLPS appeared in North America in the early 1980s. The biggest North American examples were Knight Ridder's Viewtron (based in Miami) and the Los Angeles Times' Gateway service (based in Orange County). Both used the Sceptre NAPLPS terminal from AT&T. The Sceptre contained a slow modem that connected over the consumer's telephone line to host computers. The Sceptre was expensive whether purchased or rented. Despite huge investments by their parent companies, neither Viewtron nor Gateway lasted into the second half of the decade. Another system, Keyfax, was developed by Keycom Electronic Publishing, a joint venture of Honeywell, Centel (since acquired by Sprint) and Field Enterprises, then-owner of the Chicago Sun-Times newspaper. Keyfax had originally been a WST teletext service, broadcast overnights on Field's Chicago television station WFLD-32 and through the VBI of both WFLD and national superstation WTBS; the decision was made to convert Keyfax into a subscription service, using a proprietary NAPLPS terminal device in a last-ditch effort to save the service. It did not work and Keyfax had ceased operations by the end of 1986. Other early-1980s NAPLPS technology was deployed in Canada, both as a way for rural Canadians to get news and weather information and as the platform for touchscreen information kiosks. In Vancouver these were featured at Expo 86. The kiosks became ubiquitous in Toronto under the name Teleguide, and were deployed in many shopping centres and at major tourist attractions. The latter city was the North American nexus of NAPLPS and the home of Norpak, the most successful of NAPLPS-oriented developers. Norpak created and sold hardware and software for NAPLPS development and display. TVOntario also developed NAPLPS content creation software. London, Ontario - based Cableshare used NAPLPS as the basis of touch-screen information kiosks for shopping malls, the flagship of which was deployed at Toronto's Eaton Centre. The system relied on an 8085-based microcomputer which drove several NAPLPS terminals fitted with touch screens, all communicating via Datapac to a back end database. The system offered news, weather and sports information along with shopping mall guides and coupons. Cableshare also developed and sold a leading NAPLPS page creation utility called the "Picture Painter." In the late 1980s, Tribune Media Services (TMS) and the Associated Press operated a cable television channel called AP News Plus that provided NAPLPS-based news screens to cable television subscribers in many U.S. cities. The news pages were created and edited by TMS staffers working on an Atex editing system in Orlando, Florida, and sent by satellite to NAPLPS decoder devices located at the local cable television companies. Among the firms providing technology to TMS and the Associated Press for the AP News Plus channel was Minneapolis-based Electronic Publishers Inc. (1985–1988). In 1981, two amateur radio operators (VE3FTT and VE3GQW) received special permission from the Canad
FoundationDB
FoundationDB is a free and open-source multi-model distributed NoSQL database owned by Apple Inc. with a shared-nothing architecture. The product was designed around a "core" database, with additional features supplied in "layers." The core database exposes an ordered key–value store with transactions. The transactions are able to read or write multiple keys stored on any machine in the cluster while fully supporting ACID properties. Transactions are used to implement a variety of data models via layers. The FoundationDB Alpha program began in January 2012 and concluded on March 4, 2013, with their public Beta release. Their 1.0 version was released for general availability on August 20, 2013. On March 24, 2015, it was reported that Apple has acquired the company. A notice on the FoundationDB web site indicated that the company has "evolved" its mission and would no longer offer downloads of the software. On April 19, 2018, Apple open sourced the software, releasing it under the Apache 2.0 license. == Main features == The main features of FoundationDB include the following: Ordered key–value store In addition to supporting standard key-based reads and writes, the ordering property enables range reads that can efficiently scan large swaths of data. Transactions Transaction processing employs multiversion concurrency control for reads and optimistic concurrency for writes. Transactions can span multiple keys stored on multiple machines. ACID properties FoundationDB guarantees serializable isolation and strong durability via redundant storage on disk before transactions are considered committed. Layers Layers map new data models, APIs, and query languages to the FoundationDB core. They employ FoundationDB's ability to update multiple data elements in a single transaction, ensuring consistency. An example is their SQL layer. Commodity clusters FoundationDB is designed for deployment on distributed clusters of commodity hardware running Linux. Replication FoundationDB stores each piece of data on multiple machines according to a configurable replication factor. Triple replication is the recommended mode for clusters of 5 or more machines. Scalability FoundationDB is designed to support horizontal scaling through the addition of machines to a cluster while automatically handling data replication and partitioning. Systems supported FoundationDB supports packages for Linux, Windows, and macOS. The Linux version supports production clusters, while the Windows and macOS versions support local operation for development purposes. Configurations on Amazon EC2 are also supported. Programming language bindings FoundationDB supports language bindings for Python, Go, Ruby, Node.js, Java, PHP, and C, all of which are made available with the product. == Design limitations == The design of FoundationDB results in several limitations: Long transactions FoundationDB does not support transactions running over five seconds. Large transactions Transaction size cannot exceed 10 MB of total written keys and values. Large keys and values Keys cannot exceed 10 kB in size. Values cannot exceed 100 kB in size. == History == FoundationDB, headquartered in Vienna, Virginia, was started in 2009 by Nick Lavezzo, Dave Rosenthal, and Dave Scherer, drawing on their experience in executive and technology roles at their previous company, Visual Sciences. In March 2015 the FoundationDB Community site was updated to state that the company had changed directions and would no longer be offering downloads of its product. The company was acquired by Apple Inc., which was confirmed March 25, 2015. On April 19, 2018, Apple open sourced the software, releasing it under the Apache 2.0 license.
Digital Michelangelo Project
The Digital Michelangelo Project was a pioneering initiative undertaken during the 1998–1999 academic year to digitize the sculptures and architecture of Michelangelo using advanced laser scanning technology. The project was led by a team of 30 faculty, staff, and students from Stanford University and the University of Washington, with the aim of creating high-resolution 3D models of Michelangelo's works for scholarly, educational, and preservation purposes. == Objectives == The primary goals of the Digital Michelangelo Project were: To apply recent advancements in laser rangefinder technology for digitizing large cultural artifacts. To create detailed digital archives of Michelangelo's sculptures and architectural spaces for future study and analysis. To explore potential educational and curatorial applications for 3D scanned data. === Artworks digitized === The project involved scanning several iconic works by Michelangelo, including: David The Unfinished Slaves (Atlas, Awakening, Bearded, and Youthful) St. Matthew The allegorical statues from the Medici tombs (Night, Day, Dawn, and Dusk) The architectural interiors of the Tribuna del David at the Galleria dell'Accademia and the New Sacristy in the Medici Chapels. == Technology and methodology == === 3D scanning === The project's primary scanner was a laser triangulation rangefinder mounted on a motorized gantry, custom-built by Cyberware Inc. The scanner used a laser sheet to project onto an object, capturing its shape through triangulation. Multiple scans were taken from various angles and combined into a single, detailed 3D mesh. The resolution achieved was fine enough to capture even Michelangelo's chisel marks, with triangles approximately 0.25 mm on each side. In addition to shape data, color data was captured using a spotlight and a secondary camera, enabling the creation of textured 3D models. === Data processing === The project developed a software suite for processing the scanned data. This included: Aligning and merging multiple scans into a seamless 3D model. Filling holes in the geometry caused by inaccessible areas. Correcting color data for lighting inconsistencies and shadowing. Non-photorealistic rendering techniques were also applied, highlighting surface features such as Michelangelo’s chisel marks for enhanced visualization. == Logistical challenges == The scale and complexity of the project presented several challenges: Data size: The dataset for David alone comprised 2 billion polygons and 7,000 color images, occupying 60 GB of storage. Artifact safety: Ensuring the safety of the statues during scanning required extensive crew training, foam-encased equipment, and collision-prevention mechanisms. == Applications and impact == The digitized models have numerous potential applications: Art history: Allowing precise measurements and geometric analysis, such as determining chisel types or evaluating structural balance. Education: Providing new ways to study art, including interactive viewing from unconventional angles and with custom lighting. Museum curation: Enhancing visitor experiences through interactive kiosks and virtual models. The project demonstrated the potential for 3D technology to preserve and disseminate cultural heritage. == Data distribution == The project's models are available through Stanford University for scholarly purposes, under strict licensing due to Italian intellectual property laws. === ScanView === To provide public access to the 3D models while respecting usage restrictions, the project developed ScanView, a client/server rendering system. ScanView allows users to view and interact with high-resolution 3D models without downloading the data. The client component consists of a freely available viewer program and simplified 3D models. Users can navigate these models locally, adjusting position, orientation, lighting, and surface appearance. When a user finalizes a view, the client queries a remote server for a high-resolution rendering of the model, which is sent back to overwrite the simplified version on the user’s screen. A typical query-response cycle takes 1–2 seconds, depending on network conditions. To protect the models from unauthorized reconstruction, the system employs several security measures, including: Encrypting queries Perturbing viewpoint and lighting parameters Adding noise and warping rendered images Compressing images before transmission ScanView operates on Windows-based PCs and provides access to selected models, including David and St. Matthew, as well as other artifacts such as fragments of the Forma Urbis Romae and items from the Stanford 3D Scanning Repository. == Sponsors == The Digital Michelangelo Project was supported by Stanford University, Interval Research Corporation, and the Paul G. Allen Foundation for the Arts.
Data-centric AI
Data-centric AI is an approach within artificial intelligence that emphasizes on improving the quality, consistency and representativeness of the data used to train machine learning models, rather than focusing primarily on optimizing model architectures or algorithms. This idea has gained traction as researchers and practitioners have come to believe that many performance limitations of machine learning systems stem from issues such as noisy labels, biased datasets, and lack of coverage in the data. Data-centric AI involves disciplined approach to data cleaning, augmentation, labeling, and governance that improves model performance and reliability in applications such as computer vision, natural language processing, and further.
Reflection lines
Engineers use reflection lines to judge a surface's quality. Reflection lines reveal surface flaws, particularly discontinuities in normals indicating that the surface is not C 2 {\displaystyle C^{2}} . Reflection lines may be created and examined on physical surfaces or virtual surfaces with the help of computer graphics. For example, the shiny surface of an automobile body is illuminated with reflection lines by surrounding the car with parallel light sources. Virtually, a surface can be rendered with reflection lines by modulating the surfaces point-wise color according to a simple calculation involving the surface normal, viewing direction and a square wave environment map. == Mathematical definition == Consider a point p {\displaystyle p} on a surface M {\displaystyle M} with (normalized) normal n {\displaystyle n} . If an observer views this point from infinity at view direction v {\displaystyle v} then the reflected view direction r {\displaystyle r} is: r = v − 2 ( n ⋅ v ) n . {\displaystyle r=v-2(n\cdot v)n.} (The vector v {\displaystyle v} is decomposed into its normal part v n = ( n ⋅ v ) v {\displaystyle v_{n}=(n\cdot v)v} and tangential part v t = v − v n {\displaystyle v_{t}=v-v_{n}} . Upon reflection, the tangential part is kept and the normal part is negated.) For reflection lines we consider the surface M {\displaystyle M} surrounded by parallel lines with direction a {\displaystyle a} , representing infinite, non-dispersive light sources. For each point p {\displaystyle p} on M {\displaystyle M} we determine which line is seen from direction v {\displaystyle v} . The position on each line is of no interest. Define the vector r p {\displaystyle r_{p}} to be the reflection direction r {\displaystyle r} projected onto a plane P {\displaystyle P} that is orthogonal to a {\displaystyle a} : r p = r − ( r ⋅ a ) a {\displaystyle r_{p}=r-(r\cdot a)a} and similarly let v p {\displaystyle v_{p}} be the viewing direction projected onto P {\displaystyle P} : v p = v − ( v ⋅ a ) a {\displaystyle v_{p}=v-(v\cdot a)a} Finally, define v o {\displaystyle v_{o}} to be the direction lying in P {\displaystyle P} perpendicular to a {\displaystyle a} and v p {\displaystyle v_{p}} : v o = a × v p {\displaystyle v_{o}=a\times v_{p}} Using these vectors, the reflection line function θ ( p ) : M → ( − π , π ] {\displaystyle \theta (p):M\rightarrow (-\pi ,\pi ]} is a scalar function mapping points p {\displaystyle p} on the surface to angles between v p {\displaystyle v_{p}} and r p {\displaystyle r_{p}} : θ = arctan ( r p ⋅ v o , r p ⋅ v p ) {\displaystyle \theta =\arctan {(r_{p}\cdot v_{o},r_{p}\cdot v_{p})}} where a r c t a n ( y , x ) {\displaystyle arctan(y,x)} is the atan2 function producing a number in the range ( − π , π ] {\displaystyle (-\pi ,\pi ]} . ( v p {\displaystyle v_{p}} and v o {\displaystyle v_{o}} can be viewed as a local coordinate system in P {\displaystyle P} with x {\displaystyle x} -axis in direction v p {\displaystyle v_{p}} and y {\displaystyle y} -axis in direction v o {\displaystyle v_{o}} .) Finally, to render the reflection lines positive values θ > 0 {\displaystyle \theta >0} are mapped to a light color and non-positive values to a dark color. == Highlight lines == Highlight lines are a view-independent alternative to reflection lines. Here the projected normal is directly compared against some arbitrary vector x {\displaystyle x} perpendicular to the light source: θ = arctan ( n a ⋅ a ⊥ , n a ⋅ x ) {\displaystyle \theta =\arctan {(n_{a}\cdot a^{\perp },n_{a}\cdot x)}} where n a {\displaystyle n_{a}} is the surface normal projected on the light source plane P {\displaystyle P} : n a ^ / | n a ^ | , n a ^ = n − ( n ⋅ a ) a {\displaystyle {\hat {n_{a}}}/|{\hat {n_{a}}}|,{\hat {n_{a}}}=n-(n\cdot a)a} The relationship between reflection lines and highlight lines is likened to that between specular and diffuse shading.