Re: Attribute name prefixes, domains, joins, ISO 11179
From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Wed, 30 Nov 2005 01:39:25 +0100
Message-ID: <438cf471$0$11070$e4fe514c_at_news.xs4all.nl>
>
>
> 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.
Date: Wed, 30 Nov 2005 01:39:25 +0100
Message-ID: <438cf471$0$11070$e4fe514c_at_news.xs4all.nl>
archon wrote:
> 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.
Maybe you could reconsider not being interested in naming domains.
Suppose you'ld have a 'PaintCode' domain instead of the ambiguous 'Code'
(and have a paintcode authority - you /do/ need one).
Q: What kind of PaintCode is it?