Unmappable Fields

Where GH#{n} is mentioned, it refers to a GitHub issue number n in the ePO project.

TED#5

There are a total of 46 unmappable fields in the earlier eForms mapping exercise under the TED#5 project, covering EF10-24 and EF29, SDK v1.3-1.10.

eForms SDK ID Name Mapping Notes (public)

BT-738-notice

Notice Publication Date Preferred

unmappable since publicationProvision was deleted in ePO 4.0.0. This is not a problem as these values are not provided in the xml input data.

BT-738-notice

Notice Preferred Publication Date

unmappable since publicationProvision was deleted in ePO 4.0.0. This is not a problem as these values are not provided in the xml input data.

OPT-001-notice

UBL version ID (UBL)

unmappable since ePO 4.0.0 does not provide a property for this.

OPT-002-notice

Customization ID (UBL)

unmappable since ePO 4.0.0 does not provide a property for this.

BT-01(e)-Procedure

Procedure Legal Basis (NoID)

Unmappable

BT-26(m)-Procedure

Classification Type (e.g. CPV)

The value of the listName attribute needs to be 'cpv' and it is added as an xpath condition for the mapping of BT-262-Procedure.

BT-26(a)-Procedure

Classification Type (e.g. CPV)

The value of the listName attribute needs to be 'cpv' and it is added as an xpath condition for the mapping of BT-263-Procedure.

BT-09(a)-Procedure

Cross Border Law

unmappable
Field value will NOT be created in the output if it is a ""masked"" value and a ""corresponding"" privacy field is also present.

BT-26(m)-Lot

Classification Type (e.g. CPV)

The value of the listName attribute needs to be 'cpv' and it is added as an xpath condition for the mapping of BT-262-Lot.

BT-26(a)-Lot

Classification Type (e.g. CPV)

The value of the listName attribute needs to be 'cpv' and it is added as an xpath condition for the mapping of BT-263-Lot.

OPT-090-Lot

Buyer Categories

Unmappable, see https://github.com/OP-TED/ted-rdf-mapping-eforms/issues/2

OPT-110-Lot-FiscalLegis

URL to Fiscal Legislation

Unmappable. We can refer to this as a generic Document, referenced by a notice. But there is no way to specify that this is a fiscal legislation document

OPT-111-Lot-FiscalLegis

Fiscal Legislation Document ID

Unmappable. We can refer to this as a generic Document, referenced by a notice. But there is no way to specify that this is a fiscal legislation document.
OP Feedback: This is mandatory in UBL when using OP-301 and/or OPT-111. Therefore this is not to be mapped.

OPT-120-Lot-EnvironLegis

URL to Environmental Legislation

Unmappable. We can refer to this as a generic Document, referenced by a notice. But there is no way to specify that this is an Environmental legislation document

OPT-112-Lot-EnvironLegis

Environmental Legislation Document ID

Unmappable. We can refer to this as a generic Document, referenced by a notice. But there is no way to specify that this is Environmental legislation document.
OP Feedback: This is mandatory in UBL when using OP-301 and/or OPT-111. Therefore this is not to be mapped.

OPT-130-Lot-EmployLegis

URL to Employment Legislation

Unmappable. We can refer to this as a generic Document, referenced by a notice. But there is no way to specify that this is an employment legislation document

OPT-113-Lot-EmployLegis

Employment Legislation Document ID

Unmappable. We can refer to this as a generic Document, referenced by a notice. But there is no way to specify that this is an employment legislation document
OP Feedback: This is mandatory in UBL when using OP-301 and/or OPT-111. Therefore this is not to be mapped.

BT-661-Lot

Maximum Candidates Indicator

Unmappable since there is no ePO property to use to indicate that there is a maximum number.

BT-761-Lot

Tenderer Legal Form

We used to have 2 properties in ePO 3.1.0 to encode the legal for requirements: epo:hasContractorLegalFormRequirement with a boolean value, that could be used to map this field, and epo:hasContractorLegalFormRequirementDescription that could provide the mapping for BT-76-Lot. In EPO 4.0.0 only epo:hasContractorLegalFormRequirement was kept, and its type was changed to rdfs:Literal, so we will use that to map the value of BT-76-Lot, and this (if listName="required" and its value is "true") will become a condition for BT-76-Lot

