Wrong datatype syntax for EpcExternalPartReference (aka HdfProxy)
Hi,
I use the open-etp-server latest docker image with the Volve_Demo_Reservoir_Grid_Depth.epc ingested in dataspace 'demo/Volve' as suggested in the README.
Still following the README, I can observe that the command docker-compose run open_etp_server_runtime openETPServer space -S ws://open-etp-server_open_etp_server_build_run_6ccce8b7967e:9002 -u foo -p bar -s demo/Volve --stats
returns a wrong type for the EpcExternalPartReference
1 eml20.EpcExternalPartReference
2 resqml20.obj_CategoricalProperty
151 resqml20.obj_ContinuousProperty
3 resqml20.obj_DiscreteProperty
80 resqml20.obj_FaultInterpretation
7 resqml20.obj_GeneticBoundaryFeature
1 resqml20.obj_GridConnectionSetRepresentation
7 resqml20.obj_HorizonInterpretation
1 resqml20.obj_IjkGridRepresentation
1 resqml20.obj_LocalDepth3dCrs
1 resqml20.obj_OrganizationFeature
11 resqml20.obj_PropertyKind
3 resqml20.obj_PropertySet
1 resqml20.obj_StratigraphicColumn
1 resqml20.obj_StratigraphicColumnRankInterpretation
8 resqml20.obj_StratigraphicUnitFeature
8 resqml20.obj_StratigraphicUnitInterpretation
4 resqml20.obj_StringTableLookup
34 resqml20.obj_SubRepresentation
80 resqml20.obj_TectonicBoundaryFeature
3 resqml20.obj_TimeSeries
408 TOTAL
As you can see the first returned line above missed the "obj_" prefix which is not the case for the other returned datatypes.
Using my ETP1.2 client and asking for GetResources (Discovery protocol) of eml:///dataspace('demo/Volve'), I also observed the same error
*************************************************
uri : eml:///dataspace('demo/Volve')/resqml20.obj_ContinuousProperty(fd2e1600-8703-43dc-bd1d-25f7ed46f8b9)
name : 2006-10-01
sourceCount : 1
targetCount : 3
*************************************************
*************************************************
uri : eml:///dataspace('demo/Volve')/resqml20.obj_ContinuousProperty(ff31db15-b147-4260-80dd-20093bcf853d)
name : 2002-01-01
sourceCount : 1
targetCount : 3
*************************************************
*************************************************
uri : eml:///dataspace('demo/Volve')/resqml20.obj_DiscreteProperty(0578f0d3-2e8f-422a-af6f-89173f250a80)
name : fault_blocks
sourceCount : 0
targetCount : 2
*************************************************
*************************************************
uri : eml:///dataspace('demo/Volve')/resqml20.obj_DiscreteProperty(1d189a27-2f6e-445e-8720-58eb7e8e3ddf)
name : cellForFaultFace
sourceCount : 1
targetCount : 2
*************************************************
*************************************************
uri : eml:///dataspace('demo/Volve')/resqml20.obj_DiscreteProperty(c8a8e693-2057-4fe2-a519-c79357473eaf)
name : GEOLOGIC_K
sourceCount : 0
targetCount : 2
*************************************************
*************************************************
uri : eml:///dataspace('demo/Volve')/eml20.EpcExternalPartReference(f46c4dfa-0b15-4536-9469-0a2391f728e3)
name : C:/Users/dalsaab/Desktop/Light_Version/Volve_Demo_Reservoir_Grid_Depth.h5
sourceCount : 0
targetCount : 0
*************************************************
*************************************************
uri : eml:///dataspace('demo/Volve')/resqml20.obj_FaultInterpretation(0b33faf0-ca45-4e31-9c10-b403bb8a2e81)
name : |UNNAMED|
sourceCount : 1
targetCount : 1
*************************************************
The returned canonical URI for the EpcExternalPartReference misses the obj_ prefix which is not the case for the other returned URI.
Finally, looking at the postgre database, I see the same error + 2 other ones
The row 11 still misses the obj_ prefix. It is strange that row 1 and 2 also miss the obj_prefix. However, those two lines do not create any problem so far with my client. Probably because row 7 fixes row 1 and because row 2 does not look to be used.
Since the EpcExternalPartReference returned URI is not valid according to the standard definition of an ETP1.2 canonical URI, it creates blocking issue on my ETP1.2 client side (no validation and no finding for this unknown datatype). Could you please fix this issue?
FYI @deny