Quote from AntC on May 27, 2021, 6:41 am

Quote from tobega on May 27, 2021, 4:56 am

emptify(R) could be defined as being the smallest value D of all the "empties" where D InnerUnion R = R and the smallest D where D NatJoin R = D. Having a hard time formulating this exactly, but I think that's right now.

That's where this whole thread got stuck. You mean "smallest" in the sense of least in the lattice ordering induced by NatJoin? The smallest d where d NatJoin r = d is d = Dumpty, i.e. lattice bottom, which in general will have a wider heading than r's.

If you'd grok lattices, you'd notice the consequence of NatJoin and InnerUnion being 'dual's, which is that

• d InnerUnion r = r ≡ d NatJoin r = d for all r, d. So your proposal places no restriction on either.

Another possibly helpful thing, if it is needed, could be to specify the mirroring (isomorphism? homomorphism? I forget) property of emptify, such that emptify(R) NatJoin emptify(S) = emptify(R NatJoin S) and so on.

Writing emptify( r ) as r NatJoin DUM (and I can't find any way that isn't equivalent to that):

• (r NatJoin DUM) NatJoin (s NatJoin DUM) ≡ (r NatJoin s) NatJoin DUM for all r, s. Follows from the equational properties of NatJoin: it is idempotent, associative. So that's already provable.

Whatever is "humanist" about your mathematics, all maths needs the cold hard logic of equational reasoning. Tautologies/equivalences might be occasionally surprising, but they never produce decidability out of an undecidable starting position.

 

Quote from tobega on May 27, 2021, 1:13 pm

Quote from AntC on May 27, 2021, 6:41 am

Quote from tobega on May 27, 2021, 4:56 am

emptify(R) could be defined as being the smallest value D of all the "empties" where D InnerUnion R = R and the smallest D where D NatJoin R = D. Having a hard time formulating this exactly, but I think that's right now.

That's where this whole thread got stuck. You mean "smallest" in the sense of least in the lattice ordering induced by NatJoin? The smallest d where d NatJoin r = d is d = Dumpty, i.e. lattice bottom, which in general will have a wider heading than r's.

If you recall, I reversed your ordering because it makes more sense that the set of relations of a smaller heading actually is referred to as being smaller. You may find things go smoother if you try to assume that other people actually make sense instead of always assuming the opposite. I assume you should be intelligent enough to work it out.

If you'd grok lattices, you'd notice the consequence of NatJoin and InnerUnion being 'dual's, which is that

• d InnerUnion r = r ≡ d NatJoin r = d for all r, d. So your proposal places no restriction on either.

Another possibly helpful thing, if it is needed, could be to specify the mirroring (isomorphism? homomorphism? I forget) property of emptify, such that emptify(R) NatJoin emptify(S) = emptify(R NatJoin S) and so on.

Writing emptify( r ) as r NatJoin DUM (and I can't find any way that isn't equivalent to that):

• (r NatJoin DUM) NatJoin (s NatJoin DUM) ≡ (r NatJoin s) NatJoin DUM for all r, s. Follows from the equational properties of NatJoin: it is idempotent, associative. So that's already provable.

Whatever is "humanist" about your mathematics, all maths needs the cold hard logic of equational reasoning. Tautologies/equivalences might be occasionally surprising, but they never produce decidability out of an undecidable starting position.

 

The main point is to try a different approach and NOT to specify emptify in terms of DUM.

I realize, though, that the definitions I proposed probably end up specifying the identity function. That could perhaps be rectified by also specifying that emptify(DEE) is not equal to DEE.

 

Quote from tobega on June 14, 2021, 6:44 pm

Thought I'd spend a few more moments on this and the concept of an empty relation seems to be rather elusive if we just go with some set of elements and the NatJoin and InnerUnion operators. (Can we perhaps call these objects "relational lattices"?)

It struck me that most relational lattices don't even contain DUM. To illustrate, consider all relations that only have attribute A. Further, restrict that to all relations that contain the tuple where A=a. Actually, we don't even need to add DEE, we have absorption of NatJoin in ({A=a}) and absorption of InnerUnion in the relation containing tuples for all possible values of A.

There are just so many weird sets of elements that fulfil the rules. Consider the set of the relations for all false predicates containing attribute A. Absorption of InnerUnion in the empty relation with heading {A} and absorption of NatJoin in DUMPTY.

