Quote from Dave Voorhis on December 2, 2021, 11:44 am

Quote from Paul Vernon on December 2, 2021, 10:59 am

Over in another thread the following comment was made

Quote from Dave Voorhis on December 1, 2021, 10:19 pm

Quote from Paul Vernon on December 1, 2021, 8:49 pm

In a database system ... the goal should be (in my opinion anyway) about "modelling reality" (maybe "reality as perceived" if you prefer)...

I've argued here before that database systems are fundamentally about modelling data, which is not quite the same thing as modelling reality. ...

I agree.

The study of "what is reality" is known as Ontology. I've often thought database practitioners (including myself) have much to learn from this branch of philosophy.

I suggest that database systems are fundamentally about "managing the gap" between what we can reasonably store as information (i.e. ultimately as bits and bytes) and about what "really exists". So yes, modelling data is what data/database people do, and that is indeed not quite the same as modelling reality.

One way to judge the quality of a data model is to contemplate how close it is to some "reality model". The practice of data modelling is to have some idea of the reality you are interested in, and then choose the appropriate information that can reasonably be captured and stored to "represent" the things in that reality.

Ontologically, I am (as I understand) best conceived as a 4-dimensional extent of space-time. Any attempt to directly store  information corresponding the the whole of that extent is inconceivable, hence we use things like my name, my "national identity number", my fingerprint and such like to represent me (or part of me).

The question from the other thread - about when is a difference a logical difference vs an irrelevant difference - is maybe really a philosophical question. I.e. is there any ontological difference between the integer 2 and the rational 2 (or the rational {²⁄₁,⁴⁄₂,⁶⁄₃...} if you prefer to make explicit the difference in the "construction") ?

Ontologically, the number 2 is (as I understand) best conceived as the set of all sets of two things. For a data model, we would not represent a number 2 as the (infinite) set of all sets of two things, that would be unreasonable. We pick a symbol such as 2.

I don't think that a philosopher (do we have any on board?) would say that in reality there are two number 2's. One that is an integer and one that is a rational (not to mention the 2 that is a natural and the 2 that is a real etc).

If "in reality" there are not two number 2's, we should not have two number 2's in our data models.

Ontologically, and philosophically, perhaps not.

Practically, we want to avoid accidentally joining, multiplying, whatever-ing, say, invoice number (which might be 2) by/with the quantity of products ordered (which might be 2.)

Quote from Paul Vernon on December 2, 2021, 12:22 pm

Quote from Dave Voorhis on December 2, 2021, 11:44 am

Quote from Paul Vernon on December 2, 2021, 10:59 am

If "in reality" there are not two number 2's, we should not have two number 2's in our data models.

Ontologically, and philosophically, perhaps not.

Practically, we want to avoid accidentally joining, multiplying, whatever-ing, say, invoice number (which might be 2) by/with the quantity of products ordered (which might be 2.)

Agreed.

And I think that creating a type called "invoice number" and a type called "quantity" (or "quantity of product"), is not the only way to avoid such accidents.

I suspect that there are other ways, and that those other ways might actually be better than building too closely on top of the concept of types.

Of course, your next question should be (unless you have some proof that types are the only possible way): how might such another way work?

...

Quote from Dave Voorhis on December 2, 2021, 12:58 pm

Quote from Paul Vernon on December 2, 2021, 12:22 pm

Quote from Dave Voorhis on December 2, 2021, 11:44 am

Quote from Paul Vernon on December 2, 2021, 10:59 am

If "in reality" there are not two number 2's, we should not have two number 2's in our data models.

Ontologically, and philosophically, perhaps not.

Practically, we want to avoid accidentally joining, multiplying, whatever-ing, say, invoice number (which might be 2) by/with the quantity of products ordered (which might be 2.)

Agreed.

And I think that creating a type called "invoice number" and a type called "quantity" (or "quantity of product"), is not the only way to avoid such accidents.

I suspect that there are other ways, and that those other ways might actually be better than building too closely on top of the concept of types.

