Wikidata

Wikidata:Requests for comment/Organizing statements, sitelinks, and external identifiers

< Wikidata:Requests for comment


THIS RFC IS CLOSED. Please do NOT vote nor add comments.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Closing this RFC as obsolete. See #Still active ? on this page (from over 6 months ago). A number of wikidata UI elements have already changed since this proposal was introduced. External ids, part of the discussion here, have also now been implemented.

ArthurPSmith (talk) 19:53, 15 April 2016 (UTC)[reply]

Since the development team is working on a new Wikidata user interface, it might be the right time to discuss how to organize statements, sitelinks, and external identifiers, since that can have an effect on the UI too.

Statements

edit

Currently it is possible to move the position of statements up and down using the arrows that appear on edit mode. There are more than 30M statements, which suggest that this sorting method might not be sustainable if not supported by automated methods. The options that have been proposed so far include (but are not limited to):

  • using bots to sort the statements according to preferences stored on the property documentation
  • add a priority rank-level to properties
  • create a property taxonomy (see: Bugzilla:  49554 • 57843) and group the statements accordingly (i.e. group together all properties of the type "person property")
  • apply grouping depending on item taxonomy (i.e. the infobox model, freebase does something similar, too)
  • status quo

What are your thoughts on the topic? What are your preferences?

Comments about statements

edit
  • Bot sorting ? Yes, the best solution with the use of item taxonomy to identify the correct framework to apply. Property rank ? No, becausesome properties can be used in different kind of items with different importance. Same for property taxonomy. Snipre (talk) 17:44, 13 March 2014 (UTC)[reply]
  • It would be great if we could reproduce the structure of infoboxes with different sections, like for instance the infobox in w:fr:Helium which has several statement groups, however I cannot think of any way of doing it easily and without using cumbersome templates as freebase did. I agree with Snipre that we can have a general "sort number" which could be different depending on "instance of"/"subclass of". But how to manage it? If we make it too complex, it will be a hell to maintain. The order could be based on the lists on WD:P (which might be out-of-date). Pinging Ivan A. Krestinin to see what he thinks of storing that kind of information in a similar way to the constraint templates.--Micru (talk) 20:19, 13 March 2014 (UTC)[reply]
    • I think that properties sorting will create unneeded thinks that sort order is important and contains some information. Somebody will try to use this information in his algorithms... I think more perspective technique is external specialized editors. For example Wikidata editor integrated to Wikipedia infobox. — Ivan A. Krestinin (talk) 20:55, 13 March 2014 (UTC)[reply]
      • I agree partially, but for example it could be less overwhelming for casual wikidata visitors/editors if all statements with identifiers would go to the end of the page (or even hidden as suggested below). Some property pairs might make sense to put them close to each other, specially those that convey a period of time (date of birth/death, service entry/retirement, etc).--Micru (talk) 11:30, 14 March 2014 (UTC)[reply]
  • On the UI redesign page it was suggested to add statement sorting options. That could be a good compromise instead of having a fixed sorted structure. Most straightforward sorting options are:
  1. user-sorted order (status quo)
  2. numerical by property ID
  3. alphabetical by property name (user's language)
Other useful sorting options, but perhaps more difficult to implement, could be:
  1. membership properties on top, external identifiers on the bottom
  2. based on item taxonomy
Pinging The Rambling Man, Jeblad, Jon Harald Søby, and Izno, since they were interested in sorting options last year.--Micru (talk) 15:33, 15 March 2014 (UTC)[reply]
  1. Think about what happens when a wikipedian clicks on the template edit button and is invited to edit wikidata. The best user experience for them would be to have the properties arranged to match to order in that template and to have any missing properties added, ready for them to add values. We are not going to get there on this UI change but I still think it worth thinking about making the UI skinnable and flexible so that we can get there in the end. Filceolaire (talk) 23:00, 1 May 2014 (UTC)[reply]
Note that visually sorting (or organizing) the statements is more or less non-problematic, but to convey meaning in the organizing of statements are a huge can of worms – that would have implications on the data model and also how the triples should be reported in the RDF. Jeblad (talk) 15:17, 24 March 2014 (UTC)[reply]
  • Similar items should have a similar structure and - even if there is no intention - the order of statements does have a meaning. Most important information is expected to be on top - that is what most users are likely to be looking for. An order not reflecting that mental model will cause confusion and frustration.
    Sorting statements by property id, alphabetically and completely individually does not solve the issues just mentioned. Taxonomy would probably be the way to go. In fact, some kind of very basic taxonomy is already being put together when categorizing properties). However, applying taxonomy classes to items should not be strict retaining the option to add statements to items regardless of the taxonomy classes applied to them. Applying taxonomy would not result in "x has y" relations but rather "x may have y". Basically, this soft taxonomy would allow grouping/organizing statements on item level and one major benefit of having taxonomy is to be able to order the properties per taxonomy class.
    That would allow applying similar structure to similar items without sacrificing flexibility. (In addition, when applying taxonomy, one could easily find out which properties may be missing on an item as per taxonomy class.) Random knowledge donator (talk) 16:27, 24 June 2014 (UTC)[reply]
