Volatile parameters like e.g. price require frequent URI / file name updates.

[faerietree]

Stable properties

Only stable parameters / basic features that are not expected to change frequently without resulting in to a new part should be put into URI / file names, sorted alphabetically with the exception of .type which comes first and the most global / 1st subject's ID which comes last, e.g. bolt.mass_1__.thread_m6__head.type_hex__.d_.017__.height_.01__id_123. where d := diameter. i.e. <subject>.type_<type>__.property[.sub]_value_of_property__<part_subject>.aproperty_<value>__.bproperty_<value>.<file_ending>

This likely also is required should the BoM blender extension support extracting text from images and even if the dimensioning on the drawing is perfect, because the file names have to be unique anyway and having to extract the dimensions from a drawing is complex (relate numbers to sides and know what is width, length, relevant, ...) and slowing command line work and increasing time for searching parts with special properties. There is no problem encoding essential information in a single source, whether this is a configuration file to be looked up or directly in the filename is of minor importance if the properties change little and the properties are few enough to fit within maximum file name length.

Reasons for why not using a primary key like automatically incremented integer or e.g. ID:

• Which vendor's ID to choose as the default?
• IDs have to be looked up.
• Primary keys add complexity, another look up, data to maintain, ...

• No real benefit because:

  • Scenario blanco: If including stable properties and having these all redundant in several versions (file formats) of parts on change all files have to be renamed (batch rename).
  • Scenario primary key: If including the stable property primary key and looking up all other data in an XML/JSON/TEXT/... file on primary key change all files have to be renamed (batch rename).

  =>

  So no difference here. There's no benefit to using a primary key in this case. To the contrary: The primary key has to be maintained, too - and more parser functionality might be required.

  Volatile properties

  Meta data

Price, URLs and other volatile attributes can be put into the blend file as meta data, e.g. in the Object (e.g. group instance) or object data name (if part is made of a single object and this is an e.g. mesh). It will be fetched by the bill of materials generator from there.

ID quest

While IDs are considered stable, ID defaults per part are not. This means default IDs belong into the .blend to the corresponding used parts of the assembly respectively. Within company repositories the default ID of course is stable because the company ideally maintains all of the parts that are produced. Therefore it may make sense to include the ID here instead of within a binary file, because opening a binary file to know which part ID it is to check further properties may be undesirable for developers.

For users the Bill of materials generator lists the part numbers.

How to add BoM generator compatible meta data:

Composites | assemblies: If a purchasable part is made of other parts (composite/assembly), then the group should be instanced and grouped again to allow including the meta data (e.g. IDs) in the group instance's dupli group name and at the same time have the group to be linked labelled as 'Group' (fulfilling an important global standard). Note: The meta data (e.g. IDs) of the by the composite/assembly utilized parts are given in the .blend files of the parts respectively.

How to overwrite stable, volatile properties:

http://github.com/faerietree/universal_prototyping_kit/issues/5

[faerietree]

+ Price, URLs and other volatile attributes can be put into the blend file as meta data, e.g. in the Object data (e.g. mesh tab) name. It will be fetched by the bill of materials generator from there.