 |
 |
On Mon, Nov 28, 2011 at 5:15 PM, Alexander Johannesen <[log in to unmask]> wrote: Hi, First, I should apologize for my tone a bit. It's been an odd day, and, yeah, email. Sorry to be overly flippant. > Understanding this is not disconnected from designing data models > *right*. It's the same thing. By extension I should mention that > people are terrible at telling you what they want or need, but they're > good at telling you what they hate. If nothing else, I'd suggest to > tap into that wonderful hate. I think we're probably actually talking about the same thing with different language. Understanding what people want doesn't fall under the purview of what I think of as 'data modeling' -- I imagine data modeling as being quite limited in scope. So, if data modeling involves understanding actual business needs and making them possible, than I agree completely. But it sounds a bit like saying 'everything follows from user interaction design -- but of course you need to represent your underlying data somehow' ;-) There are lots of facets to building software, and representing data structures is just one of 'em. >> But an 'all flows from data modeling' thought process leads to FOAF, >> FOAF leads to hate, and hate leads to suffering. > > This sounds suspiciously like someone who don't understand the perils > of data models and how they affect all the FOAF and hate that's built > up around its faults. FOAF and suffering is a symptom of shitty data > models, not shitty code. Unless you've got a little more meat on that > argument? :) You're exactly right -- my beef with FOAF is that it's a detailed data model written for a need that didn't particularly exist. I'd argue that a better data model wouldn't help it, as the concept is flawed. My stereotype of the 'think of the data model first' approach is lots of time spent developing a data model that solves a need I think might exist, but actually doesn't. I've built software like this and it made me sad. -n