Re: Attribute name prefixes, domains, joins, ISO 11179

archon_at_quantumfire.com wrote:

> Again, this tells us only that the column exists on the widgets table.
> To infer from this that you cannot have a PaintCode without a Widget
> would be incorrect. A PaintCode just happens to be an attribute that a
> widget can have, and it has two of them. You can certainly have
> PaintCodes even if you dont have Widgets, there they are in the Paints
> table. In fact, if we were to include "Widget" here, we would have
> "WidgetTopHalfPaintCode", which would contradictingly contain two
> different class terms ("Widget" and "Paint").

I should have added, here, that this naming convention still has a problem when held against 11179: In the attribute name "TopHalfPaintCode" we have a class term (Paint), a property term (TopHalf), and a representation term (Code), but they are in an incorrect order. As I said above, I believe the class term is correctly "Paint" and not "Widget". The way I decide what the class term is for any attribute X would be to come up with the attribute name without the class term (call this Y), and then ask the question "What kind of Y is X?" So in the widgets table, where X is "the unique identifier for a widget with a number representation" and Y is "Nbr", The question is "What kind of number is Nbr" and the answer is "Widget", so the full name is "WidgetNbr"
But for X = the code representing the paint used on the top half, I can ask 3 different questions and get at least 2 different answers:

Q1: What kind of Code is it? A1 = Paint
Q2: What kind of TopHalf is it? A2 = Widget
Q3: What kind of TopHalfCode is it? A3 = ???

I'm afraid I have no sound logical reason for putting the class term "Paint" in the middle of the attribute name. Received on Tue Nov 29 2005 - 07:26:12 CET