Quote from AntC on June 14, 2021, 11:55 pm

Quote from tobega on June 14, 2021, 6:44 pm

Thought I'd spend a few more moments on this and the concept of an empty relation seems to be rather elusive

Do you mean "empty relation" as in no tuples? Or as in 'empty heading'?

• "empty relation" is an empty set. What's elusive about that? The set of Polar bears in Antarctica. The set of Penguins in Arctica.
• There's two relation values with empty heading: one is also empty of tuples (aka DUM); one isn't empty of tuples (aka DEE).

if we just go with some set of elements and the NatJoin and InnerUnion operators.

See 'relationally complete' here; or Appendix A page 7 'Closing Remarks'; or pretty much any text book on relational theory. To be adequate to express all possible queries, you need MINUS or NOT MATCHING or equivalent: then consider r NOT MATCHING r for any r in the set of elements; the given set of elements must include that result. To be adequate to express all possible queries, you need projection or REMOVE/ALL BUT or equivalent: then consider 'Are there any Polar bears in Canada?', 'Are there any Parts in Rome?', etc; note this is not asking to identify the bears or the Parts.

If you have InnerUnion, consider REL{TUP{ A a }} InnerUnion REL{TUP{ B b }};: what's the heading for that?

(Can we perhaps call these objects "relational lattices"?)

No.

It struck me that most relational lattices don't even contain DUM.

All relational lattices contain DUM. There might be arbitrary sets of relation values that don't contain DUM; you might be able to construct a lattice over them; that's a lattice-of-relations, not a "relational lattice".

To illustrate, consider all relations that only have attribute A.

How are you going to build a Supplier-and-Parts database with only a single attribute? Or an Employees-and-Departments database?

Further, restrict that to all relations that contain the tuple where A=a.

Ok let's say Aa := REL{TUP{ A a }}; What's the result of Aa NOT MATCHING Aa?

Actually, we don't even need to add DEE, we have absorption of NatJoin in ({A=a}) and absorption of InnerUnion in the relation containing tuples for all possible values of A.

There are just so many weird sets of elements that fulfil the rules.

What you've described doesn't fulfil the rules.

Consider the set of the relations for all false predicates containing attribute A. Absorption of InnerUnion in the empty relation with heading {A}

An empty relation with heading A doesn't "contain the tuple where A=a". But your premiss was "all relations" contain that. Contradiction.

and absorption of NatJoin in DUMPTY.

You started "consider all relations that only have attribute A." So what heading does DUMPTY have? And is it also lacking "the tuple where A=a"? That looks like two contradictions.

Quote from tobega on June 15, 2021, 4:57 am

Quote from AntC on June 14, 2021, 11:55 pm

Quote from tobega on June 14, 2021, 6:44 pm

Thought I'd spend a few more moments on this and the concept of an empty relation seems to be rather elusive

Do you mean "empty relation" as in no tuples? Or as in 'empty heading'?

• "empty relation" is an empty set. What's elusive about that? The set of Polar bears in Antarctica. The set of Penguins in Arctica.
• There's two relation values with empty heading: one is also empty of tuples (aka DUM); one isn't empty of tuples (aka DEE).

if we just go with some set of elements and the NatJoin and InnerUnion operators.

See 'relationally complete' here; or Appendix A page 7 'Closing Remarks'; or pretty much any text book on relational theory. To be adequate to express all possible queries, you need MINUS or NOT MATCHING or equivalent: then consider r NOT MATCHING r for any r in the set of elements; the given set of elements must include that result. To be adequate to express all possible queries, you need projection or REMOVE/ALL BUT or equivalent: then consider 'Are there any Polar bears in Canada?', 'Are there any Parts in Rome?', etc; note this is not asking to identify the bears or the Parts.

You are absolutely correct concerning the thing you want to model. I am talking about your mathematical model, which by my observations, also models a lot of things we don't want to model. So, unless you put in rules that mandate the existence of the necessary structure, your model will not necessarily reflect what you expect.

If you have InnerUnion, consider REL{TUP{ A a }} InnerUnion REL{TUP{ B b }};: what's the heading for that?

What is the rule that says the model contains either of those two things in the first place? You don't define either tuples or attributes.

 

(Can we perhaps call these objects "relational lattices"?)

No.

