Michael Baudis

> filteringTerms.yaml is a reference implementation thing. Yes, no place in the model (as file). > The question is should we remove /filtering_terms endpoints from endpoints? A) It shouldn't be...

Closing this since the schema had been fixed; erroneous implementations can be pointed to the respective issue & PR.

> Actually, from the implementation point of view I see no much difference between parameters and filters. We can use filters as they were parameters. Exactly.

It is not clear how to use ontologyTermForThisType w/o examples (i.e. terms for biosample, individual... - added some but incomplete...) and there is also a logical duplication having a "unique"...

> Definition of an element or scope of the element, to describe each type of entry type included in a beacon Excellent!

@jrambla The missing `object` type can lead to schema parsers failing to transverse the schema structure. In my testing failed to instantiate an object from the schema. But anyway -...

... also this seems to update the develop branch w/ a massive code alignment. @costero-e => Please decide about the branch management there and think about cleaning/retiring branches which aren't...

@jrambla Sure, understood. But I guess the amount of aggregators, and esp. of the ones doing such checks, outside of Beacon core developer control are ... rather small. But anyway...

@costero-e So I feel like changing `string` -> `object` (no further definitions, like `info` right now; or even using the `info` prototype). This would remove future hassle - one could...

@costero-e @redmitry I'm actually for keeping the format the way I've submitted (list of strings) since otherwise we run into read-out/interpretation problems, if ill-specified objects are used. So still IMO...