-----Original
Message-----
From: Tim Turner
[mailto:tjt@lsc.co.uk]
Sent:
05 January 2007 05:30
Cc:
plcs-dex@lists.oasis-open.org
Subject: [plcs-dex] RE: representing
part
From: Tim Turner
[mailto:timturner11@bellsouth.net]
Sent: 04 January 2007 21:54
To:
'rob.bodington@eurostep.com'
Cc:
'plcs-dex@lists.oasis-open.org'
Subject: RE: representing
part
Hi
Rob,
see
below.
Regards,
Tim
From: Rob Bodington
[mailto:rob.bodington@eurostep.com]
Sent: 04 January 2007 12:01
To: Tim Turner
Cc:
plcs-dex@lists.oasis-open.org
Subject: representing
part
Hi Tim
I have had a quick look at
representing part template.
Could you make the EXPRESS-G
diagrams look like all the other diagrams (i.e. ones drawn by
GraphicalExpress, so is it possible to change the font and the colour of the
entities?).
[Tim
Turner] Will be done - just want to concentrate on the template
instantiations first.
Picky / subjective I know but
perhaps we could adopt a convention for how to draw the
product/versio/defitnion entities form top to bottom? Rather like has been
done in product as realized? … just a suggestion
[Tim Turner] Time will
dictate
I am not sure that I agree with
passing in the detail as to whether the part is a part or
assembly.
What is that supposed to tell the
receiving system?
That the part is an assembly (just
about every part is and assembly from someone's point of
view)
Or is it telling me that there is
assembly information in the file.
[Tim
Turner] Best see the
issue log on that - RBN-9 & the resolution which was posted. Essentially,
the intent was that once the representation of the part has been setup
(Part, Part_version & PV_definition) a reference to the Part (via a
Part_version) will enable a receiver of (just the reference & related
instances) to tell if the Part is composed of an assembly or a single item
etc.. without having to exchange the entire assembly model or breakdown to
dtermine this fact. This is useful in exchanges where the full product
model is not known to all parties.
It does not imply
whether the full assembly info is in the file or not, just that it either
exists or does not.
[RBN]
I still think that this is a really bad idea!
I
think that we imposing a business practice.
One
persons detail is another person's assembly.
If
I send you a part + its assembly. Then I send you a file that refers to that
part. All I need to do is provide sufficient information to identify the
part.
I
do not need to send you the assembly again, nor do I need to tell you that you
already received it.
In
other words the sending system should not have to tell someone whether they
have received a part or not, the importer should work that
out.
I
have spoken to several people who have worked on production systems, including
some PDM schema implementations. In nearly all cases they do not send this
information. Primarily because in most cases whether something is a detail
or an assembly changes depending on who you talk to. Also a detailed
part may have product structure and an assembly may have no product structure.
(think of a carbon fibre composite. Its starts off as an assembly of plies,
which end up as a component ).
In
exchanges where detail and assembly were provided, stating whether something
was a detail or an assembly was subjective, and the receivers of the
information ignored it.
I
recommend that we should make this type of information optional. If a business
practice needs it then you can add it, but don't force it on everyone
else.
The where rule (which is
horrible and restrictive) is:
ENTITY Part
SUBTYPE OF (Product);
WHERE
WR1: SIZEOF(['part', 'raw material',
'tool']*types_of_product(SELF))=1;
END_ENTITY;
Why not just have a default product category which
is the 'part; to make the model valid.
[Tim
Turner] Yes - there is a
default product_category which is setup in this manner and connected to
the Part through the product_category_assignment to make the model
valid.
[RBN]
So remove the following and make it optional as assigning ref data to the part
(not the category)
-- provide the type of the part by classification
/assigning_reference_data(
items=Product_category,
class_name=@detail_or_assembly_type,
ecl_id=@part_ecl_id)/
This should be reflected in the
EXPRESS-G
[Tim
Turner] Agreed
The instance of
product_category is further classified with the detail/assembly info to
distinguish between those which may have an assembly or breakdown model. By
default, the classification is set to detail (i.e has no
assembly/decomposition defined for it).
[RBN]
See above – but I really do not think that we should do this in the
template
I am not sure that we need to
identify the part_view_defnition – surely that is identified by the view
definition context?
[Tim
Turner] As I understand it, to fully represent a Part, the view
definition is required, but you are correct a definition can be
identified by one (or more) view_definition_contexts. However, this
is only defining a view (which may not be unique). To uniquely identify
the Part_view_definition within a design, which may have several
assembly options for potentially many product representations and
variants it would seem reasonable to associate an identifier to it as depicted
in C001 - especially if this data needs to be maintained over
time.
[RBN]
The uniqueness of the part view definition is provided by the
view_defn_context (Any system will have a set of view_dfn_contexts – these
will be unique) and the part version to which the part view defn is
attached.
Again,
the production implementations that we have seen do not need the id and either
make it up or ignore it.
I am assuming from the
instantiation path that the following parameters
part_creator_org_id(Type='STRING')
part_creator_org_id_class_name(Type='CLASS')
part_creator_org_id_ecl_id
are to identify the part – they
are not necessarily the organization that created the part – more the
organization that owns the identifier that is being provided. So perhaps they
should not have creator in the name e.g:
part_org_id
[Tim Turner] Point
taken.
You are also assuming that the
same organization owns the id for the part and the version …. is that always
going to be the case?
[Tim
Turner] This can be separated out to take account of where this is not
the case. I had been using my tunnel vision and thinking that where
parts are getting "re-badged" within another setting, a
supplied_part_relationship would be used between the supplied part and the new
one created for reselling/after-market usage. Of course, this would assume
that the original supplier info was available.
Regards
Rob
-------------------------------------------
Rob
Bodington
Eurostep Limited
Web Page: http://www.eurostep.com
http://www.share-a-space.com
Email:
Rob.Bodington@eurostep.com
Phone: +44 (0)1452 810 960 (note new
number)
Mobile: +44 (0)7796 176 401