[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs] Extend scope of C001 Assigning_identifiers?
|
Seems
difficult to swallow, but we do seem to have gone around a few times. We created
a modular AP but have ignored the modules and then invented capabilities to
draw out the specialisations and now seem to specialising the specialisations. Gordon -----Original
Message----- I’ve been trying to follow this and now
think I understand what this is about… the PLCS DEX team is re-discovering the
STEP architecture. Only now: DEX = Integrated Resource Schema Specialized DEX = AIM short form selecting subset
of DEX resource schema Instantiated DEX = AIM short form plus
Rules, reference data and specific implementation guidance. Next you’ll find you need to formally
represent the business concepts (ARM application objects) and define their
relationship to your DEX (mapping table). If you’re going to do all that, you might
as well use something closer to STEPMod rather than how DEXLib works. We go ‘round and ‘round… Cheers, David -----Original Message----- Martin
It is
a question to which degree we need "specialized" DEXs and
capabilities, this is something we have to sort out. The objective for the
definitions below (documented in DEXLib introduction) is to reduce the amount
of Exchange agreements to a minimum. This will reduce the need for special
tailoring of translators. The objective is to reduce implementation
costs. By standardizing "instantiated" DEXs and capabilities we
eliminate the abstraction level and introduce a simplification that will make
implementations more effective.
We
are of course open for ideas that help to reduce quantity of instantiated
capabilities and DEXs.
It
seems like we have a choice between two different regimes for PLCS
implementations. One is to use the current level of precision in DEXLib. This
will require extensive use of exchange agreements and translator tailoring
for new exchanges. DEX000 (DEX Template proposal) offers a solution to reduce
cost and time delay for new exchange scenarios.
DEX types
Three levels of DEX
precision may apply in order to specify a data exchange set. · Generic DEXs define a comprehensive data exchange set that
inherently captures a number of specific data exchange ideas. A generic scope
opens for usage that is not planned or documented. Many applications, and
translators, will not be able to handle a generic scope. · Specialized DEXs normally consists of a subset of the capabilities
of the generic DEX. Often DEX specifications will be redundant. The generic and
the specialized DEX may be identical. A specialized DEX represents a family of
business data exchange requirements with identical data model structure. · Instantiated DEXs define outer leaf data exchange specifications
for single business data exchange requirements (ideas) that shall be equally
understood at both sides of an exchange. Instantiated DEXs are hence
specializations of generic (or specialized if existing) DEXs, representing each
single family member. An instantiated DEX may contain all or a subset of the
entities of the generic DEX. Capability types
Three levels of capability
precision apply in order to identify the outer leaf reference data, constraints
and rules needed to interpret specific business concepts. · Generic capabilities define the interpretation of the ARM schema
of ISO 10303-239 to fulfil business requirements for information
representation. · Specialized capability normally consists of a subset of the
entities of the generic capability. In some cases, the generic and the
specialized capability will be identical. A specialized capability represents a
family of business concepts with identical data model structure. It therefore normally is
more precise than the generic capability · Instantiated capability uses the same subset of entities as the
specialized capability. An instantiated capability defines the business concept
as the single family member of the specialized capability, with no room for
ambiguity. In reality, an instantiated capability is a further specialization
of the population of a specialized capability. (a) Short forms of instantiated
capabilities shall compose the short form of the instantiated DEX for
generation of the DEX longform. Only instantiated capabilities shall be used by
a DEX (b)The specific rules and reference data of instantiated capabilities and
DEXs shall be added to the DEX shortforms. Regarding your concerns: The situation shall to be the
opposite of the scenario you describe. DEXs and capabilities will be re-used in
different business scenarios. DEXs and capabilities shall reflect commonly used
business data exchange concepts at a level that is not subject to
interpretation. For example, the "Allowance part list" is a commonly
known business obcejct wich is subject to exchange. This concept must
be identically understood and interpreted by exchange parties. The
instantiated capabilities and their constraints in this DEX will be reused in
several DEXs. Further development of DEXLib tool is needed to manage the large
amount of concepts (Indexing machanism). We do not propose any changes to
the original idea with the DEX architecture. The only difference is that
we introduce a more detailed specification to eliminate possible ambiguities.
The capabilities shall be re-used and shall be the main bulding blocks for the
DEXs. Use of reference data will distinguish the usage of the instantiated
capabilities in different DEXs. Regards Trine From: Gibson, Martin
[mailto:ils-de@a.dii.mod.uk] Trine, Notwithstanding the
recommendations resulting from the DEX Sync meetings, and so
that we all know (or think that we know) what we're talking about before we get
to the meeting please could you provide us with your definitions of the
following:- 1) Generic DEX 2) Specific DEX 3) Instantiated DEX 4) Specialised
capability 5) Instantiated
capability I also have some concerns though. If I correctly understand your logic and
line of thought, it seems that we would ultimately end up with a standardized
DEX containing standardized capabilities for each and every data
exchange scenario that might exist in any given business domain. The
logical consequence of this would be that any particular DEX implementation
would inevitably be different from virtually any other DEX
implementation, making every AP239-based system incompatible with every
other AP239-based system. This is surely not what was originally envisaged. Regards, Martin Martin Gibson -----Original Message----- All. Based on findings in the Synchronization
workshops, it is recommended that the powerful capabilities in DEXLib are
tailored to specific business constraints by specializations, and that the
specialized capability is instantiated for the specific business data to be
exchanged. Furthermore, it is recommended that a
specific DEX is populated by instantiated capabilities. The specific DEX shall
be defined as an instantiation of the more generic DEX at the level currently
defined in DEXLib. Specialized capabilities, instantiated capabilities and
instantiated DEXes are all subject to standardization. Following the above scenario, Capability
C001 Assigning_identifiers meets requirements for a specialized capability
(subset of a larger capability, but not detailed enough for an instance of a
capability). A larger capability should allow that the identifier owner (C016
Representing_person_organization) may or may not be assigned to an
Identification_assignment. Similarly with C036 Assigning_date_time. Currently, C001 seems to require that the
ID owner shall be assigned, however there is no such formal statement. This
would also not be possible with the existing Express listing as it does not
include C016 nor C036. Hence, rules that combine information
elements from e.g. C001, C016 and C036 need to be stated in each instance of a
DEX that has such a requirement. We should try to avoid that different DEXes
hold identical rules combining C001, C016 and C036. A solution could be to extend the scope of
C001 to import C016 and C036 (formalization of Fig 2 arrangement in C001).
Specializations for C001 could then be made to formalize alternative sub
arrangements. Until this issue is resolved, the template
proposal DEX000 (which when developed into a real DEX should be an instance of
DEX001) will be provided with a rule to mandate usage of C016 in the context of
C001." Regards
DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]