Open mbaudis opened 10 months ago
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}}}}}"
}
@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.
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.
Note: The scopes
part has been addressed in #118 . Also changed the draft parameter name from target
to modelPath
.
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
[^1]: "Conceptual" since the internal implementation is obviously solution dependend
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):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.