Indicators + the database
Peter Dobcsanyi
p.dobcsanyi at designtheory.org
Thu Oct 2 19:29:13 BST 2003
Let me quote again what Peter said:
On Thu, Oct 02, 2003 at 02:44:01PM +0100, Peter Cameron wrote:
> On the point of principle, I view indicators as being for humans
> rather than for computers, and would rather have indicators for
> concepts for which a body of theory exists than for "atomic" concepts,
> whataever that means.
For me, the point is not so much "human understandable", but the
realization that a good ext-rep indicator is not necessarily atomic. A
good ext-rep indicator is one which is being enquired about a lot by
humans, machines in general, by whatever agents. With other words, it
is popular; maybe because it is a "concepts for which a [nice] body of
theory exists" (inclusion of 'nice' from me).
On Thu, Oct 02, 2003 at 01:05:48PM -0400, John P. Morgan wrote:
>
> On Thu, 2 Oct 2003 17:21:32 +0100 Peter Dobcsanyi
> <p.dobcsanyi at designtheory.org> wrote [...]
> >
> >These two principles are not always easy to reconcile.
> >
>
> I have missed things before, but do we really have anything on the
> table that is not *easy* for humans to understand?
What I meant, i.e. the difference between atomic and complex properties,
has nothing to do with how easy humans can understand either of them.
For example, indicator 't_design' is a good ext-rep indicator but
unlikely to make it into the database indicators since it can be
expressed in terms of more simple, atomic, indicators, which, likely,
can also be used to build up other properties on demand.
> On Thu, 2 Oct 2003 17:21:32 +0100 Peter Dobcsanyi wrote:
> >Indeed, we should have two sets of indicators, one for the ext-rep
> >and one for the database. These two sets are neither equal nor
> >distinct. They should be "optimized" according to different
> >criteria. We can, of course, try to make their intersection as large
> >as possible but the specific role-oriented optimization must have the
> >priority.
>
> Sorry, I don't know if I really get the point. If an indicator is not
> in the ext rep, how does the user know about it? If the user does know
> about it and can use it, for selecting a list of designs say, then why
> should it not be in the external rep?
The user need not know much about the internals of the database, he just
should go about his design business and ask stupid questions. "Stupid"
here means "popular" :-) so chances are that it can be expressed in the
ext-rep, assumed we did a good work with measuring up the market for
ext-rep, in particular, for the indicators. It is the job of the several
layers of software between the user and the database (GUI, expert
system, middle layer etc.) to figure out how this query can be served
using what is inside of the database.
I am not against having these two sets of indicators as close as
possible, the closer they are the better. However, I do not believe that
these two sets of indicators, or in general, the ext-rep and the
database structure can be or should be made equal.
My stating this principle should not be taken as a vote in any way in
the ongoing discussion about particular indicators. I don't know enough
to formulate good maths/stats arguments, so I am listening and waiting.
Until next Monday 24:00 GMT, then I'll vote: if agreement has not been
reached none of them will make it for version 1.0 <bummer!>
Of course, nothing will prevent you guys to keep arguing about them and
put them into version 1.1 perhaps just a few days later assuming that
this won't break backward compatibility. Keep in mind, version 1.0 is
not the final step just a step in a, hopefully, very long development.
-- ,
Peter Dobcsanyi
More information about the Developers
mailing list