Re: Modeling question...

From: David BL <>
Date: Tue, 18 Nov 2008 09:02:43 -0800 (PST)
Message-ID: <>

On Nov 18, 10:39 pm, "Brian Selzer" <> wrote:
> "David BL" <> wrote in message
> > Anyway, I think there are data entry applications where the concept of
> > "shared values" needs to be under user control. For example in the
> > data entry of a CAD drawing of a car the user may or may not want all
> > the wheels to share the same geometry. The problem with simple copy
> > and paste (and no logical sharing) is that any future edits to the
> > wheel geometry need to be repeated on every copy. The obvious
> > solution seems to be to reference a single shared geometry for a wheel
> > - hence the need for an abstract identifier. Are you suggesting that
> > an alternative is to instead use an integrity constraint! If so how
> > can you specify which geometries are logically tied and which are not
> > (ie even though they just happen to be equivalent in value at that
> > moment in time)? Doesn't that require abstract identifiers of some
> > sort anyway? I can't imagine that values that happen to be the same
> > are always assumed to be shared, because then it would be impossible
> > for a user to copy and paste a value in order to create a copy that
> > will subsequently diverge.
> I think that once a copy is made, the copy should be completely separate
> from the original.

I agree, and it reminds me of "pass by value" versus "pass by reference" for the parameters of a function call in a language like C/C ++.

Note that (assuming values don't exist in space and time) it's actually meaningless to talk about copying a value. Copying can only mean assigning the current value held by one variable into a different variable. I believe it follows that variables have a bigger role to play than (just) relvars in certain data centric applications.

There seems to be two options when copying graphs interconnected using abstract identifiers - either copy the abstract identifier values verbatim, or else allocate new values for the abstract identifiers in order to create an isomorphic graph. This complicates what it means to copy a variable.

A rich type system eliminates the ambiguity of copying a variable. For example, if a data type represents an electronic circuit and we distinguish internal node identifiers from external ones, then an assignment operator can make an independent, isomorphic copy of the internal components and node identifiers but share the external node identifiers.

> If there are shared components, such as the wheel
> geometry in your example, then those components should be segregated into a
> separate relation or set of relations.

The representation of complex scene graphs raises many questions. I have this vague idea that the best approach is some kind of hybrid of RM, recursive value types (defined on some grammar) and controlled use of abstract identifiers. But add to the melting pot is the fact that / rendered/ scenegraphs often need to exhibit complex behaviours so it can be useful to think of them as Finite State Machines. This suggests an OO perspective (and it's worth noting that abstract identifiers and OIDs have much in common), but these days I think a data centric approach is best.

> If two individuals have exactly the
> same attributes, then not enough attributes have been specified so that the
> individuals represented by values for those attributes can be distinguished.
> What you seem to be suggesting here has been suggested over and over: using
> an artifical identifier to represent the haecceity of an individual, or
> those attributes that are not relevant to the problem at hand but whose
> values would serve to distinguish two otherwise identical individuals, which
> is essentially (pun intended) the same thing.

Actually I don't think it's useful to associate an /abstract/ identifier with the "haecceity of an individual". I'm assuming here an "individual" is outside the RM formalism and something in the UoD about which propositions can be stated. I don't think an identifier for an individual in the UoD should be referred to as "abstract". It could instead be described (rather subjectively) as "natural" versus "artificial" - and in either case it may even be generated by the DB. Nevertheless it is assumed to represent a name for something for which the external predicates make various propositions.

I want to limit the term /abstract identifier/ to where it (only) represents the name of a variable holding an abstract mathematical value within some scope within the DB.

The physicist Max Tegmark uses the term "baggage" to refer to the informal bindings between things in the real world and the identifiers (like "electron") that appear in all our existing models or descriptions of reality. He was using this term with reference to the question of whether it's possible for there to be a theory of everything described in a way that's completely free from baggage. He claimed the only way is to use sets of abstract identifiers that have "no baggage" because their meaning is only derived from their axiomatically defined relationships to each other. This is hand wavy stuff, but I think the distinction is relevant to DB theory. Received on Tue Nov 18 2008 - 18:02:43 CET

Original text of this message