It seems to be typical usecase that user want to look up which persons comply to a search constraint, e.g. by filling in an autocomplete input box. The return to this kind of request should be human readable to help the user make decisions on the sensibility of the result. A typical behaviour would be to return an identifier but it should be human readable.
Conceptually this human readable label to a person would have to be considere a statement on the person or be constructed from the statements stored in the prosopographical resource and thus only being returned via the factoid and statement endpoints. Creating this on client side is a) expensive and b) needs knowledge about the details of the implementation.
We (i.e. @sennierer and @richardhadden and me @GVogeler ) suggest to introduce a return label property for GET requests on the person resource, which would have the following features:
no expectation to be consistent over time
not considered to be explicitely stored (i.e. it might be created algorithmically on the fly from a currente state of date stored)
not mandatory (and would suggest to use the id of the person as default value)
not to be part of content in POST and PUT requests, although it can be part of the returns.
In practice this label would typically constructed from statements on names, basic biographical dates (birth, death) and maybe a claim of fame / occupation, but the decision how to construct this label would be completely under responsibility of the service provider.
It seems to be typical usecase that user want to look up which persons comply to a search constraint, e.g. by filling in an autocomplete input box. The return to this kind of request should be human readable to help the user make decisions on the sensibility of the result. A typical behaviour would be to return an identifier but it should be human readable. Conceptually this human readable label to a person would have to be considere a statement on the person or be constructed from the statements stored in the prosopographical resource and thus only being returned via the factoid and statement endpoints. Creating this on client side is a) expensive and b) needs knowledge about the details of the implementation. We (i.e. @sennierer and @richardhadden and me @GVogeler ) suggest to introduce a return
labelproperty for GET requests on thepersonresource, which would have the following features:idof the person as default value)labelwould typically constructed from statements on names, basic biographical dates (birth, death) and maybe a claim of fame / occupation, but the decision how to construct this label would be completely under responsibility of the service provider.