Re: Another view on analysis and ER

From: Jan Hidders <hidders_at_gmail.com>
Date: Wed, 12 Dec 2007 16:26:22 -0800 (PST)
Message-ID: <abbeb2e8-910c-4f84-a6ed-066ea7c34f94_at_e6g2000prf.googlegroups.com>


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?

> 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. These, by definition, can be observed in the wild, at least in the sense that is relevant here. So as far as I am concerned you are just introducing an ad hoc rule for no other reason than that it seems to lead to the conclusion you were trying to prove, namely that your construct is the best way of representing entities in a database.

  • Jan Hidders
Received on Thu Dec 13 2007 - 01:26:22 CET

Original text of this message