Of course, your next question should be (unless you have some proof that types are the only possible way): how might such another way work?

...

There are undoubtedly innumerable ways they may work, but they are all effectively different types in a type system -- as are all such "these kinds of things work together in this way, whilst those kinds of things cannot (or work in that way)" mechanisms -- even if nominally not defined that way.

Quote from Paul Vernon on December 2, 2021, 1:05 pm

Quote from Dave Voorhis on December 2, 2021, 12:58 pm

There are undoubtedly innumerable ways they may work, but they are all effectively different types in a type system -- as are all such "these kinds of things work together in this way, whilst those kinds of things cannot (or work in that way)" mechanisms -- even if nominally not defined that way.

Without showing another way, I can't effectively argue against that point. Certainly other ways might look very much like a "type system" - the requirements of safety are the same, so any solutions are going to - at some level of abstraction - look quite similar. However I would ultimately still say that a 2 is a 2 is a 2 and not rely on the "inherent" typing of values such as 2:invoice-number and 2:quantity-of-product . I.e. I would use attribute names not (only) attribute values to determine what is safe and what it not

Quote from Dave Voorhis on December 2, 2021, 2:55 pm

Quote from Paul Vernon on December 2, 2021, 1:05 pm

Quote from Dave Voorhis on December 2, 2021, 12:58 pm

There are undoubtedly innumerable ways they may work, but they are all effectively different types in a type system -- as are all such "these kinds of things work together in this way, whilst those kinds of things cannot (or work in that way)" mechanisms -- even if nominally not defined that way.

Without showing another way, I can't effectively argue against that point. Certainly other ways might look very much like a "type system" - the requirements of safety are the same, so any solutions are going to - at some level of abstraction - look quite similar. However I would ultimately still say that a 2 is a 2 is a 2

Do you mean 2 the literal?

Or 2 the value?

and not rely on the "inherent" typing of values such as 2:invoice-number and 2:quantity-of-product . I.e. I would use attribute names not (only) attribute values to determine what is safe and what it not

That's (probably closest to) nominal typing, which is effectively what most popular programming languages use. https://en.wikipedia.org/wiki/Nominal_type_system

Compare with structural typing (https://en.wikipedia.org/wiki/Structural_type_system) which usually includes nominal elements, as in Tutorial D. In particular, scalars are nominally typed whilst relations and tuples are structurally typed.

Quote from Paul Vernon on December 2, 2021, 5:50 pm

Quote from Dave Voorhis on December 2, 2021, 2:55 pm

Quote from Paul Vernon on December 2, 2021, 1:05 pm

However I would ultimately still say that a 2 is a 2 is a 2

Do you mean 2 the literal?

Or 2 the value?

Both. One literal = one value.

I.e. 2 the value is 2 the literal. Value = literal. I don't really need both terms - they have no logical difference (or, at least, they are isomorphic in the context I'm interested in...).

As simple as possible?

Quote from Dave Voorhis on December 2, 2021, 7:10 pm

Quote from Paul Vernon on December 2, 2021, 5:50 pm

Quote from Dave Voorhis on December 2, 2021, 2:55 pm

Quote from Paul Vernon on December 2, 2021, 1:05 pm

However I would ultimately still say that a 2 is a 2 is a 2

Do you mean 2 the literal?

Or 2 the value?

Both. One literal = one value.

I.e. 2 the value is 2 the literal. Value = literal. I don't really need both terms - they have no logical difference (or, at least, they are isomorphic in the context I'm interested in...).

As simple as possible?

Sure, that's fine. Various languages define all literals to denote one type to which they belong.

Quote from dandl on December 3, 2021, 12:23 am

Quote from Paul Vernon on December 2, 2021, 12:22 pm

Quote from Dave Voorhis on December 2, 2021, 11:44 am

Quote from Paul Vernon on December 2, 2021, 10:59 am

If "in reality" there are not two number 2's, we should not have two number 2's in our data models.

