search

ga4gh / mme-apis

Documentation for the MatchmakerExchange APIs
https://github.com/ga4gh/mme-apis
34 stars 19 forks source link

Unsupported feature handling/error codes #84

Open allasm opened 9 years ago

allasm commented 9 years ago

We should agree how a matcher should indicate that certain data in a query was ignored when performing matching - either because certain optional fields were not supported, or because some of the required fields contain data in an unsupported ontology/format (e.g. a matcher may support MIM and not Orphanet, or only know assembly X and not Y)

Relequestual commented 9 years ago

How would that information be used? What's the Use Case for wanting this?

Relequestual commented 9 years ago

@buske @fschiettecatte Any further thoughts on this? I could see it may be useful for development purposes, but otherwise, how could it be displayed to the end user and under what conditions? Can anyone think of practical examples where this information would be informative, and the potential formats it might?

fschiettecatte commented 9 years ago

I would agree with @relequestual that this might be useful for testing, but I am not sure of the ROI needed to spec, implement and support.

buske commented 9 years ago

I think it is useful for two reasons:

I find the latter to be a much stronger argument. A simple way to implement this is to have the response include a parsed version of the query. Fields that could not be parsed or interpreted, or were not used, would not be returned.

Relequestual commented 8 years ago

I'm tempted to push this to v2.0. Thoughts?

Reviewing it now, my gut reaction is to allow simply plain text for this. If we're saying the simplest and actually useable use cases are for testing / debugging, and transparancy to the user, then english is probably the best form to do this.

We COULD come up with some meta language to describe how the query was transformed and executed, but then that opens a whole new can of worms of standards of meta data. If we see value in that in terms of machine readable information which could suggest which tunable elements to tweak, then I think we could pass on this query to the Meatadata Task Team.

For now, a human readable field would seem appropriate, and could be part of 1.1, but I think it may fit better with the modular vision for 2.0. I think the gain would be grater as part of 2.0 than 1.1, but open to hearing arguments either way.

buske commented 8 years ago

I think we should put this off to 2.0.