Re: Ping: dawn, some mvl questions

mAsterdam wrote:
> Keith H Duggar wrote:
> > Since this something is part of "whatever" we fail to
> > preserve "whatever". However, I think we do agree on
> > this point?
>
> Because of the physical conversions (and changes of
> context) it is impossible to retain all of the
> whatever. Is that what we agree upon? :-)

Yeah. From other statements you made it seems we agree on that. So this statement

> > > We could choose to preserve whatever is in the layout
> > > and the handwriting

we agree is inaccurate. Replacing "whatever" by "some of what" would be more accurate.

> No, there are several clumsy ways to represent lists using
> only relations.
>
> > Since, on the other hand, I find relations a quite
> > elegant solution for ordering,
>
> the "numbered items" way or the "successive items" way?

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.

> > You cannot deem information important without knowledge
> > of it.
>
> Right. So, we have to postpone our decision on deeming
> things (un-)important we do not (maybe yet) fully
> understand.

Well that is part of the /decision/ process. What I don't understand is why this /decision/ process is relevant to logical data models or their physical representation. For example, if we decide caution is best and that order may be important, then we temporarily deem it important and represent it in whatever data model we have chosen. Whether the model has lists or not seems irrelevant.

> > Thus it is obviously always feasible to make known,
> > deemed important information explicit.
>
> That's optimistic, IMO.

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

> Respect your ignorance. ;-)

I have a HUGE respect for my ignorance ;-).

> Say we have a list.
>
> We don't, at this time, know whether the order in the list
> is significant or not (so excluding situations where the
> order is alphabetic, size or however evidently
> content-based).
>
> We cannot, at this time, agree upon what the explicit
> order communicates (and whether or not it tries to
> communicate anything).
>
> Now, when we only have relations to carry information
> (information principle) we have to either lose the order
> or add some attribute (an item number or a successor
> reference) to keep it - however, when we add this, we are
> creating either information or misinformation. At this
> point in time we have no way of knowing.

Adding an order attribute doesn't create any information it simply represents logically what was already there (physical order in the paper example). I can see that adding an ID for use in say a directed edge relation might add information in some sense to a paper list. However as far as electronic representations goes the ID attribute is simply making explicit what is usually implicit, references.

> Hmm... I think there is more common ground than you
> suspect at this time. No problem, I am patient.

Yes I think so too. I think at the moment we differ mainly on what we consider "clumsy" and whether the "clumsy" relational solutions add information/misinformation.

> > we probably have little more to communicate on this
> > particular topic.
>
> Oh :-( Ok.

Yeah that was premature, sorry.

> By keeping the list as a list no such awkward choice
> has to be made.
>
> BTW, how is a list not logical?

A list can be either physical or logical, implicit or explicit. These qualifications are key.

> > > Some might be tempted to tautoligize the issue by
> > > stating that all implicit information is deemed
> > > unimportant by definition. However this also affects
> > > all derived data.
> >
> > Sorry what precisely is the tautology?
>
> Sorry, I thought that was obvious. This is the tautology
> I had in mind :
>
> All important information is explicit.
> If it's not explicit it can't be important.

Ah I see. That is a manufactured tautology with some subtle context shifting (the phrase "can't be" which implies a future context, "information" and "explicit" may refer either to the source or the model representation, and "important" implies some alternate "objective" context) and as such doesn't reflect on anything we have discussed. This is more accurate (which I also quote in another form below):

    Some source information is deemed important.     Information deemed important is modeled explicitly.

Thus

    deemed important -> modeled explicitly

Which is not a tautology. Because of the context shifting your statement is ambiguous. Can you disambiguate by substituting appropriately?

    OD important -> SM explicit
    SM implicit -> OD important

    OD = { objectively , deemed }
    SM = { source , model }

> > It's not really a semantics argument, it's an argument
> > for a method. The method being: step 1) determine (deem)
> > which information is important. step 2) make important
> > information explicit.
> >
> > Mistakes in step 1) have nothing to do with particular
> > data models. As for step 2) I think we could employ a
> > data model of our choice, relational being one of the
> > options.

• Keith --