Re: Modeling question...

From: Brian Selzer <>
Date: Tue, 18 Nov 2008 08:39:34 -0500
Message-ID: <rAzUk.5920$>

"David BL" <> wrote in message
> On Oct 30, 7:41 pm, JOG <> wrote:

>> On Oct 30, 1:51 am, David BL <> wrote:
>> > On Oct 29, 8:39 pm, JOG <> wrote:
>> > > On Oct 29, 2:37 am, David BL <> wrote:
>> > > > On Oct 29, 9:13 am, JOG <> wrote:
>> > > > > The RM handles facts as naturally as stating them in predicate 
>> > > > > logic.
>> > > > > And why would one ever model things other than facts in predicate
>> > > > > logic?
>> > > > Exactly!
>> > > Then may I suggest that your argument is not with the RM, but with 
>> > > the
>> > > use of predicate logic to model equations, engines, etc. And yet this
>> > > to me seems trivially true - if I was modelling a human in an art
>> > > class I'd use clay, not predicate logic.
>> > I don't think it's quite so trivial.   For example, consider tri-
>> > surface as a value-type.  A simple type decomposition as a set of
>> > triangles where each triangle is independently defined by 3 vertices
>> > doesn't express the constraint that the triangles tend to meet each
>> > other.  It seems appropriate to introduce abstract identifiers for
>> > the vertices in order that they may be shared.
>> > This is evidently a relational solution.  However unlike typical uses 
>> > of the RM there
>> > doesn't appear to be some external UoD to which the tuples,
>> > interpreted as propositions can be related.
>> I use Oracle Spatial to do exactly this sort of thing day in day out
>> in a geospatial domain, and no abstract identifers are introduced. The
>> coordinates of any vertex are used. That is what identifies them -
>> that is what is used (note that these coordinates can happily be
>> relative). Constraints to maintain adjacency use the spatial operators
>> offered by SDO_RELATE. It is very good.
>> I karate chop your example to pieces! Haiii-ya.

> Please forgive my ignorance - I'm not familiar with Oracle Spatial.
> Are you suggesting that for a tri-surface all that is needed is a
> single relation for the triangles, and when for example you want to
> change what is conceptually a shared vertex (and so which is
> understood to impact multiple triangles), it is assumed that all
> vertex values that appear in the relation with that same value (ie
> coords) are indeed logically shared and therefore are all
> automatically updated by the DBMS at the same time? If so it is not
> clear to me how and when the DBMS knows that such an elaborate update
> policy is required. I presume it is inferred from the integrity
> constraints. Is that right? Does the DBMS provide such a facility in
> a generic way?

> This reminds me of the idea that one can change the key of a tuple in
> a relation and have the DBMS automatically update all foreign key
> references across the entire database.

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

>> > Rather it seems that a particular tri-surface /value/ has introduced a 
>> > local and private
>> > namespace in order to privately apply the RM.  Note as well that this
>> > is not like an RVA (where we think of only a single relation as a
>> > value) because a tri-surface value is associated with /two/ relations
>> > - one for the vertices and another for the triangles.
>> > I have wondered whether abstract identifiers are needed precisely when
>> > it is useful to express the concept of "common sub-expressions" within
>> > nested value-types.  Note that scene graphs are typically thought of
>> > as DAGs not trees for precisely this reason.
>> > I think there is an interesting interplay between 1) degrees of
>> > freedom (or entropy or storage space if you like) in the encoding of a
>> > value, 2) abstract identifiers, 2) integrity constraints and 4) update
>> > anomalies.   The existing normalisation theory in the literature seems
>> > relevant but doesn't seem to me to account for recursive type
>> > definitions and abstract identifiers.
>> I am yet to be convinced of the need for abstract identifers (or
>> invention of recursive types) from the examples offered so far.. the
>> wff is the most interesting, but I am currently questioning the sense
>> or utility of decomposing an equation in such a manner /at the logical
>> level/ (as opposed to the physical).

Received on Tue Nov 18 2008 - 14:39:34 CET

Original text of this message