Confusion about identifiers

[mill6-plat6aux]

Regarding the URN syntax redefined in Tech Spec ver2.3, is it systematically summarized in another document? If so, please provide a link.
At least from reading only Tech Spec ver2.3, it seems that some of the descriptions are causing a bit of confusion.

• Lack of consistency between company identifiers and product identifiers.

  • At least up until version 2.2, company identifiers were urn:pathfinder:company:customcode:buyer-assigned:* or urn:pathfinder:company:customcode:vendor-assigned:*, and product identifiers were urn:pathfinder:company:customcode:buyer-assigned:* or urn:pathfinder:company:customcode:vendor-assigned:*, so the format was symmetrical.
  • From version 2.3, the company identifier is urn:pact:company:customcode:buyer-assigned:* or urn:pact:company:customcode:vendor-assigned:*, which seems to be a continuation of all previous versions, but the product identifier is urn:pact:sample-buyer.com:buyer-id:*, urn:pact:sample-supplier.com:supplier-id:*, which is a significantly different format from previous versions and no longer symmetrical with the company identifier.
  • Is this okay as a format system?

• The distinction between buyer and vendor in ver2.2 was ambiguous and difficult to use as an identifier. For example, the relationship between two companies (buyer/seller) may change depending on the product, and in that case, it is difficult to tell from the ProductFootprint itself which company defined the identifier.

  • The format urn:pact:sample.com:product-id:* in ver2.3 makes it clear which company defined the identifier at a glance, solving the above problem.
  • However, in addition to this, the formats urn:pact:sample-buyer.com:buyer-id:* and urn:pact:sample-supplier.com:supplier-id:* remain, and the problem in ver2.2 is not completely solved. Why did they keep these formats?
  • It seems that the above problem could be solved in the same way if the format urn:pact:sample.com:company-id:* was prepared for company identifiers as well.

• There are many examples of product identifiers, but few examples of company identifiers.

  • For example, the LEI is registered with IANA and can be easily used as a URN. Shouldn't this example also be shown?
  • Chapter 8.10.1 shows an example of using an SGLN as a corporate identifier, but shouldn't an example of using a GLN be shown as well, as with the relationship between SGTIN and GTIN? (Although it would be unofficial since it is not registered with IANA)
  • For example, an example of using a corporate identifier that is widely used but not registered with IANA (such as a D-U-N-S Number) should also be shown.

• About the examples in Chapter 7.2

  • In EXAMPLE 32, there is no colon after substance-id.
  • In EXAMPLE 32, substance-id is used as the identifier-type, but in EXAMPLE 34, it is substance-number. Aren't both CAS RNs? In any case, shouldn't the usage of identifier-type be more strictly defined?

[schuur]

Thank you for these observations!

For the urn schema, the pact namespace has been chosen by the member community, as part of the move away from the pathfinder name. The guidelines for version 2.3 reflect this (as a strong recommendation). However, any company is free to use any namespace it deems suitable, including pathfinder.

The urn:pact:sample.com:product-id format has indeed be included as the recommended way of identifying products. The previous recommendation for buyer-id and vendor-id is still included but could be marked as optional.

The company Ids can definitely follow the same pattern as product Ids, moving away from buyer-assigned and vendor-assigned. It would make sense to additionally propose this, following the approval on product-id naming recommendation. We will reach out to you for feedback on a draft before bringing it to the working group.

Thanks for signalling the typo's, we'll fix these in a patch release.

[mill6-plat6aux]

I understand PACT's policy of not enforcing the custom identifier specification. However, since it is about information shared between multiple companies as an identifier, I think some degree of enforcement is necessary. If each company expresses custom identifiers completely freely, the implementation of the solution will diverge, and depending on the solution, the information may become uninterpretable.

Also, especially in Japan, there are many companies and products that have not acquired international identifiers, so I think that the custom identifier specification is actually a very important element in disseminating the PACT technical specification.

Therefore, if you continue to present custom identifiers in technical specifications, I think that the specification needs to be consistent (easy to understand) across company identifiers and product identifiers. I would appreciate it if you could consider this.