Re: Objects and Relations

On Feb 15, 9:44 pm, "JOG" <j..._at_cs.nott.ac.uk> wrote:
> On Feb 15, 2:24 am, "David BL" <davi..._at_iinet.net.au> wrote:
>
>
>
>
>
> > On Feb 15, 12:22 am, "JOG" <j..._at_cs.nott.ac.uk> wrote:
>
> > > On 14 Feb, 13:12, "Cimode" <cim..._at_hotmail.com> wrote:
>
> > [snip]
>
> > > > > 2) Hence their x,y,z position attribute always identifies them.
>
> > > > False.
>
> > > Location always identifies something. Two things cannot be in the same
> > > place. It's sort of a law of physics, and I've got to be honest,
> > > knowing it has tended to help me in daily life. Like if my tv is in
> > > the corner of the room my car probably isn't there too.
>
> > A quibble: saying "Location always identifies something" doesn't seem
> > quite right. Not all things are physical things. For example
> > location doesn't identity a company like Coca Cola.
>
> Fair point.
>
> > Furthermore some
> > physical things aren't particularly well localised in space. Eg a
> > railway line.
>
> > Also, spatial location won't be adequate in a temporal DB. I presume
> > you would then say that (x,y,z,t) identifies the thing. Would you be
> > prepared to introduce a surrogate id that stands for (x,y,z,t), so
> > that nothing keeps its identity from one moment to the next?
>
> Yes exactly, if you so wished. Or a surrogate could represent its path
> over time, whatever gets the job done.

So you're saying a surrogate id can represent an "untrackable attribute", standing for the complete world line of a particle through space and time, without actually acknowledging that the particle exists!

How do you explain the surrogate id in the relation

    Position(*id,*t,x,y,z)

used to record the world lines of multiple particles that are otherwise indistinguishable? Note the FD of x,y,z on both id and t. In what sense does the id represent an "untrackable attribute" given that the world lines *are* in fact being tracked?

[snip]

> > I am struggling with your assertion that relations only are about
> > roles and values, not entities.
>
> A relation is a subset of the cross-product of n domains. Those
> domains do not contain 'entities' they contain values. I hope that
> clarifies it.

Far from it. Let me explain my pov, by describing what various terms mean to me. Perhaps you may see something I have wrong. If that is the case I would appreciate something more specific and useful than merely "nonsense" (as Bob would typically say).

The word "exists" appears a lot in mathematics. For example consider

    P = there exists nonzero integers x,y,z such that x^2 + y^2 = z^2

Generally speaking mathematicians don't waste time arging about whether the integers exist. Instead they assume it, and ask more refined questions about existence like the one above. In this case P is true.

Now if one believes that the integers don't exist at all then clearly P will be false. Is such a philosophical position tenable for a mathematican? No! This makes me think mathematicians have a Platonic view whether they admit it or not.

Now I agree with you that entities are conceptual in nature. I also agree that they can be very precise like the integers, or rather fuzzy like you and me as humans. But to say they don't exist (even as concepts in some Platonic realm) makes a mockery of mathematics, human thought and language. Do you really want to qualify every single thing that you say with the caveat that you are pretending that those conceptual things exist? For a start you'll get stuck in an infinite regres because you're not allowed to assume you're own sentences exist.

Now onto relations... A relation is a mathematical entity. It has a head and body. The head is a set of attributes. An attribute has a name and a domain. A domain is a mathematical set. The elements of the domain are entities (and not normally values as you say above). In the context of the relation an attribute is associated with a role. For example in the relation father(F,C), the attribute named F has the father role, and the attribute named C has the child role.

The body of a relation consists of a (mathematical) set of tuples. A tuple is a (mathematical) map from attribute to an element of the attribute's domain.

Can we directly represent a relation on a computer? No! A relation is a mathematical entity. Looking at this further we also see that attribute domains are sets of entities, and those entities can't be plucked out of the Platonic realm and lodged into computer memory. This forces us to introduce the idea of a /value/. A value is nothing but a name for an entity. For example a 32 bit word in computer memory can be interpreted as a name for a particular integer.

One could say that a value for a computer is the counterpart of a noun for natural language.

> > You have yet to provide an
> > explanation. I have the impression that you think in terms of
> > entities but aren't prepared to admit it. Take for example your
> > words like "something", "item" etc
>
> Sure. My distinction with you is that I realise that entities are
> nebulous, overlapping, ill-defined things whose definition differs
> from person to person, and from one context to another. To
> constricitvely encapsulate something as an 'entity' is a mistake when
> it comes to data management.

I think people need to agree on what they understand by the entities to have any hope of agreeing on the semantic meaning of the DB.

I note however that the act of stating facts about entities goes a long way towards achieving that agreement. This is because language can only reference entities by name. Is that your point?

> While broadly irrelevant, if you have fun thinking about the
> philosophy behind it google for essentialism vs non-essentialism I
> don't know if that will help you - I fear you are entrenched in a cosy
> realist view of the world, but its worth pointing that Bhuddist
> Philosophers realised entities and 'things' are nebulous concepts
> thousands of years ago. It is hardly a new realisation.

But it is *you* that claims a philosophical position that has practical repercussions for data management.

> Now, as I said, I'm not going to get into that epistemological debate.
> But what I *will* do instead (as soon I get time) is post some
> practical negative consequences of thinking in terms of entities and
> not propositions, and why we are better off getting out of that OO
> mindset when it comes to data management. I think this would be far
> more productive.

I'm looking forward to that. Received on Fri Feb 16 2007 - 03:42:55 CET