It struck me that most relational lattices don't even contain DUM.

All relational lattices contain DUM. There might be arbitrary sets of relation values that don't contain DUM; you might be able to construct a lattice over them; that's a lattice-of-relations, not a "relational lattice".

Fair enough, I am talking of "lattice-of-relations" then, which is what the model is unless you specify enough structure.

To illustrate, consider all relations that only have attribute A.

How are you going to build a Supplier-and-Parts database with only a single attribute? Or an Employees-and-Departments database?

Further, restrict that to all relations that contain the tuple where A=a.

Ok let's say Aa := REL{TUP{ A a }}; What's the result of Aa NOT MATCHING Aa?

What's your definition of "NOT MATCHING" in the model? You may obviously not reference anything that hasn't been defined or inferred to exist, like tuples, or DUM.

Actually, we don't even need to add DEE, we have absorption of NatJoin in ({A=a}) and absorption of InnerUnion in the relation containing tuples for all possible values of A.

There are just so many weird sets of elements that fulfil the rules.

What you've described doesn't fulfil the rules.

Depends on the rules. As far as I've seen them detailed, it does, but please tell me the rule in your logic model that it doesn't fit so we can make progress.

Consider the set of the relations for all false predicates containing attribute A. Absorption of InnerUnion in the empty relation with heading {A}

An empty relation with heading A doesn't "contain the tuple where A=a". But your premiss was "all relations" contain that. Contradiction.

Sorry, forgot to put the "2." to make it more obvious that this is a different case. I thought "the set of all false predicates" was clear enough of a difference to the previous statement, especially after I had mentioned a multiplicity of weird sets.

and absorption of NatJoin in DUMPTY.

You started "consider all relations that only have attribute A." So what heading does DUMPTY have? And is it also lacking "the tuple where A=a"? That looks like two contradictions.

In this case, the same one as always, all possible attributes, no tuples.

Quote from AntC on June 16, 2021, 2:33 am

Quote from tobega on June 15, 2021, 4:57 am

Quote from AntC on June 14, 2021, 11:55 pm

Quote from tobega on June 14, 2021, 6:44 pm

Thought I'd spend a few more moments on this and the concept of an empty relation seems to be rather elusive

Do you mean "empty relation" as in no tuples? Or as in 'empty heading'?

• "empty relation" is an empty set. What's elusive about that? The set of Polar bears in Antarctica. The set of Penguins in Arctica.
• There's two relation values with empty heading: one is also empty of tuples (aka DUM); one isn't empty of tuples (aka DEE).

if we just go with some set of elements and the NatJoin and InnerUnion operators.

See 'relationally complete' here; or Appendix A page 7 'Closing Remarks'; or pretty much any text book on relational theory. To be adequate to express all possible queries, you need MINUS or NOT MATCHING or equivalent: then consider r NOT MATCHING r for any r in the set of elements; the given set of elements must include that result. To be adequate to express all possible queries, you need projection or REMOVE/ALL BUT or equivalent: then consider 'Are there any Polar bears in Canada?', 'Are there any Parts in Rome?', etc; note this is not asking to identify the bears or the Parts.

You are absolutely correct concerning the thing you want to model. I am talking about your mathematical model, which by my observations, also models a lot of things we don't want to model. So, unless you put in rules that mandate the existence of the necessary structure, your model will not necessarily reflect what you expect.

I am modelling relations as defined in TTM (particularly RM Pre 9, 10). I expect that to include DUM, DEE: RM Pro 5:

5. D shall not forget that relations with no attributes are respectable and interesting, ...

I haven't "put in rules" over and above TTM Prescriptions. RM Pre 10.b. says the body of a relation is a set. Inevitably that allows a relation with empty body -- unless I "put in rules" to ban that. I expect to model relations with empty body -- for example a relation that identifies all Polar bears in Antarctica.

RM Pre 9. says a heading is a set. Inevitably that allows a relation with empty heading -- unless I "put in rules" to ban that. Furthermore since I have chosen to model using lattice algebra, I must model the value that is Identity for NatJoin -- that is, DEE. Inevitably I must model the relation value with same heading as DEE but empty body -- that is, DUM.

