Re: Another view on analysis and ER

From: JOG <>
Date: Sun, 9 Dec 2007 13:10:32 -0800 (PST)
Message-ID: <>

On Dec 9, 5:20 pm, Jan Hidders <> wrote:
> 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.

Hmmm. Two ways I could go I guess. Add role-names to the predicates of (2) and proceed. /Or/ I could state that the requirement of rolenames,  and the lack of facility for this in a mathematical predicate (being just a boolean valued function after all), that your definition of relationship in data modelling = mathematical predicate is incorrect. How would you react to that? (and does the requirement for role-names actually thus define something as an entity?)

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

an alias for an object you mean? I certainly don't see why not. In fact lets go the whole hog and go with (role-name, entity) pairs.

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

Lets just see 'Jane' as an alias for the whole set of (role-name, entity) pairs that define her. No need for more complexity then.

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

Could you clarify this for me? I assume you are not referring to (1) as it has the Marriage predicate. And (2) indicates that x is a member of the set "Marriages" which I believe would achieve the result you are referring to.

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

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

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

Again, as far as I understand the defintion of an entity, there cannot be another entity with the same set of properties. That would define them as being identical things by LL. Perhaps I have misunderstood you.

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

Well I have no problem, other than that positing a entity/relationship model at the logical layer means that one would have already reified, and hence it is a bad move. Anyone who's used xslt for anything serious knows that taking an already-reified model and trying to transform it in a different one is an arduous task.

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

Its not a case of a UoD growing, its a case of shared data, where many users might want to impose different conceptual models. I'd also say that I'd like to avoid referring to the RM, its certainly not my focus in these meanderings.

> -- Jan Hidders

regards, Jim. Received on Sun Dec 09 2007 - 22:10:32 CET

Original text of this message