Re: One-To-One Relationships

JOG wrote:

[...]

>> What I meant to say was:
>> an entity is a relationship except that an entity is identifiable in itself,
>> while a relationship is identified by its (possibly entity-valued)
>> attribute values. But I already said that in my previous post.
>> By "identifiable" I mean "mentionable", "referrable".
>
>I still think if you examine this again you'll see it really
>struggles. 'What does identifiable in itself' mean?

By "identifiable" I mean "mentionable", "referrable". "Can be used as an attribute value."

In other words, I propose what is sometimes called an "object-oriented data model".

> We can only ever
>identify things from observable attributes (and refer to them by
>attributes too!).

Certainly, but we don't always make those attributes explicit. And we don't always know what the relevant identifying attributes are. More importantly, idenification and entities are relative; they vary with context.

For instance, I write under the hypothesis that you are a person, identifiable here as "JOG". But this assumption may be false: you may be writing under several different names, and "JOG" may be used by more than one person. Outside of this newsgroup I have no idea how to identify the person(s) writing here as JOG.

I could remedy this by attempting to find more identifying information (posting headers, newsgroup history, whatever). But I don't. I have no need to. Assuming a newsgroup writer "JOG" works fine for me for now. Should I ever want to, let's say, meet you on IRC or over coffee, I'd need to extend my model of you, and provide a more detailed identification.

The question is whether I want to impose in my modelling language the need to restructure the relationship between postings and authors as soon as I make such more detailed identifications of persons.

[...]

>> The question is not how entities are referred to in statements,
>> but how to model the meaning of those statements. Let's take the
>> "head of department" example again. Clearly when we obtain the
>> information who is head of which department, the statement giving us
>> this information will usually address the two relevant entities by name:
>> e.g. when I read that Ms Rice is the head of the USA's Foreign Affairs
>> department, I see two entities referred to by name.
>
>There's the mistake imo. You have preassumed a conclusion - that
>entities are there

Nope. My entities are constructs in my model. I construct them myself. They do refer to things in the real world, but in a way my model doesn't fully describe.

>I certainly see no entities in that statement at all. I see words. In
>fact I can guarantee the existence of those words, but I certainly
>can't metaphysical 'entities'. I can also see some words in the
>statement describe roles and some that describe values. Some roles
>aren't there so I resolve them in my noggin by context (e.g. Ms and
>capitals indicates the start of a name for example.)
>
>Just roles and values, a logical layer, on which I can impose all
>sorts of conceptual models.

Please describe how you describe that persons are heads of departments in a way that doesn't predetermine how I'm going to identify persons and departments from now on. Or is it Just Wrong to want that? Why?

>> Does that mean
>> we should express the meaning of that statement, the "head of department"
>> relationship, as one between department names and person names?
>
>Why not? Its just data. Whatever conceptual model we want to conjure
>in our heads afterwards is our own business.

Nope. We don't decide whether people change their names, the personnel administration does (where I work, at least). We don't want an administration with headless departments as a side effect of name changes.

>> No, it doesn't, which becomes evident as soon as persons or departments
>> change their names.
>
>I 100% disagree, but now your getting into well trodden ground. If a
>person changes their name are they then a different person? You are
>saying no, but you are wrong because the actual answer is... It
>depends! There's just no correct response.

Sure, we can't predict or anticipate every need for change in advance. Still, I think this particular case is pretty clear.

>If you think this is
>madness and that obviously we'd still be talking about the same
>person, I refer you back to the question "are you the same person as
>when you were 5", or my example about Harry Potter books. Context is
>everything.

I am not trying to make claims about "what a real person really is". I don't believe in references into "the real world". All we can do is refer within models, or cross-refer from one model to another.

[...]
>> My conclusion is that "head of" is a *reference* to the person entity,
>> and that we need entities (or references) as first-class citizens in
>> order to correctly express the meaning of this statement.
[...]
>
>You recognize two items as the same thing in the real world,

Nope. I know other participants in this thread use the term "entity" in that way, but I don't. I recognize them as the same *in my model*.

I should have probably explained that better ...

>by some consistent attribute (or set thereof).

The whole point of this discussion is that sometimes you do not have or want a consistent attribute to pick.

>Pick the right ones, otherwise
>your database will break.

Sure, in a database all tuples ultimately need to be identifiable in terms of user-visible attributes, to avoid the existence of multiple equivalent tuples. But even there, "the right ones" are not in general a unique choice. E.g. depending on where I come I can identify myself by my passport and/or my driver's license. Sometimes the identification chosen depends on what information is practical or legal to maintain.

>You highlight flaws in a designers schema,
>not problems in an underlying model.

?? Which model is on top of which?

>And don't underestimate how much
>context resolving we do in our heads, and the amount of semantic
>knowledge we apply to fix ambiguity and inconsistency.

You appear to underestimate how much *flexibility* we have in all this context resolution business.

-- 
Reinier