I'm modelling NatJoin is defined in Appendix A 'FORMAL DEFINITIONS` <AND>. I'm modelling NOT MATCHING and other operators as defined in 'HOW Tutorial D BUILDS ON A'.

I'm modelling exactly what I expect. "your model will not necessarily reflect what you expect" is vague and unhelpful waffle. Can you point something specific that is a consequence of my rules but which is not what expected? More hand-waving is not an answer.

 

If you have InnerUnion, consider REL{TUP{ A a }} InnerUnion REL{TUP{ B b }};: what's the heading for that?

What is the rule that says the model contains either of those two things in the first place? You don't define either tuples or attributes.

 

(Can we perhaps call these objects "relational lattices"?)

No.

It struck me that most relational lattices don't even contain DUM.

All relational lattices contain DUM. There might be arbitrary sets of relation values that don't contain DUM; you might be able to construct a lattice over them; that's a lattice-of-relations, not a "relational lattice".

Fair enough, I am talking of "lattice-of-relations" then, which is what the model is unless you specify enough structure.

No. A "lattice-of-relations" exhibits more restrictive structure than the TTM model: you'll need to say how/why certain values are excluded (such as those with empty heading). You'll have to identify the identity value for NatJoin, and demonstrate that it is unique.

To illustrate, consider all relations that only have attribute A.

How are you going to build a Supplier-and-Parts database with only a single attribute? Or an Employees-and-Departments database?

Further, restrict that to all relations that contain the tuple where A=a.

Ok let's say Aa := REL{TUP{ A a }}; What's the result of Aa NOT MATCHING Aa?

What's your definition of "NOT MATCHING" in the model? You may obviously not reference anything that hasn't been defined or inferred to exist, like tuples, or DUM.

Actually, we don't even need to add DEE, we have absorption of NatJoin in ({A=a}) and absorption of InnerUnion in the relation containing tuples for all possible values of A.

There are just so many weird sets of elements that fulfil the rules.

What you've described doesn't fulfil the rules.

Depends on the rules. As far as I've seen them detailed,

This thread has made many references to TTM rules, and to Appendix A. If you haven't "seen them detailed" is that because you haven't read those documents, or because you don't understand them? Specifically, this is the TTM forum. I expect all participants to understand TTM -- which is not to say "to agree with" it on all points.

 

Quote from tobega on June 16, 2021, 4:48 am

Quote from AntC on June 16, 2021, 2:33 am

Quote from tobega on June 15, 2021, 4:57 am

Quote from AntC on June 14, 2021, 11:55 pm

Quote from tobega on June 14, 2021, 6:44 pm

Thought I'd spend a few more moments on this and the concept of an empty relation seems to be rather elusive

Do you mean "empty relation" as in no tuples? Or as in 'empty heading'?

• "empty relation" is an empty set. What's elusive about that? The set of Polar bears in Antarctica. The set of Penguins in Arctica.
• There's two relation values with empty heading: one is also empty of tuples (aka DUM); one isn't empty of tuples (aka DEE).

if we just go with some set of elements and the NatJoin and InnerUnion operators.

See 'relationally complete' here; or Appendix A page 7 'Closing Remarks'; or pretty much any text book on relational theory. To be adequate to express all possible queries, you need MINUS or NOT MATCHING or equivalent: then consider r NOT MATCHING r for any r in the set of elements; the given set of elements must include that result. To be adequate to express all possible queries, you need projection or REMOVE/ALL BUT or equivalent: then consider 'Are there any Polar bears in Canada?', 'Are there any Parts in Rome?', etc; note this is not asking to identify the bears or the Parts.

You are absolutely correct concerning the thing you want to model. I am talking about your mathematical model, which by my observations, also models a lot of things we don't want to model. So, unless you put in rules that mandate the existence of the necessary structure, your model will not necessarily reflect what you expect.

I am modelling relations as defined in TTM (particularly RM Pre 9, 10). I expect that to include DUM, DEE: RM Pro 5:

5. D shall not forget that relations with no attributes are respectable and interesting, ...

I haven't "put in rules" over and above TTM Prescriptions. RM Pre 10.b. says the body of a relation is a set. Inevitably that allows a relation with empty body -- unless I "put in rules" to ban that. I expect to model relations with empty body -- for example a relation that identifies all Polar bears in Antarctica.

RM Pre 9. says a heading is a set. Inevitably that allows a relation with empty heading -- unless I "put in rules" to ban that. Furthermore since I have chosen to model using lattice algebra, I must model the value that is Identity for NatJoin -- that is, DEE. Inevitably I must model the relation value with same heading as DEE but empty body -- that is, DUM.

I'm modelling NatJoin is defined in Appendix A 'FORMAL DEFINITIONS` <AND>. I'm modelling NOT MATCHING and other operators as defined in 'HOW Tutorial D BUILDS ON A'.

