Re: Attribute name prefixes, domains, joins, ISO 11179
Date: Tue, 29 Nov 2005 17:26:12 +1100
> 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"
I'm afraid I have no sound logical reason for putting the class term
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