A source-code editor is a text editor program designed specifically for editing the source code of computer programs. It includes basic functionality such as syntax highlighting, and sometimes debugging. It may be a standalone application or it may be built into an integrated development environment (IDE). == Features == Source-code editors have features specifically designed to simplify and speed up typing of source code, such as syntax highlighting(syntax error highlighting), auto indentation, autocomplete and brace matching functionality. These editors may also provide a convenient way to run a compiler, interpreter, debugger, or other program relevant for the software-development process. While many text editors like Notepad can be used to edit source code, if they do not enhance, automate or ease the editing of code, they are not defined as source-code editors. Structure editors are a different form of a source-code editor, where instead of editing raw text, one manipulates the code's structure, generally the abstract syntax tree. In this case features such as syntax highlighting, validation, and code formatting are easily and efficiently implemented from the concrete syntax tree or abstract syntax tree, but editing is often more rigid than free-form text. Structure editors also require extensive support for each language, and thus are harder to extend to new languages than text editors, where basic support only requires supporting syntax highlighting or indentation. For this reason, strict structure editors are not popular for source code editing, though some IDEs provide similar functionality. A source-code editor can check syntax dynamically while code is being entered and immediately warn of syntax problems, as well as suggest code autocomplete snippets. A few source-code editors compress source code, typically converting common keywords into single-byte tokens, removing unnecessary whitespace, and converting numbers to a binary form. Such tokenizing editors later uncompress the source code when viewing it, possibly prettyprinting it with consistent capitalization and spacing. A few source-code editors do both. The Language Server Protocol, first used in Microsoft's Visual Studio Code, allows for source code editors to implement an LSP client that can read syntax information about any language with a LSP server. This allows for source code editors to easily support more languages with syntax highlighting, refactoring, and reference finding. Many source code editors such as Neovim and Brackets have added a built-in LSP client while other editors such as Emacs, Vim, and Sublime Text have support for an LSP Client via a separate plug-in. == History == In 1985, Mike Cowlishaw of IBM created LEXX while seconded to the Oxford University Press. LEXX used live parsing and used color and fonts for syntax highlighting. IBM's LPEX (Live Parsing Extensible Editor) was based on LEXX and ran on VM/CMS, OS/2, OS/400, Windows, and Java Although the initial public release of vim was in 1991, the syntax highlighting feature was not introduced until version 5.0 in 1998. On November 1, 2015, the first version of NeoVim was released. In 2003, Notepad++, a source code editor for Windows, was released by Don Ho. The intention was to create an alternative to the java-based source code editor, JEXT In 2015, Microsoft released Visual Studio Code as a lightweight and cross-platform alternative to their Visual Studio IDE. The following year, Visual Studio Code became the Microsoft product using the Language Server Protocol. This code editor quickly gained popularity and emerged as the most widely used source code editor. == Comparison with IDEs == A source-code editor is one component of a Integrated Development Environment. In contrast to a standalone source-code editor, an IDE typically also includes several tools which enhance the software development process. Such tools include syntax highlighting, code autocomplete suggestions, version control, automatic formatting, integrated runtime environments, debugger, and build tools. Standalone source code editors are preferred over IDEs by some developers when they believe the IDEs are bloated with features they do not need. == Notable examples == == Controversy == Many source-code editors and IDEs have been involved in ongoing user arguments, sometimes referred to jovially as "holy wars" by the programming community. Notable examples include vi vs. Emacs and Eclipse vs. NetBeans. These arguments have formed a significant part of internet culture and they often start whenever either editor is mentioned anywhere.
Adobe Presenter
Adobe Presenter is eLearning software released by Adobe Systems available on the Microsoft Windows platform as a Microsoft PowerPoint plug-in, and on both Windows and OS X as the screencasting and video editing tool Adobe Presenter Video Express. It is mainly targeted towards learning professionals and trainers. In addition to recording one's computer desktop and speech, it also provides the option to add quizzes and track performance by integrating with learning management systems. Adobe Presenter was designed to replace the discontinued Adobe Ovation software, which had similar functions. == Predecessor == Adobe Ovation was originally released by Serious Magic. It converted PowerPoint slides into visual presentations with additional effects. Ovation included themes called PowerLooks that could add motion and polish the presentations. They were available in a variety of color variations complete with animated backgrounds and dynamic text effects. Ovation could make text with jagged edges more readable. TimeKeeper could be used to set the period of the presentation, and the PointPrompter scrolled down the notes. Ovation's development has been discontinued, nor does it support PowerPoint 2007. == Features == The main purpose of Adobe Presenter is to capture on-screen presentations and convert them into more interactive and engaging videos. Support is given to convert Microsoft PowerPoint 2010 and 2013 presentations into videos. It also allows for content authoring on PowerPoint and ActionScript 3, and offers integration with Adobe Captivate. Slide branching enables users to control slide navigation and titles and create complex slide branching to guide viewers through the content of the presentation. Video editing tools are also provided, and offer the ability to upload to video-sharing platforms such as YouTube, Vimeo and other sites. Multimedia features such as annotations, eLearning templates, actors, audio narration and drag-and-drop elements enrich users' presentations. Quizzes and surveys is another highlighted feature, which include generating question pools, importing questions from existing quizzes and in-course collaboration which allows presenters to receive feedback by allowing them to comment on specific content within a course or ask questions for more clarity. Presenters could opt to receive feedback from viewers through video analytics and create Experience API, SCORM and AICC-compliant content. Options to publish to Adobe Connect are provided. Other unique features include universal standards support, file size control, navigational restrictions among others.
Sentential decision diagram
In artificial intelligence, a sentential decision diagram (SDD) is a type of knowledge representation used in knowledge compilation to represent Boolean functions. SDDs can be viewed as a generalization of the influential ordered binary decision diagram (OBDD) representation, by allowing decisions on multiple variables at once. Like OBDDs, SDDs allow for tractable Boolean operations, while being exponentially more succinct. For this reason, they have become an important representation in knowledge compilation. == Properties == SDDs are defined with respect to a generalization of variable ordering known as a variable tree (vtree). Provided that they satisfy additional properties known as compression and trimming (which are analogous to ROBDDs), SDDs are a canonical representation of Boolean functions; that is, they are unique given a vtree. Like OBDDs, they allow for operations such as conjunction, disjunction and negation to be computed directly on the representation in polynomial time, while being potentially more compact. They also allow for polynomial-time model counting. SDDs are known to be exponentially more succinct than OBDDs. == Applications == SDDs are used as a compilation target for probabilistic logic programs by the ProbLog 2 system since they support tractable (weighted) model counting as well as tractable negation, conjunction and disjunction while being more succinct than BDDs. SDDs have also been extended to model probability distributions, in which context they are known as probabilistic sentential decision diagrams (PSDD).
OntoWiki
OntoWiki was a free and open-source semantic wiki application, meant to serve as an ontology editor and a knowledge acquisition system. It is a web-based application written in PHP and using either a MySQL database or a Virtuoso triple store. OntoWiki is form-based rather than syntax-based, and thus tries to hide as much of the complexity of knowledge representation formalisms from users as possible. OntoWiki is mainly being developed by the Agile Knowledge Engineering and Semantic Web (AKSW) research group at the University of Leipzig, a group also known for the DBpedia project among others, in collaboration with volunteers around the world. In 2009 the AKSW research group got a budget of €425,000 from the Federal Ministry of Education and Research of Germany for the development of the OntoWiki. In 2010 OntoWiki became part of the technology stack supporting the LOD2 (linked open data) project. Leipzig University is one of the consortium members of the project, which is funded by a €6.5m EU grant. The development ended in 2016 due to the lack of capacity migrating from PHP 5 to 7 including the required Zend Framework from version 1 to 2.
AgMES
The AgMES (Agricultural Metadata Element set) initiative was developed by the Food and Agriculture Organization (FAO) of the United Nations and aims to encompass issues of semantic standards in the domain of agriculture with respect to description, resource discovery, interoperability, and data exchange for different types of information resources. There are numerous other metadata schemas for different types of information resources. The following list contains a list of a few examples: Document-like Information Objects (DLIOs): Dublin Core, Agricultural Metadata Element Set (AgMES) Events: VCalendar Geographic and Regional Information: Geographic information—Metadata ISO/IEC 11179 Standards Persons: Friend-of-a-friend (FOAF), vCard Plant Production and Protection: Darwin Core (1.0 and 2.0) (DwC) AgMES as a namespace is designed to include agriculture specific extensions for terms and refinements from established standard metadata namespaces like Dublin Core, AGLS etc. Thus, to be used for Document-like Information Objects, for example like publications, articles, books, web sites, papers, etc., it will have to be used in conjunction with the standard namespaces mentioned before. The AgMES initiative strives to achieve improved interoperability between information resources in agricultural domain by enabling means for exchange of information. Describing a DLIO with AgMES means exposing its major characteristics and contents in a standard way that can be reused easily in any information system. The more institutions and organizations in the agricultural domain that use AgMES to describe their DLIOs, the easier it will be to interchange data in between information systems like digital libraries and other repositories of agricultural information. == Use of AgMES == Metadata on agricultural Document-like Information Objects (DLIOs) can be created and stored in various formats: embedded in a web site (in the manner as with the HTML meta tag) in a separate metadata database in an XML file in an RDF file AgMES defines elements that can be used to describe a DLIO that can be used together with other metadata standards such as the Dublin Core, the Australian Government Locator Service. A complete list of all elements, refinements and schemes endorsed by AgMES is available from the AgMES website. === Creating application profiles === Application profiles are defined as schemas which consist of data elements drawn from one or more namespaces, combined by implementers, and optimized for a particular local application. Application profiles share the following four characteristics: They draw upon existing pool of metadata definition standards to extract suitable application- or requirement oriented elements. An application profile cannot create new elements. Application profiles specify the application specific details such as the schemes or controlled vocabularies. An application profile also contains information such as the format for the element value, cardinality or data type. Lastly, an application profile can refine standardized definitions as long as it is "semantically narrower or more specific". This capability of application profiles caters to situations where a domain specific terminology is needed to replace a more general one. === Sample application profiles using AgMES === The AGRIS Application Profile is a standard created specifically to enhance the description, exchange and subsequent retrieval of agricultural Document-like Information Objects (DLIOs). It is a format that allows sharing of information across dispersed bibliographic systems and is based on well-known and accepted metadata standards. The Event Application Profile is a standard created to allow members of the Agricultural community to 'know' about an upcoming event and guide them to the event Web site where they can find further information. The information communicated is thus minimum yet interoperable across domains and organizations. == AgMES and the semantic web == One of the advantages of the AgMES metadata schema is the ability to link between the metadata element and controlled vocabularies. The use of controlled vocabulary provides a "known" set of options to the indexer (and the search programmer) as to how the field can be filled out. Often the values may come from a specific thesaurus (e.g. AGROVOC) or classification schemes (e.g. the AGRIS/CARIS classification scheme) etc. Thanks to the possibility to use controlled vocabularies for metadata elements, the user is provided with the most precise information. In this context, work is also being carried out on exploiting the power of controlled vocabularies expressed as using URIs and machine-understandable semantics. In this context, FAO is promoting the Agricultural Ontology Service (AOS) initiative with the objective of expressing more semantics within the traditional thesaurus AGROVOC and build a Concept Server as a repository from which it will be always possible to extract traditional KOS.
Wetware (brain)
Wetware is a term drawn from the computer-related idea of hardware or software, but applied to biological life forms. == Usage == The prefix "wet" is a reference to the water found in living creatures. Wetware is used to describe the elements equivalent to hardware and software found in a person, especially the central nervous system (CNS) and the human mind. The term wetware finds use in works of fiction, in scholarly publications and in popularizations. The "hardware" component of wetware concerns the bioelectric and biochemical properties of the CNS, specifically the brain. If the sequence of impulses traveling across the various neurons are thought of symbolically as software, then the physical neurons would be the hardware. The amalgamated interaction of this software and hardware is manifested through continuously changing physical connections, and chemical and electrical influences that spread across the body. The process by which the mind and brain interact to produce the collection of experiences that we define as self-awareness is in question. == History == Although the exact definition has shifted over time, the term Wetware and its fundamental reference to "the physical mind" has been around at least since the mid-1950s. Mostly used in relatively obscure articles and papers, it was not until the heyday of cyberpunk, however, that the term found broad adoption. Among the first uses of the term in popular culture was the Bruce Sterling novel Schismatrix (1985) and the Michael Swanwick novel Vacuum Flowers (1987). Rudy Rucker references the term in a number of books, including one entitled Wetware (1988): ... all sparks and tastes and tangles, all its stimulus/response patterns – the whole bio-cybernetic software of mind. Rucker did not use the word to simply mean a brain, nor in the human-resources sense of employees. He used wetware to stand for the data found in any biological system, analogous perhaps to the firmware that is found in a ROM chip. In Rucker's sense, a seed, a plant graft, an embryo, or a biological virus are all wetware. DNA, the immune system, and the evolved neural architecture of the brain are further examples of wetware in this sense. Rucker describes his conception in a 1992 compendium The Mondo 2000 User's Guide to the New Edge, which he quotes in a 2007 blog entry. Early cyber-guru Arthur Kroker used the term in his blog. With the term getting traction in trendsetting publications, it became a buzzword in the early 1990s. In 1991, Dutch media theorist Geert Lovink organized the Wetware Convention in Amsterdam, which was supposed to be an antidote to the "out-of-body" experiments conducted in high-tech laboratories, such as experiments in virtual reality. Timothy Leary, in an appendix to Info-Psychology originally written in 1975–76 and published in 1989, used the term wetware, writing that "psychedelic neuro-transmitters were the hot new technology for booting-up the 'wetware' of the brain". Another common reference is: "Wetware has 7 plus or minus 2 temporary registers." The numerical allusion is to a classic 1957 article by George A. Miller, The magical number 7 plus or minus two: some limits in our capacity for processing information, which later gave way to Miller's law.
Mycin
MYCIN was an early backward chaining expert system that used black box to identify bacteria causing severe infections, such as bacteremia and meningitis, and to recommend antibiotics, with the dosage adjusted for patient's body weight — the name derived from the antibiotics themselves, as many antibiotics have the suffix "-mycin". The Mycin system was also used for the diagnosis of blood clotting diseases. MYCIN was developed over five or six years in the early 1970s at Stanford University. It was written in Lisp as the doctoral dissertation of Edward Shortliffe under the direction of Bruce G. Buchanan, Stanley N. Cohen and others. MYCIN emerged from the Stanford Heuristic Programming Project. MYCIN demonstrated the potential for expert systems in building high-performance medical reasoning programs. MYCIN is often viewed as a pioneer in the field of expert systems, even being referred to as the "grandaddy of them all-the one that launched the field" by Dr. Allen Newell. MYCIN led to the EMYCIN expert system shell ("essential MYCIN") for acquiring knowledge, reasoning with it, and explaining the results, without the specific medical knowledge. It can be described as "EMYCIN = Prolog + uncertainty + caching + questions + explanations + contexts - variables". An introduction is in Chapter 16 of Paradigms of Artificial Intelligence Programming (PAIP). == Method == MYCIN operated using a fairly simple inference engine and a knowledge base of ~600 rules by obtaining individual inferential facts identified by experts and encoding such facts as individual production rules. No other AI program at the time contained as much domain-specific knowledge clearly separated from its inference procedures as MYCIN. It would query the physician running the program via a long series of simple yes/no or textual questions. At the end, it provided a list of possible culprit bacteria ranked from high to low based on the probability of each diagnosis, its confidence in each diagnosis' probability, the reasoning behind each diagnosis (that is, MYCIN would also list the questions and rules which led it to rank a diagnosis a particular way), and its recommended course of drug treatment. MYCIN could additionally respond to queries by physicians related to why it asked the user a certain question, how it arrived at a conclusion, and why it did not consider certain factors. The developers performed studies showing that MYCIN's performance was minimally affected by perturbations in the uncertainty metrics associated with individual rules, suggesting that the power in the system was related more to its knowledge representation and reasoning scheme than to the details of its numerical uncertainty model. Some observers felt that it should have been possible to use classical Bayesian statistics. MYCIN's developers argued that this would require either unrealistic assumptions of probabilistic independence, or require the experts to provide estimates for an unfeasibly large number of conditional probabilities. Subsequent studies later showed that the certainty factor model could indeed be interpreted in a probabilistic sense, and highlighted problems with the implied assumptions of such a model. However the modular structure of the system would prove very successful, leading to the development of graphical models such as Bayesian networks. === Context === A context in MYCIN determines what types of objects can be reasoned about. They are similar to variables in Prolog, or environment variables in operating systems. === Evidence combination === In MYCIN it was possible that two or more rules might draw conclusions about a parameter with different weights of evidence. For example, one rule may conclude that the organism in question is E. Coli with a certainty of 0.8 whilst another concludes that it is E. Coli with a certainty of 0.5 or even −0.8. In the event the certainty is less than zero the evidence is actually against the hypothesis. In order to calculate the certainty factor MYCIN combined these weights using the formula below to yield a single certainty factor: C F ( x , y ) = { X + Y − X Y if X , Y > 0 X + Y + X Y if X , Y < 0 X + Y 1 − min ( | X | , | Y | ) otherwise {\displaystyle CF(x,y)={\begin{cases}X+Y-XY&{\text{if }}X,Y>0\\X+Y+XY&{\text{if }}X,Y<0\\{\frac {X+Y}{1-\min(|X|,|Y|)}}&{\text{otherwise}}\end{cases}}} Where X and Y are the certainty factors. This formula can be applied more than once if more than two rules draw conclusions about the same parameter. It is commutative, so it does not matter in which order the weights were combined. The combination formula was designed to have the following desirable properties: −1 can be interpreted as "false", +1 as "true", and 0 as "uncertain". Combining unknown with anything leaves it unchanged. Combining true with anything (except false) gives true. Similarly for false. Combining true and false is a division-by-zero error. Combining +x and -x gives unknown. Combining two positives (except true) gives a larger positive. Similarly for negatives. Combining a positive and a negative gives something in between. === Examples === The following examples come from Chapter 16 of PAIP, which contains an implementation in Common Lisp of a modified and simplified version of MYCIN for pedagogical purposes. A rule, and an English paraphrase generated by the system: == Results == An evaluation of MYCIN was conducted at the Stanford Medical School. The first phase of the evaluation consisted of 10 test cases of diverse origin, chosen by a physician who was not acquainted with MYCIN's methods or knowledge base. These cases were presented to 7 physicians and 1 senior medical student. 10 prescriptions were compiled for each of the cases, 1 recommended by MYCIN, 1 prescribed by the treating physician at the county hospital, and 8 by the aforementioned individuals. The second phase of the evaluation consisted of eight infectious disease specialists being provided the clinical summary and set of 10 prescriptions for each of the 10 cases and tasked to provide their own recommendations for each case and assess the 10 prescriptions. MYCIN received an acceptability rating of 65%, which was comparable to the 42.5% to 62.5% rating of five faculty members. This study is often cited as showing the potential for disagreement about therapeutic decisions, even among experts, when there is no "gold standard" for correct treatment. == Practical use == MYCIN was never actually used in practice. This wasn't because of any weakness in its performance. Some observers raised ethical and legal issues related to the use of computers in medicine, regarding the responsibility of the physicians in case the system gave wrong diagnosis. However, the greatest problem, and the reason that MYCIN was not used in routine practice, was the state of technologies for system integration, especially at the time it was developed. MYCIN was a stand-alone system that required a user to enter all relevant information about a patient by typing in responses to questions MYCIN posed. MYCIN ran on the DEC KI10 PDP-10, supporting a large time-shared system available over the early Internet (ARPANet), before personal computers were developed. MYCIN's greatest influence was accordingly its demonstration of the power of its representation and reasoning approach. Rule-based systems in many non-medical domains were developed in the years that followed MYCIN's introduction of the approach. In the 1980s, expert system "shells" were introduced (including one based on MYCIN, known as E-MYCIN (followed by Knowledge Engineering Environment - KEE)) and supported the development of expert systems in a wide variety of application areas. A difficulty that rose to prominence during the development of MYCIN and subsequent complex expert systems has been the extraction of the necessary knowledge for the inference engine to use from the human expert in the relevant fields into the rule base (the so-called "knowledge acquisition bottleneck").