BT-45-Lot

Rewards Other

In EPO 4.0.0 the prize descriptions are provided as one (summary) value at the epo:DesignContestRegimeTerm (epo:hasDescriptionOfPrizes), not as descriptions of individual prizes as it is provided in eForms, so this is currently not directly mappable to EPO.

BT-47-Lot

Participant Name

Unmappable

OPT-060-Lot

Execution Requirements Factor

According to OP Feedback: Unmappable, this is a technical field required for a semantic association in the XML therefore it is not necessary in the RDF

OPT-050-Lot

Document Status

Based on OP Feedback, this is not to be mapped explicitly. Rather, it is used as part of the XPath expression in fields BT-708-Lot and BT-737-Lot, to specify whether the language of a procurement document is an official or unofficial language.

OPT-140-Lot

Procurement Documents ID

According to OP Feedback: This is mandatory in UBL when specifying information for procurement documents. Therefore this is not to be mapped.

BT-726-LotsGroup

Suitable For SMEs

This is unmappable. OP gave the following explanation: Because a lot is suitable for SMEs does not mean the LotGroup is suitable for SMEs. Suitable for SMEs is inherited from Procurement Object for the lot. LotGroup inherits neither from Lot or ProcurementObject therefore this is not mappable.

BT-300-LotsGroup

Additional Information

According to OP feedback: LotGroup cannot inherit from Lot and therefore this is not mappable.

BT-543-LotsGroup

Award Criteria Complicated

As per OP’s feedback, this cannot be mapped, as there is no relationship between epo:LotGroup and epo:AwardEvaluationTerm. GitHub issue https://github.com/OP-TED/ePO/issues/633 was opened for EPO. Potential mapping after EPO update:
epo:LotGroup / epo:AwardEvaluationTerm / rdf:langString
?this epo:isSubjectToLotSpecificTerm[!MissingProperty!] / epo:hasAwardCriteriaEvaluationFormula ?value .

BT-733-LotsGroup

Award Criteria Order Justification

As per OP’s feedback, this cannot be mapped, as there is no relationship between epo:LotGroup and epo:AwardEvaluationTerm. GitHub issue https://github.com/OP-TED/ePO/issues/633 was opened for EPO. Potential mapping after EPO update:
epo:LotGroup / epo:AwardEvaluationTerm / rdf:langString
?this epo:isSubjectToLotSpecificTerm[!MissingProperty!] / epo:hasAwardCriteriaOrderJustification ?value .

BT-509-Organization-Company

Organisation eDelivery Gateway

This is unmapped, as it does not have direct corresponce in EPO.
The only way that this information can be translated to the EPO model, would be to create a Channel on the Role that is referencing this Organization (through the epo:playedBy relationship), and add this value as the epo:hasAddressURL on that Channel.
So, the epo:AgentInRole instance that has a epo:playedBy relationship to this org:Organization instance should have another mapping:
Class path: epo:AgentInRole / cv:Channel / xsd:anyURI
Property path: ?this epo:exposesChannel / epo:hasAddressURL ?value .
where the ?value comes from this field. Quite hard, if not impossible, to instantiate this using RML.

OPT-201-Organization-TouchPoint

TouchPoint Technical Identifier

We use the value of this field as part of the IRI of this new ContactPoint instance, created at ND-Touchpoint, so that it can be referenced later.

BT-509-Organization-TouchPoint

eDelivery Gateway

This is unmapped, as it does not have direct corresponce in EPO.
The only way that this information can be translated to the EPO model, would be to create a Channel on the Role that is referencing this TouchPoint (through the epo:hasContactPointInRole relationship), and add this value as the epo:hasAddressURL on that Channel.
So, the epo:AgentInRole instance that has a epo:hasContactPointInRole relationship to this cpov:ContactPoint instance should have another mapping:
Class path: epo:AgentInRole / cv:Channel / xsd:anyURI
Property path: ?this epo:exposesChannel / epo:hasAddressURL ?value .
where the ?value comes from this field. Quite hard, if not impossible, to instantiate this using RML.

