You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suggest to enumerate the three types of filtering terms to constrain the property.
Currently, the property is the following:
"type":{
"description": "Either \"custom\", \"alphanumeric\" or ontology/terminology full name. TODO: An ontology ... with a registered prefix does not need a full name so one may better use CURIE to indicate that the resource can be retrieved from the id. This also will allow to provide an enum here.",
"examples": [
"Human Phenotype Ontology",
"alphanumeric"
],
"type": "string"
}
The "custom" type already includes any other type of filters. This enumeration will help to standardize the filters endpoint in the different instances of Beacon, specially when gathering them in the Beacon Network.
The text was updated successfully, but these errors were encountered:
I addressed this issue by creating this new PR #90 . @SergiAguilo I couldn't add you as reviewer because I couldn't tag you, so I added @redmitry instead
In the beaconFilteringTermsResults.json the "type" property of the FilteringTerm is ambiguous as it only requires an string.
I suggest to enumerate the three types of filtering terms to constrain the property.
Currently, the property is the following:
My suggestion is:
The "custom" type already includes any other type of filters. This enumeration will help to standardize the filters endpoint in the different instances of Beacon, specially when gathering them in the Beacon Network.
The text was updated successfully, but these errors were encountered: