Domain Value

Some operational definitions: domain value describes any value used in DomainModelling. value describes anything for which an intrinsically complete representation can be provided in finite space and time. Some properties of values and domain values include immutability (of the value, not of the representation), intrinsic identity (ideally decidable), finite KolmogorovComplexity, and computability. Related concepts include DomainModel, ValueObject, DomainObject, ObjectIdentity (since DomainModelling often utilizes a concept of 'objects'), and MultiValuedLogic (most DomainModels inherit a set of values from a logic).

Sources of DomainValues include (but aren't necessarily limited to):

measurement - wavelengths, amplitudes, distances, temperatures, delta-time, geometries, topographies and relative positions, connectivity, masses, counts, etc. As a rule of thumb, measurements have units and limited precision or potential for inaccuracy. Fundamentally, these are 'initial' observations only with respect to a particular DomainModel: they are no less derived than any other DomainValue (indeed, they are usually derived from "more primitive" DomainModels, sometimes the implicit models we carry around in our heads that derive of our experience and use of language), yet they are often primitive in the sense that a given DomainModel will be capable of using these values but incapable of deriving all of them.
assignment - addresses, regions, phone numbers, latitude and longitude, date, names, ObjectIdentity, etc. Things assigned by human institutions rather than derived from other properties or provided by mother nature. These are almost always primitive DomainValues in the sense that, seeing as they are assigned externally, most DomainModels have little or no support for deriving them (except from other assigned values).
assumption - assumed defaults in the absence of extra information... e.g. when predicting the weather tomorrow, we assume there won't be a freak solar flare or massive meteoric impact. And when talking about birds, we often assume we're talking about the sort that can fly.
deduction - deductive application of DomainModel axioms to measured or assumed DomainValues will result in more DomainValues. Within the DomainModel, axioms are considered 'true'. In Science, they just haven't been falsified yet. Axioms that hold under great scrutiny are sometimes considered 'laws'.
induction and abduction - there are several forms of inference weaker than deduction and axioms. Primary among these are induction (which is based on strengthening or weakening of a conclusion based on combining evidence that is individually inconclusive)
scores - arithmetic combinations of other DomainValues and conditions over them (e.g. +1 if X, -1 if Y, *1.2 at the end if Z). Scores can be objective and automated, and will generally be somewhat arbitrary, but have proven repeatedly in practice to support effective prediction and planning. Scores can be made in multiple categories. Used as a tool in induction and abduction.
qualification - assigning truth values (from MultiValuedLogic) to properties; generally derived.
classification - related to scoring, but one ends with a class (e.g. a name for a color, a genus for a plant) instead of a number. Generally based on qualitative combinations rather than quantitative ones. A useful tool here is the Rubric.

In addition, one should consider MetaModels - or models of models. In the domain of MetaModels, components of models themselves become DomainValues, including: axioms and laws, Rubrics, systems of scoring, description of assumptions, mechanisms of assignment, and forms of measurement.

Sometimes we call arrangements of 'primitive' DomainValues "data" while we call the derived forms (from deduction, assumption, induction, scores, rubrics, etc.) "information". It's all derived, of course, but it is sometimes useful in discussion to note the relative 'level' of derivation. In a MetaModel we might call it all 'information', but assign each piece of information a few numbers based on how many 'steps' from 'initial' information it happens to be. These numbers, in a MetaModel, can be useful for limiting confidence in a deduction.

DomainModelling can be used for both analysis and synthesis, for both prediction and planning. For planning, we're interested in deriving DomainValues (e.g. arrangements of troops, or connectivity in a graph) necessary to achieve desirable properties (e.g. victory, failover redundancy). For prediction, we're interested in deriving future properties (e.g. victory, failover redundancy) from DomainValues (e.g. arrangement of troops, or connectivity in a graph). When it comes to PrimitivesAndMeansOfComposition in DomainModelling, it is very useful if the set of "properties" being planned for or predicted are themselves DomainValues; this property allows one to predict or plan multiple 'steps' forward since in each step you have DomainValues.

One might consider a ProgrammingLanguage as a modeling system in which synthesis of language structures is aimed to achieve particular properties. In this case the DomainValues would be the language structures. Relative to PrimitivesAndMeansOfComposition and the composition of models, one predicts it useful that arbitrary language structures can be composed to achieve new language structures - this is a property we on this wiki have described as SymmetryOfLanguage, and in CS in general we call 'FirstClass' those language structures that can be produced and composed in this manner. Of course, like all models, those written in a ProgrammingLanguage often becomes less reliable and more difficult to analyze, verify, and confirm as the compose new layers. Like DomainModels, programs need testing, analysis, and sometimes some optimization analogous to the sort we achieve by combining axioms into theorems.

A 'DomainSpecificLanguage' in this analogy is one that supports DomainValues (language structures, measurements) and embeds domain derivations (assumptions, axioms) targeted toward a specific domain or class of domains. A 'GeneralPurposeProgrammingLanguage' would be the MetaModel of programming language systems, and could probably be analyzed in terms of how readily one can construct domain models (perhaps as library APIs if not working with ExtensibleProgrammingLanguage) and how well one can compose different domain models (without invasively modifying their domain APIs or stumbling over CrossCuttingConcerns like mutexes, locking, logging, garbage collection, problematic inefficiencies, etc.).

In the RelationalModel, data is modeled as relationships between DomainValues, and RelationalModel models the data (not the domain). In this sense, RelationalModel is not domain specific.

In practice, most RDBMS technologies are limited to supporting DomainValues targeted towards 'typical' business applications such as customer and order databases. (This makes sense. They're paying for it.) Existing RDBMS technologies are too limited for efficient application in general science, math, and any sort of MetaModel application due the limitations imposed on DomainValues. This is not a fault of RelationalModel in general.

Related to this, there's been some ongoing combat in pages including CrossToolTypeAndObjectSharing, RelationalAndTrees, RelationalTreesAndGraphsDiscussion, and other pages regarding whether 'complex' domain values (such as geometries, topologies, graphs, and MetaModel DomainValues such as rules, axioms, propositions, assumptions, requests, permissions, etc.) should be represented in the manner specified by EfCodd, DateAndDarwen, et al. as DomainValues in a relationship, or be unfolded into external relations and referenced by use of surrogate keys. It isn't a HolyWar - as noted, it doesn't count as a HolyWar if it's just TopMind is HandWaving by himself against the world.

YOU are the handwaver, not me. You are vague, obtuse, and difficult.

You say that, but it's just more of your handwaving, this time with a bit of a temper-tantrum thrown in.

I find this definition vague. It needs a rework. Examples of domain values and non-domain values to compare would be helpful.

I do agree examples are helpful, and that's why I provided a list of examples: measures, scores, classifications, multi-valued logic, assignment, etc. You claim this 'vague'. I ask that you justify that claim rather than just asserting it.

I am willing to provide more specific examples.

Some DomainValues:

  3 meters (measure)
  2.95 meters plus or minus 5 centimeters with 95% confidence (measure)
  true   (logic value)
  7 cars (measure)
  6205 W. 115th Street  (assignment)
  TopMind (assignment)
  14/15 on Glasgow Coma Scale (score)
  1325 on SAT (score)
  homo sapiens (classification)
  crow (classification)
  thumb (classification)
  has thumb (qualification)
  chair-like (qualification)
  6"x12"x3" (measure, geometric domain)

DomainValues can be derived from axioms and assumptions, induction and abduction, scoring systems, etc. These assumptions and systems constitute the 'DomainModel'. Examples:

relativity physics axiom: E=mc^2 Newtonian physics axiom: F=ma typical assumption: if it's a bird it can fly typical assumption: chairs can be sat in detective's scoring system: means + motive + opportunity

There are, of course, an unlimited number of DomainModels. Some even prove to be useful.

Facts or Data:

'TopMind' is assigned to individual 'homo sapiens' TopMind has thumb TopMind scores 14/15 on Glasgow Coma Scale

Example derivations:

  'homo sapiens' generally qualify as having thumbs (induction)
  Conversing on Wiki requires Eyes, Verbal, Motor skills (induction)
  TopMind does not obey commands, and so loses point on GCS (scoring)
  TopMind member of 'homo sapiens' (questionable assumption)

Equally important, perhaps more so, and also requested above, are examples of "information" that is *not* a DomainValue. If no information is not a DomainValue, then we might as well call it "info" instead of some geekier term that will only serve to confuse. In other words, PrematureComplexity of terms.

Logically, you have that point reversed. There are infinite examples of DomainValues that are *not* "information", so one shouldn't indiscriminately call it all "info". A simple example of a value that is not information: 'true'.

Axioms, assumptions, rubrics, scoring systems, algorithms, etc. are also not "information"; they are parts of DomainModels, and DomainModels are more or less formal sets of prediction rules. It is information to know that a particular DomainModel is successful at making predictions about observations, but DomainModels themselves should be treated like prime numbers: each has some unique properties and common properties that distinguish them from other values, but there are infinite of them and simply because you're holding a DomainModel doesn't imply it is based on any observations.

Vice versa, by stratifying into a MetaModel, all forms of representable 'information' can be expressed as DomainValues by stratifying into the MetaModel. E.g. the relational schema models a particular domain with specific semantics for each tuple in each relation. The RelationalModel says that units of data are described as tuples in relations, and thus makes 'tuples' and 'relations' the DomainValues. A model of the RelationalModel is written in a logic that allows many variants... an 'implementation' of the RelationalModel, for example, is a model of the RelationalModel.

DomainValue is utilized relative to a given DomainModel. Confusion about stratification into the MetaModel is very rare in practice. Every 'value' is a value in at least one domain, but it is generally obvious which values aren't relevant in a given domain (e.g. we don't deal with "furious" and "angry" in the study of triangles). As with many other words, it would usually take a HumptyDumpty/DevilsAdvocate/sophist bastard to utterly ignore context and word-lawyer "DomainValue" in an active attempt to confuse the issue. My 'model' of the Internet tells me I can count on a few such guys hanging around any active forum, of course, but that doesn't reduce the value of the words to make useful distinctions.

As a final note, use of DomainModel, DomainValue, etc. were refined over several centuries. Calling it "PrematureComplexity of terms" is a statement made in ignorance of the processes and forces leading to the distinctions, a tad arrogant and disrespectful, and a few centuries late.

The above makes no sense, still. It's all relative anyhow.

The proper way to say that, TopMind, is "I can't make sense of the above". I suspect the problem is more your logic processing unit than what is written above, but I welcome second opinions.

[Here's a second opinion: The above is perfectly clear, albeit somewhat tainted with invective.]

I've seen good tech writing and poor tech writing. Yours is poor. If you are good at deciphering Rosetta's Blabber, good for you. Gold Star for your forehead. But I am not an archaeologist.
[I didn't write the above, but I do find it perfectly clear.]

Suppose I'm in a financial firm and I am studying to prediction accuracy of multiple stock analysts. I keep a table of predictions made by the analysis to use to compare to actual results. To me, these "predictions" are data just like any other data. My tools don't have to treat such info ANY DIFFERENT than any other "data". The distinction is relative. -t

[Huh? What does that have to do with the above?]

It implied that predictions are not DomainValues?.

[No, it didn't, at least not of the type of "prediction" you're referring to, which from your point of view is a measure or assignment. I think you've misunderstood the above.]

Again, please give me CLEAR examples of things that are NOT DomainValues?. No more HandWaving.

My Hyundai is not a DomainValue. The RAM in my computer is not a DomainValue. UnknowableNumbers aren't DomainValues. The definition at the top of the page is pretty clear; if you find yourself incapable of applying it, blame your rather silly tendency to dismiss distinctions you consider trivial simply because they aren't relevant to the viewpoint you're holding at the moment. ThingsThatAreDifferentAreNotTheSame.

TopMind said: My tools don't have to treat such info ANY DIFFERENT than any other "data". That is true: you don't need to treat "info" as separate from "data". But it seems you are assuming that just because you have a DomainValue, you also have "info" or "data". Not all DomainValues are data. Perhaps a Venn Diagram would help:

 ---------------------------------------------------
 | All computable values and value types...        | 
 |   includes non-digital types, such as analog    |  Non-computable/non-representable
 |   signals and quantum structures                |  constructs are out here...
 |                                                 |  infinite KolmogorovComplexity
 |  ---------------------------------------------  |  RicesTheorem, RussellParadox 
 |  |  All DomainValues (all values of          |  |  GoedelsIncompletenessTheorem
 |  |   types used in domain modelling, ever).  |  |  UnknowableNumbers
 |  |                 __________________________|__|___  ... and, of course, things in the
 |  |                [                          .  .   ] real world that aren't even value-like.
 |  |    ------------[----                      .  . U ] 
 |  |    |           [   |     One Logic Model  .  .   ]
 |  |    | Data      [ B |                      .  .   ]
 |  |    |      |---------------------|         .  .   ]
 |  |    |      | A  [ C |            |         .  .   ]
 |  |    -------|----[---- Theorems   |         .  .   ]
 |  |           |    [________________|_________.__.___]
 |  |           |  One DomainModel    |         |  |
 |  |           | (axioms,classes,etc)|         |  |
 |  |           |---------------------|         |  |
 |  |                                           |  |
 |  --------------------------------------------|  |
 |-------------------------------------------------|

Ignoring overlap...

'Data' refers to all possible data produced from observations, measurements, assignment, etc. and either stored someplace or in the act of transport from one place to another. The amount of 'Data' at any given moment in time is finite.
'Logic Model' is a system of MultiValuedLogic, variables, statements, and inference rules. A formal logic is a math or calculi, but not all logics are formal.
'Theorems' are things that are true if the DomainModel is accurate and the logic is consistent. These are thing things you can prove 'on paper' without ever making an empirical observation. Theorems include "hypotheses" that can be used to verify a DomainModel.
'DomainModel' includes axioms, classifications, assumptions, scoring mechanisms and rubrics, etc.
box 'U' contains things that can be described in the logic model, but that are meaningless (undecidable, divergent, paradoxes, undefined, unknowable values, etc.). These are problematic when implementing the Logic Model. Not all logics stretch into the undecidable.
box 'A' is that fraction of the Data that can be input into a particular DomainModel, but cannot be outputs from the DomainModel (i.e. "input-only" data).
box 'B' is the fraction of the Data that could be output from the Logic Model, but isn't used by the DomainModel. I.e. stuff from 'B' could be output by theorems in the DomainModel. Stuff from box 'B' could be inputs to another DomainModel that uses or overlaps the same Logic model.
box 'C' is the fraction of data that can be both input to the DomainModel and output from DomainModel theorems. It can be used in iterative (i.e. multi-step) predictions and planning. It is often favorable for box "C" to be fairly large.

Everything in the 'Data' box (including overlap with 'A', 'B', 'C') qualifies as "information", though some people prefer to further distinguish 'raw' Data (e.g. input streams from a sensor device) from Information by calling only "processed" stuff (theorem outputs found in boxes 'B' and 'C') "information". I don't care one way or the other, as I tend to view Data as a "flow" (as per DataflowProgramming, DataManipulation) rather than a static entity.

Everything outside the 'Data' box is not information. Axioms aren't information. Theorems aren't information. Logics aren't information. DomainModels aren't information. Since you like the word so much, it might help for you to think of it this way: Anything that can be produced by pure MentalMasturbation, without any inputs from the outside world, cannot possibly be information or data. Since one can invent DomainModels and Logic models on whim, those aren't information.

If I pull the number '7' out of my arse, the number 7 isn't information, even though it is a DomainValue. And if there is a number that nobody ever uses for the lifespan of this universe, that is also not information or data, but it is still a DomainValue. The fact that I pulled number '7' out of my arse, however, is information, since it says something about the world. Data that a particular DomainModel is correct 99% of the time is information.

Despite what you're thinking, tools do benefit from treating DomainValues as distinct from Data. The main difference between them: For DomainValues, you need operators, equality comparisons, conversions, serialization, storage, and GarbageCollection. If your tool is "general purpose" or "MetaModel" in nature, you additionally require expression support for a range of DomainValues wide enough to describe a Logic Model, Theorems, Axioms, Assumptions, Heuristics, Rubrics, Scoring systems, and user-defined types to support new classifications, new measurements, new assignments, etc. so that people can create entirely new DomainModels. Data, on the other hand, needs DataManipulation support, and will be described by the expression of of DomainValues in a MetaModel (such as the expression of a tuple in the RelationalModel of data).

I'd still like to see explicit examles of common computerized "stuff" that are not DomainValue's. The above is not clear enough to make the definition useful for IT work.

[Your sound card, display, keyboard and printer are not DomainValues. In the context of end-user applications, pointers are not DomainValues. The RelationalModel is notable in that it describes data purely in terms of relationships between DomainValues, but this purity may be compromised by the use of surrogate keys that have no reality outside of the information system. Such keys are not DomainValues; they are effectively pointers.]

The definition is fine, TopMind. If you can't make use of it, that's a statement about your incompetence, not the definition.

I guess I am just dumb. Bad broken toppie brain. The def looks like utter nonsense to me. We don't digitize keyboards. I mean stuff that is binary on disks and in RAM. Software. Your keyboard scenario is an example of a UselessTruth, just like the helicopter example.

[When someone doesn't understand something, it is helpful to explain even that which appears obvious, especially when they write general phrases like "common computerized 'stuff'". Keyboards are common computerized "stuff". I hope the explanation that pointers and surrogate keys are not domain values clarifies things. By the way, I'm not sure what you mean by "the helicopter example."]

Another approach that appears not in your documentation toolkit is to supply examples of what the questioner actually asked for to begin with.

[Sorry, I don't understand. You asked for "examles [sic] of common computerized 'stuff' that are not DomainValue's". I provided some. What's the problem?]

("Examles" are what doctors give to sick camels.)

"Computerized stuff" and "computer stuff" do not mean the same.

[Ah. I interpreted it in a very broad sense. You might have been clearer to ask for examples of common values that are not DomainValues.]

It would probably turn into a fight over the definition of "value". Thus, I avoided the word.

[In retrospect, you probably shouldn't have. Anyway, to me, "computerized stuff" implies things like mobile phones, fancy dishwashers with digital front-panels, automotive fuel-injection systems and the like, i.e., things with embedded CPUs. (They aren't DomainValues either, by the way.)]

I probably should have said "digitized". (When people say "you should computerize your accounting", usually they mean use software instead of paper and hand-calculators. I generally didn't associate it with "has a little CPU chip inside", but I suppose its possible to interpret it that way.) Now that that's out of the way, where's the examples?

[I gave you some examples: In the context of end-user applications, surrogate keys and pointers are not domain values.]
"In the context of" leaves too much wiggle room. The distinction between "pointer" and "ID" can be fuzzy, for example. A pointer can also serve as an ID, or is a "data value" to somebody working at a lower-level. It's all relative. You risk PrematureClassification?. Everything can be viewed as a pointer (or set membership). -t
[*Eyes roll*]

Of the things that are 'digitized', the ones most clearly not DomainValues are services and objects and anything else with extrinsic identity. Those aren't values at all (as noted in the opening, values have intrinsic identity and are intrinsically complete). Since they aren't values, they cannot be DomainValues. I cannot provide examples of the region outside 'DomainValue' and inside 'value'. That represents the pool of potential value types that don't yet have names or uses. That region is not empty, though. That can be proven non-constructively.

They don't yet have names? That is fishy.

More usefully, where 'DomainValue' is a useful distinction, is when discussing DomainValues relative to a given DomainModel. In this sense, surrogate keys between elements of the domain model (be they values or objects) are not themselves domain values. Nor are computation errors or evaluation forms in the logic model.

If you are truly confused on this issue, why don't you provide an example you think is problematic in actual application?

Content bickering aside, that's a nice diagram. Kudos! I'm afraid that TabMunging may mess it up some day though. A lot of my source code examples get munged over time. That's why I put dots instead of spaces. -t

[Don't you mean "constant bickering aside..."?]

(This text appears to have been inadvertently mis-inserted.)

Data - even data from box "C" - in general shouldn't be stored or encapsulated as part of the model (having it cached as part of the model's implementation is a different story).

MarchZeroNine