Re: Another view on analysis and ER

From: JOG <>
Date: Sat, 15 Dec 2007 09:25:57 -0800 (PST)
Message-ID: <>

On Dec 15, 2:51 pm, Bob Badour <> wrote:
> JOG wrote:
> > On Dec 15, 10:57 am, Jan Hidders <> wrote:
> >>On 14 dec, 13:00, JOG <> wrote:
> >>>On Dec 13, 12:26 am, Jan Hidders <> wrote:
> >>>>On 11 dec, 12:37, JOG <> wrote:
> >>>>>On Dec 10, 6:33 pm, Jan Hidders <> wrote:
> >>>>>>On 9 dec, 22:10, JOG <> wrote:
> >>>>>>>On Dec 9, 5:20 pm, Jan Hidders <> wrote:
> >>>>>>>>On 9 dec, 04:04, JOG <> wrote:
> >>>>>>>>>Now in ontology, it is generally accepted that an
> >>>>>>>>>object, or entity, is nothing more than a compressence of a collection
> >>>>>>>>>of properties - i.e. (attribute, value) pairs.
> >>>>>>>>[....]
> >>>>>>>>I'm also not comfortable with the usage of "is" here. I'd agree that
> >>>>>>>>this is how entities can be described, but saying that they "are"
> >>>>>>>>these descriptions seems wrong to me.
> >>>>>>>Why are you uncomfortable with that. An entity is nothing more and
> >>>>>>>nothing less than the 'compressence' of its _full_ set of all its
> >>>>>>>attributes.
> >>>>>>>>After all, different descriptions may describe the same entity.
> >>>>>>>Well, I haven't talked about describing entities, rather we're
> >>>>>>>defining them. This is an entity as our model sees it, not how it is
> >>>>>>>seen in the real world (obviously there are concessions, given the set
> >>>>>>>of possible attributes is probably infinite).
> >>>>>>But that is what I'm saying, isn't it? These sets of properties are
> >>>>>>part of your model of a piece of reality and as such *represent*
> >>>>>>entities that are part of that reality, Saying that they *are* these
> >>>>>>entities is sloppy use of language and confuses the map with the
> >>>>>>territory. If I didn't know any better I'd almost think you could be
> >>>>>>accused of muddled thinking. :-)
> >>>>>Ha, I'll have you know that it would only be a case of muddled writing
> >>>>>not muddled thinking sir! In my defence I'd refer you back to some
> >>>>>posts I made a while back in another thread where I was promoting a
> >>>>>distinction between a "construct" and an "entity" to try and avoid the
> >>>>>very ambiguity that you are talking about. I hold little hope of
> >>>>>changing anyones terminology though, however worthwhile I think that
> >>>>>would be ;)
> >>>>Just our own terminology for the duration of this discussion seems
> >>>>ambitious enough. :-) At least it seems we're on the same page here,
> >>>>so that's nice. Btw. what is the difference between your internal
> >>>>entity / construct and a tuple with named fields?
> >>>The construct/entity might well be encoded as a tuple, but there may
> >>>be a host of other valid encodings. I would not want the concept be
> >>>seen as tied to an RM encoding, nor constrain it to being viewed as a
> >>>finite partial function. I would rather see it in a more general
> >>>fashion as a mathematical relation between attributes (a name and a
> >>>domain) and values (objects/entities/whatever), over which one might
> >>>apply all the facilities that set theory can accord.
> >>Two thing are puzzling for me here. Why are you now suddenly including
> >>a domain in the definition? That is certainly not usual in ontology,
> >>and it looks to me like an echo of a certain rather clumsy
> >>formalization of the relational model. Why not simply a binary
> >>relation over attribute names and entities?
> > That would be fine for simplicity. I mention domains only in that for
> > an attribute of an item, such as colour for example, there are is a
> > constrained set of applicable entities (blue, red, etc) that are
> > acceptable. Why do you view this as clumsy?
> >>And why do you leave out
> >>the functionality requirement, i.e., for each attribute name there is
> >>at most one associated entity?
> > Because I do not see on what ground you would posit that an entity can
> > only have one attribute with a certain role-name. My name is James,
> > but it is equally Jim or Jamie. They are all used as a first_name
> > attribute for me. As a completely different example consider a
> > friendship entity - it has two components which play exactly the same
> > roles as "friend" attributes (unless you wouldprefer "friend1" and
> > "friend2"!). I see no argument to be bound to a partial function,
> > rather than using a the more general mathematical relation of which
> > binary functions are a subset.
> >>Other than that I see no difference
> >>with tuple, except that you allow it to be infinite. Correct? In that
> >>case I think I would prefer the terminology of "infinite tuple".
> > I have found the fact that database tuples and mathematical tuples
> > have different definitions confuses many learning db theory.
> > Additionally, using the term 'tuple' might blur the separation of
> > conceptual and logical layers, so I think i'd prefer term "attribute
> > sets" for the sake of clarity.
> >>>>>I would say though that the internal entity (henceforth referred to as
> >>>>>a construct by myself) and the external entity, /must/ share the same
> >>>>>identifiers for them to be consistent with each other. Its a simple
> >>>>>rule, but without it one ends up in a artificial quagmire of hidden
> >>>>>surrogates or OID's (which have no correspondence whatsoever with data
> >>>>>as observed out in the wild), or worse still, broken databases.
> >>>>That is something that you still have to show. To me it is very clear
> >>>>what OIDs correspond to: they correspond the entities we want to
> >>>>represent.
> >>>Well, I have never suggested that anyone doesn't understand what an
> >>>OID corresponds to.
> >>Well. "Has no correspondence whatsoever with data as observed" might
> >>be construed as such. :-)
> > The key was "as observed", in that we do not have OID's outside of the
> > database, which I am sure we would all agree. But I see where the
> > confusion lay.
> >>>The concern is the fact they are superfluous and
> >>>facilitate results which have no correspondence to the real world with
> >>>which we are modelling - they add nothing that cannot be achieved with
> >>>content-based addressing. But then this is all well documented by
> >>>date, pascal, darwen, etc.
> >>>Ought I infer that you don't agree with their perspective?
> >>That's putting it very mildly.
> >>>That
> >>>somehow all of an entity's properties can change and yet, because it
> >>>has an OID, it is magically the same thing? No theory of identity that
> >>>I have ever read would accede to such a view (even substance
> >>>theorists), and yet it perpetuates in computer science due to the
> >>>familiarity we all have with memory allocation.
> >>It is basically a correct view. There is no law that says that you
> >>necessarily have to have all the direct properties in your UoD that
> >>are needed for identfication, or that the properties that identify you
> >>are immutable.
> > Look, to identify an external entity, some attribute /must/ be
> > immutable for us to recognize it as the same thing (in fact for it to
> > be the same thing full stop), so let me exemplify what I think is the
> > problem in your reasoning:
> Actually, the requirement is a little weaker. Some attribute must be
> immutable during each change for us to recognize something as the same
> thing, but it doesn't always have to be the same attribute.

Hi Bob. Can't agree with you entirely. If an entity is subject to x changes at (T1, T2...Tx), with a different attribute being the immutable one between each change, well if someone independently comes along and compares the item as it was at T1 with its most recent state at Tx, he is going to have no idea that they were the same object. He needs something to be the same across all changes to know an object at Ty is the same one as at Tx.

> At a certain level, there is not much difference between self-aware,
> self-identifying me and Grandpa's Axe.
> [snip]
Received on Sat Dec 15 2007 - 18:25:57 CET

Original text of this message