Real Information

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 InformationDataStructure and can be used to build RepresentationalUserInterfaces.

-- JonGrover

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 RealInformation? What does RealInformation look like?

I think information can be described with questions. This may be a good way of labeling a piece of real information. Under InformationDataStructures, 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 ConceptPermutationEmergentPropertyStructure which I call an EndemeSet. 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 RealInformation itself, is it? What does the RealInformation itself look like?

Here is one piece of information using the BusinessTalentEndemeSet: businesstalent:CRDGBMLQVHFJNOAEPUSTKI - This is my personal Endeme for BusinessTalent? --JonGrover

One has to be careful about managing derived information in such a way that timeliness, concurrency, AcId, 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: MicrosoftAccess Queries. They are just not defined in English. Maybe ProLog if you want something a bit more fancy.

One of the characteristics of information is that it is not guaranteed to meet the AcId test. Information is designed metaphorically like a GrayCode. In the information realm, small inconsistencies produce small variations. Whereas in the data realm small inconsistencies produce large variations. this is why AcId is critical when working with data and non-critical with information. This is a significant difference between RealData and RealInformation.

[Everything past the sensors is derived. ;-) ReactiveProgramming and DataflowProgramming models are quite promising for these goals; cf. FunctionalReactiveProgramming or ReactiveDemandProgramming.]

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 InformationVsData 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 MetaData 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 GiGo. I would suggest changing the title to UnstructuredInformation?, because "real" implies the alternative is "fake" or useless. -t

The alternative to RealInformation is data. I am using the term RealInformation 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 RealData though as the counterpoint to RealInformation

I am open to a better term than RealInformation.

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 GiGo.

CategoryInformation, CategoryInformationOrientation