Re: Ping: dawn, some mvl questions

mAsterdam (mA)
Keith H Duggar (KHD)

(First mA I accidently sent you an email subject "Please Stop". That was a stupid accident the email had nothing to do with you please ignore it.)

mA wrote :
> No, there are several clumsy ways to represent lists using
> only relations.

KHD wrote :
> Since, on the other hand, I find relations a quite elegant
> solution for ordering,

mA wrote :
> the "numbered items" way or the "successive items" way?

KHD wrote :
> I think it would depend on my purpose. However, the
> solution I find "elegant" at the moment is the ID with an
> edge relation. I like it because it can represent any
> directed graph in addition to lists of course, you can
> have arbitrarily many DGs for a set of nodes, and since I
> still get stuck on "how" thinking sometimes, I can readily
> see how to efficiently implement such a relation and
> algorithms using it.

mA wrote :
> Let's see if I understand. We view the list as a very
> simple graph, the idea being that if we have a relation
> capable of describing any directed graph we surely can
> describe a list, right?
>
> The drawback would be that the preservation of the
> listness is not garantueed. Whithout additional
> constraints there is no stopping anyone from inserting
> nodes which make the described graph more complex. Now the
> list is gone.
>
> BTW it would be very similar to the "successive
> items" way (which also has this drawback), no?

Ok so this goes to the /using/ or /manipulation/ of a list representation as opposed to modeling correct? And isn't this a physical or implementation issue as opposed to a logical issue?

I assume (though I truly have no idea) that DBMS provide mechanisms for specifying such constraints? In other words it's the responsibility of an implementation to guarantee "listness" is maintained. Correct?

mA wrote:
> Let's go that way for now. Which relation representation
> of the list do we choose - is it consequential? If we
> have lists in our model, we may have performance penalties
> in our implementation, but no open door to misinformation.

If I understand you correctly, then I honestly do not know. Isn't this the core physical independence question? Logical vs Physical? What vs how? See I come from a /how/ programming background so I don't have deep experience with separating logical and physical concerns. And thus I don't know how well they can be separated in practice. Thus far it seems most abstractions do come with some cost; but, perhaps this has more to do with bias for certain logical models in hardware design.

KHD wrote:
> Why? If information is known and deemed important what is
> preventing us from making explicit? Can you give an
> example?

mA wrote:
> Not strictly an example, just a thought. In order to
> ascertain the importance of information it has to be
> observed (explicit information) or derived (implicit
> information) first. Think of an artefact from a crime
> scene - what information is there? The potential is huge.

Sure, we agree that any physical thing represents a vast information content. I'm just pointing out that information we do /know/ (ie observe or derive) can be made explicit if we choose.

• Keith --