Re: [ontolog-forum] Prospects made into Customers and Vice Versa

[Thomas Johnston <tmj44p@xxxxxxx>]

Response to Pat's Comment

Are there time-varying sets, in the sense of sets whose membership varies over time? Of course not. And so, although I never said that the term "time-varying set" referred to the notion of a set whose membership varied over time, it is certainly easy to read the term that way. So I spoke carelessly, and I apologize for that.

I seem to recall adopting the term "time-varying set" from Chris Date. That doesn't legitimate the term, but it may explain why it came to mind as I wrote my comment. And the fact that an important author in the field of relational databases also uses the term suggests that there is something that he, like I, think that the term might usefully be referring to.

In my case, as indicated in my reply to John Sowa in this same thread, I think the term is a reasonable one to be used to refer to a specific temporal sequence of sets. The idea is that each transformation of (update to) a relational table puts that table in a new state; and it is each of those states that is a set, and the temporal sequence of those sets that I used the term "time-varying set" to refer to.

I expressed this idea much more clearly in my reply to John Sowa in this thread, written at close to the same time as my reply to Pat. Here's a summary statement of what I said:

(i) A table in a relational database is a time-varying object.

(ii) A transformation to the contents of a table (i.e. an insert, update or delete) replaces the current state of the table with a different state.

(iii) Each of those states is a set – specifically a subset of the Cartesian Product of the ordered set of sets which makes up the columns of the table.

(iv) At any point in time in the life-history of a table, it is in one and only one state; it physically realizes one and only one set.

(v) The temporally-ordered sequence of those states, then, constitutes the life-history of that table. (This temporally-ordered sequence is not itself a set, because the same set may occur in the sequence at multiple non-contiguous periods of time.)

(vi) I used the name "time-varying set" to refer to that temporal sequence of sets.

(vii) What relates the sets in each of these "time-varying sets"? If we use the Principle of Extension, I don't see a straightforward answer to the question. But if we use the Principle of Abstraction, the answer is that the sets in a "time-varying set" are related by having (a) the same universe of discourse, and (b) the same "predicate" (as Stoll puts it), or "set membership criterion" as I would prefer to put it.

As an aside I also note (since this topic is one I have worked on for a long time), that the standard (ISO 9075:2011 and/or TSQL2) theories of bitemporal data include the notion that there are two "time-varying sets" (in this sense) corresponding to each table, one tracking the temporally-ordered change of state of the objects represented by rows in each table, and the other tracking the temporally-ordered change of state of each table itself.

With this interpretation of the phrase "time-varying set", and with relational database tables being the original topic under discussion, my original point can be rephrased like this: a relational table is a "time-varying set" (i.e. a temporal sequence) of table states, each state being a specific collection of rows. By the Principle of Abstraction, what each of those states has in common is that they are defined on the same universe of discourse (a Cartesian Product of sets) and use the same set membership criterion.

And I once again apologize for using a term which originally seemed innocuous enough, but which I now realize is more naturally understood the way Pat understood it – as an oxymoron. I will henceforth try to use some such term as "temporal sequence of table states (sets)".

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (01)