Defer implementation of query-by-example

[bwalsh]

Leaving open for review during our next call. If no comments at that point, we can close

Request

http://yuml.me/edit/bf06b90a

Query by example

There are four datatypes types for each entity [string, external identifier, ontology identifier and 'entity']. Currently the implementation handles queries of [string, external identifier and ontology identifier].

The 'entity' query is a type of query-by-example defined in [GenomicFeatureQuery,EvidenceQuery,PhenotypeQuery]. We have not implemented them. Challenges that arose:

• schema constraints: there are several fields within the schemas that are defined as non-null. This may be fine when creating an entity from a data store, however, they are problematic when creating an entity to be used in a query.
• additional discussions needed to determine what properties from an existing entity will be used for the query and which will be ignored. For example a Feature has [id,parentIds, featureSetId, referenceName, start,end, strand, featureType, attributes] we need to specify exactly what the query's expectations are.

Recommendation: Leave the schema definitions as-is. However, leave the entity query-by-example unimplemented. Implement when demand exists with sufficient use case details.

[diekhans]

The lack of a specific subject (field) for the for the queries is both confusing and fragile. Adding a new field could cause existing queries to behave in unexpected ways .

If we know the desired behavior, then it's easy to make the schema more specific (and I can help). If we don't know the desired behavior, we have a bigger problem.

Avoiding making the schema queries clear doesn't seem like a good goal. The picture above indicates just the problem. This is also inconsistent with the rest of the API.