The art of information: In the olden days, programmers mixed information and data orientation. Knowing when to use one or the other was an art form. More recently, most information orientation has been thrown out and the industry has moved solidly toward data orientation. This is good in that mixing the two approaches causes problems. There is really code that should be data oriented only. This is bad in that information orientation is useful and valuable and makes some goals/problems much easier to achieve/solve. Data orientation has become strong enough by itself to support an information oriented software development layer on top of it. -------------------------------------------------------------------- Lexicon of roughly equivalent Data and information oriented concepts Data Oriented jargon Information Oriented jargon -------------------- --------------------------- problem goal solve achieve solution program server computer differentiate distinguish differentiation distinction ordered bitwise enumeration endeme column, member field, value table schema EndemeSet Data Oriented approaches Information Oriented Approaches ------------------------ ------------------------------- identity PK GUID PK exception handling latent error detection default to null specified default value strong typing value interpretation objects, classes, members loosely coupled fields UI code generators table, class, and field metadata ORM code generators generic classes information hiding information drill-down parameterized SQL dynamic SQL tables and objects tables and metadata enhanced lists single categories per item multiple categories per item conceptual decorators data driven-combinations of concepts category membership category ordering 1's and 0's relative weightings One dimensional code format Two dimensional code format text files Spreadsheets aspect oriented programming code that knows about itself self-documenting code self-referential code large complex objects toolbox of simple objects hierarchical paths non-hierarchical paths many relational tables few generic tables Data Oriented UI Information Oriented UI ---------------- ----------------------- single-select multi-select errors cause exceptions errors are ignored precise data formats situational data interpreters UI displaying data elements UI representing information structures Application defined search User defined search Category based search keyword based search one standardized UI user specific/adjustable UI's Higher level Data Orientation Higher Level Information Orientation ----------------------------- ------------------------------------ structured data semantic relationships horizontal layered architecture vertical metadata controlled architecture integrated silos universal information metadata hierarchy network object oriented patterns OWL information proxies data proxies project stage specialization project domain synergy/specialization Users specify UI precisely Users specify middle tier precisely networking objects imported data interpretations CSV, XML, JSON Lists of values with universal field descriptors relational database endematic infobase XML with schemas XML without schemas UI converts data to information middle tier works with information directly front and back end driven middle tier driven ------------------------- ------------------ UI and DB based specifications middle tier based specifications the middle tier is glue the front and back ends between the front are outgrowths and the back ends of the middle tier Data Oriented Goals Information Oriented Goals ------------------- -------------------------- Never imprecise Graceful degradation Highly tested system Highly flexible system High performance High usefulness Standardized Ad Hoc There is nothing that says that data and information oriented approaches can not be mixed. Many projects can benefit from the concepts in both columns. -- JonGrover 'Should this page be called DataAndInformationOrientation instead?' It occurs to me that DataOriented techniques in an InformationOriented system often look like an AntiPattern, and InformationOriented techniques in a DataOriented system also often look like an AntiPattern. ''How do you define "data"? How do you define "information"?'' RealInformation and RealData are hard to define as the discussions on those pages indicate. For me it is sort of a sense that this kind of programming is InformationOriented, and that kind of programming is DataOriented. I don't have a good definition because it is sort of an intuitive sense I have. RealInformation tends to make more sense to users and RealData tends to make more sense to programmers. The basis of my intuitive sense is that I have been working with EndemeSet s for a couple of decades now, and I sort of get an Information or a Data CodeSmell when I am working in one or the other realm. Information smells different than data. Wikipedia http://en.wikipedia.org/wiki/Information has a good article on information which goes what information is better than I can. Other sites that try to get at the difference are http://www.diffen.com/difference/Data_vs_Information and http://www.differencebetween.info/difference-between-data-and-information. This page attempts to get at the difference by showing differences in implementation and thinking between the two realms. ''It sounds like your distinctions -- like all I've seen that try to distinguish "data" from "information" -- are personal and artistic rather than objective and scientific. What is the theoretical basis for your EndemeSet?'' I have just added this to the EndemeSet page: An endeme set is a list of concepts that can be combined in any order. The order is important. Order indicates priority, priority indicates importance, importance implies meaningfulness. When meaning is applied to something that is a form of information. Therefore an endeme set is a schema for an endeme, and an endeme is an atomic unit of information. This is as close as I have been able to get to a theoretical underpinning for an endeme set. ''That's not a theoretical underpinning, that's a description with some rationale. A theoretical underpinning is a logical and mathematical basis that imparts rigour. For example, the theoretical basis for the RelationalModel is SetTheory and FirstOrderLogic.'' Information is not rigourous, nor is it a branch of mathematics. It is a branch of business or philosophy. My thesis is that an EndemeSet implements an atomic unit of information. The Informatics world is a practical application of technology to people's needs for information. My practical work has identified areas where an information oriented mindset can save money, and provide better value to companies, users, and customers. Projects that were once too expensive for a small company can now be achieved using endeme sets. As a result there is significant low hanging fruit for a business to profit from once we start using endemes. You can take endemes to your employer and if you see a good use for them you can provide valuable software functionality to them and their customers that you could not before. You can benefit by using this new primitive type and so can your customers. This page is one part of teaching people how to learn the InformationOriented mindset by showing a list of things that tend more toward one or the other mindset. You can benefit if you want to learn this. ''How does your approach compare to or relate to the RelationalModel, SqlLanguage, ObjectOriented modelling, and semantic modelling in general?'' Relational modeling, SQL language and ObjectOriented modeling are DataOriented, whereas SemanticModelling is InformationOriented. This has to do with differences in the implementation of the 'contexts' inherent in the models. Relational and object oriented models provide context for each data element however the context is implemented in a way that is very hard to change - columns of tables, and members of classes. Whereas semantic models are more often soft-coded. Relationships among nodes in a semantic web are considered data and artifacts are not produced in code that define these relationships. Instead, programs are written to used the relationships that reside in data somewhere rather than to implement those relationships themselves. ---- CategoryInformationOrientation