I'm modelling exactly what I expect. "your model will not necessarily reflect what you expect" is vague and unhelpful waffle. Can you point something specific that is a consequence of my rules but which is not what expected? More hand-waving is not an answer.

 

If you have InnerUnion, consider REL{TUP{ A a }} InnerUnion REL{TUP{ B b }};: what's the heading for that?

What is the rule that says the model contains either of those two things in the first place? You don't define either tuples or attributes.

 

(Can we perhaps call these objects "relational lattices"?)

No.

It struck me that most relational lattices don't even contain DUM.

All relational lattices contain DUM. There might be arbitrary sets of relation values that don't contain DUM; you might be able to construct a lattice over them; that's a lattice-of-relations, not a "relational lattice".

Fair enough, I am talking of "lattice-of-relations" then, which is what the model is unless you specify enough structure.

No. A "lattice-of-relations" exhibits more restrictive structure than the TTM model: you'll need to say how/why certain values are excluded (such as those with empty heading). You'll have to identify the identity value for NatJoin, and demonstrate that it is unique.

To illustrate, consider all relations that only have attribute A.

How are you going to build a Supplier-and-Parts database with only a single attribute? Or an Employees-and-Departments database?

Further, restrict that to all relations that contain the tuple where A=a.

Ok let's say Aa := REL{TUP{ A a }}; What's the result of Aa NOT MATCHING Aa?

What's your definition of "NOT MATCHING" in the model? You may obviously not reference anything that hasn't been defined or inferred to exist, like tuples, or DUM.

Actually, we don't even need to add DEE, we have absorption of NatJoin in ({A=a}) and absorption of InnerUnion in the relation containing tuples for all possible values of A.

There are just so many weird sets of elements that fulfil the rules.

What you've described doesn't fulfil the rules.

Depends on the rules. As far as I've seen them detailed,

This thread has made many references to TTM rules, and to Appendix A. If you haven't "seen them detailed" is that because you haven't read those documents, or because you don't understand them? Specifically, this is the TTM forum. I expect all participants to understand TTM -- which is not to say "to agree with" it on all points.

 

Your mathematical model of TTM will only model exactly what you define with the definitions and logical requirements you put into it. If you put in too few definitions, your model will reflect not only TTM but also a lot of other things. Logic/mathematics cannot tell that you intended something different or more.

So if you take the set consisting of just DEE, for example, or one of these I have described, which of your rules prohibits that from being the universe of values being considered in the mathematics of your model?

In TTM, the universe of values is very clearly defined. So far I believe you have said that you don't define either attributes or tuples in your model. So what rules introduce the required structure? What rules prohibit your model from also depicting a set (closed under your operations) such as I have described?

Quote from AntC on June 16, 2021, 6:30 am

Quote from tobega on June 16, 2021, 4:48 am

Quote from AntC on June 16, 2021, 2:33 am

Quote from tobega on June 15, 2021, 4:57 am

Quote from AntC on June 14, 2021, 11:55 pm

Quote from tobega on June 14, 2021, 6:44 pm

Thought I'd spend a few more moments on this and the concept of an empty relation seems to be rather elusive

Do you mean "empty relation" as in no tuples? Or as in 'empty heading'?

• "empty relation" is an empty set. What's elusive about that? The set of Polar bears in Antarctica. The set of Penguins in Arctica.
• There's two relation values with empty heading: one is also empty of tuples (aka DUM); one isn't empty of tuples (aka DEE).

if we just go with some set of elements and the NatJoin and InnerUnion operators.

See 'relationally complete' here; or Appendix A page 7 'Closing Remarks'; or pretty much any text book on relational theory. To be adequate to express all possible queries, you need MINUS or NOT MATCHING or equivalent: then consider r NOT MATCHING r for any r in the set of elements; the given set of elements must include that result. To be adequate to express all possible queries, you need projection or REMOVE/ALL BUT or equivalent: then consider 'Are there any Polar bears in Canada?', 'Are there any Parts in Rome?', etc; note this is not asking to identify the bears or the Parts.

