Re: cdt glossary [several items]

mAsterdam wrote:

[...]

>> Attempt: an address is a position in some address space:
>> unlike references, on which the only meaningful operations are
>s/meaningful //
>> comparison for equality and dereferencing, operations such as
>> ordering and subtraction are meaningful on addresses.
>s/meaningful/possible/
>
>Ok?

Yes, probably better.

>>> [Data]
>>> "Known facts that can be recorded and have implicit meaning."
>>> -- Fundamentals of Database Systems, Elmasri & Navathe.
>>
>> Not so good: the same data can have different interpretations.
>
>Only when you adhere to the idea that data may have no meaning.

No.

>> [...]
>>
>>> Warning: tongue in cheek definition
>>> Information is what you want. Data is what you are given.
>>
>> Makes sense. What is more, this is the literal meaning of "data".
>
>:-) , but I am not going to explain the joke in the glossary.

Well, of course the meaning of "data" could have floated farther away from its origins than it has.

>>> [Information]
>>> 0. data in context, data with meaning.
>>> (This implies a definition of data as being without context,
>>> without meaning - see data)
>>> 1. new data to the receptor.
>>> 2. available data, relevant to some decision or action.
>>> Also see [Data].
>>
>> I don't think this correct: information is not data with meaning,
>> it is meaning of data.
>
>That is a new one to me. Do you have a soure?

Oxford English Dictionary:

 information (noun)
   1 facts or knowledge provided or learned.    2 what is conveyed or represented by a particular sequence of symbols,      impulses, etc.

Wikipedia:

  Information is the state of a system of interest.   Message is the information materialized.

I'd say "message" is "data", but I was trying to provide a more general description than "state of a system of interest". The OED does it better.

>I like these communication layers (bottom to top):
>Fatic, Syntactic, Semantic and Pragmatic -
>but I mostly take care to explain when using
>them, sometimes even dropping the term itself.

I'd never heard of fatic, but you explained it well (on Apr 7, 2006).

>>> [Key]
>>> A value, used to identify something.
>>> See also primary key, and (TODO:) foreign key.

[...]

>Improvements welcome.

"One or more relation attributes that form the left hand side of a functional dependency, i.e. such that all different relation tuples differ in the value of at least one of these attributes." ?

>>> [NULL]
>>> Roughly: a special marker that can be put in a place
>>> inside a data structure where an actual value is expected.
>>
>> Isn't this *exactly* what NULL is?
>
>Arrgggh! (just search for 'NULL' in the archives for why).
>Any objections to s/Roughly: a/A/ ?

None at all.

[...]

>Coming up with an agreeable definition of 'Object' in cdt
>will earn you real beer (in Amsterdam).

I'll think about it.

>>> [Primary key] (SQL, not RM)
>>> A key of a table, composed of one or more
>>> named columns, uniquely identifies a row in a table.
>>
>> Only if you mean: such that every row's values for its key columns
>> uniquely identify that row in the table.
>
>Yes. Now how to rephrase this with only adding
>the necessary complexity?

I don't think it can be done.

>>> A table can have only one primary key.
>>
>> In other words: one such key, picked by the schema designer.
>> (How? I don't think there is a single universal criterion.)
>
>It is a trade-off. I like the list Bob Badour uses,
>e.g. in thread "Separate PK in Jxn Tbl?" he wrote:
> > The design criteria for keys are:
> > uniqueness, irreducibility, simplicity, stability and familiarity
> > (in no particular order.)

Looks good. Add it to the lemma then? You also have stuff about NULL ...

[...]

>Columns may be ordered or named.
>
>There are corresponding formalisms: the unnamed (why not 'ordered'?
>I really need to read the Alice book) perspective and the named
>perspective. I just learned that.

I think it's because the order is essentially arbitrary; the ordering is never used. No greater than or arithmetic on column indices.

>>> [Type]
>>> " TYPES are sets of things we can talk about;
>>> RELATIONS are (true) statements bout those things."
>>> -- Chris Date, Feb 2004
>>
>> This is just wrong.

[...]
>> A type is *not* a set.
>
>http://en.wikipedia.org/wiki/Type_system says
>"A type indicates a set of values that have the same sort of generic
>meaning or intended purpose"

There's a big difference between "indicates" and "is" here. The absence of a comma after "values" is important as well.

But I have to withdraw what I wrote. I was thinking of set theory, in which sets are entirely defined by what their elements are. In practice, when we talk about sets such as the natural numbers or, say, Dates, we're really talking about types. So if anything's wrong, I should blame set theory, rather than Date.

>> Does the Third Manifesto use the term 'class'?
>
>First edition, P 15:
>In discussing "What concept is it in the relational world that is the
>counterpart to the concept /object class/ in the object world",
>(yes, the same megalomania here, twice) they argue that the answer to
>this question should be "domain".

Nice! I agree. (And I don't object to the term "world" here.)

>>> [Transaction]
>>> A set of database operations constituting a logical unit of work.

[...]

OK, as a most general definition this is good, but more detail is perhaps in order.

-- 
Reinier