Re: Property sheet, ad hoc, property page, flexible data
Date: 24 Jul 2005 20:19:17 -0700
Message-ID: <1122261556.993275.167950_at_g47g2000cwa.googlegroups.com>
dawn wrote:
> Marshall Spight wrote:
>
> > because the values in
> > the name column *aren't* metadata, since we don't know what they
> > mean, other than "they are names."
>
> Who is the "we" in that sentence?
The programmer and the software he writes.
> The user knows what they mean and
> can, perhaps, write reports that qualify rows based on the value
> related to a particular tag.
I disagree. The users (plural) *don't* know what they mean. The reason this doesn't work is because there is no canonical, homogenous user who knows what he knows. Instead there are vast seas of users. And while I would agree that one particular user probably knows what he means when he enters a particular name, we have no reason to believe that anyone else will agree. In fact, we have strong reason to believe that chaos will be the order of the day.
Tags/labels/what have you are lexical data merely; they have no semantics exactly because they have no schema. (Beyond the minimal "this is the name, and this is the value.")
> > you're limited to exactly whatever domains you allow up front;
> > probably int and string, say, but certainly not, say, three pairs of
> > int/float tuples and a list of x, y points.
>
> Or perhaps a relation-valued attribute ...
Sure.
> I'd prefer they were all defined as strings and
> cast to whatever is needed at the time, but in a SQL-DBMS, that might
> not be as easy.
That is a much worse way to do things. If evenything is a string and can be cast to anything as needed, then you can't reason about your code. It has no useful statically analyzable properties.
> I didn't ask for that
> gmail star, but I really appreciate it and suspect that it increases my
> productivity.
I am glad you are enjoying gmail.
I would propose that the star is not an example of a used defined fields, but gmail labels are. They match your option 2) pretty well.
Marshall Received on Mon Jul 25 2005 - 05:19:17 CEST