You are absolutely correct concerning the thing you want to model. I am talking about your mathematical model, which by my observations, also models a lot of things we don't want to model. So, unless you put in rules that mandate the existence of the necessary structure, your model will not necessarily reflect what you expect.

I am modelling relations as defined in TTM (particularly RM Pre 9, 10). I expect that to include DUM, DEE: RM Pro 5:

5. D shall not forget that relations with no attributes are respectable and interesting, ...

I haven't "put in rules" over and above TTM Prescriptions. RM Pre 10.b. says the body of a relation is a set. Inevitably that allows a relation with empty body -- unless I "put in rules" to ban that. I expect to model relations with empty body -- for example a relation that identifies all Polar bears in Antarctica.

RM Pre 9. says a heading is a set. Inevitably that allows a relation with empty heading -- unless I "put in rules" to ban that. Furthermore since I have chosen to model using lattice algebra, I must model the value that is Identity for NatJoin -- that is, DEE. Inevitably I must model the relation value with same heading as DEE but empty body -- that is, DUM.

I'm modelling NatJoin is defined in Appendix A 'FORMAL DEFINITIONS` <AND>. I'm modelling NOT MATCHING and other operators as defined in 'HOW Tutorial D BUILDS ON A'.

I'm modelling exactly what I expect. "your model will not necessarily reflect what you expect" is vague and unhelpful waffle. Can you point something specific that is a consequence of my rules but which is not what expected? More hand-waving is not an answer.

 

If you have InnerUnion, consider REL{TUP{ A a }} InnerUnion REL{TUP{ B b }};: what's the heading for that?

What is the rule that says the model contains either of those two things in the first place? You don't define either tuples or attributes.

 

(Can we perhaps call these objects "relational lattices"?)

No.

It struck me that most relational lattices don't even contain DUM.

All relational lattices contain DUM. There might be arbitrary sets of relation values that don't contain DUM; you might be able to construct a lattice over them; that's a lattice-of-relations, not a "relational lattice".

Fair enough, I am talking of "lattice-of-relations" then, which is what the model is unless you specify enough structure.

No. A "lattice-of-relations" exhibits more restrictive structure than the TTM model: you'll need to say how/why certain values are excluded (such as those with empty heading). You'll have to identify the identity value for NatJoin, and demonstrate that it is unique.

To illustrate, consider all relations that only have attribute A.

How are you going to build a Supplier-and-Parts database with only a single attribute? Or an Employees-and-Departments database?

Further, restrict that to all relations that contain the tuple where A=a.

Ok let's say Aa := REL{TUP{ A a }}; What's the result of Aa NOT MATCHING Aa?

What's your definition of "NOT MATCHING" in the model? You may obviously not reference anything that hasn't been defined or inferred to exist, like tuples, or DUM.

Actually, we don't even need to add DEE, we have absorption of NatJoin in ({A=a}) and absorption of InnerUnion in the relation containing tuples for all possible values of A.

There are just so many weird sets of elements that fulfil the rules.

What you've described doesn't fulfil the rules.

Depends on the rules. As far as I've seen them detailed,

This thread has made many references to TTM rules, and to Appendix A. If you haven't "seen them detailed" is that because you haven't read those documents, or because you don't understand them? Specifically, this is the TTM forum. I expect all participants to understand TTM -- which is not to say "to agree with" it on all points.

 

Your mathematical model of TTM will only model exactly what you define with the definitions and logical requirements you put into it.

Yes. It's a model. That's what 'model' means in a mathematical sense.

I see no point in continuing this vacuous discussion.

If you put in too few definitions, your model will reflect not only TTM but also a lot of other things. Logic/mathematics cannot tell that you intended something different or more.

So if you take the set consisting of just DEE, for example,

... then I'm bound to include also DUM. DEE is a non-empty set. The definitions in TTM require also including all possible bodies for that heading. To put it in terms of operations: the result from DEE NOT MATCHING DEE. To put it in terms of lattices: to count as a lattice needs at least two elements; and specifically a bounded lattice needs both a top and bottom, IOW an identity and an absorbing element for the 'meet' operation aka NaturalJoin.

or one of these I have described, which of your rules prohibits that from being the universe of values being considered in the mathematics of your model?

In TTM, the universe of values is very clearly defined. So far I believe you have said that you don't define either attributes or tuples in your model. So what rules introduce the required structure? What rules prohibit your model from also depicting a set (closed under your operations) such as I have described?

I've said all along the lattice structure is modelling TTM-defined relations. The 'rules' of the lattice are lattice rules -- as per wikipedia, for example.

"such as [you] have described" is not coherent -- either as a lattice structure, or as a set of TTM-style relation values. I'd go so far as to say you've failed to describe anything as exhibiting a structure. This isn't a case of 'Neurodiversity'. You seem to lack the mental furniture.

Quote from tobega on June 16, 2021, 8:05 pm

Quote from AntC on June 16, 2021, 6:30 am

Quote from tobega on June 16, 2021, 4:48 am

Quote from AntC on June 16, 2021, 2:33 am

Quote from tobega on June 15, 2021, 4:57 am

Quote from AntC on June 14, 2021, 11:55 pm

Quote from tobega on June 14, 2021, 6:44 pm

Thought I'd spend a few more moments on this and the concept of an empty relation seems to be rather elusive

Do you mean "empty relation" as in no tuples? Or as in 'empty heading'?

• "empty relation" is an empty set. What's elusive about that? The set of Polar bears in Antarctica. The set of Penguins in Arctica.
• There's two relation values with empty heading: one is also empty of tuples (aka DUM); one isn't empty of tuples (aka DEE).

if we just go with some set of elements and the NatJoin and InnerUnion operators.

See 'relationally complete' here; or Appendix A page 7 'Closing Remarks'; or pretty much any text book on relational theory. To be adequate to express all possible queries, you need MINUS or NOT MATCHING or equivalent: then consider r NOT MATCHING r for any r in the set of elements; the given set of elements must include that result. To be adequate to express all possible queries, you need projection or REMOVE/ALL BUT or equivalent: then consider 'Are there any Polar bears in Canada?', 'Are there any Parts in Rome?', etc; note this is not asking to identify the bears or the Parts.

You are absolutely correct concerning the thing you want to model. I am talking about your mathematical model, which by my observations, also models a lot of things we don't want to model. So, unless you put in rules that mandate the existence of the necessary structure, your model will not necessarily reflect what you expect.

I am modelling relations as defined in TTM (particularly RM Pre 9, 10). I expect that to include DUM, DEE: RM Pro 5:

5. D shall not forget that relations with no attributes are respectable and interesting, ...

I haven't "put in rules" over and above TTM Prescriptions. RM Pre 10.b. says the body of a relation is a set. Inevitably that allows a relation with empty body -- unless I "put in rules" to ban that. I expect to model relations with empty body -- for example a relation that identifies all Polar bears in Antarctica.

RM Pre 9. says a heading is a set. Inevitably that allows a relation with empty heading -- unless I "put in rules" to ban that. Furthermore since I have chosen to model using lattice algebra, I must model the value that is Identity for NatJoin -- that is, DEE. Inevitably I must model the relation value with same heading as DEE but empty body -- that is, DUM.

I'm modelling NatJoin is defined in Appendix A 'FORMAL DEFINITIONS` <AND>. I'm modelling NOT MATCHING and other operators as defined in 'HOW Tutorial D BUILDS ON A'.

