Re: Syntacs, Semantics, and the Problem Domain

"David Cressey" <dcressey_at_verizon.net> wrote in message news:3E%Qf.670$Rb.124_at_trndny05...
> This topic is a spin off from another topic, where Marshall Spight
> brought
> syntax and semantics into the conversation.
>
> My term "the problem domain" comes from a phrase that crops up over and
> over in "Object Oriented Analysis (Coad&Yourden, 1992). The complete
> phrase
> is "the problem domain and the system's responsibilities". That phrase
> captures in a few words, a disctinction that many of us, myself included,
> keep dancing around all the time.
>
> The person who understands the problem domain, sometimes, called the
> "subject matter expert" is the most underrated stakeholder in the majority
> of large scale database application projects. Especially when you
> consider
> the projects that go awry because the subject was not well enough
> understood when version one was frozen.
>
> In any event, I finally got my answer as to whether a pizza has a set of
> toppings or a list. More importantly, I got an answer about whether we
> should look to the problem domain or the system's responsibilities to find
> the answer: we should look to the problem domain. In other words if you
> really want to know, ask somebody who runs a pizza parlor. If that
> person
> is a franchisee, he may have to accept the franchisor's answer to the
> question, or lose his franchise. But that's where the answer lies.
>
> Now let me turn to the question of syntax and semantics: If I design
> schema
> of tables, the syntax of tables is going to make it look like the set of
> toppings is a set, not a list. If I design a pick file to hold the same
> data, it's going to look like the set of toppings is a list, just
> because
> the convenience of using the multivalue feature is, in this case, going to
> overwhelm any other design considerations.
>
> That makes it seem as though the question is a syntactic one, and platform
> dependent to boot. But it isn't. It's really semantics. Now, most of
> the
> problems I have with the comments of pickies generally in c.d.t. is that,
> nearly always, they come down to the idea that a team consisting of two
> or
> three pickies are so very productive that they can provide all the
> technical
> services to support and run a large scale database.
>

If you're not concerned about consistency or correctness, then just about any team could be that productive.

    Answers:                $5.00.
    Correct Answers:   $50.00.
    Dumb Looks:         FREE.

> I don't think so. I remain unconvinced. And unless there is a FORMAL
> vehicle for speading understanding about :what the data really means"
> among
> all stakeholders, the road leads to hell. "What the data really means"
> is
> really about both syntax and semantics. It's about the rpoblem domain,
> too,
> not just the system's responsibilities. Now this objection is by no means
> limited to Pick. Codd wrote about how the RDM itself didn't pin the
> semantics of a columns down tight enough to make all users of the database
> share a common understanding.
>
> Semantics seem to me to tread on the "problem domain" more so than systax
> does. But I wonder what others think.
>

"What the data really means" is all semantics: syntax is arbitrary. Semantics depend upon the problem domain to provide a frame of reference. Syntax is independent of the problem domain.

>
>
>
>
>
>
Received on Mon Mar 13 2006 - 04:02:09 CET