Sorry my mistake, I will fix or pull this later tonight.

@MatthiasWiesmann in what format do you expect them here? It's hard to validate as the input alfanumeric and of variable length.

The most common one used also by the EU validation API seems to pass country as two letter iso separated from the vatid itself.

Basically I would suggest to do this:

{ 
  "@context" : "https://schema.org",
  "@type" : "Organization",
  "name" "Trenitalia",
  "iso6523": "9912IT05403151003"
}

Instead of this

{ 
  "@context" : "https://schema.org",
  "@type" : "Organization",
  "name" "Trenitalia",
  "vatID": "IT05403151003"
}

As the first version is globally unambiguous.
A more robust approach would be do do both, so different systems can parse the data.

{ 
  "@context" : "https://schema.org",
  "@type" : "Organization",
  "name" "Trenitalia",
   "iso6523": "9912IT05403151003",
  "vatID": "IT05403151003"
}

Fixed and also referenced iso6523Code

Should this/these be rdfs:subPropertyOf :identifier ?

Having said that, should we be adding to the proliferation of domain-specific identifier types when there is a standard approach to handle such needs:

{ 
  "@context" : "https://schema.org",
  "@type" : "Organization",
  "name" "Trenitalia",
  "identifier": {
   "@type": "PropertyValue",
   "propertyID": "iso6523",
   "value":  "9912IT05403151003"
    }
}

Honestly, reading into it I have a general question:
iso6523 seems to be only used by PEPPOL which in exchange is consumed through "access points", stupidly asked, was this implmented for a "one size fits all" or with any consumer in mind? Everybody (including google) seems to use the vatID instead of 6523. It seems to be relevant only for cross border e-invoicing through 3rd party gateways and not directly relevant to systems consuming schema.

Actually ISO 6523 is a third party solution which solves exactly the identifier structure you suggested.
The structure is OID (identifier type) + actual identifier, so it allows to express in a non ambiguous fashion the many identifiers which are not tax identifiers.

So the goal was to avoid adding more identifiers, it certainly makes more sense to have it at the root than say, DUNS. It also allow to distinguish cases where there are many government identifiers, like in France, where there is SIREN, SIRET. Some examples.

Yeah I saw that. The doubt that came up is that it seems like it's only consumed through special purpose systems connecting national einvoicing systems to the European interchange. Not saying it's not used, but I believe it's not really used in the web space. I align here with what you want, but I agree that maybe nesting it under identifier all together with also companyRegistration (which pains me as I just committed that) in one unified approach seems ideal. But I also see that vatID is already in use by google merchant so I don't know what can be done!

On a related note, the example in https://schema.org/iso6523Code is invalid as it duplicates "iso6523Code" instead of using an array.

Greetings to Australia :)

Can you elaborate?

On a related note, the example in https://schema.org/iso6523Code is invalid as it duplicates "iso6523Code" instead of using an array.

Right, I'll send a fix.

On a related note, the example in https://schema.org/iso6523Code is invalid as it duplicates "iso6523Code" instead of using an array.

Fix is here for your reviewing pleasure: #4649

Closing since it is a description update only. I suggest opening a new issue for the discussion about whether or not these should be a subproperty of identifier (if needed).