adapt-data-type-definitions.json: Revisit ID Type and ID Source Type, refactor as Scheme ID, Scheme Agency ID, and use ID Type Code as a business defined name for the ID

[dubnemo]

I still take the stance that the IDType defined is really a scheme, and IDSourceType is very confusing as both IDType and IDSourceType has GLN as an example.
A scheme defines the data representation, aka a formal descriptive way to parse and recognize the identifier, which in some case there will be logic in creating the identifer. UUID is a classic example, as GUID is the 'Microsoft way' or scheme and DCE created another scheme. There are many versions of each scheme as noted in RFC 9562. Therefore the IDSource in these examples are actually Microsoft or DCE. Just saying.

GTIN and GLN are other schemes, which the source is GS1.

I could go on an on. I bought this up the first day of the ADAPT kickoff meeting in Bloomington, citing ANSI ASC X12 as the origin of these concepts. UN/ECE spent considerable clock-cycles 'fixing this' with the notion of schemeId and schemeAgencyId, probably a LOT more human-hours spent debating this than we have spent in AgGateway.

ID Type in X12 was a business contextual name for the identifier, which is much different than a scheme since scheme is for the technical folks solving problems. The UN ended up calling this typeCode instead. I cannot remember if UN/EDIFACT also fixed the X12 submission to the UN/ECE but there were a lot of changes to address concerns like this.

Sorry I did not see this earlier.

[knelson-farmbeltnorth]

I agree that the redundancy of GLN is confusing.

IDType is one of UUID, STRING, LONGINT, URI, and GLN. IDSourceType is GLN or URI.

At best, we lack good definitions for these.

[knelson-farmbeltnorth]

@dubnemo @aferreyra @strhea if we accurately define a code and its source, why do we need IdType and IDSourceType? The "Code" is a unique identifier issued by the "Source" If Source is required to be a URI that refers to a specific list of identifiers, then the other fields seem redundant.

If by source we mean to capture some entity that publishes more than one list of codes (say GS1), and there are expected to be the same code in use in multiple lists from said source, then why not capture the specific URI/identifier in "Source" that refers to the appropriate list? E.g. Source = https://id.gs1.org/01/ for GTIN and https://id.gs1.org/414/ for GLN.

Do we really need to identify what is a string vs. a UUID? This seems like some well-intentioned technical design left over from the ADAPT Framework.

[dubnemo]

> and there are expected to be the* same code *in use in multiple lists

from said source, This above part is never the case. Most times, there are multiple lists each *for different purposes *and those lists are versioned over time. I also view codes and identifiers as different things, as do other standard organizations such as UN/CEFACT and ANSI (e.g., X9, X12). Codes are static and maintained (controlled), and identifiers are dynamically generated. I invite you to dive into the world of Electronic Data Interchange (EDI) where the entire data dictionary in UN/EDIFACT and ASC X12 is a collection of different code lists with semantic definitions for the list itself and every code value in that list. The entire transaction message syntax is an assembly of these codes, and placeholders for (code qualified) identifiers and free-form strings in specific record types (segments). These data dictionaries contain, what we are calling in AgGateway, 'controlled vocabularies'. X12 processes still exist where codes and their associated definition are submitted, reviewed by an advisory group, and voted on by members before they are added to the list in the data dictionary. URI -- I don't think many of the lists are publicly available via URI. That would be great! If this happens in my lifetime, I will buy the first round of cocktails. UUIDs have many schemes for the different representations (formats). GTINs and GLNs are taxonomical identifiers with different 'parts' to the identifier including a company prefix that is the first few characters, based on the amount of money paid to GS1 to generate and hold these identifiers in their Data Hub registry, which are then propagated and made accessible to retailer Point of Sale systems.

…

On Thu, Mar 27, 2025 at 2:05 PM Kelly Nelson ***@***.***> wrote: @dubnemo <https://github.com/dubnemo> @aferreyra <https://github.com/aferreyra> @strhea <https://github.com/strhea> if we accurately define a code and its source, why do we need IdType and IDSourceType? The "Code" is a unique identifier issued by the "Source" If Source is required to be a URI that refers to a specific list of identifiers, then the other fields seem redundant. If by source we mean to capture some entity that publishes more than one list of codes (say GS1), and there are expected to be the same code in use in multiple lists from said source, then why not capture the specific URI/identifier in "Source" that refers to the appropriate list? E.g. Source = https://id.gs1.org/01/ for GTIN and https://id.gs1.org/414/ for GLN. Do we really need to identify what is a string vs. a UUID? This seems like some well-intentioned technical design left over from the ADAPT Framework. — Reply to this email directly, view it on GitHub <#156 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHXOQO3FHGI4G4FMSGLXRD32WRDXVAVCNFSM6AAAAABTDGI5SOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJZGEZTINBWGU> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: knelson-farmbeltnorth]*knelson-farmbeltnorth* left a comment (ADAPT/Standard#156) <#156 (comment)> @dubnemo <https://github.com/dubnemo> @aferreyra <https://github.com/aferreyra> @strhea <https://github.com/strhea> if we accurately define a code and its source, why do we need IdType and IDSourceType? The "Code" is a unique identifier issued by the "Source" If Source is required to be a URI that refers to a specific list of identifiers, then the other fields seem redundant. If by source we mean to capture some entity that publishes more than one list of codes (say GS1), and there are expected to be the same code in use in multiple lists from said source, then why not capture the specific URI/identifier in "Source" that refers to the appropriate list? E.g. Source = https://id.gs1.org/01/ for GTIN and https://id.gs1.org/414/ for GLN. Do we really need to identify what is a string vs. a UUID? This seems like some well-intentioned technical design left over from the ADAPT Framework. — Reply to this email directly, view it on GitHub <#156 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHXOQO3FHGI4G4FMSGLXRD32WRDXVAVCNFSM6AAAAABTDGI5SOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJZGEZTINBWGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[knelson-farmbeltnorth]

