Michael Baudis

@redmitry Well, I wouldn't mind how you name your endpoint as long as path & entry type are provided. But it is inconsistent: ``` individual: ... endpoints: ... runs: returnedEntryType:...

@redmitry Where is the ``` "endpointSets": { "Variants": { ``` ... from? Shouldn't be anywhere (unless it ended somewhere in a branch?). Back to case: IMO fix is sound.

@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...

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 *...

> * A resultset is the equivalent of a collection. > * The collection concept is defined in the framework. > * Every model could have different entry types of...

... but one thing I still do not see is where in the schema we define which type of `resultSets` (_i.e._ `cohort` or `dataset`) is being returned... I use dataset...

@jrambla This doesn't help. Logically a dataset isn't a collection of variants but a collection of records in the entities of the data model, with inherently consistent ids used for...

@jrambla Datasets: Well, the unitary connection in the diagram was mostly to emphasize the difference between cohorts as a transversal collection type, and datasets as the "internal organization" one, as...

@jrambla > Yes, exactly. We just use datasetIds ... is actually in line w/ the framework examples (which in principle don't have to be in line w/ the default model...