universal material structure

[malkosh]

limiting u3m to just visual data is going to only add more issues later. Here is the proposed structure. These can change but at least the major categories are set.

1. visual properties
2. physical properties
3. material information
4. custom
   1. visual properties
   2. physical properties
   3. material information
   4. additional

[malkosh]

And here is the proposed material information we are interested in saving. Items that state multiple can have multiple entries. Anything more than this goes under custom/material information

1. supplier
   1. title (multiple)
      1. name
      2. supplier ID
      3. country of origin
      4. description
2. composition
   1. title (multiple)
      1. raw material
      2. ratio
      3. country of origin
      4. description
3. manufacturing
   1. manufacturer
      1. name (multiple)
   2. minimum order
   3. lead times
      1. title (multiple)
         1. minimum
         2. maximum
         3. description
   4. discontinued (boolean)
   5. components
      1. title (multiple)
         1. name of component
         2. country of origin
   6. asset category
      1. title (multiple)
         1. type
         2. supplier ID
4. treatments
   1. title (multiple)
      1. type
      2. supplier
5. coating
   1. title (multiple)
      1. type
      2. supplier
6. dimensions
   1. name
   2. width
      1. dimension
      2. variation
      3. cuttable
      4. printable
   3. length
      1. dimension
      2. variation
   4. thickness
      1. dimension
      2. variation
   5. weight
      1. dimension
7. care
   1. wash
   2. bleach
   3. dry
   4. iron
   5. dryclean
8. color
   1. RGB
   2. CMYK
   3. LAB
   4. HEX
   5. Pantone
   6. Coloro
   7. custom
9. pricing
   1. title (multiple)
      1. name
      2. description
      3. price
      4. unit
10. sustainability
    1. title (multiple)

[vizoomartin]

Hi Yazan, i have a few questions/remarks:

• 4.custom: This whole point of this section is that it's not structured/defined, so everybody can input their own information, in their own space (e.g. "vizoo":, "swatchbook":...) without risk of the databeing overridden by another application. If we again define input areas (visual, physical, material, additional), this custom specific safe guard will be lost. Everybody could place their specific space in each section, but i dont see the benefit in comparison to the current implementation?
• 3.1.i.b supplier ID: How can this work? IDs are specific for each brand or plm/dbsystem, and should not be part of the interoperable u3m.

As discussed before, we are hesitant to add dynamic information (price, lead times, dimensions, minimum order etc) to a file that can exist disconnected from this information, as the information will not be reliable. PLM InfoI think we have to decide whether u3m includes PLM information (like in your suggestion) or, is an addition to the PLM data for a full material. Again, we should address the concern above though if PLM data makes sense outside of the PLM system. Confidentiality: part of the suggested info is probably confidential for each company (price, lead time, minimum order, names etc). If that's the case, the materials can also only be distributed inside the company, instead of e.g. from supplier to several companies.

Nevertheless, it does make sense to include data to categorize/search/filter the materials. Proposal to add to "material":

"material":{
...
 "color":[
  "RGB":"",
  "LAB":"",
  ...
 ],
 "physics":{
  "mass":100 //(e.g. g/m²)
  "thickness":1 //(mm)
 },
 "supplier":[ //list
  "name":"",
  "country":""
 ],
"composition":[ //list
  "raw_material":"",
  "percent":"" //(%)
 ],
 "contruction/contructiontype":"" //that could be very helpful to categorize, maybe as a list?
}

[ReinhardOnVizoo3d]

I agree that "dynamic" data should not be part of u3m. Supplier id however is not dynamic and can be part of u3m in my view. Just we should clarify exactly for each item what it means. In case of Supplier id, does it mean the id of the supplier or the supplier internal material id? Generally I see no reason not to add such "PLM information".

[malkosh]

dynamic data can be under custom I would argue however that there is a difference between set custom data and dynamic one. for example. pricing can have set public data and negotiated dynamic price

At that point in terms of confidentiality, the software system should be the one taking care of what data to contain or not otherwise even if the confidential data is under custom, it can still be shared. so the responsibility is on the user and the software

supplier data is a must. supplier ID certainly can be per client but again two different fields supplier Name set supplier internal ID dynamic or custom

but I still think the data structure can at least be organized by type not by vendor, otherwise this is less of a standard and more of catchall. if that makes sense

[malkosh]

plus the moment you put it under material information, it leaves your space alone, it doesn't touch physics or visuals. it's already in a separate space. and IF vendors need a dedicated space, they can go under additional.

[enirevlow]

@malkosh @vizoomartin I agree we should look in the metadata part and see if there are some which should be in common section. I would also love to have more input from a PLM partner, if possible. As of now, we already have partners working to support this structure, so I suggest let's introduce version 1 first and discuss about this issue as high priority for version 2. Maybe we should have organize a small workshop early next year with all concerned/interested parties.

[vizoomartin]

Please see the draft in the upcoming U3M newsletter, lets use this as basis for discussion