Re: Another view on analysis and ER

From: Jan Hidders <>
Date: Sun, 9 Dec 2007 09:20:27 -0800 (PST)
Message-ID: <>

On 9 dec, 04:04, JOG <> wrote:
> On Dec 9, 1:32 am, Jan Hidders <> wrote:
> > On 8 dec, 21:37, JOG <> wrote:
> > > My question is when should one choose to represent (in FOL if one so
> > > desires) something as a thing, as in Exists x, or as a predicate, X().
> > > So if I have my previous example "John from London married Jane from
> > > Manchester in a Church", do I have:
> > > 1) Married(Husband:John, Wife:Jane, Instituion:Church)
> > > 2) EXISTS! x E marriages [ Husband(x, John) ^ Wife(x, Jane) ^
> > > Institution(x, Church) ]
> > > First one is marriage as a predicate, the second one the marriage as a
> > > thing, x. Which to choose, and when.
> > The most simple one that allows you to model your UoD properly. In the
> > context of FOL this would usually be 1) except if you also have
> > predicates in your UoD in which a marriage plays a role as an entity.
> > In the latter case you should probably use 2) but it could also be
> > that you have to expand even more and also objectify the relationship
> > between marriage and husband. Obviously this can repeat itself in
> > theory an arbitrary number of times, and each time you replace a
> > relationship with an new entity type and a few new relationships that
> > represent the roles. In a very real sense you can compare it to
> > zooming in on a fractal. The design principle can then be formulated
> > as zooming in as much as is needed to place all the predicates you
> > have to model, but no more.
> > Note that in an ER dialect that allows objectification, such as ORM,
> > zooming in one time can often be dealt with by objectification and
> > keep the basic structure of the model the same, but the second time it
> > will change it.
> Ok, thanks for the feedback. I have certainly advanced my
> understanding or ERM via these discussions, which I don't often get
> the opportunity to do.
> But now we're finally on the same page, let me offer my final argument
> as to why (at least in data modelling) relationships and entities are
> the same things. In my example, where a single proposition could be
> written as either,
> 1) x = Married(Husband:John, Wife:Jane, Instituiton:Church)
> 2) EXISTS! x E marriages [ Husband(x, John) ^ Wife(x, Jane) ^
> Institution(x, Church) ]
> I'm sure you noted I tweaked FOL - the predicate instantiated in (1)
> is unordered in that it includes attribute names rather than being
> positional (which I think we'd all accede is in data modelling, where
> attribute names are a vital part of the information being modelled).

Agreed. But you were not completely consistent; the predicates Husband, Wife and Institution seem to be ordered again.

> Okay so my proposition in predicate form is a set of (attribute,
> value) pairs.

Values? We haven't yet defined what those are yet, have we? All I see there are (attribute-name, entity) pairs. So what is the difference between treating Jane as an object and as a number? Maybe we could agree for the time being on the following: a value is en entity that has at least one lexical representation (i.e. as a string) and is identified by its lexical representation.

This matters because if Jane is not a value but an abstract entity then you will probably replace the pair (Wife:Jane) with another set of pairs that identifies her. If there are multiple candidate keys then the choice of that set may not be clearly dictated by your UoD. Also your relatively simple ternary predicate is now represented by something that may have many more roles.

Note by the way that if you want to define propositions that way then you should also include the predicate name somehow, because the same set of pairs might apply to different propositions.

> 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.

Again, I would first like to know the definition of "value" here and whether it is exactly the same as in the previous case. Come to think of it, also the notion of "attribute" might need some closer examination. Think of weak entities, for example. These, by definition, cannot be described by their attributes, unless, of course, you extend the notion of attribute such that it includes inferred indirect attributes such as the name of the owner of the dog which would then have to be an attribute of the dog.

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. After all, different descriptions may describe the same entity. Note how this is different for instantiated predicates; they are the same iff they concern the same predicate and the same entities in the same roles. But what is similar is that also here you should probably include something in the description that refers to the entity type (or a set of entity types), because there might be an entity with the exact same properties except that it belongs to different entity types. Yet another difference between entities and propositions: propositions can belong to at most one relationship type.

> Ergo, in both (1) and (2) the marriage x can be described by exactly
> the same construct... a set of (attribute, value) pairs!
> This is the representation that underpins both, and I could infer /
> either/ conceptual model, (1) or (2) from that underlying
> representation. If I stick to that denotation I never have to
> fractally dig down, reobjectify, reify, etc. We have one single
> representation of the shared data from which someone may infer their
> own particular perspective of the universe of discourse, objectifying
> their hearts content to fit their particular application.

Sure. With the "reify only when needed" rule you also get a unique ER model from which you can infer all others. So what is the problem?

What you might argue is that there is a difference in robustness in the sense that when the UoD grows it might be that your are forced to reify and therefore have to change the basic structure of already existing parts of your schema, whereas in the RM schema you probably only need to add new relations and columns but can leave the already existing ones alone. Apart from the fact that this is a rare event, because in practice objectification can deal with most reification, it can in the remaining cases be dealt with by defining a view for the applications that prefer the old schema.

  • Jan Hidders
Received on Sun Dec 09 2007 - 18:20:27 CET

Original text of this message