Add SKU TEI type

[oej]

See #187 (comment)

[ppkarwasz]

As I mentioned during the workshop, I’m still unclear on the purpose of TEI types—specifically, why they impose a fixed syntax on the identifiers that manufacturers can assign within their own namespaces.

PR #187 reinforces this confusion. It states:

The user needs to get the TEI from the manufacturer, through a reseller or directly. The TEI is defined by the manufacturer and can normally not be derived from known information.

If consumers cannot derive a valid TEI from other known information (such as an SKU), then what benefit does a restricted TEI type like sku offer?

Wouldn’t it be more flexible and future-proof to define TEIs more generically, for example:

urn:tei:<domain_name>:<unique_identifier>

This approach gives manufacturers full control over their identifier format without requiring consumers to interpret or construct them based on predefined types.

Rethinking the Role of TEI Types

Rather than using TEI types to enforce syntax rules on manufacturer identifiers, we might consider using them to indicate the kind of object being referenced in the TEA service. For instance:

• urn:tei:product:<domain_name>:<unique_identifier> – refers to a TEA product, with identifier format left to the manufacturer’s internal systems.
• urn:tei:component:<domain_name>:<uuid> – refers directly to a TEA component, potentially used in SBOMs to point to upstream supplier data.

This would make TEI types more meaningful in the context of TEA object resolution, without unnecessarily constraining identifier syntax.

[oej]

I think that adding a type will enable syntax-checking for some of the TEIs, which will aid the user in entering a correct TEI.

[oej]

I don't think we have any use case for discovery of a component so far. Do we?

[oej]

Move the general discussion to #189 - let's keep this issue focused on SKU. Thank you!

[ppkarwasz]

I think that adding a type will enable syntax-checking for some of the TEIs, which will aid the user in entering a correct TEI.

If we are concerned about users typing the TEI on their keyboard, couldn't we solve this by adding a short checksum field of one or two symbols?