The Object Data Management Group (ODMG) was conceived in the summer of 1991 at a breakfast with object database vendors that was organized by Rick Cattell of Sun Microsystems. In 1998, the ODMG changed its name from the Object Database Management Group to reflect the expansion of its efforts to include specifications for both object database and object–relational mapping products. The primary goal of the ODMG was to put forward a set of specifications that allowed a developer to write portable applications for object database and object–relational mapping products. In order to do that, the data schema, programming language bindings, and data manipulation and query languages needed to be portable. Between 1993 and 2001, the ODMG published five revisions to its specification. The last revision was ODMG version 3.0, after which the group disbanded. == Major components of the ODMG 3.0 specification == Object Model. This was based on the Object Management Group's Object Model. The OMG core model was designed to be a common denominator for object request brokers, object database systems, object programming languages, etc. The ODMG designed a profile by adding components to the OMG core object model. Object Specification Languages. The ODMG Object Definition Language (ODL) was used to define the object types that conform to the ODMG Object Model. The ODMG Object Interchange Format (OIF) was used to dump and load the current state to or from a file or set of files. Object Query Language (OQL). The ODMG OQL was a declarative (nonprocedural) language for query and updating. It used SQL as a basis, where possible, though OQL supports more powerful object-oriented capabilities. C++ Language Binding. This defined a C++ binding of the ODMG ODL and a C++ Object Manipulation Language (OML). The C++ ODL was expressed as a library that provides classes and functions to implement the concepts defined in the ODMG Object Model. The C++ OML syntax and semantics are those of standard C++ in the context of the standard class library. The C++ binding also provided a mechanism to invoke OQL. Smalltalk Language Binding. This defined the mapping between the ODMG ODL and Smalltalk, which was based on the OMG Smalltalk binding for the OMG Interface Definition Language (IDL). The Smalltalk binding also provided a mechanism to invoke OQL. Java Language Binding. This defined the binding between the ODMG ODL and the Java programming language as defined by the Java 2 Platform. The Java binding also provided a mechanism to invoke OQL. == Status == ODMG 3.0 was published in book form in 2000.[1] By 2001, most of the major object database and object-relational mapping vendors claimed conformance to the ODMG Java Language Binding. Compliance to the other components of the specification was mixed.[2] In 2001, the ODMG Java Language Binding was submitted to the Java Community Process as a basis for the Java Data Objects specification. The ODMG member companies then decided to concentrate their efforts on the Java Data Objects specification. As a result, the ODMG disbanded in 2001. In 2004, the Object Management Group (OMG) was granted the right to revise the ODMG 3.0 specification as an OMG specification by the copyright holder, Morgan Kaufmann Publishers. In February 2006, the OMG announced the formation of the Object Database Technology Working Group (ODBT WG) and plans to work on the 4th generation of an object database standard. == ODMG Compliant DBMS == Orient ODBMS: http://www.OrienTechnologies.com Objectivity/DB C++, Java and Smalltalk interfaces.
Pandemonium architecture
Pandemonium architecture is a theory in cognitive science that describes how visual images are processed by the brain. It has applications in artificial intelligence and pattern recognition. The theory was introduced by the artificial intelligence pioneer Oliver Selfridge in his 1959 paper "Pandemonium - A Paradigm for Learning". It describes the process of object recognition as the exchange of signals within a hierarchical system of detection and association, the elements of which Selfridge metaphorically termed "demons". This model is now recognized as the basis of visual perception in cognitive science. Pandemonium architecture arose in response to the inability of template matching theories to offer a biologically plausible explanation of the image constancy phenomenon. Contemporary researchers praise this architecture for its elegancy and creativity; that the idea of having multiple independent systems (e.g., feature detectors) working in parallel to address the image constancy phenomena of pattern recognition is powerful yet simple. The basic idea of the pandemonium architecture is that a pattern is first perceived in its parts before the "whole". Pandemonium architecture was one of the first computational models in pattern recognition. Although not perfect, the pandemonium architecture influenced the development of modern connectionist, artificial intelligence, and word recognition models. == History == Most research in perception has been focused on the visual system, investigating the mechanisms of how we see and understand objects. A critical function of our visual system is its ability to recognize patterns, but the mechanism by which this is achieved is unclear. The earliest theory that attempted to explain how we recognize patterns is the template matching model. According to this model, we compare all external stimuli against an internal mental representation. If there is "sufficient" overlap between the perceived stimulus and the internal representation, we will "recognize" the stimulus. Although some machines follow a template matching model (e.g., bank machines verifying signatures and accounting numbers), the theory is critically flawed in explaining the phenomena of image constancy: we can easily recognize a stimulus regardless of the changes in its form of presentation (e.g., T and T are both easily recognized as the letter T). It is highly unlikely that we have a stored template for all of the variations of every single pattern. As a result of the biological plausibility criticism of the template matching model, feature detection models began to rise. In a feature detection model, the image is first perceived in its basic individual elements before it is recognized as a whole object. For example, when we are presented with the letter A, we would first see a short horizontal line and two slanted long diagonal lines. Then we would combine the features to complete the perception of A. Each unique pattern consists of different combination of features, which means those that are formed with the same features will generate the same recognition. That is, regardless of how we rotate the letter A, is still perceived as the letter A. It is easy for this sort of architecture to account for the image constancy phenomena because you only need to "match" at the basic featural level, which is presumed to be limited and finite, thus biologically plausible. The best known feature detection model is called the pandemonium architecture. == Pandemonium architecture == The pandemonium architecture was originally developed by Oliver Selfridge in the late 1950s. The architecture is composed of different groups of "demons" working independently to process the visual stimulus. Each group of demons is assigned to a specific stage in recognition, and within each group, the demons work in parallel. There are four major groups of demons in the original architecture. The concept of feature demons, that there are specific neurons dedicated to perform specialized processing is supported by research in neuroscience. Hubel and Wiesel found there were specific cells in a cat's brain that responded to specific lengths and orientations of a line. Similar findings were discovered in frogs, octopuses and a variety of other animals. Octopuses were discovered to be only sensitive to verticality of lines, whereas frogs demonstrated a wider range of sensitivity. These animal experiments demonstrate that feature detectors seem to be a very primitive development. That is, it did not result from the higher cognitive development of humans. Not surprisingly, there is also evidence that the human brain possesses these elementary feature detectors as well. Moreover, this architecture is capable of learning, similar to a back-propagation styled neural network. The weight between the cognitive and feature demons can be adjusted in proportion to the difference between the correct pattern and the activation from the cognitive demons. To continue with our previous example, when we first learned the letter R, we know is composed of a curved, long straight, and a short angled line. Thus when we perceive those features, we perceive R. However, the letter P consists of very similar features, so during the beginning stages of learning, it is likely for this architecture to mistakenly identify R as P. But through constant exposure of confirming R's features to be identified as R, the weights of R's features to P are adjusted so the P response becomes inhibited (e.g., learning to inhibit the P response when a short angled line is detected). In principle, a pandemonium architecture can recognize any pattern. As mentioned earlier, this architecture makes error predictions based on the amount of overlapping features. Such as, the most likely error for R should be P. Thus, in order to show this architecture represents the human pattern recognition system we must put these predictions into test. Researchers have constructed scenarios where various letters are presented in situations that make them difficult to identify; then types of errors were observed, which was used to generate confusion matrices: where all of the errors for each letter are recorded. Generally, the results from these experiments matched the error predictions from the pandemonium architecture. Also as a result of these experiments, some researchers have proposed models that attempted to list all of the basic features in the Roman alphabet. == Criticism == A major criticism of the pandemonium architecture is that it adopts a completely bottom-up processing: recognition is entirely driven by the physical characteristics of the targeted stimulus. This means that it is unable to account for any top-down processing effects, such as context effects (e.g., pareidolia), where contextual cues can facilitate (e.g., word superiority effect: it is relatively easier to identify a letter when it is part of a word than in isolation) processing. However, this is not a fatal criticism to the overall architecture, because is relatively easy to add a group of contextual demons to work along with the cognitive demons to account for these context effects. Although the pandemonium architecture is built on the fact that it can account for the image constancy phenomena, some researchers have argued otherwise; and pointed out that the pandemonium architecture might share the same flaws from the template matching models. For example, the letter H is composed of 2 long vertical lines and a short horizontal line; but if we rotate the H 90 degrees in either direction, it is now composed of 2 long horizontal lines and a short vertical line. In order to recognize the rotated H as H, we would need a rotated H cognitive demon. Thus we might end up with a system that requires a large number of cognitive demons in order to produce accurate recognition, which would lead to the same biological plausibility criticism of the template matching models. However, it is rather difficult to judge the validity of this criticism because the pandemonium architecture does not specify how and what features are extracted from incoming sensory information, it simply outlines the possible stages of pattern recognition. But of course that raises its own questions, to which it is almost impossible to criticize such a model if it does not include specific parameters. Also, the theory appears to be rather incomplete without defining how and what features are extracted, which proves to be especially problematic with complex patterns (e.g., extracting the weight and features of a dog). Some researchers have also pointed out that the evidence supporting the pandemonium architecture has been very narrow in its methodology. Majority of the research that supports this architecture has often referred to its ability to recognize simple schematic drawings that are selected from a small finite set (e.g., letters in the Roman alphabet). Evidence from these types of exper
Software design
Software design is the process of conceptualizing how a software system will work before it is implemented or modified. Software design also refers to the direct result of the design process – the concepts of how the software will work which may be formally documented or may be maintained less formally, including via oral tradition. The design process enables a designer to model aspects of a software system before it exists with the intent of making the effort of writing the code more efficiently. Creativity, past experience, a sense of what makes "good" software, and a commitment to quality are success factors for a competent design. A software design can be compared to an architected plan for a house. High-level plans represent the totality of the house (e.g., a three-dimensional rendering of the house). Lower-level plans provide guidance for constructing each detail (e.g., the plumbing lay). Similarly, the software design model provides a variety of views of the proposed software solution. == Part of the overall process == In terms of the waterfall development process, software design is the activity that occurs after requirements analysis and before coding. Requirements analysis determines what the system needs to do without determining how it will do it, and thus, multiple designs can be imagined that satisfy the requirements. The design can be created while coding, without a plan or requirements analysis, but for more complex projects this is less feasible. Completing a design prior to coding allows for multidisciplinary designers and subject-matter experts to collaborate with programmers to produce software that is useful and technically sound. Sometimes, a simulation or prototype is created to model the system in an effort to determine a valid and good design. == Code as design == A common point of confusion with the term design in software is that the process applies at multiple levels of abstraction such as a high-level software architecture and lower-level components, functions and algorithms. A relatively formal process may occur at high levels of abstraction but at lower levels, the design process is almost always less formal where the only artifact of design may be the code itself. To the extent that this is true, software design refers to the design of the design. Edsger W. Dijkstra referred to this layering of semantic levels as the "radical novelty" of computer programming, and Donald Knuth used his experience writing TeX to describe the futility of attempting to design a program prior to implementing it: TEX would have been a complete failure if I had merely specified it and not participated fully in its initial implementation. The process of implementation constantly led me to unanticipated questions and to new insights about how the original specifications could be improved. == Artifacts == A design process may include the production of art Software design documentation such as flow chart, use case, Pseudocode, Unified Modeling Language model and other Fundamental modeling concepts. For user centered software, design may involve user experience design yielding a storyboard to help determine those specifications. Documentation may be reviewed to allow constraints, specifications and even requirements to be adjusted prior to coding. == Iterative design == Software systems inherently deal with uncertainties, and the size of software components can significantly influence a system's outcomes, both positively and negatively. Neal Ford and Mark Richards propose an iterative approach to address the challenge of identifying and right-sizing components. This method emphasizes continuous refinement as teams develop a more nuanced understanding of system behavior and requirements. The approach typically involves a cycle with several stages: A high-level partitioning strategy is established, often categorized as technical or domain-based. Guidelines for the smallest meaningful deployable unit, referred to as "quanta," are defined. While these foundational decisions are made early, they may be revisited later in the cycle if necessary. Initial components are identified based on the established strategy. Requirements are assigned to the identified components. The roles and responsibilities of each component are analyzed to ensure clarity and minimize overlap. Architectural characteristics, such as scalability, fault tolerance, and maintainability, are evaluated. Components may be restructured based on feedback from development teams. This cycle serves as a general framework and can be adapted to different domains. == Design principles == Design principles enable a software engineer to navigate the design process. Davis suggested principles which have been refined over time as: The design process should not suffer from "tunnel vision" A good designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job. The design should be traceable to the analysis model Because a single element of the design model can often be traced back to multiple requirements, it is necessary to have a means for tracking how requirements have been satisfied by the design model. The design should not reinvent the wheel Systems are constructed using a set of design patterns, many of which have likely been encountered before. These patterns should always be chosen as an alternative to reinvention. Time is short and resources are limited; design time should be invested in representing (truly new) ideas by integrating patterns that already exist (when applicable). The design should "minimize the intellectual distance" between the software and the problem as it exists in the real world That is, the structure of the software design should, whenever possible, mimic the structure of the problem domain. The design should exhibit uniformity and integration A design is uniform if it appears fully coherent. In order to achieve this outcome, rules of style and format should be defined for a design team before design work begins. A design is integrated if care is taken in defining interfaces between design components. The design should be structured to accommodate change The design concepts discussed in the next section enable a design to achieve this principle. The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered Well-designed software should never "bomb"; it should be designed to accommodate unusual circumstances, and if it must terminate processing, it should do so in a graceful manner. Design is not coding, coding is not design Even when detailed procedural designs are created for program components, the level of abstraction of the design model is higher than the source code. The only design decisions made at the coding level should address the small implementation details that enable the procedural design to be coded. The design should be assessed for quality as it is being created, not after the fact A variety of design concepts and design measures are available to assist the designer in assessing quality throughout the development process. The design should be reviewed to minimize conceptual (semantic) errors There is sometimes a tendency to focus on minutiae when the design is reviewed, missing the forest for the trees. A design team should ensure that major conceptual elements of the design (omissions, ambiguity, inconsistency) have been addressed before worrying about the syntax of the design model. == Design concepts == Design concepts provide a designer with a foundation from which more sophisticated methods can be applied. Design concepts include: Abstraction Reducing the information content of a concept or an observable phenomenon, typically to retain only information that is relevant for a particular purpose. It is an act of Representing essential features without including the background details or explanations. Architecture The overall structure of the software and the ways in which that structure provides conceptual integrity for a system. Good software architecture will yield a good return on investment with respect to the desired outcome of the project, e.g. in terms of performance, quality, schedule and cost. Control hierarchy A program structure that represents the organization of a program component and implies a hierarchy of control. Data structure Representing the logical relationship between elements of data. Design pattern A designer may identify a design aspect of the system that has solved in the past. The reuse of such patterns can increase software development velocity. Information hiding Modules should be specified and designed so that information contained within a module is inaccessible to other modules that have no need for such information. Modularity Dividing the solution into parts (modules). Refinement The process of elaboration. A hierarchy is developed by decomposing a macrosco
ShowScoop
ShowScoop is a website and mobile app platform on which users can rate and review artists, concerts, and music festivals that they have seen/attended. The reviews and ratings are designed to be informative of how well such performances are live. This helps concert-goers decide which live music events they want to attend. == History == ShowScoop was founded in August 2012 by Micah Smurthwaite and is based out of San Diego, CA. In February 2013, ShowScoop launched its mobile app at the SF Music Tech Summit. The application is currently available on the iPhone, with plans to expand into the Android market in the future. == Services == ShowScoop uses crowdsourcing to provide accurate ratings of live concert experiences. In addition to viewing ratings, users are encouraged to rate and review concerts they have attended. The ShowScoop database includes nearly one million artists and over 2.5 million live music events. ShowScoop users can rate artists on four aspects of the performance: stage presence, crowd interaction, sound quality, and visual effects. The rating system uses an ascending scale from one to five in each of the aspects, with five being the highest score. In addition to the quantitative ratings, ShowScoop users are also free to write qualitative reviews in a provided comment section. This allows users to explain their ratings and add further insight or opinion. ShowScoop incorporates several facets of social media into its services. Users can create a user profile to share limited personal information and store their ratings and reviews. Users are also given the option of sharing their evaluations with their social networks on Facebook and Twitter. Users can "like" reviews, follow artists, and follow other ShowScoop users. The mobile app allows users to take photos, apply filters, and share the final image in conjunction with reviews and through Instagram. == Road Crew == ShowScoop's "Road Crew" is a group made up of top contributors within the ShowScoop community. The Road Crew assists in curating artist pages, assuring information quality and accuracy. In return, members of the Road Crew are given incentives, including free tickets to concerts and personal invitations to exclusive shows. Applicants to the Road Crew are judged on the number and quality of their reviews, the photos and videos they have posted, and their general engagement with the ShowScoop community in following and liking users and reviews.
Tweak programming environment
Tweak is a graphical user interface (GUI) layer written by Andreas Raab for the Squeak development environment, which in turn is an integrated development environment based on the Smalltalk-80 computer programming language. Tweak is an alternative to an earlier graphic user interface layer called Morphic. Development began in 2001. Applications that use the Tweak software include Sophie (version 1), a multimedia and e-book authoring system, and a family of virtual world systems: Open Cobalt, Teleplace, OpenQwaq, 3d ICC's Immersive Terf and the Croquet Project. == Influences == An experimental version of Etoys, a programming environment for children, used Tweak instead of Morphic. Etoys was a major influence on a similar Squeak-based programming environment known as Scratch.
Groover
Groover is an online platform, record label and distributor, connecting artists and musicians with music professionals and media outlets. The service was founded in 2018 in France and operates from offices in Paris and New York. The platform has over 3,000 active contacts, including SPIN Magazine and Sofar Sounds. Groover uses a micro-payment model. Among the platform's over 500,000 regular users are record labels such as Ninja Tune, Ba Da Bing Records, Dance To The Radio, Roche Musique, Wagram Music, Secret City Records, and artists including Bonobo, Michael Bolton, Aloe Blacc, Haddaway, Passenger, La Femme and Chinese Man. == History == Groover was launched at the MaMA Music Convention in October 2018. It was co-founded by Dorian Perron, Romain Palmieri, and Rafaël Cohen while they were students at UC Berkeley. Initially growing in France, the company has expanded to the United States, Canada, the United Kingdom, Brazil, Italy, and elsewhere in Europe. In March 2019, Groover was part of the Business France delegation at the South by Southwest (SXSW) festival. In June 2019, Groover raised €1.3 million from various angel investors. In April 2021, Groover acquired the platform Soonvibes, which had 70,000 users at the time, in order to strengthen its community in the electronic music space. In November 2021, Groover announced a €6 million funding round from Bpifrance Creative Industries and Partech. Between 2023 and 2025, Groover entered strategic partnerships with major artist service providers, including CD Baby, TuneCore, SoundCloud, UnitedMasters, Symphonic Distribution, Audiomack and SACEM. In February 2024, Groover announced a Series A funding round of $8 million from OneRagTime, Trind, Techmind, and Mozza Angels. == Function == Using a micro-payment system, professionals listen to tracks and provide written feedback. These professionals retain full editorial independence and are under no obligation to share the track or contact the artist. == Awards == 2nd Prize for Music Innovation 2023 from the Centre national de la musique (France) "Future Creator" Award at the Petit Poucet Competition 2019 Jury's Special Mention at the MaMA Invent 2019 competition 1st Prize for Digital Initiative in Culture, Communication & Media 2019 awarded by Audiens "Start-up of the Year" at the Social Music Awards 2020 French American Entrepreneurship Award 2022 at the French Consulate in New York
Netvibes
Netvibes is a French brand of Dassault Systèmes that previously ran a web service offering a dashboard and feed reader. Currently, the company offers business intelligence tools. == History == === 2005–2012 === Founded in 2005 by Tariq Krim, the company provided software for personalized dashboards for real-time monitoring, social analytics, knowledge sharing, and decision support. === 2012–present === On February 9, 2012, Dassault Systèmes announced the acquisition of Netvibes. As of 2024, Netvibes also contains the operations of two other software companies acquired by Dassault Systèmes: Exalead: founded in 2000 by François Bourdoncle, the company provided search platforms and search-based applications for consumer and business users. On June 9, 2010, Dassault Systèmes acquired the company. Proxem: Founded in 2007 by François-Régis Caumartin, the company provided AI-powered semantic processing software and services. On June 23, 2020, Dassault Systèmes acquired Proxem and integrated its technology into the 3DEXPERIENCE® platform to complement its information intelligence applications. Dassault Systèmes announced in April 2025 that Netvibes would retire its standalone web service offering on June 2, 2025. == Activities == Brand monitoring – to track clients, customers and competitors across media sources all in one place, analyze live results with third party reporting tools, and provide media monitoring dashboards for brand clients. E-reputation management – to visualize real-time online conversations and social activity online feeds, and track new trending topics. Product marketing – to create interactive product microsites, with drag-and-drop publishing interface. Community portals – to engage online communities Personalized workspaces – to gather all essential company updates to support specific divisions (e.g. sales, marketing, human resources) and localizations. The software was a multi-lingual Ajax-based start page or web portal. It was organized into tabs, with each tab containing user-defined modules. Built-in Netvibes modules included an RSS/Atom feed reader, local weather forecasts, a calendar supporting iCal, bookmarks, notes, to-do lists, multiple searches, support for POP3, IMAP4 email as well as several webmail providers including Gmail, Yahoo! Mail, Hotmail, and AOL Mail, Box.net web storage, Delicious, Meebo, Flickr photos, podcast support with a built-in audio player, and several others. A page could be personalized further through the use of existing themes or by creating personal theme. Customized tabs, feeds and modules can be shared with others individually or via the Netvibes Ecosystem. For privacy reasons, only modules with publicly available content could be shared.