Real information is imprecise by nature. It has no natural order. It is what customers really want. It makes a difference to them. Real information is not just a name or a number or a date. It is a pattern within that data. Or real information can be the context of that data. Real information is what requirements are built from. Real information can be stored in an Information Data Structure and can be used to build Representational User Interfaces.
-- Jon Grover
Please provide an example.
Some examples of the use of real information would be:
'which employees would fit which job functions best?' (conclusions using real information)
'what are the technical support levels of resistance in a particular stock?' (real information)
'what are the relative characteristics of various investment opportunities for a venture capital company?' (conclusions using real information)
'what factors are most important when identifying how to improve quality of patient care?' (conclusions using real information)
'what colors work well together and what colors don't in a user interface?' (conclusions using real information)
'what are the characteristics of the colors that do and don't work well together?' (real information)
'what are the financial relationships among various different people and organizations?' (real information)
Some of the items on this list are real information directly and some are very close results of using real information.
Aren't these examples of questions or queries, rather than Real Information? What does Real Information look like?
I think information can be described with questions. This may be a good way of labeling a piece of real information. Under Information Data Structures, I have listed three labels for examples. The information data structure I have the most experience with is the one I have been researching which I describe as the Concept Permutation Emergent Property Structure which I call an Endeme Set. I have put one example on that page.
It's true that information can be described or labeled with questions, but that isn't the Real Information itself, is it? What does the Real Information itself look like?
Here is one piece of information using the Business Talent Endeme Set: businesstalent:CRDGBMLQVHFJNOAEPUSTKI - This is my personal Endeme for Business Talent --Jon Grover
One has to be careful about managing derived information in such a way that timeliness, concurrency, Ac Id, etc. are sufficiently addressed. Are the results stored/cached, or merely the specification (query)? There is already something common that readily supplies something like the above: Microsoft Access Queries. They are just not defined in English. Maybe Pro Log if you want something a bit more fancy.
One of the characteristics of information is that it is not guaranteed to meet the Ac Id test. Information is designed metaphorically like a Gray Code. In the information realm, small inconsistencies produce small variations. Whereas in the data realm small inconsistencies produce large variations. this is why Ac Id is critical when working with data and non-critical with information. This is a significant difference between Real Data and Real Information.
[Everything past the sensors is derived. ;-) Reactive Programming and Dataflow Programming models are quite promising for these goals; cf. Functional Reactive Programming or Reactive Demand Programming.]
Information is just the data you're looking for. If you're looking for edges in a picture, then placement of edges is 'information'. The choice of 'humans' as the only agency for whom information becomes 'real' seems quite arbitrary. No matter which level, the difficulty is in extracting relevant information from a poorly organized sea of inconsistent data.
One of the characteristics of information in the Information Vs Data comparison is that frequently the same query can be used and useful for multiple users when working with data, but with information, most users will need different queries.
The boundary between "structured" and "unstructured" is blurry. Ideally all information would be "structured", or at least properly labeled or categorized or marked with Meta Data to assist with automated searching, viewing, and/or processing of such data. However, it's often not deemed economical to fully "tag" information such that it's left as-is or under-categorized. If you mean "users don't want to bother classifying/tagging information", of course they don't. But if you want automation to assist you in using the info, it's a necessary chore. Trade-offs trade-offs, AKA Gi Go. I would suggest changing the title to Unstructured Information, because "real" implies the alternative is "fake" or useless. -t
The alternative to Real Information is data. I am using the term Real Information because people often mistake data for information. There is nothing fake, worthless or wrong with data, it just isn't information. A table of data selected from a database is data. I do need a term something like Real Data though as the counterpoint to Real Information
I am open to a better term than Real Information.
Data isn't information? That's a heavy claim. And customers don't "really want" unstructured data, as the opening implies. They want information in a format THEY like, be that heavily formatted or descriptive. Ideally they want GIWO - Garbage in, wonderful (stuff) out. But that's not realistic. The universe tends to toward Gi Go.
See original on c2.com 