Re: Mixing OO and DB

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 16 Feb 2008 01:44:13 +0100
Message-ID: <47b63102$0$14357$e4fe514c_at_news.xs4all.nl>


Dmitry A. Kazakov wrote:
> mAsterdam wrote:

>> Dmitry A. Kazakov wrote:
>>> mAsterdam wrote:
>>>
>>> But you certainly should have a mental picture
>>> where "data" plays some role. 
>> Is it necessary for both sides of the border to fully understand the
>> formalisms en vogue at the other side? I don't think so.
>> Your position - I trust you'll correct me if I'm wrong -
>> is: there is no data, no other side, no border to cross.

>
> Maybe what you are using "data" for, could be common.

That's nice. Let's see if we can get rid of the scarequotes. Call it blurk for now.

>>>> ... Which primitive elements does your formal system have?
>>> Value, type, variable, operation.
>> That looks rich enough to get somewhere.
>>
>> Somewhat OT to this thread - just because I am curious:
>> do you have a reference to definitions/descriptions of how these act 
>> together you consider worthwhile?

>
> Date's definitions were OK for values and types.

> Any value has exactly one type.
We know that doesn't work in practise, but that may be due to the poor type systems (or their implementations) in use. Maybe it works in theory and just not yet in practise - I really don't know. Anyway, your statement does sort of draw type into the basics of the common ground as well, no? For precision: I do not need to accept "Any value has exactly one type." in order to accept blurk.

> Variables map the computational states onto values. I think it would
> be more or less acceptable for anybody. Much more difficult is to agree on
> subtype and class. Class is a set of types. Subtype is a type relation of
> some properties (transitive, reflexive etc), and so on.

I agree that that is more difficult. Let's not rush here.

>>>>> Bad. It means that you have to formalize "memorize" in some quite tricky
>>>>> way. Honestly I don't know what could be the difference between "memorized
>>>>> Pi", "not-yet-memorized Pi", "once-memorized-but-forgotten-by-now Pi" and
>>>>> so on.
>>>> Are you suggesting π is data?
>>> Yes. But you can take some P(pi)=true instead.
>> Or R(P(π)) - packaging a symbol/value doesn't make it data.
>> In order to be data it should convey a fact, relevant in a
>> sense outside the formal system, i.e. an observation, or the basis
>> for a decision.

>
> Then I see no disagreement anymore. Is all that rant going on for years
> between c.d.t and c.o just about what to feed to the beast?

Heh. Could it be?

> [ BTW, it was exactly the point I made in my first post to this thread. It
> is not about theory it is about selling stuff = making sense outside the
> system = getting money out of customers. (:-)) ]

I see the smiley. :-|

>>>>>>> May I translate data into a different
>>>>>>> representation and then erase the original record? 
>>>>>>> Will data still be there?
>>>>>> Iff it conveys the same facts as the original record, sure.
>>>>> OK, that means that data = facts + record medium of:
>>>>>
>>>>> D = (F, R)
>>>> Guessing about your notation as D denotes Data, F denotes Facts, R is 
>>>> the requirement that the fact is recorded, R is just 1.
>>> (A side question, in "R is just 1", were "just 1" data or fact?)
>> It is the 'recorded' property of the fact.
>> As you deny the existence of facts and data
>> I don't see how this is relevant to you.

>
> In order to be able say, that the property (or whatever) "is 1" has to be
> data (to be any "useful", using your terms). Thus it itself needs this
> property, which constitutes an infinite recursion.

If you are going to accept blurk, you need to get used to the discipline of not accepting that something is blurk just because there are some symbols. We need to establish the common (/in/formal) understanding first.

A plot without an understood legend is a meaningless drawing. With it, it is a depicted chunk of blurk.

>>> And, equivalently, you cannot describe
>>> recording in terms of either data or facts.
>> Yep, that's the fate of primitives and semi-primitives.

>
> In other words being recorded / data is incomputable.

Being recorded - maybe, but data - why not?

>>> But I see no disagreement in the core issue: 
>>> a formal system does not operate meanings.
>> I see no agreement to the core issue:
>> A formal system needs to support meaning to be useful.

>
> "To support" needs to be defined.

No, it merely needs to be understood. A definition is neither a necessary nor a sufficient conditon for understanding. It may sharpen it, and it may assist in formalizing the understanding.

> If you mere mean self-consistency or Turing-completeness, then it is OK.

It is not what I meant.
In fact I wonder how you arrived to think that is what I meant.

> If you mean something finer than that, you have to say what.

Nothing finer. Coarser if anything.
What is the raison d'être of the structure of a bridge? That's easy: it supports the substance of the parts of the bridge to interact such that the bridge can do what it is designed for: carry traffic without blocking what is underneath. Take away the purpose of the bridge, take away the substance, either way the structure is futile.

> Anyway it would be not "I want data, else there is no
> common ground." It would be about the structure of the formal system which
> you wished deploy for what you call data. (Maybe, I could to do it as well,
> but for something having a different name.)

If that what it takes to get rid of the scarequotes, I have no problem with you calling it something else if there are enough common associations and isomorphisms - and no blocks. Do you have a name in mind? Blurk sucks.

>>> It is we who assign meanings to the inputs and outputs, and, at
>>> yet another level of understanding, judge about the formal system as a
>>> whole in terms of its usefulness, for example.
>> It is IPO vs. IDO (late 70's debate) all over:
>>
>> Input values - Process - Output values: It does not matter what the 
>> input means, as long as the output is correctly processed from the input.
>>
>> Input process - Data - Output process: The input process (datacapture) 
>> is to be constrained in order to prevent inconsistencies in the data. 
>> The output process (rendering) should be validated not to corrrupt 
>> meaning. "You have  01 vacation days left". Ouch - but just within the 
>> currently acceptable range.

>
> In both cases you constrain a process. So if complementary of views was
> your point, I think it is invalid.
  1. This does not follow.
  2. Complementary views - on what?

> Further if you want to deal with D in
> IDO, you need a language to describe D.

Schema + external predicates come to mind.

> That is a formal system, a process.
> I.e. you cannot abstract D out of some processes, generating, carrying,
> understanding data.
>

>>>>> Yes, we cannot reason about meaning while staying 
>>>>> within the same formal system.
>>>>> Because you seem to bind data with a meaning (as I do), that immediately
>>>>> kicks the notion of data out of the formal system. So data do not exist
>>>>> there. Which is all my point! No data, nothing to worry about.
>>>> And the result is a hermetic system as useful as solipsism.
>>>> Have some fun there! I'm out waiting until you are bored of it.
>>> OK, I am back on vacation. How are you going to formalize something which
>>> cannot be formalized? (:-))
>> Hey, I am not the one eager to formalize without
>> a proper, shared, informal understanding.

>
> Neither I am.

It sure looks that way, even in your post I am replying to now.

> But shared can be also a method of understanding.
> You consider understanding as a premise (data (:-)).
> Do it rather as process (behavior (:-)).

--
What you see depends on where you stand.
Received on Sat Feb 16 2008 - 01:44:13 CET

Original text of this message