aasx.adapter: fix semantic id type deserialization of ModelReference

[JGrothoff]

Many AASX packages include semantic ids with external or model references.

Concept descriptions are lost when reading and writing back to AASX

Problem

When a semantic id with a ModelReference is deserialized its type is currently set to the abstract type Referable.
When the aasx is serialized again and the semantic id refers to a concept description, it is skipped, because only concrete ModelReference types are looked up and serialized.

Solutions

• Suggested: Set the type of the semantic id to the concrete type determined by the last key element.
• Alternative: Skip the type check as errors are caught anyway (EAFP style). Maybe lowering the loglevel to warning or info.

Writing aasx with external references as semantic ids produce many info logs

Problem

Often an external reference with a global id (e.g. to ECLASS IRDIs) is used as semantic id.
A typical technical data submodel may easily contain around 100 of them.
Writing to an aasx will print an info message for each semantic id, that is not a model reference to an concept description, which clutters the output.

Solutions

• Suggested: skip external references without log message
• Alternative: lower logging level to debug or delete log info.

[JGrothoff]

I hope this won't introduce side effects, as the _construct_model_reference method is used frequently.
We could addittionaly add a check and fallback to type_ if last_key_type is type(None).

[s-heppner]

Thank you very much for your input!
This is indeed a quite complicated problem, as the specification was not clear about which ReferenceType to use and therefore we have lots of weird AASX files in the wild.

I agree that our SDK should not discard content without warning when reading and writing again, so that is definitly something that needs to be addressed.

Regarding your suggestions: I need to do some more thinking about which solution is the one with the least repercussions. I'll bring this discussion to our dev meeting and will get back to you.

[JGrothoff]

Thanks for investigating the topic so far!
I will try to add or update the tests to cover the issue (thats why i marked this as Draft).

[JGrothoff]

I added a test that covers all semantic ids that are expected to be ModelReferences for the same type.

[s-heppner]

This is what we concluded in our meeting:

• We cannot allow writing wrong AASXs. If the ConceptDescription of the ModelReference is not found, we should raise an Error as the AASX is wrong.
• However, we should obviously not silently discard content, as in not warning the user about the issue.
• We should try to declutter our output (if there's not actually an issue with the ExternalReference). This message may be now unnecessary and might have been historically grown

Sadly, I did not have time yet to look deeper into the matter.

[JGrothoff]

• We cannot allow writing wrong AASXs. If the ConceptDescription of the ModelReference is not found, we should raise an Error as the AASX is wrong.

I rebased on main and changed to a re-raise for those cases. It will raise an error if the reference is a ModelReference and has the type ConceptDescription, but it can't be resolved in the given object_store.
Of couse, we could change the Exeception class here, but i will leave that up to you.

This will still not check if

• an abstract Reference or
• a ModelReference with type other than a ConceptDescription
  can be resolved and is contained in the object_store (or in the objects_to_be_written).
  But it will log an info message about that, like before.