Re: Another view on analysis and ER
Date: Sat, 15 Dec 2007 10:51:10 -0400
Message-ID: <4763e9e2$0$5300$9a566e8b_at_news.aliant.net>
JOG wrote:
> On Dec 15, 10:57 am, Jan Hidders <hidd..._at_gmail.com> wrote:
>
>>On 14 dec, 13:00, JOG <j..._at_cs.nott.ac.uk> wrote:
>>
>>
>>
>>
>>>On Dec 13, 12:26 am, Jan Hidders <hidd..._at_gmail.com> wrote:
>>
>>>>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?
>>
>>>The construct/entity might well be encoded as a tuple, but there may
>>>be a host of other valid encodings. I would not want the concept be
>>>seen as tied to an RM encoding, nor constrain it to being viewed as a
>>>finite partial function. I would rather see it in a more general
>>>fashion as a mathematical relation between attributes (a name and a
>>>domain) and values (objects/entities/whatever), over which one might
>>>apply all the facilities that set theory can accord.
>>
>>Two thing are puzzling for me here. Why are you now suddenly including
>>a domain in the definition? That is certainly not usual in ontology,
>>and it looks to me like an echo of a certain rather clumsy
>>formalization of the relational model. Why not simply a binary
>>relation over attribute names and entities?
> > > That would be fine for simplicity. I mention domains only in that for > an attribute of an item, such as colour for example, there are is a > constrained set of applicable entities (blue, red, etc) that are > acceptable. Why do you view this as clumsy? > >
>>And why do you leave out
>>the functionality requirement, i.e., for each attribute name there is
>>at most one associated entity?
> > > Because I do not see on what ground you would posit that an entity can > only have one attribute with a certain role-name. My name is James, > but it is equally Jim or Jamie. They are all used as a first_name > attribute for me. As a completely different example consider a > friendship entity - it has two components which play exactly the same > roles as "friend" attributes (unless you wouldprefer "friend1" and > "friend2"!). I see no argument to be bound to a partial function, > rather than using a the more general mathematical relation of which > binary functions are a subset. > >
>>Other than that I see no difference
>>with tuple, except that you allow it to be infinite. Correct? In that
>>case I think I would prefer the terminology of "infinite tuple".
> > > I have found the fact that database tuples and mathematical tuples > have different definitions confuses many learning db theory. > Additionally, using the term 'tuple' might blur the separation of > conceptual and logical layers, so I think i'd prefer term "attribute > sets" for the sake of clarity. > >>>>>>surrogates or OID's (which have no correspondence whatsoever with data
>>>>>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
>>>>>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.
>>
>>>Well, I have never suggested that anyone doesn't understand what an
>>>OID corresponds to.
>>
>>Well. "Has no correspondence whatsoever with data as observed" might
>>be construed as such. :-)
> > > The key was "as observed", in that we do not have OID's outside of the > database, which I am sure we would all agree. But I see where the > confusion lay. > >>>>content-based addressing. But then this is all well documented by
>>>The concern is the fact they are superfluous and
>>>facilitate results which have no correspondence to the real world with
>>>which we are modelling - they add nothing that cannot be achieved with
>>>date, pascal, darwen, etc.
>>
>>>Ought I infer that you don't agree with their perspective?
>>
>>That's putting it very mildly.
>>
>>
>>>That
>>>somehow all of an entity's properties can change and yet, because it
>>>has an OID, it is magically the same thing? No theory of identity that
>>>I have ever read would accede to such a view (even substance
>>>theorists), and yet it perpetuates in computer science due to the
>>>familiarity we all have with memory allocation.
>>
>>It is basically a correct view. There is no law that says that you
>>necessarily have to have all the direct properties in your UoD that
>>are needed for identfication, or that the properties that identify you
>>are immutable.
> > > Look, to identify an external entity, some attribute /must/ be > immutable for us to recognize it as the same thing (in fact for it to > be the same thing full stop), so let me exemplify what I think is the > problem in your reasoning:
Actually, the requirement is a little weaker. Some attribute must be immutable during each change for us to recognize something as the same thing, but it doesn't always have to be the same attribute.
At a certain level, there is not much difference between self-aware,
self-identifying me and Grandpa's Axe.
[snip]