OPT-999

Dummy Tender Award Date

It seems that ePO does not have a Concept for this.

BT-1561-NoticeResult

Group Framework Re-estimated Value

Field value will NOT be created in the output if it is a ""masked"" value and a ""corresponding"" privacy field is also present.
This field cannot be mapped to EPO 4.0.0, but will be mapped to EPO 4.2.0, see ePO GH issue #644.

OPT-210-Tenderer

Tendering Party ID

We create an epo:OrganisationGroup instance and use this ID as part of its IRI.

OPT-301-Tenderer-MainCont

Main Contractor ID Reference

The relationship between the subcontractor and the "main" contractor giving it a subcontract (which is one of the tenderers within this tendering party) cannot be mapped according to EPO 4.0.0.

OPT-321-Tender

Tender Technical Identifier

There is no need to map this field per se, as the value of this field, which is a technical identifier, will be used (only) as part of the epo:Tender instance IRI that is created at the node ND-LotTender.
The proper identifier instance the will be associated to the epo:Tender intence will be provided by the field BT-3201-Tender.

BT-1711-Tender

Tender Ranked

Cannot be mapped, as ePO does not provide a way of explicitly encoding this indicator. However, a SPARQL query can be written that checks whether the output contains an epo:TenderAwardOutcome instance that links to this epo:Tender instance, and which has a value on the epo:hasAwardRank property, or not.

BT-730-Tender

Subcontracting Value Known

Cannot be mapped, as ePO does not provide a way of explicitly encoding this indicator. However, a simple SPARQL query can be written that checks whether the output contains the value in question, or not.

BT-731-Tender

Subcontracting Percentage Known

Cannot be mapped, as ePO does not provide a way of explicitly encoding this indicator. However, a simple SPARQL query can be written that checks whether the output contains the value in question, or not.

OPT-322-LotResult

LotResult Technical Identifier

We create an epo:LotAwardOutcome instance at the node ND-LotResult, and use this ID as part of its IRI.
There is no need for a mapping here, as ePO does not foresee an adms:identifier on the LotAwardOutcome class.

OPT-155-LotResult

Vehicle Type

This code does not exist in ePO. Instead, each of the three values found in the codelist are represented in ePO as attributes mapped in field OPT-156-LotResult.

BT-712(a)-LotResult

Buyer Review Complainants (Code)

In EPO 4.0.0 BT-712 is only covered as a number, without a codelist for specifying type, because that s how CELEX Annex specifies it. The at-voc:review-type codelist is used in the context of the epo:ReviewDecision class, which is used only in relation to the epo:CompletionNotice class.
So, this field cannot be (and doesn’t need to be) mapped explicitely, but we could use it as part of an XPath condition for the mapping of BT-712(b)-LotResult, since for that mapping to be valid, this field should have the value 'complainants' (which is currently the only value in the at-voc:review-type codelist).

BT-760-LotResult

Received Submissions Type

Field value will NOT be created in the output if it is a "masked" value and a "corresponding" privacy field is also present.

BT-506-UBO

UBO Email Address

Unmappable, since we do not have an email attribute for a Person. We could use the business of the person’s contact point but that is already mapped elsewhere.

BT-503-UBO

UBO Telephone Number

Unmappable, since we do not have a telephone attribute for a Person. We could use the business of the person’s contact point but that is already mapped elsewhere.

BT-739-UBO

UBO Contact Fax

Unmappable, since we do not have a fax attribute for a Person. We could use the business of the person’s contact point but that is already mapped elsewhere.

TED#7

There are a total of 53 unmappable fields in the second and most recent eForms mapping exercise under the TED#7 project, covering all eForms subtypes as of April 2025 except X01 and X02, SDK v1.3-1.13 except v1.4.

eForms SDK ID Name Mapping Notes (public)

BT-804-Review

Review Technical Identifier

This is a Technical identifier, which will be used as part of the IRI, but not directly mapped as an identifier, because there is only one property for the (ReviewObject) document that can point to an adms:Identifier instance, and that will be used to map field BT-784-Review.