@dubnemo Within an ADAPT Id, the dynamic part is the Reference Id, the permanent part is the collection of Unique Ids. Whether other organizations never use the term "identifier" to mean something permanent is perhaps worth discussion, but for now an ADAPT Unique Id means a permanent identifier for something issued by some party.

My general point was that at a high level we need to know the unique id and what the source of that unique id is. We should not need to carry around a lot of duplicated contextual information about the source or id. If the source + id is insufficient to uniquely identify something, then we have entered the wrong source + id. As to whether this can be accomplished in 2 string fields is the question, but I don't see the point in carrying around, e.g., an issuing agency in addition to the id type if the id type is always issued by that agency.

Also, in practical terms all Ids can be handled as strings. We don't need hints to suggest how software might parse the id, which is what 3/5 of the IdTypes currently are.

I am aware there are not always formal URIs for id schemes. Maybe we call it "Source" and define it as "URI, URL or Issuer name". Bottom line is we need to communicate to the receiving party whose id it is. I see a risk of perfection standing in the way of good enough here.

[dubnemo]

[image: knelson-farmbeltnorth]*knelson-farmbeltnorth* My main point is that IDType is fundamentally wrong, as it should describe to the business usage, and only GLN is related to the business usage (global location number). The other values UUID, STRING, LONGINT, URI are data type *schemes *(aka data representation) and therefore technical; not business related. We are mixing semantics hence why I state it fundamentally wrong. I prefer explicit strongly typed semantics and this is not. No guessing. Scott

…

On Fri, Mar 28, 2025 at 8:32 AM Kelly Nelson ***@***.***> wrote: @dubnemo <https://github.com/dubnemo> Within an ADAPT Id, the dynamic part is the Reference Id, the permanent part is the collection of Unique Ids. Whether other organizations never use the term "identifier" to mean something permanent is perhaps worth discussion, but for now an ADAPT Unique Id means a permanent identifier for something issued by some party. My general point was that at a high level we need to know the unique id and what the source of that unique id is. We should not need to carry around a lot of duplicated contextual information about the source or id. If the source + id is insufficient to uniquely identify something, then we have entered the wrong source + id. As to whether this can be accomplished in 2 string fields is the question, but I don't see the point in carrying around, e.g., an issuing agency in addition to the id type if the id type is always issued by that agency. Also, in practical terms all Ids can be handled as strings. We don't need hints to suggest how software might parse the id, which is what 3/5 of the IdTypes currently are. I am aware there are not always formal URIs for id schemes. Maybe we call it "Source" and define it as "URI, URL or Issuer name". Bottom line is we need to communicate to the receiving party whose id it is. I see a risk of perfection standing in the way of good enough here. — Reply to this email directly, view it on GitHub <#156 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHXOQOZQQSROOGSRQMM6OYD2WVFNLAVCNFSM6AAAAABTDGI5SOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRRGM3TMOBXHA> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: knelson-farmbeltnorth]*knelson-farmbeltnorth* left a comment (ADAPT/Standard#156) <#156 (comment)> @dubnemo <https://github.com/dubnemo> Within an ADAPT Id, the dynamic part is the Reference Id, the permanent part is the collection of Unique Ids. Whether other organizations never use the term "identifier" to mean something permanent is perhaps worth discussion, but for now an ADAPT Unique Id means a permanent identifier for something issued by some party. My general point was that at a high level we need to know the unique id and what the source of that unique id is. We should not need to carry around a lot of duplicated contextual information about the source or id. If the source + id is insufficient to uniquely identify something, then we have entered the wrong source + id. As to whether this can be accomplished in 2 string fields is the question, but I don't see the point in carrying around, e.g., an issuing agency in addition to the id type if the id type is always issued by that agency. Also, in practical terms all Ids can be handled as strings. We don't need hints to suggest how software might parse the id, which is what 3/5 of the IdTypes currently are. I am aware there are not always formal URIs for id schemes. Maybe we call it "Source" and define it as "URI, URL or Issuer name". Bottom line is we need to communicate to the receiving party whose id it is. I see a risk of perfection standing in the way of good enough here. — Reply to this email directly, view it on GitHub <#156 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHXOQOZQQSROOGSRQMM6OYD2WVFNLAVCNFSM6AAAAABTDGI5SOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRRGM3TMOBXHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[knelson-farmbeltnorth]

@dubnemo how do you find my suggestion that we could simply delete the 2 type fields? Is there an alternative you would propose?

[dubnemo]

@knelson-farmbeltnorth
I'd like to back up, to ensure that I am not misinterpreting.

Can you provide an example payload (JSON snippet) of a uniqueId object with all four attributes populated?

That is something that is truly missing from the documentation:
https://adaptstandard.org/docs/unique-id/

[knelson-farmbeltnorth]

@dubnemo When we see the equivalent of this object used in the ADAPT Framework, it is generally something like:

ID = Some UUID
Source = URL for a particular company
IDType = "UUID"
IDSourceType = "URI"

[dubnemo]

As I thought. IDType and IDSourceType are declarations of the data type, not *business semantics *that *qualify *the ID value. What I am proposing is a breaking change, therefore ADAPT Standard 2.0. Let me articulate in another post, however since it is a breaking change to v1.0, we will need to put this issue in the backlog. Perhaps we use Milestones in the repo and link this to that milestone.

…

Message ID: ***@***.***>