Re: Ping: dawn, some mvl questions

Keith H Duggar wrote:
mAsterdam wrote:

Keith H Duggar wrote:

Precisely! There is a wealth of PHYSICAL information
lost whenever we change PHYSICAL representation.

Your screaming doesn't make it more right.

The CAPS were for emphasis not screaming.

Ok. To much usenet, I guess. I am used
to /this/, _this_ and *this*, (for resp. italics,
underlined and bold, some newsreaders even render
them so) but not to THIS.

Accepted.

And the emphasis
was not part of the argument but rather part of the
communication. I emphasized in hopes of avoiding key words
being lost as I thought happened before when you made the
statement

"So let's lose the order? I don't think that is wise
always."

Since IMPLICIT was key (and you added universal qualification).

The information itself is not physical. It is carried by
physical media, allright.

Ok. No need for us to descend a spiral of semantics, so I will
go along with you on this.

That would be /ascending/, in my view.
It don't mean a thing if it don't mean a thing.
If this is to poetic to your taste: data structures
have no reason to exist if the values they hold
do not (directly or indirectly) carry meaning.

Chris Date's use of an external predicate with
every relation, necessary to interpret it's tuples
into true propositions, serves this purpose.

We could choose to preserve whatever is in the layout and
the handwriting by scanning an image of the piece of paper
(which is what many companies do, BTW).

I disagree. We do NOT preserve "whatever". Conversion from
one physical system to another always loses something.

If this wasn't clear yet: I do agree with your observation
on the loss from physical conversion (until all data
is captured - after that lossless replication and duplication
is possible). However, by retaining as much as we can
of the whatever, we keep the possibillity open of capturing
some more data from the same source (document in this
case) later on.

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? :-)

Perhaps you have defined "layout" to satisfy your
scanner implementation argument.

?

We could choose to preserve some of what is in the layout
by mimicking the original layout in your textfile.


Yes though "some" is key of course.

Yep.

And if we wish to
preserve across physical implementations we had better make
the "some" explicitly part of the logical model. That is part
of Codd's point in 1970 1.2.1. Furthermore, if we wish to
communicate the "some" then it must be made an explicit part
of an agreed upon common model. (communicate, explicit,
agreed, common).


Hence the great importance of developing a LOGICAL model
and to make all information DEEMED important EXPLICIT
rather than IMPLICIT.

As soon as we have perfect knowledge, we can do that. IOW
it is a goal not allways feasible.


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.

Thus it is obviously always feasible to make known,
deemed important information explicit.

That's optimistic, IMO.

Your point applies to
other information that is either unknown or deemed
unimportant. Now sure, we may deem information unimportant
that later turns out to be important. This happens all the
time, particularly in scientific research. For example not
measuring observables that later we theorize are important.
Then the experiments must be repeated. However, this is a
decision problem (or a fact of ignorance) not a problem with
a logical data model.

Respect your ignorance. ;-)

Say we have a list.

We don't, at this time, know wether 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 wether 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.

By keeping the list as a list no such awkward choice
has to be made.

BTW, how is a list not logical?

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.

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.


The key here is "not based on the content".

Indeed.


That is the problem we must avoid.

Not if we have lists.


For by content you must mean LOGICAL content.

Which, BTW, includes implicit content. Yes.


Ok, back where we started full circle. Seems we are not
effectively communicating and I'm not up for stepping beyond
common sense to a protracted semantics debate. It seems we
do not share the same sense for words such as physical,
logical, content, and perhaps implicit.

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

Finally, I really don't understand the repeated "nails
and hammers" analogy in this context. Are you trying to
say "if all one has is LOGIC everything is LOGICAL"? :-)

Do you really think that?

I'll translate: If all you have is sets, order is
either lost or has to be made explicit in one of
several clumsy ways.


It's best to clearly state initially what you mean to say
without relying on cliche analogies. Doing so will reduce
the likelihood that translation is required. Especially when
the analogy may be quite flawed as I believe this one is.
Consider that the RMD has much more than just sets. Thus the
"all you have is sets" is flawed right from the start.

'"all you have is sets" is flawed right from the start.'
Agreed :-)

More importantly, explicitly and clearly stating what you
actually think may reveal important information. In this
case you reveal that you categorize a relation as "one of
several clumsy ways".

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?

we probably
have little more to communicate on this particular topic.

Oh :-( Ok.
.

Relevant Pages

  • Re: Ping: dawn, some mvl questions
    ... context) it is impossible to retain all of the ... the model has lists or not seems irrelevant. ... deemed important information explicit. ... explicit what is usually implicit, ...
    (comp.databases.theory)
  • Re: Ping: dawn, some mvl questions
    ... The CAPS were for emphasis not screaming. ... Since IMPLICIT was key. ... communicate the "some" then it must be made an explicit part ...
    (comp.databases.theory)
  • Re: Code block literals
    ... > What's implicit to me is that the use of an iterator is never specified. ... But such expansion wouldn't be any more "explicit" than USING the ... *iterator usage* in the two languages. ...
    (comp.lang.python)
  • Re: Code block literals
    ... > implicit invocation of an iterator, ... special operation works as indicated by its syntax. ... would not be "more explicit", ... This has nothing to do with "eschewing code blocks", ...
    (comp.lang.python)
  • Re: ? RE: Default Transfer Syntax in Part-10 files?
    ... I find there is no shortage of "bad ideas" in the DICOM standard, ... I find it surprising that the default transfer syntax isn't mandatory ... > supports, and they are all explicit VR, ergo implicit VR ...
    (comp.protocols.dicom)