edit

Sitelinks appear always at the bottom of item pages, but the big number of them makes sometimes difficult to navigate the page (more distance to scroll to the "add sitelink", hard to find relevant languages to the user, etc). It is planned to merge all links to special wikis into one group (see: Bugzilla:  55507). And there are more options to reduce the space by showing only the languages relevant to the user with the option to expand the list. What are your thoughts on the topic? What are your preferences?

edit
  • Well, I have already seen items deleted only because they have no notable sitelink to Wikipedia, (but had such to Wikisource), so removing any sitelink in the UI which the UI does not think is notable to the user, that sounds really risky. I would prefer to have one matrix for all projects, that such mistakes shouldn't happen again. -- Lavallen (talk) 13:11, 13 March 2014 (UTC)[reply]
  • I propose to collapse the sitelinks part by default because after a period of correction, the number of modifications will become very small. But no change to the current display. Snipre (talk) 17:48, 13 March 2014 (UTC)[reply]
  • +1 to having a total number of sitelinks written on top of the sitelink section, and +1 to collapse sitelink lists if the list is >5 links, at least for the languages the user doesn't speak.--Micru (talk) 20:34, 13 March 2014 (UTC)[reply]
  • +1 for the collapsed list of sitelinks, apart for the relevant languages chosen by users. The total number of sitelinks (separated by projects) on the top of the page can be useful. --Paperoastro (talk) 20:53, 14 March 2014 (UTC)[reply]
  • I'd propose a single box for all sitelinks, with most relevant ones (based on the user's settings, as Compact language links) at the top, maybe with the others collapsed. --Ricordisamoa 02:55, 13 April 2014 (UTC)[reply]
  • There is already a "Main language first" gadget which (in my case) moves enwp to the top of the list. Collapsable sitelinks are good but maybe that gadget could keep your set language visible. Collapsing the sitelinks would help the situation Lavallen talked about since it would mean the wikisource sitelinks would be more visible - if the WP links are collapsed then the WS links wouldn't scroll off the page. Filceolaire (talk) 22:50, 1 May 2014 (UTC)[reply]

External identifiers

edit

External identifiers,also known as authority control (see: Template:Authority control properties or the more comprehensive MediaWiki:Gadget-AuthorityControl.js), are currently treated as statements. They also take a big chung of the page area, while not providing direct information. Additionaly the approval process is slow, since they are discussed as properties, when their usage is different and more restricted. The options that have been proposed so far include (but are not limited to):

  • treat authority control IDs as sitelinks with a community-controlled approval process
  • move them automatically to the bottom
  • put them on another screen area (Reasonator puts them on the right)
  • collapse them into a hidden group of "authority control statements"

What are your thoughts on the topic? What are your preferences?

Comments about external identifiers

edit
The whole concept of "identifiers" as it is right now is completly borken and should be reworked. Use URIs as identifiers! Jeblad (talk) 15:19, 24 March 2014 (UTC)[reply]

Still active ?

edit

@Micru: Can we close this RfC after more than one year without new edit ? Thanks Snipre (talk) 11:42, 13 August 2015 (UTC)[reply]

@Snipre: You can close this RfC since a lot of changes have happened already and more will happen in this front, therefore this rfc is obsolete.--Micru (talk) 21:17, 20 August 2015 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_comment/Organizing_statements,_sitelinks,_and_external_identifiers&oldid=322000489"