Is IRI with "pim:" scheme there by design or is it a bug?

[jakubklimek]

When I look into the store, I see IRIs starting with pim:. Is this intentional? It seem weird, as those IRIs should be https based.
e.g. pim:https://slovník.gov.cz/legislativní/sbírka/361/2000/pojem/má-evidovaného-držitele

[sstenchlak]

These IRIs are temporary and are not stored anywhere. Let me know if you think it would be better to use the HTTP-based iris.

The idea is that the interface between the CIM adapter (searching for elements, adding a surrounding, etc.) and our models uses the same constructs used in the model. Therefore, when you search for classes to add, you get a list of classes in PIM-like format. Similarly, you'll get a PIM graph of the surroundings when you want to add attributes or classes. These constructs are then used by extracting the necessary information and calling the operation which creates PIM and PSM entities in the model. CIM IRI is used just to make things easier. The prefix is added to stress that this is no longer a CIM entity. After the user is done, these resources are dropped and no longer used.

EDIT: Yes, it is intentional

[jakubklimek]

You mean they are not stored anywhere besides the model, right?

And what do you mean by "after the user is done"? I think we expect the specification (the specification manager project) to be part of the published artifacts so that it can be edited later. This means that the PIM and PSM gets stored somewhere, no?
Or am I missing something?

Regarding the "pim:" prefix, it is just that in general, those should be from the list and not invented arbitrarily. The question is whether you later somehow rely on the structure those "pim:" IRIs being somehow similar to CIM IRIs (which you should not), or they are still black boxes for you, and therefore can be changed/generated quite freely. Then we can discuss the change later.

[sstenchlak]

When you use a search box to pick a PSM root, you get a list of entities that were found in CIM. Then, you are asked to pick one entity you want to start with, and the class, represented by the entity, becomes your PSM root and is added to the PIM model as well. Both classes, PIM and PSM that are added to the model have the regular IRI - that with UUID in it.

I still need to somehow represent those entities in the search box and I decided that they should have the same interface as the PIM class, that is stored in the model. And these classes/entities use the IRIs with the prefix. So from one part of the application, you will get a list of those entities. You let the user pick one, and from that, the other part of the application creates PIM and PSM classes or association and attributes in case of "Add surroundings dialog." After that, you do not need those entities anymore.

You asked if I later somehow rely on the structure. After the search result or get surroundings result is constructed, those IRIs are treated as black boxes, hence not parsed nor somehow recreated from CIM IRIs. But, while constructing the result, I use them to simplify things. If X refers to Y, then I create pim:X that refers to pim:Y instead of making unique IRIs and then using dictionary to lookup for class with proper interpretation. I agree that this should be changed.

[jakubklimek]

I see, so what I see in the screenshot, the pim: IRI, is a temporary search result. If I were to choose it, it becomes a regular UUID IRI. OK, that does not seem like an urgent issue then.

[sstenchlak]

Yes, you are correct. The UI thinks that this is a regular class, and that was the point. To not treat these classes differently so I can use already existing components, like this dialog, to show details. Yes, it is not an urgent issue, but it is an issue.