Datatype "Identifier" should always be an URI

[mrentsch65]

Is your feature request related to a problem? Please describe.
Currently the data type "Identifier" is defined as "string with max 2048 and min 1 characters":
https://industrialdigitaltwin.io/aas-specifications/IDTA-01001/v3.1/spec-metamodel/datatypes.html#Identifier

Since the AAS defines a webbased infrastructure, only web-addressable identifiers should be allowed in the future to support a seamless toolchain without hardcoded dependencies as required for other identifier types.

Describe the solution you'd like
Change definition of "Identifier" to the same as https://industrialdigitaltwin.io/aas-specifications/IDTA-01001/v3.1/spec-metamodel/datatypes.html#PathType:
"string with max 2048 and min 1 characters, conformant to an URI as per RFC 2396"

[seicke]

During the work of the IDTA guideline "How to transport ECLASS in the Asset Administration Shell" there was a lengthy and in-depth discussion about the usage of Eclass IRDI vs. Eclass IRI identifier as semanticId for SMEs.

@fscheren22 @StenGruener Correct me, if I remember wrong, but we decide to use the Eclass IRDI as semanticId and the Eclass IRI as optional supplementalSemanticId. The reason for this were existing implementations (based on Eclass IRDIs) and the existing SMT specifications including SMEs with Eclass IRDIs as semanticId.

From my pooint of view: Changing the identifier datatype as proposed means that conventional Eclass (and IEC CDD!) IRDIs can no longer be used as identifier and almost all existing SMTs would no longer comply.

[seicke]

In my opinion, another argument against the proposal:

The value of a key is of type identifier: https://admin-shell.io/aas/3/1/Key/value
The key is used to define references, e.g. within a AAS using idShorts!

[mrentsch65]

In my original motivation I had the data type for "assetType" in mind, which is currently "Identifier". But since "Identifier" is obviously also used in other contexts, I would switch my solution proposol towards replacing the data type for "assetType" with "anyUri".

[StenGruener]

@seicke if i recap correctly: there are two issues:
Issue 1:

• Eclass:

  • has an IRDI definition
  • has an URL representation
    both are not the same, since some forbidden characters, but can be mapped to each other with some background logic

• CDD

• has an IRDI definition

• has no URL representation (to my best knowledge)

So by changing we will "exclude" CDD out of AAS world

Issue 2:
we decided to keep IRDI as "primary" SemanticID in order to keep "backward-compatibility" to existing AAS apps and model templates. Ideally those things should not change more frequent than 3-5 years to give some stability to the tooling infrastructure

[StenGruener]

In my original motivation I had the data type for "assetType" in mind, which is currently "Identifier". But since "Identifier" is obviously also used in other contexts, I would switch my solution proposal towards replacing the data type for "assetType" with "anyUri".

@mrentsch65 what would be the advantage of the change, e.g., what would be possible what is not possible now? or what would be restricted?

[mrentsch65]

@StenGruener: assetType defines the relationship of an AAS instance to an AAS type. The very basic identifier of any AAS is its id (an URI) that must IMHO be used in such referencing contexts. If basically any string up to length 2048 is the data type for it, there is no possibility for even basic content validation of this very crucial information. Thus in my opinion there should be a data type restriction.
The other reason is that the AAS is a webbased infrastructure technology and thus web-addressable identifiers should be used anyway to support a seamless toolchain without hardcoded dependencies as required for historical identifier types like IRDIs.
This does not mean to exclude IRDIs for semantic referencing purposes.

[StenGruener]

if i recap correctly, AAS has a "derivedFrom" reference, which is what you meant, correct?

assetType should speak about the asset, not AAS, so here maybe ECLASS categories in IRDI format may be even quite useful?

[mrentsch65]

You are most likely right regarding usage of derivedFrom and assetKind. But does this touch the original subject of this issue, that webbased references of type URI better be used and some datatype definition should provide the ability to perform data validation?

Regarding the derivation topic, I am looking for cookbook recipes, since the specification appears rather confusing. Are you aware of coded reference examples for the simple cases like how an Instance-AAS correctly references it's Type-AAS and so on?

[StenGruener]

I believe we need to support IRDIs (personally i'd like to get rid of them for IRIs, too).

Additionally, Eclass has classification classes: https://eclass.eu/support/technical-specification/structure-and-elements/classification-class . Those are not even IRDIs I believe, but probably quite useful for types.

So ideally, the maintainers of the IRDI standard (is it ISO/IEC) should come with some bijective transformation to IRI, e.g. defining an own schema. Eclass is doing some similar efforts, but those need to be on IRDI level. Or AAS-community should define those mappings and move on, who can make a proposal? We need to cover, IRDIs, ECLASS classification strings, UUIDs, what else?

I am not aware of any good derivation examples, i can ask in my sub-wg if you kindly open a question: https://github.com/admin-shell-io/questions-and-answers/issues

[BirgitBoss]

In Catena-X there was also a decision to only use URI for AAS ID and Asset ID.

For DPP there is a standard (currently under review) defining the allowed identifiers for "AssetInformation/globalAssetId" and "AAS/id" and (very roughly) "AdministrativeInformation/creator" or "SpecificAssetId/externalSubjectId"
I do not know all of these standards that are allowedf in the context of DPP but if all of them are conformant to URI then I would also support it.

semanticId is different.

Extract from Content of CEN/CLC/JTC 24 N 287:

ID schemes for products...............................................................................................................................
ID scheme 5.1: Web enabled, structured path and query ID for products.....................................
ID scheme 5.2: Identification Link (IL).....................................................................................................
ID scheme 5.3: Decentralized identifiers (DID) for products.............................................................
ID scheme 5.4: Product and group identification..................................................................................
ID Scheme 5.5: Digital Object Identifier (DOI) for products...............................................................
ID schemes for economic operators and facilities................................................................................
ID scheme 6.1: Structured path identification for organizations.....................................................
ID scheme 6.2: Legal Entity Identifier (LEI)............................................................................................
ID scheme 6.3: Decentralized identifiers (DID) for economic operator and facility...................
ID scheme 6.4: Digital Object Identifiers (DOI) for economic operator and facility...................

P.S. derivedFrom and assetType are implicitly covered as well since they reference an AAS or an Asset via ID.