Unsupported feature handling/error codes

[allasm]

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]

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

[Relequestual]

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

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]

I think it is useful for two reasons:

• testing and debugging
• transparency (what information was received and used)

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]

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]

I think we should put this off to 2.0.