Re: Another view on analysis and ER

On Dec 9, 5:20 pm, Jan Hidders <hidd...@xxxxxxxxx> wrote:
On 9 dec, 04:04, JOG <j...@xxxxxxxxxxxxx> wrote:



On Dec 9, 1:32 am, Jan Hidders <hidd...@xxxxxxxxx> wrote:

On 8 dec, 21:37, JOG <j...@xxxxxxxxxxxxx> 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 role-
names, 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.
.

Relevant Pages

  • Re: Another view on analysis and ER
    ... desires) something as a thing, as in Exists x, or as a predicate, X. ... has at least one lexical representation and is ... Note by the way that if you want to define propositions that way then ... because in practice objectification can deal with most reification, ...
    (comp.databases.theory)
  • Re: Question from a Prolog dummy
    ... nowhereface@xxxxxxx writes facts such as 'happy'. ... that they are facts for - in this case, under happy/1. ... But you could switch on hashing, on the functor and arity of the first argument of the hashed predicate: ... likes(jane, fred). ...
    (comp.lang.prolog)
  • Re: syllogism
    ... >symbolism in the context of implication, ... If one takes the objects b and c out of the predicate, ... asserting a system of propositions, just as, in the above ...
    (sci.logic)
  • Re: syllogism
    ... > For science it is classes SI, ... > If one takes the objects b and c out of the predicate, ... > asserting a system of propositions, just as, in the above ... > transformations, have significance for us because we are not ...
    (sci.logic)
  • Re: Coextensive properties?
    ... out communication the "girlie" charge (cognitive "science" full of ... predicate logic as a universal theoretical framework. ... asserting a system of propositions, just as, in the above ...
    (sci.logic)