More metadata fields in manifests: icon, documentation

[wetneb]

In an API client like OpenRefine, it would be nice if we could:

• have a logo for each reconciliation service that has been added by the user. This suggests a standard way to obtain a logo for a service, either by supplying it as a field in the manifest, or by serving it at a standard location relative to the manifest (such as a favicon)
• offer a link to the documentation of the service, for instance to find out what properties or types it supports;
• anything else?

Intuitively it does not hurt to add optional support for such things: that does not make the life of service developers harder, and can yield nice benefits for the user if those mechanisms end up being adopted widely.

[thadguidry]

Version of their service? Since the URL might have version specified but that's inconsistent to parse by clients, so a metadata field is best I think.

[wetneb]

Do you mean the version of the software running the service? (I am assuming you are not talking about the version of the protocol since that is already exposed as a field). I guess that could be useful indeed, for instance to notice any changes in scoring / properties supported / …

[thadguidry]

Correct, not the protocol version. I was recalling what @epaulson had said on a meeting one time. A service provider could be providing machine learning feedback, etc. and have the current state of algorithms as a version (and potentially offer multiple versions to consumers). Having a metadata field for the version of the service, it's logo, it's URL.