[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: ap210 issue
Tom,
apologies for the delay in replying. There is no "official"
mapping PUBLISHED as yet, so I would not like to pre-empt one, should
one appear in the public domain, which, hopefully, one will soon. In the
short term, the PLCS capability on assigning identifiers seems a good
place to start. Essentially the way it works for a part design is:
An identifer_assignment holds the part type code, and is classified as a
"part_identification_code" (so that you know the function of the
identifier assignment).
An organization is assigned using an
organization_or_person_in_organization_assignment, with the assignment
classified as "Owner_of".
The organization is assigned an identifier corresponding to its DUNS or
CAGE code (or both) (and ISO/DIS 21849 also allows a European code) and
the identifier assignment is classified as a subtype of
organization_identification_code, depending on whether it is a DUNS or
CAGE code.
I'm not sure about the mapping for product_as_individual - do you need
this as well?
This may seem rather more complex than STEP is used to. In PLCS,
classification has replaced the use of strings for role assignments,
since the set of role assignments can then be placed under configuration
control in an external library.
The use of the entity ID strings has also been avoided, since many
parts, organizations, etc. actually carry multiple identifiers. (I saw
one US company boast that after business process re-engineering, it had
reduced the number of renumberings down to 40). I know in practice that,
for a common bought-out part, we apply the original manufacturer's
number, our catalogue number and a NATO stock number, and customers also
often require additional (client defined) numbers. By always applying
the ID through an identifier_assignment, this means systems need use
only one mechanism, rather than two, to find the identifiers. This is
also why PLCS deprecates the use of Alias.
I hope will do until the official mapping is made broadly available
(unless anyone wishes to correct me).
Sean Barker
0117 302 8184
-----Original Message-----
From: AP Interoperability Team Exploder
[mailto:AP-INTEROP-L@ATICORP.ORG] On Behalf Of Thomas Thurman
Sent: 04 January 2006 15:15
To: AP-INTEROP-L@ATICORP.ORG
Subject: Re: ap210 issue
Sean,
The compatibility with UID is an important capability and we clearly
wish to avoid conflicts in approach.
What is the specific mapping from the components of UID to the PLCS data
model?
Best Regards,
Tom
Thomas R. "Tom" Thurman
MS 108-105
Rockwell Collins Inc.
400 Collins Road N.E.
Cedar Rapids Ia, 52498, USA
phone:(319)295-2280
FAX:(319)295-2393
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.
"Barker, Sean
(UK)"
<sean.barker@BAES
To
YSTEMS.COM> AP-INTEROP-L@ATICORP.ORG
Sent by: AP
cc
Interoperability
Team Exploder
Subject
<AP-INTEROP-L@ATI Re: ap210 issue
CORP.ORG>
01/03/2006 07:32
AM
Please respond to
"Barker, Sean
(UK)"
<sean.barker@BAES
YSTEMS.COM>
My reading of UNIQUE rules is that they are formulated as an enquiry
against a database, even if it is an abstract database. For the rule to
make any sense, it needs to specify the scope over which the UNIQUE rule
applies, and this is outside the scope of EXPRESS. There has been some
discussion whether a UNIQUE rule on an identifier is actually useful, or
whether this is something which can only be advised in the user
guidance.
The combination of organization (as id owner) and an id gives a better
chance of enforcing a unique id, however the problem is then one of
ensuring the id owner is uniquely identified. This could be done by
applying an id to the organization, with its organization-id owner -
such as the DoD or independent organizations such as DNV - however, this
gives the possibility of infinite regression. Alternatively, the
organization identifier could be classified by origin (e.g. Dunns code,
CAGE code), since there are relatively few systems of organization
identifiers that are of interest.
The whole problem of identification in open environments has been
extensively discussed (for many months) in the PLCS project, and the
conclusions are described in the PLCS capability assigning identifiers.
One of the most significant decisions was NEVER to use Product.id, as
without the context of identifier owner, this attribute is not
meaningful. In PLCS, all identifiers are assigned using
Identifier_assignment with an associated organization in the role of
identifier owner, and with an assigned identifier classified as CAGE,
DUNNS, etc. One of the reasons for this was to enable compatibility with
the UID approach now mandated in the DoD.
Given the current pressure to use UID, and the increasing interest in
PLCS, I would strongly advise any BAE SYSTEMS company to mandate
internally the PLCS approach to identification, and to urge its use in
any contracts with BAE SYSTEMS.
Sean Barker
0117 302 8184
-----Original Message-----
From: AP Interoperability Team Exploder
[mailto:AP-INTEROP-L@ATICORP.ORG] On Behalf Of Nettles, Darla
Sent: 20 December 2005 16:08
To: AP-INTEROP-L@ATICORP.ORG
Subject: FW: ap210 issue
*** WARNING ***
This mail has originated outside your organization, either from an
external partner or the Global Internet.
Keep this in mind if you answer this message.
Response forwarded from Keith
Darla Nettles
-----Original Message-----
From: Hunten [mailto:khch@charter.net]
Sent: Tuesday, December 20, 2005 10:17 AM
To: Nettles, Darla
Subject: Re: ap210 issue
I do not see why this is a universal requirement. No other APs have
come
forward with this requirement, so I would say that the onus is on AP210
to
apply the constraint within their domain.
If the AP210 team wishes to make this universal within STEP, then we
must
get expicit consensus from all AP teams involved.
I wll try to call in - but I will be driving into town to take my car in
for
service so I may drop out.
Keith
----- Original Message -----
From: "Nettles, Darla" <Nettles@aticorp.org>
To: <khch@charter.net>
Sent: Tuesday, December 20, 2005 8:42 AM
Subject: FW: ap210 issue
Keith:
You should probably take a look at this and weigh-in
Darla Nettles
-----Original Message-----
From: AP Interoperability Team Exploder
[mailto:AP-INTEROP-L@ATICORP.ORG] On Behalf Of Thomas Thurman
Sent: Monday, December 19, 2005 4:13 PM
To: AP-INTEROP-L@ATICORP.ORG
Subject: ap210 issue
We have one issue I would like to address and get an actual answer on:
how to handle unique constraint on product.
Here is a current summary.
We didn't discuss this on the recent AP-INTEROP calls and now we need a
final
decision:
- do nothing (default when it does not come to a decission)
- add a UNIQUE rule on Product.id
- add a UNIQUE rule on Part.id, Document.id, Template.id, ...
- add a global where rule to ensure that the combination of product/part
and id_owner.name is unique
Tom
Thomas R. "Tom" Thurman
MS 108-105
Rockwell Collins Inc.
400 Collins Road N.E.
Cedar Rapids Ia, 52498, USA
phone:(319)295-2280
FAX:(319)295-2393
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]