Informational field for filtering terms

[mbaudis]

IMO the best (and non-breaking) improvement for filtering terms would be to add a modelPath (naming suggestions welcome) informational field which indicates against which field in the beacon default model a term is being applied logically (even if your local storage/implementation looks different):

  type: NCIT thesaurus (cancer subtree)
  id: NCIT:C66951
  label: Adenocarcinoma, Endocervical Type
  modelPath: biosamples.histologicalDiagnosis.id

This would help to make implementers understand the usage of the term in a resource, and could also be used e.g. as information in autocompletes etc.

[redmitry]

This is similar as the implementations actually do behind... but I oppose.
Things are more complicated - the id may be in array (for instance) or backing implementation (e.g. OMOP) wont have this format,
I think using "scope" as we already have is good enough to distinguish and the implementation (internally may do what it want).
For instance in BSC java implementation:

 {
    "id": "LOINC:3141-9",
    "label": "Weight",
    "type": "alphanumeric",
    "scopes": ["individual"],
    "query": "{'measures': {'$elemMatch': {'assayCode.id': '$$id', 'measurementValue.value': {$$operator: $$value}}}}}"
}

[mbaudis]

@redmitry This is a purely informational field, more for human readability. As an implementer, you just indicate this for a logical understanding where in the Beacon default model this would map. As a user you just use {"filters":{"id":"..."}} or the GET equivalent. This mostly addresses the understanding of filters.
Also: scopes should reflect the entities you can filter, not the entyity where the filter is being applied.

[redmitry]

Hm... understand.
For the information this even could be the schema element identifier in a form of Json Pointer.
How to interpret is in a case of multiple scopes?
Imagine the LOINC:3141-9 ("weight") filter that could be applied to several entryTypes.
The target will changes depending of the scope applied.

[mbaudis]

Note: The scopes part has been addressed in #118 . Also changed the draft parameter name from target to modelPath.

[mbaudis]

Updated argument: From recent discussions it has become apparent that this informational field would provide a powerful option to align between beacons, more than the filtering terms itself since

• when using the same model (e.g. the v2 default) identical paths in different resources would allow to compare the used terms for providing mapping solutions
• this is more feasible than having only terms available w/o indication of their conceptual target parameters¹

Footnotes

1. "Conceptual" since the internal implementation is obviously solution dependend ↩