On Tue, 29 Jan 2008 11:59:00 -0000, Michael Kay <mike@s...> wrote:

>> However, you
>> wouldn't normally expect to factor out "Person" as the common
>> superclass; that's the kind of technical construct that is
>> appropriate for a logical model, but often inappropriate for
>> a conceptual model.
>
> I think it's very common, and very beneficial, to find abstractions like
> this being created in the business domain rather than the technical  
> domain.
> For example, legislation will talk about "vehicles" rather than cars,
> bicycles, and lorries; HR people will have a term that covers employees  
> and
> full-time contractors; and finance people will lump together cash and
> buildings as "assets". It's true that the technical design might identify
> further abstractions (for example treating phone numbers, email  
> addresses,
> and postal addresses as examples of something more general) - but these  
> are
> far less valuable than those that originate in the business, because you
> can't build common business processes around them.

I was abbreviating things a bit for the purposes of the previous e-mail.   
What I should have said more clearly is that the conceptual model should  
be the business experts view of the problem, using their terminology and  
their way of viewing things.  The logical model should be the technicians  
view of teh solution, using their terminology and their way of viewing  
things.

So, what I should have said is that introducing "Person" as the common  
superclass of "Employer" and "Employee" is something you would normally do  
in the logical model, but you would only do that in the conceptual model  
if the business experts view the world that way.  If the business experts  
don't think about the world that way, then I wouldn't add the superclass.   
If they do think about the world that way, then I would.  The model has to  
represent their view, rather than a particular view of how model should be  
constructed (especially as regards "normalisation" of the data via  
introduced ancestor classes).  The reason for this is that the conceptual  
model needs to remain accessible and understandable by business experts.   
If the conceptual model turns into something that is more technically  
formal and proper, but less understandable to the business experts, then  
its value is lost.

This is how I how I discuss conceptual/logical/physical in the course that  
I've given the last few years at the CSW XML Summer School in Oxford.

Cheers, Tony.
-- 
Anthony B. Coates
London, UK
+44 (79) 0543 9026
abcoates.work@y...

From mike@s... Tue Jan 29 15:58:21 2008
Received: from aji.w3.org ([133.27.228.225])
	by