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