The JAUS Tool Set (JTS) is a software engineering tool for the design of software services used in a distributed computing environment. JTS provides a graphical user interface (GUI) and supporting tools for the rapid design, documentation, and implementation of service interfaces that adhere to the Society of Automotive Engineers' standard AS5684A, the JAUS Service Interface Design Language (JSIDL). JTS is designed to support the modeling, analysis, implementation, and testing of the protocol for an entire distributed system. == Overview == The JAUS Tool Set (JTS) is a set of open source software specification and development tools accompanied by an open source software framework to develop Joint Architecture for Unmanned Systems (JAUS) designs and compliant interface implementations for simulations and control of robotic components per SAE-AS4 standards. JTS consists of the components: GUI based Service Editor: The Service Editor (referred to as the GUI in this document) provides a user friendly interface with which a system designer can specify and analyze formal specifications of Components and Services defined using the JAUS Service Interface Definition Language (JSIDL). Validator: A syntactic and semantic validator provides on-the-fly validation of specifications entered (or imported) by the user with respect to JSIDL syntax and semantics is integrated into the GUI. Specification Repository: A repository (or database) that is integrated into the GUI that allows for the storage of and encourages the reuse of existing formal specifications. C++ Code Generator: The Code Generator automatically generates C++ code that has a 1:1 mapping to the formal specifications. The generated code includes all aspects of the service, including the implementations of marshallers and unmarshallers for messages, and implementations of finite-state machines for protocol behavior that are effectively decoupled from application behavior. Document Generator: The Document Generator automatically generates documentation for sets of Service Definitions. Documents may be generated in several formats. Software Framework: The software framework implements the transport layer specification AS5669A, and provides the interfaces necessary to integrate the auto-generated C++ code with the transport layer implementation. Present transport options include UDP and TCP in wired or wireless networks, as well as serial connections. The transport layer itself is modular, and allows end-users to add additional support as needed. Wireshark Plugin: The Wireshark plugin implements a plugin to the popular network protocol analyzer called Wireshark. This plugin allows for the live capture and offline analysis of JAUS message-based communication at runtime. A built-in repository facilitates easy reuse of service interfaces and implementations traffic across the wire. The JAUS Tool Set can be downloaded from www.jaustoolset.org User documentation and community forum are also available at the site. == Release history == Following a successful Beta test, Version 1.0 of the JAUS Tool Set was released in July 2010. The initial offering focused on core areas of User Interface, HTML document generation, C++ code generation, and the software framework. The Version 1.1 update was released in October 2010. In addition to bug fixes and UI improvements, this version offered several important upgrades including enhancement to the Validator, Wireshark plug-in, and generated code. The JTS 2.0 release is scheduled for the second quarter of 2011 and further refines the Tool Set functionality: Protocol Validation: Currently, JTS provides validation for message creation, to ensure users cannot create invalid messages specifications. That capability does not currently exist for protocol definitions, but is being added. This will help ensure that users create all necessary elements of a service definition, and reduce user error. C# and Java Code Generation: Currently, JTS generates cross-platform C++ code. However, other languages including Java and C# are seeing a dramatic increase in their use in distributed systems, particularly in the development of graphical clients to embedded services. MS Word Document Generation: HTML and JSIDL output is supported, but native Office-Open-XML (OOXML) based MS Word generation has advantages in terms of output presentation, and ease of use for integration with other documents. Therefore, we plan to integrate MS Word service document generation. In addition, the development team has several additional goals that are not-yet-scheduled for a particular release window: Protocol Verification: This involves converting the JSIDL definition of a service into a PROMELA model, for validation by the SPIN model checking tool. Using PROMELA to model client and server interfaces will allow developers to formally validate JAUS services. End User Experience: We plan to conduct formal User Interface testing. This involves defining a set of tasks and use cases, asking users with various levels of JAUS experience to accomplish those tasks, and measuring performance and collecting feedback, to look for areas where the overall user experience can be improved. Improved Service Re-Use: JSIDL allows for inheritance of protocol descriptions, much like object-oriented programming languages allow child classes to re-use and extend behaviors defined by the parent class. At present, the generated code 'flattens' these state machines into a series of nested states which gives the correct interface behavior, but only if each single leaf (child) service is generated within its own component. This limits service re-use and can lead to a copy-and-paste of the same implementation across multiple components. The team is evaluating other inheritance solutions that would allow for multiple leaf (child) services to share access to a common parent, but at present the approach is sufficient to address the requirements of the JAUS Core Service Set. == Domains and application == The JAUS Tool Set is based on the JAUS Service Interface Definition Language (JSIDL), which was originally developed for application within the unmanned systems, or robotics, communities. As such, JTS has quickly gained acceptance as a tool for generation of services and interfaces compliant with the SAE AS-4 "JAUS" publications. Although usage statistics are not available, the Tool Set has been downloaded by representatives of US Army, Navy, Marines, and numerous defense contractors. It was also used in a commercial product called the JAUS Expansion Module sold by DeVivo AST, Inc. Since the JSIDL schema is independent of the data being exchanged, however, the Tool Set can be used for the design and implementation of a Service Oriented Architecture for any distributed systems environment that uses binary encoded message exchange. JSIDL is built on a two-layered architecture that separates the application layer and the transport layer, effectively decoupling the data being exchanges from the details of how that data moves from component to component. Furthermore, since the schema itself is widely generic, it's possible to define messages for any number of domains including but not limited to industrial control systems, remote monitoring and diagnostics, and web-based applications. == Licensing == JTS is released under the open source BSD license. The JSIDL Standard is available from the SAE. The Jr Middleware on which the Software Framework (Transport Layer) is based is open source under LGPL. Other packages distributed with JTS may have different licenses. == Sponsors == Development of the JAUS Tool Set was sponsored by several United States Department of Defense organizations: Office of Under Secretary of Defense for Acquisition, Technology & Logistics / Unmanned Warfare. Navy Program Executive Officer Littoral and Mine Navy Program Executive Officer Unmanned Aviation and Strike Weapons Office of Naval Research Air Force Research Lab
Rule-based machine translation
Rule-based machine translation (RBMT) is a classical approach of machine translation systems based on linguistic information about source and target languages. Such information is retrieved from (unilingual, bilingual or multilingual) dictionaries and grammars covering the main semantic, morphological, and syntactic regularities of each language. Having input sentences, an RBMT system generates output sentences on the basis of analysis of both the source and the target languages involved. RBMT has been progressively superseded by more efficient methods, particularly neural machine translation. == History == The first RBMT systems were developed in the early 1970s. The most important steps of this evolution were the emergence of the following RBMT systems: Systran Japanese MT systems Today, other common RBMT systems include: Apertium GramTrans == Types of RBMT == There are three different types of rule-based machine translation systems: Direct Systems (Dictionary Based Machine Translation) map input to output with basic rules. Transfer RBMT Systems (Transfer Based Machine Translation) employ morphological and syntactical analysis. Interlingual RBMT Systems (Interlingua) use an abstract meaning. RBMT systems can also be characterized as the systems opposite to Example-based Systems of Machine Translation (Example Based Machine Translation), whereas Hybrid Machine Translations Systems make use of many principles derived from RBMT. == Basic principles == The main approach of RBMT systems is based on linking the structure of the given input sentence with the structure of the demanded output sentence, necessarily preserving their unique meaning. The following example can illustrate the general frame of RBMT: A girl eats an apple. Source Language = English; Demanded Target Language = German Minimally, to get a German translation of this English sentence one needs: A dictionary that will map each English word to an appropriate German word. Rules representing regular English sentence structure. Rules representing regular German sentence structure. And finally, we need rules according to which one can relate these two structures together. Accordingly, we can state the following stages of translation: 1st: getting basic part-of-speech information of each source word: a = indef.article; girl = noun; eats = verb; an = indef.article; apple = noun 2nd: getting syntactic information about the verb "to eat": NP-eat-NP; here: eat – Present Simple, 3rd Person Singular, Active Voice 3rd: parsing the source sentence: (NP an apple) = the object of eat Often only partial parsing is sufficient to get to the syntactic structure of the source sentence and to map it onto the structure of the target sentence. 4th: translate English words into German a (category = indef.article) => ein (category = indef.article) girl (category = noun) => Mädchen (category = noun) eat (category = verb) => essen (category = verb) an (category = indef. article) => ein (category = indef.article) apple (category = noun) => Apfel (category = noun) 5th: Mapping dictionary entries into appropriate inflected forms (final generation): A girl eats an apple. => Ein Mädchen isst einen Apfel. == Ontologies == An ontology is a formal representation of knowledge that includes the concepts (such as objects, processes etc.) in a domain and some relations between them. If the stored information is of linguistic nature, one can speak of a lexicon. In NLP, ontologies can be used as a source of knowledge for machine translation systems. With access to a large knowledge base, rule-based systems can be enabled to resolve many (especially lexical) ambiguities on their own. In the following classic examples, as humans, we are able to interpret the prepositional phrase according to the context because we use our world knowledge, stored in our lexicons:I saw a man/star/molecule with a microscope/telescope/binoculars.Since the syntax does not change, a traditional rule-based machine translation system may not be able to differentiate between the meanings. With a large enough ontology as a source of knowledge however, the possible interpretations of ambiguous words in a specific context can be reduced. === Building ontologies === The ontology generated for the PANGLOSS knowledge-based machine translation system in 1993 may serve as an example of how an ontology for NLP purposes can be compiled: A large-scale ontology is necessary to help parsing in the active modules of the machine translation system. In the PANGLOSS example, about 50,000 nodes were intended to be subsumed under the smaller, manually-built upper (abstract) region of the ontology. Because of its size, it had to be created automatically. The goal was to merge the two resources LDOCE online and WordNet to combine the benefits of both: concise definitions from Longman, and semantic relations allowing for semi-automatic taxonomization to the ontology from WordNet. A definition match algorithm was created to automatically merge the correct meanings of ambiguous words between the two online resources, based on the words that the definitions of those meanings have in common in LDOCE and WordNet. Using a similarity matrix, the algorithm delivered matches between meanings including a confidence factor. This algorithm alone, however, did not match all meanings correctly on its own. A second hierarchy match algorithm was therefore created which uses the taxonomic hierarchies found in WordNet (deep hierarchies) and partially in LDOCE (flat hierarchies). This works by first matching unambiguous meanings, then limiting the search space to only the respective ancestors and descendants of those matched meanings. Thus, the algorithm matched locally unambiguous meanings (for instance, while the word seal as such is ambiguous, there is only one meaning of seal in the animal subhierarchy). Both algorithms complemented each other and helped constructing a large-scale ontology for the machine translation system. The WordNet hierarchies, coupled with the matching definitions of LDOCE, were subordinated to the ontology's upper region. As a result, the PANGLOSS MT system was able to make use of this knowledge base, mainly in its generation element. == Components == The RBMT system contains: a SL morphological analyser - analyses a source language word and provides the morphological information; a SL parser - is a syntax analyser which analyses source language sentences; a translator - used to translate a source language word into the target language; a TL morphological generator - works as a generator of appropriate target language words for the given grammatica information; a TL parser - works as a composer of suitable target language sentences; Several dictionaries - more specifically a minimum of three dictionaries: a SL dictionary - needed by the source language morphological analyser for morphological analysis, a bilingual dictionary - used by the translator to translate source language words into target language words, a TL dictionary - needed by the target language morphological generator to generate target language words. The RBMT system makes use of the following: a Source Grammar for the input language which builds syntactic constructions from input sentences; a Source Lexicon which captures all of the allowable vocabulary in the domain; Source Mapping Rules which indicate how syntactic heads and grammatical functions in the source language are mapped onto domain concepts and semantic roles in the interlingua; a Domain Model/Ontology which defines the classes of domain concepts and restricts the fillers of semantic roles for each class; Target Mapping Rules which indicate how domain concepts and semantic roles in the interlingua are mapped onto syntactic heads and grammatical functions in the target language; a Target Lexicon which contains appropriate target lexemes for each domain concept; a Target Grammar for the target language which realizes target syntactic constructions as linearized output sentences. == Advantages == No bilingual texts are required. This makes it possible to create translation systems for languages that have no texts in common, or even no digitized data whatsoever. Domain independent. Rules are usually written in a domain independent manner, so the vast majority of rules will "just work" in every domain, and only a few specific cases per domain may need rules written for them. No quality ceiling. Every error can be corrected with a targeted rule, even if the trigger case is extremely rare. This is in contrast to statistical systems where infrequent forms will be washed away by default. Total control. Because all rules are hand-written, you can easily debug a rule-based system to see exactly where a given error enters the system, and why. Reusability. Because RBMT systems are generally built from a strong source language analysis that is fed to a transfer step and target language generator, the source language analysis and targe
Computational law
Computational law is the branch of legal informatics concerned with the automation of legal reasoning. What distinguishes Computational Law systems from other instances of legal technology is their autonomy, i.e. the ability to answer legal questions without additional input from human legal experts. While there are many possible applications of Computational Law, the primary focus of work in the field today is compliance management, i.e. the development and deployment of computer systems capable of assessing, facilitating, or enforcing compliance with rules and regulations. Some systems of this sort already exist. TurboTax is a good example. And the potential is particularly significant now due to recent technological advances – including the prevalence of the Internet in human interaction and the proliferation of embedded computer systems (such as smart phones, self-driving cars, and robots). There are also applications that do not involve governmental laws. The regulations can just as well be the terms of contracts (e.g. delivery schedules, insurance covenants, real estate transactions, financial agreements). They can be the policies of corporations (e.g. constraints on travel, expenditure reporting, pricing rules). They can even be the rules of games (embodied in computer game playing systems). == History == Speculation about potential benefits to legal practice through applying methods from computational science and AI research to automate parts of the law date back at least to the middle 1940s. Further, AI and law and computational law do not seem easily separable, as perhaps most of AI research focusing on the law and its automation appears to utilize computational methods. The forms that speculation took are multiple and not all related in ways to readily show closeness to one another. This history will sketch them as they were, attempting to show relationships where they can be found to have existed. By 1949, a minor academic field aiming to incorporate electronic and computational methods to legal problems had been founded by American legal scholars, called jurimetrics. Though broadly said to be concerned with the application of the "methods of science" to the law, these methods were actually of a quite specifically defined scope. Jurimetrics was to be "concerned with such matters as the quantitative analysis of judicial behavior, the application of communication and information theory to legal expression, the use of mathematical logic in law, the retrieval of legal data by electronic and mechanical means, and the formulation of a calculus of legal predictability". These interests led in 1959 to the founding a journal, Modern Uses of Logic in Law, as a forum wherein articles would be published about the applications of techniques such as mathematical logic, engineering, statistics, etc. to the legal study and development. In 1966, this Journal was renamed as Jurimetrics. Today, however, the journal and meaning of jurimetrics seems to have broadened far beyond what would fit under the areas of applications of computers and computational methods to law. Today the journal not only publishes articles on such practices as found in computational law, but has broadened jurimetrical concerns to mean also things like the use of social science in law or the "policy implications [of] and legislative and administrative control of science". Independently in 1958, at the Conference for the Mechanization of Thought held at the National Physical Laboratory in Teddington, Middlesex, UK, the French jurist Lucien Mehl presented a paper both on the benefits of using computational methods for law and on the potential means to use such methods to automate law for a discussion that included AI luminaries like Marvin Minsky. Mehl believed that the law could by automated by two basic distinct, though not wholly separable, types of machine. These were the "documentary or information machine", which would provide the legal researcher quick access to relevant case precedents and legal scholarship, and the "consultation machine", which would be "capable of answering any question put to it over a vast field of law". The latter type of machine would be able to basically do much of a lawyer's job by simply giving the "exact answer to a [legal] problem put to it". By 1970, Mehl's first type of machine, one that would be able to retrieve information, had been accomplished but there seems to have been little consideration of further fruitful intersections between AI and legal research. There were, however, still hopes that computers could model the lawyer's thought processes through computational methods and then apply that capacity to solve legal problems, thus automating and improving legal services via increased efficiency as well as shedding light on the nature of legal reasoning. By the late 1970s, computer science and the affordability of computer technology had progressed enough that the retrieval of "legal data by electronic and mechanical means" had been achieved by machines fitting Mehl's first type and were in common use in American law firms. During this time, research focused on improving the goals of the early 1970s occurred, with programs like Taxman being worked on in order to both bring useful computer technology into the law as practical aids and to help specify the exact nature of legal concepts. Nonetheless, progress on the second type of machine, one that would more fully automate the law, remained relatively inert. Research into machines that could answer questions in the way that Mehl's consultation machine would picked up somewhat in the late 1970s and 1980s. A 1979 convention in Swansea, Wales marked the first international effort solely to focus upon applying artificial intelligence research to legal problems in order to "consider how computers can be used to discover and apply the legal norms embedded within the written sources of the law". Considerable progress on the development of the second type of machine was made in the following decade, with the development of a variety of expert systems. According to Thorne McCarty, "these systems all have the following characteristics: They do backward chaining inference from a specified goal; they ask questions to elicit information from the user; and they produce a suggested answer along with a trace of the supporting legal rules." According to Prakken and Sartor the representation of the British Nationality Act as a logic program, which introduced this approach, was "hugely influential for the development of computational representations of legislation, showing how logic programming enables intuitively appealing representations that can be directly deployed to generate automatic inferences". In 2021, this work received the Inaugural CodeX Prize as "one of the first and best-known works in computational law, and one of the most widely cited papers in the field." In a 1988 review of Anne Gardner's book An Artificial Intelligence Approach to Legal Reasoning (1987), the Harvard academic legal scholar and computer scientist Edwina Rissland wrote that "She plays, in part, the role of pioneer; artificial intelligence ("AI") techniques have not yet been widely applied to perform legal tasks. Therefore, Gardner, and this review, first describe and define the field, then demonstrate a working model in the domain of contract offer and acceptance." Eight years after the Swansea conference had passed, and still AI and law researchers merely trying to delineate the field could be described by their own kind as "pioneer[s]". In the 1990s and early 2000s more progress occurred. Computational research generated insights for law. The First International Conference on AI and the Law occurred in 1987, but it is in the 1990s and 2000s that the biannual conference began to build up steam and to delve more deeply into the issues involved with work intersecting computational methods, AI, and law. Classes began to be taught to undergraduates on the uses of computational methods to automating, understanding, and obeying the law. Further, by 2005, a team largely composed of Stanford computer scientists from the Stanford Logic group had devoted themselves to studying the uses of computational techniques to the law. Computational methods in fact advanced enough that members of the legal profession began in the 2000s to both analyze, predict and worry about the potential future of computational law and a new academic field of computational legal studies seems to be now well established. As insight into what such scholars see in the law's future due in part to computational law, here is quote from a recent conference about the "New Normal" for the legal profession: "Over the last 5 years, in the fallout of the Great Recession, the legal profession has entered the era of the New Normal. Notably, a series of forces related to technological change, globalization, and the pressure to do more with less (in both corpo
Artificial intelligence in pharmacy
Artificial intelligence in pharmacy refers to the application of artificial intelligence (AI) techniques across pharmaceutical research and practice, including drug discovery, drug delivery, safety monitoring, clinical decision support, and pharmacy operations. Machine learning, deep learning, and natural language processing have been applied to tasks ranging from molecular design to patient adherence monitoring, with the aim of reducing development costs, improving accuracy, and personalizing treatment. Adoption has been uneven. Barriers include limited AI training among pharmacists, high infrastructure costs, and the risk of harm from models trained on unrepresentative data. Regulatory frameworks for AI-based pharmaceutical tools remain in active development across most jurisdictions. == Applications == === Drug discovery and development === Drug development is resource-intensive: bringing a single drug to market typically costs around $2.6 billion and takes 12–14 years. Machine learning algorithms have been applied to analyze molecular datasets to identify potential drug candidates, predict drug–target interactions, and optimize formulations. Artificial neural networks and generative adversarial networks have been used in drug discovery tasks including virtual screening, structure-activity relationship modeling, and de novo molecule generation. Peptides designed using AI methods have shown activity against multidrug-resistant bacteria, and transcriptomic data from human cell lines has been used to train deep learning models to classify drugs by therapeutic properties. Results in drug discovery have been mixed. AI models depend on the quality and diversity of their training data; those trained on narrow chemical libraries can fail to generalize to novel molecular scaffolds. The gap between high virtual screening hit rates and success in preclinical or clinical testing remains a persistent challenge, and the translation of computationally predicted candidates into approved drugs has been slower than early projections suggested. === Drug delivery systems === AI methods including neural networks, principal component analysis, and neuro-fuzzy logic have been applied to identifying biological targets for pharmaceuticals and analyzing genetic information relevant to drug design. Computational models can predict how a formulation will behave in biological systems, helping narrow the field before laboratory synthesis begins. Systems have been proposed that monitor patient response and adjust doses in real time based on individual physiology, with potential applications in chronic disease management. Research has also explored AI applications in targeted cancer treatments and oral vaccine delivery, areas where precise control over drug release kinetics is a design priority. === Drug safety === AI has been applied to predicting and detecting adverse drug reactions using techniques including knowledge graphs, logistic regression classifiers, and neural networks. A 2023 study developed a machine learning algorithm using knowledge graph analysis to classify known causes of adverse reactions. Natural language processing and deep learning models including long short-term memory (LSTM) networks have shown better performance than conventional methods for detecting opioid misuse, drawing on both structured data from electronic health records and unstructured sources such as clinical notes. AI-based pharmacovigilance systems can scan large volumes of electronic health records and social media for drug safety signals at a scale not feasible with manual review. Limitations include difficulty distinguishing drug-related adverse events from unrelated conditions in free-text data, and the need for validated benchmarks to measure model performance against existing safety monitoring standards. === Clinical decision support and personalized medicine === Machine learning systems trained on patient datasets can predict individual risk profiles, including potential allergies and drug–drug interactions, reducing the risk of harm in complex polypharmacy cases where the number of possible interactions exceeds what a clinician can readily assess. Personalized dosing models have been developed for drugs with narrow therapeutic windows — including anticoagulants and immunosuppressants — using patient-specific variables such as weight, renal function, and relevant genetic markers. Prospective clinical validation of these systems has lagged behind their technical development. Most published evaluations report performance on retrospective datasets, and the regulatory pathway for AI-based clinical decision support tools in pharmacy varies by jurisdiction. === Pharmacy operations and automation === Robotic and AI-driven systems have been applied to dispensing accuracy and pharmacy logistics. At the UCSF Medical Center, robotic technology produced 350,000 medication doses with no dispensing errors recorded. Robots such as TUG assist with preparing and transporting medications and laboratory samples within hospital settings. AI has also been applied to inventory management, with demand-forecasting systems predicting medicine requirements to reduce shortages and minimize waste from expired stock. In community pharmacy settings, AI tools have been used to flag potential prescription errors and alert pharmacists to drug–drug interactions before dispensing. === Medication adherence === Confirming that patients take prescribed medications as directed is a persistent challenge in healthcare. AI-enabled tools including smart pillboxes, RFID tags, ingestible sensors, and video check-ins have been applied to this problem. Smart pillboxes record when they are opened, providing real-time adherence data that can be reviewed remotely by care teams. Ingestible sensors transmit a signal after dissolution, offering direct confirmation of ingestion rather than proxy measures such as pill count or self-report. == Adoption challenges == === Barriers === Several barriers limit AI adoption in pharmacy practice. Many published evaluations report model performance on retrospective datasets rather than prospective clinical outcomes, making it difficult to assess real-world benefit. Pharmacists have reported limited AI training and knowledge, and research facilities often lack the computational infrastructure required for model development and validation. Models trained on biased or unrepresentative datasets can produce misleading results with direct patient safety consequences. === Regulatory frameworks === Regulatory frameworks for AI-based pharmaceutical tools are in active development. In the United States, the Food and Drug Administration (FDA) has issued guidance on AI and machine learning-based software as a medical device, addressing requirements for pre-market review and post-market performance monitoring. The European Medicines Agency has published discussion papers on the use of AI across the medicines development lifecycle, with particular attention to transparency in model training and validation. The absence of harmonized international standards creates compliance complexity for developers operating across multiple jurisdictions. === Ethical challenges === AI adoption raises data privacy and security concerns, including the risk of exposing sensitive patient information through data breaches. Algorithmic bias presents a related hazard: a model trained on an unrepresentative patient population may generate unsuitable treatment recommendations for patients not reflected in its training data, with potential for disparate outcomes across demographic groups. The opacity of some machine learning models, particularly deep neural networks, limits clinicians' ability to interpret or contest a recommendation, raising questions of accountability when a model-assisted decision results in patient harm. === Proposed solutions === Responses proposed in the literature include AI-focused education programs for pharmacists, increased public funding for healthcare AI research, encryption and governance frameworks for patient data, and regulatory requirements to prevent the use of biased training datasets. Greater transparency about training data provenance, model architecture, and validation methodology has also been recommended, including disclosure requirements in regulatory submissions. === Future directions === Research groups have called for tighter integration between AI systems and electronic health records to reduce healthcare costs and improve continuity of care across settings. International collaboration through shared AI frameworks and federated learning approaches has been proposed to address data scarcity in underrepresented patient populations and accelerate validation across institutions.
Tamarin Prover
Tamarin Prover is a computer software program for formal verification of cryptographic protocols. It has been used to verify Transport Layer Security 1.3, ISO/IEC 9798, DNP3 Secure Authentication v5, WireGuard, and the PQ3 Messaging Protocol of Apple iMessage. Tamarin is an open source tool, written in Haskell, built as a successor to an older verification tool called Scyther. Tamarin has automatic proof features, but can also be self-guided. In Tamarin lemmas that representing security properties are defined. After changes are made to a protocol, Tamarin can verify if the security properties are maintained. The results of a Tamarin execution will either be a proof that the security property holds within the protocol, an example protocol run where the security property does not hold, or Tamarin could potentially fail to halt.
Explanation-based learning
Explanation-based learning (EBL) is a form of machine learning that exploits a very strong, or even perfect, domain theory (i.e. a formal theory of an application domain akin to a domain model in ontology engineering, not to be confused with Scott's domain theory) in order to make generalizations or form concepts from training examples. It is also linked with Encoding (memory) to help with Learning. == Details == An example of EBL using a perfect domain theory is a program that learns to play chess through example. A specific chess position that contains an important feature such as "Forced loss of black queen in two moves" includes many irrelevant features, such as the specific scattering of pawns on the board. EBL can take a single training example and determine what are the relevant features in order to form a generalization. A domain theory is perfect or complete if it contains, in principle, all information needed to decide any question about the domain. For example, the domain theory for chess is simply the rules of chess. Knowing the rules, in principle, it is possible to deduce the best move in any situation. However, actually making such a deduction is impossible in practice due to combinatoric explosion. EBL uses training examples to make searching for deductive consequences of a domain theory efficient in practice. In essence, an EBL system works by finding a way to deduce each training example from the system's existing database of domain theory. Having a short proof of the training example extends the domain-theory database, enabling the EBL system to find and classify future examples that are similar to the training example very quickly. The main drawback of the method—the cost of applying the learned proof macros, as these become numerous—was analyzed by Minton. === Basic formulation === EBL software takes four inputs: a hypothesis space (the set of all possible conclusions) a domain theory (axioms about a domain of interest) training examples (specific facts that rule out some possible hypothesis) operationality criteria (criteria for determining which features in the domain are efficiently recognizable, e.g. which features are directly detectable using sensors) == Application == An especially good application domain for an EBL is natural language processing (NLP). Here a rich domain theory, i.e., a natural language grammar—although neither perfect nor complete, is tuned to a particular application or particular language usage, using a treebank (training examples). Rayner pioneered this work. The first successful industrial application was to a commercial NL interface to relational databases. The method has been successfully applied to several large-scale natural language parsing systems, where the utility problem was solved by omitting the original grammar (domain theory) and using specialized LR-parsing techniques, resulting in huge speed-ups, at a cost in coverage, but with a gain in disambiguation. EBL-like techniques have also been applied to surface generation, the converse of parsing. When applying EBL to NLP, the operationality criteria can be hand-crafted, or can be inferred from the treebank using either the entropy of its or-nodes or a target coverage/disambiguation trade-off (= recall/precision trade-off = f-score). EBL can also be used to compile grammar-based language models for speech recognition, from general unification grammars. Note how the utility problem, first exposed by Minton, was solved by discarding the original grammar/domain theory, and that the quoted articles tend to contain the phrase grammar specialization—quite the opposite of the original term explanation-based generalization. Perhaps the best name for this technique would be data-driven search space reduction. Other people who worked on EBL for NLP include Guenther Neumann, Aravind Joshi, Srinivas Bangalore, and Khalil Sima'an.
Riffusion
Riffusion is a neural network, designed by Seth Forsgren and Hayk Martiros, that generates music using images of sound rather than audio. The resulting music has been described as "de otro mundo" (otherworldly), although unlikely to replace man-made music. The model was made available on December 15, 2022, with the code also freely available on GitHub. The first version of Riffusion was created as a fine-tuning of Stable Diffusion, an existing open-source model for generating images from text prompts, on spectrograms, resulting in a model which used text prompts to generate image files which could then be put through an inverse Fourier transform and converted into audio files. While these files were only several seconds long, the model could also use latent space between outputs to interpolate different files together (using the img2img capabilities of SD). It was one of many models derived from Stable Diffusion. In December 2022, Mubert similarly used Stable Diffusion to turn descriptive text into music loops. In January 2023, Google published a paper on their own text-to-music generator called MusicLM. Forsgren and Martiros formed a startup, also called Riffusion, and raised $4 million in venture capital funding in October 2023.