PROPERTY ontology is too generic to resolve clashing identifiers

[GregIthaca]

After loading a dataset and running into errors of the following type:

PROPERTY_000089,SYSTEM COMMS does not exhibit CWE-788 (Access of memory location after end of buffer),COMMS,CWE-788,ACERT-SARIF,URI lookup on [?scopeOf_ENTITY] found multiple URI's matching: COMMS,89
PROPERTY_000090,SYSTEM COMMS does not exhibit CWE-908 (Use of unitialized resource),COMMS,CWE-908,ACERT-SARIF,URI lookup on [?scopeOf_ENTITY] found multiple URI's matching: COMMS,90

I used the RACK GUI to search for the offending instances by setting up both a CONSTRUCT and a SELECT DISTINCT query on the ENTITY class with a runtime constraint of = 'COMMS'. The construct query gave the following anomalous-looking result:

The SELECT DISTINCT query showed the following:

ENTITY	ENTITY_type	identifier
uri://semtk#67ffb66c-8f06-4e07-8ac2-b5e3e9cc8685	http://arcos.rack/SYSTEM#SYSTEM	COMMS
uri://semtk#f5a139ed-5382-4c65-981a-93b6e4522241	https://UPSat_SystemModel/Overlay#Subsystem_Requirement	COMMS

Because the type of the PROPERTY is generically listed as ENTITY, it's not possible to use it to attribute the PROPERTY that a CLAIM 'declares' unless there is a unique identifier across all subclasses of ENTITY for the scopeOf that PROPERTY.

Is there any straightforward way to resolve this other than explicitly subclassing PROPERTY for each scope of interest, for example (in this case) 'SYSTEM'?

[glguy]

The obvious solution is not to have identifiers that conflict across classes. Then there's no ambiguity. In previous ingestion packages we've used class-based prefixes on identifiers to avoid conflicts. But renaming all your identifiers probably isn't what you're asking for.

Another solution is to make a new nodegroup that uses a type-specific lookup for scope. To do this I started with SemTK's Nodegroup > Get class template... and then replaced the scopeOf ENTITY node with a SYSTEM node. Then I could save this node group and use it as the target of an ingestion by name.

ingest_PROPERTY - modified.json

A solution that I think would work in principle (but perhaps would require a new feature) would be to allow you to specify the type you were intending to match as one of the columns of the CSV. I don't think we can do this today and I'm going to have to look after I make this reply.

[GregIthaca]

Even the first solution is entirely reasonable; the issue is that right now the GE trial ingestion package contains identifiers that came directly from SysML that was ingested, and so there isn't a lot of control over the names.

I wasn't aware of the type-specific nodegroup option. We had fallen back to using exclusively the "default" nodegroups, but I can see that would be a very elegant solution here, and I think we still have al the architecture in place that would be needed for it.