I'm modelling exactly what I expect. "your model will not necessarily reflect what you expect" is vague and unhelpful waffle. Can you point something specific that is a consequence of my rules but which is not what expected? More hand-waving is not an answer.

 

If you have InnerUnion, consider REL{TUP{ A a }} InnerUnion REL{TUP{ B b }};: what's the heading for that?

What is the rule that says the model contains either of those two things in the first place? You don't define either tuples or attributes.

 

(Can we perhaps call these objects "relational lattices"?)

No.

It struck me that most relational lattices don't even contain DUM.

All relational lattices contain DUM. There might be arbitrary sets of relation values that don't contain DUM; you might be able to construct a lattice over them; that's a lattice-of-relations, not a "relational lattice".

Fair enough, I am talking of "lattice-of-relations" then, which is what the model is unless you specify enough structure.

No. A "lattice-of-relations" exhibits more restrictive structure than the TTM model: you'll need to say how/why certain values are excluded (such as those with empty heading). You'll have to identify the identity value for NatJoin, and demonstrate that it is unique.

To illustrate, consider all relations that only have attribute A.

How are you going to build a Supplier-and-Parts database with only a single attribute? Or an Employees-and-Departments database?

Further, restrict that to all relations that contain the tuple where A=a.

Ok let's say Aa := REL{TUP{ A a }}; What's the result of Aa NOT MATCHING Aa?

