daniel added a comment.

Here's a straw man idea for the approach using qualifiers:

Scenario:

  • we assume that we typically have the plain text name, and use it to find a URI, not the other way around
  • we have a "person" data type that uses plain string values
  • we have a single well known property for qualifying a "person"-type statement with a URL/URI that identifies the person.

This means:

  • The new data type can be added with minimal effort in the backend.
  • Clients that need to know a URI for a person need to know about the person-uri qualifier property
  • The UI needs to know the special qualifier property.

UI integration could work like this:

  • if the statement has the type "person" and does not yet have a person-uri qualifier, a button labeled "Find URI for Foo" is added next to the "add qualifier" button. "Foo" is the plain name from the main snak.
  • when that button is clicked, we search well known data sets (Wikimedia users, Wikidata items, ORCID, VIAF) for the name, and allow the user to choose one of the results.
  • a person-uri qualifier is added containing the URI from the search.

When editing a "person" statement that already has a person-uri qualifier, nothing special happens.

@Lydia_Pintscher, @Jan_Dittrich, what do you think? It seems to me that the decision is mostly a UI issue at this point.


TASK DETAIL
https://phabricator.wikimedia.org/T127929

EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: thiemowmde, Ladsgroup, Liuxinyu970226, Pigsonthewing, Bugreporter, Jan_Dittrich, Josve05a, Sadads, Pokefan95, gerritbot, DannyH, Micru, intracer, mkroetzsch, Aklapper, daniel, Steinsplitter, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, El_Grafo, Mbch331
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to