RE: [xml-dev] Discover data patterns or Create data patterns?

["Len" <cbullard@hiwaay.net>]

"Len will tell me I've got it all wrong..."

Why?  The challenge isn't abstraction.  An abstraction is post-process and
can accomplish a goal including sharing or explaining it to anyone else.

Processes act on data.  A pattern is an output.  No abstraction without an
observer "exercising".

I think method can be taught.   It isn't necessarily a lesson in truth, but
then, except for logical formalisms, how do we know what is true?  The
investigation would be to pick or create the formalism.  

What values do you value?  Choice of choices, second order or third order
systems.

So as Steve said, "What Michael said".  It amounts to the same thing.

len


From: Michael Kay [mailto:mike@saxonica.com] 
 
Rather than "uncover patterns", I would say "formulate abstractions". But it
amounts to the same thing.

Aristotle said that you discover types by identifying sets of instances with
similar characteristics - there are lots of woolly things in that field,
let's call them sheep. Plato said that instances come into being by being
formed from types. Chicken or egg? Len will tell me I've got it all wrong...

Either way, data analysis is essentially an exercise in grouping objects
into types, and the people who do it best are those who are best at finding
useful abstractions. When the abstractions already exist in the outside
world, the data analyst can be said to be discovering them; when they don't,
he can be said to be inventing them. Usually it's a bit of both: when you
decide that "geographical region" is a useful concept to include in your
model, you can't claim to have invented the idea, but you will have to do a
lot of work to define precisely what you mean by it.

I don't think that the ability to formulate good abstractions can be taught
- but I think it can be learned.