Re: Trying to define Surrogates

I've changed my position. I just had a revelation that the need for key stability is a symptom of the problem, not the problem itself. I still think that the model has a problem, but the root cause has nothing to do with how stable a key is: rather, it is that there isn't a mechanism defined in the model to correlate tuples during an update. I posted in the other thread the line of thinking that led to this revelation, but I'm going to repost, so that others who are not following that thread can comment. I'm going to use the subject "Relation Schemata vs. Relation Variables" if you'd like to follow it.

"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:1156044497.924940.277890_at_m73g2000cwd.googlegroups.com... Brian Selzer wrote:
> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
> news:1155947515.920269.149070_at_p79g2000cwp.googlegroups.com...
> >A few useful things have also come up for in the process of thinking
> >about this:
> >
> >1) It has cemented in my mind the knowledge that identification is what
> >matters in data modelling, not identity. i.e. I can see two things are
> >different, but if I want to talk about them, identification of that
> >difference is the vital aspect. i.e.
> >
> >Ex Ey isCow(x) & isCow(y) & ¬x=y
> >
> >maybe be perfectly /true/ but it is of little use unless I am able to
> >identify how ¬x=y.
> >
>
> So. Identity and identification are different things. I'll buy that.
> Identification is the result of what someone did to distinguish one thing
> from all others; Identity is what something has that distinguishes it from
> all others. Identification is a symbol that someone assigned to
> something;
> identity is what they used to distinguish something so that they could
> make
> the assignment. I think that the frame of reference is critical. The
> important differences between identification and identity are that
> identification doesn't change, but it's tied to the observation, and that
> the perception of identity depends on the frame of reference.
> Two people can assign different identification to something, or the same
> person may
> assign different identification at different times. For example, Borders
> may have assigned the symbol 1324326 to you, whereas Sears assigned
> 3215131,
> or Borders may assign the symbol 1214123 to you at a later date.

So much ambiguity in this that I can't follow it at all. I'm pretty certain its nothing to do with what I was saying. Anyhow, all of this has been covered in the other thread, and I know you are not wont for convincing.

> Also something can appear different at different times and still be
> distinguishable from all other things at each point in time. For example,
> you could be fifth in line at the bank at 3:00pm and third in line at
> 3:05pm.

O.k. one last time:

Yes, but it is vital that your means of identifying that 'something' is consistent between 3.00 and 3.05 otherwise we wouldn't be able to tell it was the same thing at all. Its the external identification that's crucial.

>
> >2) All items can be distinguished, if ultimately by nothing else than
> >their location. In fact even change can be accounted for by identifying
> >an item by its path in space over its lifetime. A magical identity (or
> >genidentity, or perdurance, or whatever) is metaphysical nonsense.
> >
>
> How do you articulate that path and associate it with the item under
> discussion?
> Also, two items can occupy the same space at a particular
> instant or during an interval--even the entire lifetime, especially if one
> is part of the other. How do you differentiate between them?
>
> >3) Duplicate propositions are so wrong it hurts my head to think about
> >them. I obviously understood this before in terms of the definition of
> >a set, but now doubly so in the context of identification.
> >
> >4) Lists don't belong at the lowest level of modelling. The items in a
> >list are not duplicates even if they appear so. The 5th head in a list
> >of coin throwing results is not the same thing as the first. It has
> >distinguishing attributes, the time it occurred for instance, or the
> >item that preceded it.
> >
> >5) oid's are a nonsense in terms of data modelling. Distinguishing an
> >assertion by pointing at it continually cannot be shared by a new
> >observer (and so is of no use to databases) and is unnecessary given
> >(2). It would be like trying to keep track of the identity of cans of
> >campbells soup by pointing at them. You're going to run out of hands
> >very quickly and you're in /serious/ trouble if you ever want a beer.
> >
>
> oid's don't identify assertions, they identify what the assertions are
> about.
> They are a symbol for the endurant essense of something--an
> articulation of the path of the thing through spacetime, perhaps.
> There appears to be a lot of confusion about this. A database is
> knowledge about
> things; it is not a representation of things. That's the difference
> between
> a database and an object store. A database is a set of propositions about
> things; an object store is a set of representations of things. A
> candidate
> key can only identify something indirectly.
> It identifies the proposition
> about something. An oid, on the other hand, identifies something
> directly.
> The extra level of indirection is important.
>
> >I know some of these things are intuitive to many on cdt, but I find it
> >useful to know these conclusions can arise from examining exactly what
> >identity and identification mean.
Received on Sun Aug 20 2006 - 18:29:55 CEST