Re: Modeling Address using Relational Theory

dawn wrote:
> Marshall Spight wrote:
> A very significant and oft used operation that is
> done with address is to order the lines of the address.

That's not an operation. You don't start with them in one state and end with them in another. There's no function; you don't have inputs and output.

There's no place in your code where you sort city, state, and zip, for example.

> Ordering is THE KEY function
> that is applied to these attributes -- would you agree with that?

No. The order you are speaking of is not an attribute of the data; it's an attribute of the presentation of the data, which is consistent with the fact that we're speaking of attributes of the metadata.

The operations we look at to decide whether something is a list or not is the operations on the data, NOT the operations on the metadata.

> Do you mean that the semantics of these two
> lines includes no ordering?

Yes.

> What might you name them otherwise to
> avoid all hint of ordering information in the naming?

I see no need to rename them. The names are hints to the human; they have no meaning to the computer.

> >From a programmer's perspective, the ordering operation is one of the
> few things we have to care about with these text fields, perhaps along
> with max length.

Only in the UI. In the business logic, there is no concept of one being ahead of the other.

> We need to put one of these first and the other second.

What exactly do you mean by "put"? Are you talking about the in-memory layout of a C struct? I believe you're talking about the UI, which has no relevance for the sematics of the fields.

> When these are two separate attributes, the way we know which
> one is ordered before the other is by reading the attribute names.

That's just as true for city, state, and zip, though; and you've agreed they aren't lists. So this criterion is not sufficient.

> Is it the case that you do not see the ordering function as an
> advantage of declaring these addressLines to be a list attribute, or
> that it is not sufficient to justify use of a list from your
> perspective?

I don't see the ordering function in the first place.

> > just
> > like I don't think firstName, lastName has any order, even
> > though *conventionally* *in the USA* we *present* one always
> > before the other. For both names and address lines, in other
> > countries the conventions may be different.
>
> I completely agree when it comes to the name and do not see the same
> pattern with the address.

To me they are the same.

> This one is not an experience issue. Isn't "ordering" a list
> operation?

No. *Sorting* is a list operation. Note that one never sorts the address components.

Let's put it another way. What if we went in to your source code and globally renamed addr1 to addr2 and vice versa. The UI would stay the same, though. No code would break. In fact, if you stripped the binaries, the before-and-after would be binary-identical.

This demonstrates that there are no list *operations* being done on the fields.

> It isn't an operation ON the list, it is an operation on
> the data -- it is intrinsic in the type "list" where otherwise you need
> to apply the operation to two separate attributes.

I don't agree that it's an operation on the data.

> It might sound like I'm rehashing, but I think that there is the
> potential here for me to communicate this question in a way that I get
> back the type of information I am seeking. I'm trying to understand if
> there is a logical rationale, aside from constraints in the target
> dbms, for a conceptual or logical model of address to split these lines
> out into addr1, addr2.

Sure. As I've said, I wouldn't model addr1 and addr2 as a list in a Java object, even in the absence of, say, jdbc. They'd be separate properties, just as city and zip would be.

> Would the logic be the same if someone were to suggest that word1 of a
> description, word2, ... word20 should be split out into twenty
> attributes rather than putting them into a space-delimited single
> attribute? If not, what am I missing?

No.

You're missing the fact that your string of words doesn't have any structure beyond "description" but the address does.

> The January budget is not interchangable with the December budget, but
> that doesn't mean that we would not want these in an array, right?

Yeah, "interchangable" was a poor choice of words.

> > If I were modelling a chessboard, say to solve
> > the 8 queens problem, each one of the 8x8 squares is distinct
> > from the next, but they're all instances of the same thing.
> > I'd certainly use a list of lists and not make up 64 names,
> > or even use 64 attributes with names like square35. I'd probably
> > use a list even if it was 2x2.
>
> But these square are not interchangeable either.

They kind of are, though. The only relationship they have with each other is a spatial one. 2,2 isn't any different than 3,5, except for its position. They have no differing semantics. The semantics are all semantics for the entire grid, not for any given square.

> If I thought this was just perspective, I would not be so persistent.
> Based on your description, I'm thinking there is some world-wide
> standard related to the second & third lines of an address of which I
> am not aware that would render these lines as having different
> meanings.

I really haven't done all that much with addresses and I'm not all that into ISO standards. (Sorry, Joe. :-) I'm just going off of caffeine, stubbornness, and my own understanding of semantics. Plus some address work I did on a big webapp.

Marshall Received on Sun Sep 04 2005 - 20:25:47 CEST