Re: Another view on analysis and ER

From: David Cressey <cressey73_at_verizon.net>
Date: Mon, 17 Dec 2007 15:55:58 GMT
Message-ID: <i_w9j.4403$L91.4324_at_trndny05>


"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:HKv9j.31817$JD.30368_at_newssvr21.news.prodigy.net...
>
> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
> news:eb2e158c-91be-4e38-8f98-3ee6157e87f2_at_s8g2000prg.googlegroups.com...
> > On Dec 15, 10:57 am, Jan Hidders <hidd..._at_gmail.com> wrote:
> >> On 14 dec, 13:00, JOG <j..._at_cs.nott.ac.uk> wrote:
> >>
> >>
> >>
> >> > On Dec 13, 12:26 am, Jan Hidders <hidd..._at_gmail.com> wrote:
> >>
> >> > > On 11 dec, 12:37, JOG <j..._at_cs.nott.ac.uk> wrote:
> >>
> >> > > > On Dec 10, 6:33 pm, Jan Hidders <hidd..._at_gmail.com> wrote:
> >>
> >> > > > > On 9 dec, 22:10, JOG <j..._at_cs.nott.ac.uk> wrote:
> >>
> >> > > > > > On Dec 9, 5:20 pm, Jan Hidders <hidd..._at_gmail.com> wrote:
> >>
> >> > > > > > > On 9 dec, 04:04, JOG <j..._at_cs.nott.ac.uk> 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:
> >
> > 1) Say the construct in our UoD representing the entity E does not use
> > its immutable identifer, X.
> > 2) In the outside world imagine that, unbeknownst to us everything
> > about the external entity E changes apart from X.
> > 3) We are presented with E, but cannot find /one single/ attribute
> > that matches with any of the constructs in our UoD.
> > 4) We hence deign it to be a new construct, and add it. The original
> > construct is now garbage, and its continued existence in the db will
> > generate serious querying errors.
> > 5) Broken database.
> >
>
> I don't agree with your line of reasoning. This is what can happen:
>
> 1) Say the construct in our UoD representing the entity E does not use its
> immutable identifier, X.
> 2) In the outside world, everything about entity E changes apart from X.
> 3) The database is told what is different about entity E via an UPDATE,
> 4) The representation in the database is adjusted to reflect the current
> state of entity E.
> 5) Consistent database.
>

The question of whether it's "the same entity" or "a different entity " is also moot.

(By "different entity", I mean different instance, not different type). Received on Mon Dec 17 2007 - 16:55:58 CET

Original text of this message