BT-783-Review

Review Request or Decision

(Starting with SDK 1.13) the value of this field (which can have one of the two code list values "Decision" and "Request") is to be used in XPath conditions, to decide if the node ND-ReviewStatus is to be instantiated as epo:ReviewRequest or epo:ReviewDecision, and the value of all "sibling" fields should be added to that.

BT-786-Review

Review Notice Section Identifier

This is not directly mappable to ePO 4.0.0.
The values of this fields are ""section IDs"" defined in this table: https://docs.ted.europa.eu/eforms/latest/schema/all-in-one.html#_referring_to_sections_of_a_notice
Some of them, which represent technical ids, could be mapped to existing instances, by adding some conditional mappings according to the values in this table, with this Class Path/Property Path:
epo:ReviewRequest / xsd:anyURI
?this epo:hasElementReference ?value .
However this would be only a partial solution (i.e. it would not work for all values), so we decided it is cleaner not to map the value of this field to EPO 4.0.0 at all, but only to the next version of EPO, where this problem will be resolved.
See GH issue: https://github.com/OP-TED/ePO/issues/756

BT-806-Procedure

Exclusion Grounds Source

Unmappable because the Exclusion Ground Source concept was added in the second amendment of the eForms Annex. The concept Exclusion Ground Source does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-681-Lot

Foreign Subsidies Regulation

Unmappable because the Foreign Subsidies concept was added in the second amendment of the eForms Annex. The concept Foreign Subsidies does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-821-Lot

Selection Criteria Source

Unmappable because the Selection Criteria Source concept was added in the second amendment of the eForms Annex. The concept Selection Criteria Source does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-810-Lot

EED Applicable

Unmappable because the EED concept was added in the second amendment of the eForms Annex. The concept EED does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-811(a)-Lot

EED List (Basis)

Unmappable because the EED concept was added in the second amendment of the eForms Annex. The concept EED does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-811(b)-Lot

EED List (Item)

Unmappable because the EED concept was added in the second amendment of the eForms Annex. The concept EED does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-684-Lot

IPI Measures are Applicable

Unmappable because the IPI concept was added in the second amendment of the eForms Annex. The concept IPI does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

OPT-150-Lot

Subcontracting Allowed

Unmappable. This field existed only until SDK v1.8, which will be deprecated in April 2025. The field has never been used, therefore the decision is not to map (not even in future version of EPO)

BT-682-Tender

Foreign Subsidies Measures

Unmappable because the Foreign Subsidies concept was added in the second amendment of the eForms Annex. The concept Foreign Subsidies does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-685-LotResult

Specific IPI Measure

Unmappable because the IPI concept was added in the second amendment of the eForms Annex. The concept IPI does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-687-LotResult

Exception to the application of the IPI Measure

Unmappable because the IPI concept was added in the second amendment of the eForms Annex. The concept IPI does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-688-LotResult

Overriding reasons relating to the public interest

Unmappable because the IPI concept was added in the second amendment of the eForms Annex. The concept IPI does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-686-LotResult

Number of tender applications that fall under this IPI Measure

Unmappable because the IPI concept was added in the second amendment of the eForms Annex. The concept IPI does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-811(a)-LotResult

EED List (Basis)

Unmappable because the EED concept was added in the second amendment of the eForms Annex. The concept EED does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-811(b)-LotResult

EED List (Item)

Unmappable because the EED concept was added in the second amendment of the eForms Annex. The concept EED does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-812-LotResult

Energy Efficiency Label

Unmappable because the EED concept was added in the second amendment of the eForms Annex. The concept EED does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-813-LotResult

Energy Consumption in kWh/year

Unmappable because the EED concept was added in the second amendment of the eForms Annex. The concept EED does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

OPT-080-LotResult

Consumption Metric

Unmappable because the EED concept was added in the second amendment of the eForms Annex. The concept EED does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-814-LotResult

Energy Savings in kWh/year

Unmappable because the EED concept was added in the second amendment of the eForms Annex. The concept EED does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

OPT-081-LotResult

Savings Metric

Unmappable because the EED concept was added in the second amendment of the eForms Annex. The concept EED does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-815-LotResult

