Leif,
Still waters run deep, so any troubled ones are fairly shallow ones
; - )
I think I understand what you are saying and raise two
proposals - though the implications need to be
clearer..
Your experiences seem not to involve full exchange file scope as
defined by the Dexs, since you are dealing with legacy data and more
ad-hoc query-related data extraction which does not require a fully
instantiated Step file acc. to one or other Dexs. However, for longterm
data archiving I suspect that this may be
required.
The suggestion is that there needs to be (or is already) a generic
set of capabilities that may then be extended with standardized terms for
common usage within a domain. These terms of common usage I would suggest
are those defined by the user community (such as MoD, Nato, or other large
organization) and are represented as reference data.
This means that the capabilities can/should only provide example
reference data until the particular exchange community has adopted a
specific set/collection of reference data for that industry/domain. Once
adopted, the reference data can be used to complete the schema in terms of
the acceptable values for attributes such as identifiers and relevant
rules can be written to enforce these. This version of the capability(s)
is what you are saying needs/could be standardized.
In other guises, this is close to the subject of a set
of implementor's agreements, but begins at a little higher
level.
From this view I can see that pre & post processor guidence may
be a little premature and would need to be careful not to include items
that are effectively example reference data items.
However, some of the sections on this subject are indeed more
generic & for example, under the capability
representing_assembly_structure the first pre-processor statement
reads...
-
No cyclic part_view_definiton structures may be defined. The
value of the identification_assignment.identifier (for PDM Schema this
is the local id attribute) must be unique in combination with the same
relating assembly and related component definitions. For PLCS this
implies that the identifier for each part_view_definition, part_version
and part must be unique within the assembly. It is generally recommended
that only subtypes of assembly_component_relationship be instantiated.
It is not necessary to instantiate the optional relation_type,
location_indicator or quantity attributes for an instance of
next_assembly_usage in the context of a basic parts list. If information
on the assembly type is to be represented, then this additional
information should be represented using the
view_definition_context.description attribute. This information is
linked through the part_view_definition.additional_contexts attribute
inherited from product_view_definition (leaving the application_domain
and life_cycle_stage attributes empty). Examples of such type
information are 'functional assembly', 'manufacturing assembly', and
'design assembly'.....
.... I think most is still applicable, except for those examples
which might be different depending upon usage.
Prop 1: This information, however, is now captured under the
CVS versioning so removing these sections for now, is not a problem and
may aid consistency across the capabilities. I could agree to putting this
on the "back-burner" for now so that the complexity issue can be
ironed-out first; though I suspect we may need to come back to it at some
point.
The other thing that seems to come out of this (for me at least) is
a question on whether the capabilities should document any of the items
referenced from a select type. In some capabilities I see examples that
are specific to the Dex within which it is primarily to be used, but when
I look at Dex 1, I realize that the example (entity used) in the
capability is not actually present (e.g. out of scope). Likewise, I could
have done the same in generating capabilities under Dex1 & for
example, in assigning_identifiers I may have only used the entity "Part"
when showing how the identification_assignment works, though this may not
be present in al Dexs.
Prop 2: We (modellers) need to decide if we are to document
the contents of these select types or not. I have actually documented ALL
PLCS entities available from the identification_item select type, though
only chosen one for the example. I have also added notes to state that
this list may change depending upon the usage of the capability (i.e. in
which Dex) since the contents of the list may be pruned according to the
scope. However, someone looking at the capability, from a *re-use point of
view*, would be able to see which entities are referable from the material
and to make decisions accordingly for the Dex they are planning.
I would therefore, suggest this as a default position
when documenting the capabilties, (though I am still open to
discussion)!
Kind regards,
Tim
I get some of the picture.
As you are aware, we have had some uncertainty as to wether the
current PLCS capabilities and DEX'es can easily be reused in our pilots,
and we have communicated our needs and ideas back to Rob and
others.
In this work we have not met the problem you refer to with
documentation of capabilities and the related DTD.
I appreciate that the PDM schema rightly calls on pre and
postprocessors. However, we have not met the need for these in our work.
Why?
As in PLCS, we develop generic capabilities, and these are to a
large extent of the same type. Then we instantiate the capabilities to
hold real data. Currently, thes instantiated data are legacy type, not
subject to standardisation, but they should (using reference data) be
identical to stable logistics business data as found e.g. in DefStan
00-60. Then the instantiated caps (possibly grouped inside a generic
cap) should be standardised.
To be able to use caps (the instantiated ones), instantiation
diagrams (also candidates for standardisation when populated with
reference data) are developed. These represent business concepts
where the caps are used and reused.
To populate a PLCS database, we have not met needs for
postprocessing other than as defined in the instantiations (the mapping
diagrams). This, however, does not mean that postprocessing is not an
added value, but the need should be carefully assessed before another
level of complexity is added to PLCS.
To extract data from the PLCS database, query is used. Again no
other need for preprocessing, and again, carefully assess the need,
complexity and cost benefit..
We believe that the exchange specification for import and export
technically is the same, but there may be other reasons why this is
not so.
Also, provided pre and post processing is introduced, care should
be taken to distinguish between the generic part and the instantiatied
part. I see the generic parts only as aids to develop the instantiated
parts. When the logistics domain is fully populated with instantiated
reference data, these should be used by all, and the need for the
generic capabilities disappear. Mapping legacy data to PLCS will then be
done using the instantiation diagrams and the instantiated
capabilities. Databases and data exchanges will hold instantiated
data (legacy or the reference data substitution for the legacy data),
not generic capabilities.
Knowing well I am operating in troubled water, I still hope this
is to help and not to confuse. If the latter, forget the
mail.
Best regards
Leif Tonning
Oh um, sorry!
Well a lot of the early capabilities had sections on pre &
post processor guidence in the main body, underneath the descriptions
of the entity attributes being documented. For example, under
representing assembly structures & BOM there is a section on Postprocessor
Recommendations. However, these sections need
to be moved to the usage area (I.e. in amongst the entity
definitions), but I cannot copy the section to that part as the dtd
seems not to allow it. I need to see some sort of example on how this
should be done, or for the dtd to change to enable a simpler
format.
I believe that I can just delete the attribute sections I have
manually provided since these are already available in the usage
area.
Regards,
Tim
Hi, Tim
Sorry, I'm not on the net. Probably
I have missed some communication and do not understand what you are
asking.
I will do
my best to give you an answer, but need better to understand the
issue
Leif t
-----Original
Message-----
From: Tim Turner
[mailto:timturner11@bellsouth.net]
Sent:
28. april 2004 20:32
To: Rob Bodington (E-mail); Tonning, Leif
Subject:
Pre-post processor info
Guys,
I'm trying to address
the issue of moving much of this information into the usage
section, but I need an example where this has been done that I can
follow.
Do you have anything I
could look at?
Cheers,
Tim
**************************************************************
Neither
the confidentiality nor the integrity of this message can be
guaranteed following transmission on the Internet.
All messages
sent to a DNV email addressee are swept by Sybari Antigen for the
presence of computer viruses.
DNV acknowledges that SPAM email
represents a potential security risk, and DNVs filters to block
unwanted emails are therefore continuously adjusted. DNV has
disabled "out of office" replies to the Internet
**************************************************************
**************************************************************
Neither
the confidentiality nor the integrity of this message can be guaranteed
following transmission on the Internet.
All messages sent to a DNV
email addressee are swept by Sybari Antigen for the presence of computer
viruses.
DNV acknowledges that SPAM email represents a potential
security risk, and DNVs filters to block unwanted emails are therefore
continuously adjusted. DNV has disabled "out of office" replies to the
Internet
**************************************************************