Encoding the internal museum ID properly

[tschleider]

This is based on the following e-mail conversation

We agreed to not touch the UUID generation for objects, based on the JSON IDs, but we realised that the internal museum IDs are not / not fully represented in the KG and need to address this.

Results of all P2_has_types of E42 Identifier Assignment: LINK

[tschleider]

I went through every converter and made sure that the internal museum number is now in the KG (if available) without touching the URI UUID generation.

I uploaded the fix to stage. Here an example from IMATEX: https://ada-preprod.silknow.org/describe/?url=http%3A%2F%2Fdata.silknow.org%2Fobject%2F79a4a7d4-0479-39df-a5ae-f93b99deb7dc%2Fid%2F2655&sid=383

[tschleider]

Now also on production:

https://data.silknow.org/object/79a4a7d4-0479-39df-a5ae-f93b99deb7dc/id/2655

[rtroncy]

Good, what about normalizing the P2_has_type values attached to E42_Identifier_Assignment?

[tschleider]

I normalised all P2 values of E42 according to the mail of @mpuren : Link

Example from above again: https://data.silknow.org/object/79a4a7d4-0479-39df-a5ae-f93b99deb7dc/id/2655

I also went through every dataset and checked that we have implemented all existing museum IDs.

Next step should probably be to only show the rdfs:label value of all E42s that have P2 "Object Identifier" @rtroncy @ehrhart in ADASilk, right? Because right now we show the dc:identifier value of every E22 and this is not in all cases the internal museum object identifier that the domain experts expect.

[tschleider]

Since our last discussion this could be merged with #77.

Internal Museum identifiers are now the value of dc:identifier of E22 and nowhere else. E42 and E15 are normally not instantiated anymore. Example:

http://data.silknow.org/object/ef3d3703-f96d-391d-af4c-15884e613281

Issue can be closed.