Data And Information

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 jargonInformation Oriented jargon ----------------------------------------------- problemgoal solveachieve solutionprogram servercomputer differentiatedistinguish differentiationdistinction ordered bitwise enumerationendeme column, memberfield, value table schemaEndemeSet

Data Oriented approachesInformation Oriented Approaches ------------------------------------------------------- identity PKGUID PK exception handlinglatent error detection default to nullspecified default value strong typingvalue interpretation objects, classes, membersloosely coupled fields UI code generatorstable, class, and field metadata ORM code generatorsgeneric classes information hidinginformation drill-down parameterized SQLdynamic SQL tables and objectstables and metadata enhanced lists single categories per itemmultiple categories per item conceptual decoratorsdata driven-combinations of concepts category membershipcategory ordering 1's and 0'srelative weightings One dimensional code formatTwo dimensional code format text filesSpreadsheets aspect oriented programmingcode that knows about itself self-documenting codeself-referential code large complex objectstoolbox of simple objects hierarchical pathsnon-hierarchical paths many relational tablesfew generic tables

Data Oriented UIInformation Oriented UI --------------------------------------- single-selectmulti-select errors cause exceptionserrors are ignored precise data formatssituational data interpreters UI displaying data elementsUI representing information structures Application defined searchUser defined search Category based searchkeyword based search one standardized UIuser specific/adjustable UI's

Higher level Data OrientationHigher Level Information Orientation ----------------------------------------------------------------- structured datasemantic relationships horizontal layered architecturevertical metadata controlled architecture integrated silosuniversal information metadata hierarchynetwork object oriented patternsOWL information proxiesdata proxies project stage specializationproject domain synergy/specialization Users specify UI preciselyUsers specify middle tier precisely networking objectsimported data interpretations CSV, XML, JSONLists of values with universal field descriptors relational databaseendematic infobase XML with schemasXML without schemas UI converts data to informationmiddle tier works with information directly

front and back end drivenmiddle tier driven ------------------------------------------- UI and DB based specificationsmiddle tier based specifications

the middle tier is gluethe front and back ends between the frontare outgrowths and the back endsof the middle tier

Data Oriented GoalsInformation Oriented Goals --------------------------------------------- Never impreciseGraceful degradation Highly tested systemHighly flexible system High performanceHigh usefulness StandardizedAd 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