What's your definition of "NOT MATCHING" in the model? You may obviously not reference anything that hasn't been defined or inferred to exist, like tuples, or DUM.

Actually, we don't even need to add DEE, we have absorption of NatJoin in ({A=a}) and absorption of InnerUnion in the relation containing tuples for all possible values of A.

There are just so many weird sets of elements that fulfil the rules.

What you've described doesn't fulfil the rules.

Depends on the rules. As far as I've seen them detailed,

This thread has made many references to TTM rules, and to Appendix A. If you haven't "seen them detailed" is that because you haven't read those documents, or because you don't understand them? Specifically, this is the TTM forum. I expect all participants to understand TTM -- which is not to say "to agree with" it on all points.

 

Your mathematical model of TTM will only model exactly what you define with the definitions and logical requirements you put into it.

Yes. It's a model. That's what 'model' means in a mathematical sense.

I see no point in continuing this vacuous discussion.

If you put in too few definitions, your model will reflect not only TTM but also a lot of other things. Logic/mathematics cannot tell that you intended something different or more.

So if you take the set consisting of just DEE, for example,

... then I'm bound to include also DUM. DEE is a non-empty set. The definitions in TTM require also including all possible bodies for that heading. To put it in terms of operations: the result from DEE NOT MATCHING DEE. To put it in terms of lattices: to count as a lattice needs at least two elements; and specifically a bounded lattice needs both a top and bottom, IOW an identity and an absorbing element for the 'meet' operation aka NaturalJoin.

I'm not sure anything of what you're saying here is relevant. What forces you to include DUM? DEE NatJoin DEE is DEE, DEE InnerUnion DEE is DEE, all the math works beautifully. If you do require two elements, have you specified a model rule for that? Even if you have, I have also provided sets of infinite number of elements that do not contain either DEE or DUM as we know them that remain closed under our operations and have both a lattice top and a lattice bottom.

or one of these I have described, which of your rules prohibits that from being the universe of values being considered in the mathematics of your model?

In TTM, the universe of values is very clearly defined. So far I believe you have said that you don't define either attributes or tuples in your model. So what rules introduce the required structure? What rules prohibit your model from also depicting a set (closed under your operations) such as I have described?

I've said all along the lattice structure is modelling TTM-defined relations. The 'rules' of the lattice are lattice rules -- as per wikipedia, for example.

"such as [you] have described" is not coherent -- either as a lattice structure, or as a set of TTM-style relation values. I'd go so far as to say you've failed to describe anything as exhibiting a structure. This isn't a case of 'Neurodiversity'. You seem to lack the mental furniture.

You're right, in this case neurodiversity has nothing to do with it. Your need to resort to ad hominem attacks proves something, and I don't think it's me or my intelligence it reflects poorly on.

Go ahead, try your operations on my proposed sets and everything should just work. And if they don't you should be able to say which rule is contradicted. I'm not sure I have all your definitions taken into account if you've added any beyond NatJoin and InnerUnion.

How do you define "NOT MATCHING" in your model? Once we've established that, we can just perform the operations (within the model) on one of my sets and see what the result is. Without knowing that definition I can only say what we would like it to be, not what it actually is according to the model.

Now the existence of multiple universes of values, even strange ones, is not necessarily a problem, they will still behave the right way and the correct relational universe will also be modelled well enough.

The fact that there is a set of values that work with the model where the value we think of as DEE does not exist is not a problem as long as there exists some element that works like we expect DEE to work. That would still be lattice top (or is it bottom, the choice is really arbitrary).

When the model applies to sets that don't contain DUM, then we can't say that the model contains DUM. Again this is not necessarily a problem if we can find some element that acts like DUM, but the question is how. Have you been able to prove a unique DUM yet?

If you haven't, the following could possibly work: define the function called emptify that distributes over both NatJoin and InnerUnion such that emptify(emptify(A)) = emptify(A). Now state that emptify(DEE) = DUM and DUM != DEE. I don't know if we can say anything more interesting that doesn't already follow from the specified rules.