Ontologically, and philosophically, perhaps not.

Practically, we want to avoid accidentally joining, multiplying, whatever-ing, say, invoice number (which might be 2) by/with the quantity of products ordered (which might be 2.)

Agreed.

And I think that creating a type called "invoice number" and a type called "quantity" (or "quantity of product"), is not the only way to avoid such accidents.

I suspect that there are other ways, and that those other ways might actually be better than building too closely on top of the concept of types.

Of course, your next question should be (unless you have some proof that types are the only possible way): how might such another way work?

...

Ok, paper tiger time.

Take the numbers 17 and 24. To me, these are old friends. 17 is prime, 1001 in binary, 11 hex, two digits, square is 289, oldest you can be and can't vote, youngest age to learn to drive, counting number after 16 and before 18, the name of various books and films, MIG 17, T17 tank, , etc. 24 is two dozen, factors are 2,3,4,6,8,12, 4 six-packs in a carton, between 23 and 25, square is 576, 11000 in binary, 30 octal, three 17s are 51, three 24s are 72, etc, etc. [And there are some maths features, but we don't talk about them.]

There there is 87413.366. Nothing special, just a sequence of digits with a dot in it, but it looks like something I could do maths with if I wanted to.

IOW numbers, like everything else I know about, is just a tag but it comes with lots of useful baggage. 17 and 24 are not values of a type, they are entities in their own right with their own attributes and features.

Forget maths, wrong starting point. Maths is a purely artificial construct that (mysteriously) turns out to be useful, except when it isn't. No maths. Also no hardware, no bits, no 'performance' concerns.

Think brain, associations, algorithms, processes, patterns, tags, connections, etc.

FWIW my view is that there is a whole new kind of brain-like software waiting to be invented, and it's built on quite different principles. For now, values and types are the only way we know.

Quote from Paul Vernon on December 3, 2021, 10:40 am

Quote from dandl on December 3, 2021, 12:23 am

17 and 24 are not values of a type, they are entities in their own right with their own attributes and features.

Yes. That has been my point in the Which type? topic.  17 is a value full stop. It does not "carry with it", even conceptually, some identification of the type to which it belongs.

It is not the type of a value that is important, it is the name we associate with a value that gives its meaning. So, using ordered pairs (i.e. attributes - which I write as name:value), your examples above (well some of) become

{ prime:17
, "oldest (age in years) you can be and can't vote":17
, "youngest age (in years) to learn to drive":17
, "counting number after 16 and before 18":17
, "between 23 and 25":24
}

Some of  your examples don't use the values 17 or 24 and some do that arguably should not. To take the latter point, it would probably better to have the following attributes with a value of 17 years not the value of 17. I.e.:

{ "oldest age you can be and can't vote":17 years
, "youngest age to learn to drive":17 years
}

Where the value 17 years is (logically) a different value than 17.

Well actually I would like a system that can (automatically) recognise that {"oldest age you can be and can't vote":17 years} and {"oldest age in years you can be and can't vote":17} are (to a greater or lesser extent) equivalent.

Which is another way of me saying that I don't agree with the position that attribute names are arbitrary placeholders and that all meaning should be deferred to predicates... but hey that really is another topic.

---

as to the point that 17 is 10001 in binary and 11 in hex. Yes that is true. Still I equate representation with value, so for me "1001 in binary" would be a value such as 10001b and "11 in hex" would be a say x11. Then you could have records such as

  { "Equivalent Thing":10001b, "Thing":17 }
, { "Equivalent Thing":x11   , "Thing":17 }

I.e at best 1001b and 17 are equivalent (for some definition of equivalent). What they most certainly are not is the same. Not the same, not equal.

Like 17 , seventeen, Seventeen, dix-sept, XVII , MIG 17  all can be considered equivalent to some degree (well, I'ld argue about MIG 17), but certainly none are the same value - if you equate representation with value, which I do and I think is the (only) sensible way to go about things