Energy Efficiency Quantity

Unmappable because the EED concept was added in the second amendment of the eForms Annex. The concept EED does not exist in ePO 4.0.0. it will be introduced in 5.0.0.

BT-127-notice

Future Notice

Likely unmappable. See GH issue https://github.com/OP-TED/ePO/issues/726

BT-26(m)-Part

Classification Type (e.g. CPV)

Unmappable (See GH #726)

BT-26(a)-Part

Classification Type (e.g. CPV)

Unmappable (See GH #726)

OPT-110-Part-FiscalLegis

URL to Fiscal Legislation

Unmappable (See GH #726)

OPT-111-Part-FiscalLegis

Fiscal Legislation Document ID

Unmappable (See GH #726)

OPT-120-Part-EnvironLegis

URL to Environmental Legislation

Unmappable (See GH #726)

OPT-112-Part-EnvironLegis

Environmental Legislation Document ID

Unmappable (See GH #726)

OPT-130-Part-EmployLegis

URL to Employment Legislation

Unmappable (See GH #726)

OPT-113-Part-EmployLegis

Employment Legislation Document ID

Unmappable (See GH #726)

BT-71-Part

Reserved Participation

unmappable

OPT-050-Part

Document Status

unmappable

BT-708-Part

Documents Official Language

This is not properly mappable to EPO.
The closest mapping, which was originally proposed, is:
CP: epo:AccessTerm / epo:ProcurementDocument / at-voc:language
PP: ?this epo:involvesProcurementDocument / epo:hasOfficialLanguage ?value .
However, as explained in GH issue https://github.com/OP-TED/ePO/issues/732, the information under any given repetition of the ND_PartProcurementDocument node, can refer either to a single document or to a place where multiple documents can be accessed.
codeList/id modified to ""language"" (generalization) from SDK 1.12 onwards.

BT-737-Part

Documents Unofficial Language

This is not properly mappable to EPO.
The closest mapping, which was originally proposed, is:
CP: epo:AccessTerm / epo:ProcurementDocument / at-voc:language
PP: ?this epo:involvesProcurementDocument / epo:hasUnofficialLanguage ?value .
However, as explained in GH issue https://github.com/OP-TED/ePO/issues/732, the information under any given repetition of the ND_PartProcurementDocument node, can refer either to a single document or to a place where multiple documents can be accessed.
codeList/id modified to ""language"" (generalization) from SDK 1.12 onwards.

OPT-140-Part

Procurement Documents ID

Unmappable for the same reason as OPT-140-Lot

OPT-070-Lot

Reserved Execution justification

Unmappable. See GH issue https://github.com/OP-TED/ePO/issues/726

OPP-040-Procedure

Main Nature - Sub Type

Unmappable (See GH #726)

OPT-071-Lot

Quality Target Code

Unmappable (See GH #726)

OPT-072-Lot

Quality Target Description

Unmappable (See GH #726)

OPP-020-Contract

Assets related contract extension indicator

Unmappable (See GH #726)

OPP-021-Contract

Used asset

Unmappable (See GH #726)

OPP-022-Contract

Significance (%)

Unmappable (See GH #726)

OPP-023-Contract

Predominance (%)

Unmappable (See GH #726)

OPP-080-Tender

Kilometers Public Transport

Unmappable (See GH #726)

OPP-035-Tender

Revenues Allocation of tickets sales code

Unmappable (See GH #726)

OPP-032-Tender

Revenues Allocation

Unmappable (See GH #726)

OPP-030-Tender

Contract conditions Code

Unmappable (See GH #726)

OPP-031-Tender

Contract Conditions Description (other than revenue allocation)

Unmappable (See GH #726)

OPP-033-Tender

Penalties and Rewards Code

Unmappable (See GH #726)

OPP-034-Tender

Penalties and Rewards Description

Unmappable (See GH #726)

SHACL Violations

Issue

sh:DatatypeConstraintComponent epo:hasPublicationDate false positive (tooling/MWB issue), many files (e.g. 440582-2024)

sh:DatatypeConstraintComponent epo:hasOJSIssueNumber known type conflict issue in ePO (expects integer but reality is string)

sh:MinCountConstraintComponent epo:hasAwardCriteriaStatedInProcurementDocuments known issue in ePO 4

sh:MinCountConstraintComponent epo:hasOfficialLanguage known issue

sh:ClassConstraintComponent time:unitType known tooling issue (requires external Time ontology loaded during validation)

sh:MinCountConstraintComponent epo:isSubjectToProcedureSpecificTerm issue with missing elements in some data (no relevant Procedure terms) with other reason

sh:MinCountConstraintComponent epo:refersToLot known issue with referenced entity with minimal information (previous Notice) generally (“external resources”)

sh:MinCountConstraintComponent epo:hasTimePeriod known issue about alternative predicate

sh:DatatypeConstraintComponent epo:hasBeginning known type conflict issue in ePO (expects dateTime but reality is date) generally

sh:DatatypeConstraintComponent epo:hasEnd known type conflict issue in ePO (expects dateTime but reality is date) generally

sh:MinCountConstraintComponent epo:hasNoticeType known issue with referenced entity with minimal information (previous Notice) generally (“external resources”)

sh:MinCountConstraintComponent epo:refersToProcedure known issue with referenced entity with minimal information (previous Notice) generally (“external resources”)

sh:DatatypeConstraintComponent epo:hasContractConclusionDate known type conflict issue in ePO (expects dateTime but reality is date) generally

sh:MinCountConstraintComponent epo:hasProcedureType issue with missing elements in some data (no ProcedureCode or even TenderingProcess) with other reason

sh:DatatypeConstraintComponent epo:hasAwardDecisionDate known type conflict issue in ePO (expects dateTime but reality is date) generally

sh:MinCountConstraintComponent adms:identifier known issue about missing identifier for planned procurement objects

sh:MinCountConstraintComponent epo:hasLotReference referenced entity with minimal information (proxy FrameworkAgreement)

sh:DatatypeConstraintComponent epo:hasEstimatedInvitationToTenderDate known type conflict issue in ePO (expects dateTime but reality is date) generally

sh:DatatypeConstraintComponent epo:hasProcurementDocumentChangeDate known type conflict issue in ePO (expects dateTime but reality is date) generally

sh:MinCountConstraintComponent epo:relatesToEFormSectionIdentifier issue with missing elements in some data (no changed section identifier), see for e.g. SDK example change-cn_24_void

sh:DatatypeConstraintComponent epo:hasOpeningDateTime known type conflict issue in ePO (expects dateTime but reality is date) generally

sh:DatatypeConstraintComponent epo:hasReceiptTenderDeadline known type conflict issue in ePO (expects dateTime but reality is date) generally

sh:DatatypeConstraintComponent epo:hasAdditionalInformationDeadline known type conflict issue in ePO (expects dateTime but reality is date) generally

sh:DatatypeConstraintComponent epo:hasEstimatedInvitationToExpressInterestDate known type conflict issue in ePO (expects dateTime but reality is date) generally

sh:MaxCountConstraintComponent epo:hasMainActivity known issue about multiple activity types declared in some data

sh:MaxCountConstraintComponent dct:description known issue about multiple values with language tags

sh:DatatypeConstraintComponent epo:hasDeadline known type conflict issue in ePO (expects dateTime but reality is date) generally

sh:MinCountConstraintComponent epo:isSubmittedForLot known issue about Lot- vs. LotGroup-specific property

sh:DatatypeConstraintComponent epo:hasReceiptExpressionDeadline known type conflict issue in ePO (expects dateTime but reality is date) generally

sh:DatatypeConstraintComponent epo:hasReceiptParticipationRequestDeadline known type conflict issue in ePO (expects dateTime but reality is date) generally

sh:MaxCountConstraintComponent epo:hasRecurrenceDescription known issue about multiple values with language tags

sh:MaxCountConstraintComponent locn:fullAddress when reported in multilingual notices (e.g. the SDK example cn_24_multilingual), known issue about multiple values with language tags

sh:MaxCountConstraintComponent skos:prefLabel known issue about multiple values with language tags