The UI should show some hint if suggested statements or references are available, even if the part where they are found is currently collapsed. This is the default for references. For statements, it only happens when there are long lists of statements that do not have the suggestions on top. The challenge is to find a good but not overly intrusive display for this.

Hi,

The link to the respective Wikidata page is incorrect for property pages (e.g. on http://tools.wmflabs.org/sqid/#/view?id=P106). The click on P106 (top) leads to

https://www.wikidata.org/wiki/P106

instead of

https://www.wikidata.org/wiki/Property:P106

This happens also for the "Wikidata page" link. This could be fixed by linking to the entity page (for properties and entities - i.e. using https://www.wikidata.org/entity/ instead of https://www.wikidata.org/wiki/).

Andreas

It would be good if the label filter would take the id into account, so that you also get P18 when entering P18 as a label.

Statement values are now shown in the order they are stored in Wikidata. As the main criterion, values should instead be ordered by rank (preferred > normal > deprecated).

Further possibilities to define an order with one rank:

• Temporal information (P580, P585 qualifiers, highest first)
• Position information (P1352, P1545 qualifiers, lowest first)

Ordering by item label is maybe not good since it means the order may change when the labels are fetched (this happens on demand while the page is loaded).

So we cannot use sanitization strategy because

//.useSanitizeValueStrategy('escape') // using this makes it impossible to use HTML (links, tooltips, etc.) in variable replacements

are there other options to deal with this than turning off this security feature? (the to_trusted filter or similar maybe?). If my understanding of the matter is correct, then for an application that basically displays only publicly available data, having XSS vulnerability is not the end of the world. Still it would be nice to not have it if possible.

The query view should indicate when we are waiting for results by adding a spinner. It should also indicate when a query timed out or otherwise failed. Currently this happens only in some cases, but apparently not on all timeouts. In case of a timeout, the server may respond with a partial result list that is interrupted by a Java exception string.

A first spin-off from the current work on a query UI should be a stand-alone view that shows results from a fixed SPARQL query, without providing any UI to change it. This would be used by other views to link to such results. It should be possible to view the full SPARQL query and to go to the query service to edit it, but by default there should simply be a clean result page with the paged list we already have now.

The view can assume that the given SPARQL query has a single result variable of a predefined name (e.g. "entity") rather than having to find it form an arbitrary query string.

Some statement suggestions of PS cannot be rejected. It would be good to have a little error popup as in the Wikidata gadget in this situation. Currently, SQID just logs an error (typically 404) in the console.

Huge thanks for the work on feature #69!

I noted that article references are also listed just by the Wikidata item label:

This makes a lot of sense, but less common for article type references ('instance of' 'scientific article', like the above example for Q23571594.

Any change of using a JavaScript library to show the full references? There are likely other libraries that would be an alternative, but the below uses citation.js to give what I mean (for Q23571040):

with this output:

Is this an interesting next subproject to work on?

All settings that are irrelevant for the current view and all settings that are the default should always be excluded. The links are excessively long and therefore hard to work with at the moment.

The property P580 (start time) is not to be found in the property browser. End time is also missing. Something seems to cause some properties to vanish. The properties correctly appear on property pages, showing that the relevant data is in the json file.

Currently the inputs only provide typeahead suggestions for English labels since they are loaded with the json. Do we want to support typeahead in different languages?

Fetching all the entity labels for a language is on the expensive side but maybe the MediaWiki API wbsearchentities action could be utilized?

I get the error:
SyntaxError: Unexpected token '='. Expected a ')' or a ',' after a parameter declaration. from dist.min.js line 75739.

This line is var searchEntities = function(str, lang='en', limit=7) {.

The error is raised because argument default values are not supported by other browsers than Chrome 49+ and Firefox 15+

The query view issues path queries to navigate the class hierarchy, but forgets to use DISTINCT to eliminate duplicates, which are caused by multiple paths leading to the same thing.

The View view should show links to WIkipedia and other project pages.

Thoughts:

1. Which languages to offer?
   Available UI translation as prominent options, but also all (or most?) languages available in Wikidata for entity labels.
2. Widget position?
   In the navbar at the top right corner. Should be easy to spot but not in the way.
3. Presentation of choices?
   Having each Language name how it is written in that Language (like on Wikidata)

The application should have a global search field in its navigation bar that can be used to find arbitrary entities, or at least arbitrary items. One could use the Wikidata API to get suggestions.

The Browse view allows properties to be filtered by the properties co-occurring in items ("Has Property"). The same should also be possible with classes, since we also have property co-occurrence information for each class. It would be good to add this, since it would allow things like showing all properties used on humans in the property browser.

It seems that the currently selected sorting criterion is not stored in the permanent link.

When running a query directly using the run parameter, the LIMIT is part of the query string. It would be better if this would be controlled by the UI, so that one can also offer to show either some or all results. It could be useful if one could set the initial LIMIT through a URL parameter too, since 10000 may not always be useful/necessary as a default, depending on the query.

When linking to query.wikidata.org as per #55, a reasonable limit should be picked specifically for this UI (maybe 1000, since hte browser tends to get very slow with very many results there). This does not need to depend on the current limit in our query view.

SQID is not currently aware of redirects. For example Q12302864 redirects to Q806798 but the display of SQID does not implement this (the data shown is correct but the id is not).

This also affects proposals in Primary Sources: if a proposed value is a redirect to an existing one it should not be shown. This aspect seems somewhat harder to fix, since we are not retrieving all item information when displaying statements, and it might take too long to do this.

@arsylum @guenthermi Now that we have split the code into smaller files, it would be good to revisit the structure and rethink some of the choices. Things I noticed:

1. The distribution of code across modules app, util, and query is rather arbitrary. Is there any reason to have more than one module in the first place? Do modules define the directory structure or are the two unrelated?
2. The controllers for each view are currently not easy to distinguish from other code. It would maybe be good to adopt some naming convention for the source files of controllers.
3. The file src/js/app/app.js contains code that is specific to the browse view. It seems this should be moved somewhere else.

It would be nice if we could use translatewiki.net to have people update our messages. There should be technical ways of connecting our message files to this infrastructure, but I do not know how to do it. There is some documentation on translatewiki, yet it will need some time to find out how to do the details. Help from contributors is welcome here.

Picking up from #90

Note: we need to rethink the white space at the page bottom. It is there to ensure that there is always a scroll bar (otherwise the layout may jump if one expands something that makes the page longer)

If this is the only reason for the white space then something like overflow-y: scroll on the <body> (or the app-wrapping <div>) is probably a more convenient solution.

We should have one file per module rather than the long JavaScript files with many modules we have now. The files can be compiled and minified for deployment to ensure efficient loading nonetheless. This is a critical blocker for having further people contribute to the code and for moving on with own developments.

(@guenthermi @arsylum tracking here what we discussed in email; let's have related discussions on this thread)

If multiple suggested statements agree on their claim (value and qualifiers), then one suggestions is displayed for each of them. It would be better to collapse the suggestions as done by the Primary Sources Wikidata gadget.

When running queries directly via "further results", the query view currently shows a text box and a button "run query". It would be better to change this as follows:

• The textbox and "run query" button are not shown.
• There is a control to show the query text. But it should not be editable and there should be no "run" button there either, because the query view currently cannot handle arbitrary SPARQL queries.
• There should be a link to open the query in the UI of query.wikidata.org. This is also good enough for editing.
• All of the controls ("show query" and link to query.wikidata.org) should occupy only very little space at the top, to avoid pushing the results down too far.

This should probably say instead that entity is not a subclass of any other class

entity (Q35120)

thing 

something that exists
subclass of: every entity is also a(n) no value
instance of: entity is not an instance of any other class

I just now discovered the convenience of the uib-pagination directive from ui.bootstrap which we depend on anyway. It can be used like this: (see bef1a9e)

<nav><uib-pagination 
    total-items="qui.pagination.numItems"
    items-per-page="qui.pagination.tableSize"
    ng-model="qui.pagination.activePage"
    max-size="qui.pagination.pageSelectorSize"
    previous-text="&laquo;"
    next-text="&raquo;"
    class="pagination-sm"
    boundary-link-numbers="true"
    ng-change="qui.pagination.setPage()"
 ></uib-pagination></nav>

This directive is preferable to the previous markup since it provides more features and is easier to read.

Also once the PaginationController's own pagination model is no longer used, that logic can be removed (which is about half of the code volume of pagination.controller).

The View view should show incoming statements. Ideally, all statement data should be shown, but for a start the items that have an incoming link, together with the property, would be helpful.

To compare and evaluate class hierarchies it helps a lot to get a hierarchical (multi)tree view. The "Classification" section should provide such view on request. I created a command line script with output such as this: each item in the tree should be shown with number of instances and indication when the same item occurs multiple times in the hierarchy. Number of superclasses would also be nice to see multiple inheritance.

There is a piece of code in sqid.module (from former app/app) that apparently is used nowhere:
$("[data-toggle=popover]").popover({html:true});

From what I can tell it's a jquery-ui feature, but since I cannot find markup that would be affected by it I guess it should be deleted.

Note that there also is uib-popover.

currently i18n is only instantiated when a controller depends on it. Eg http://tools.wmflabs.org/sqid/#/?lang=de doesn't have the intended effect, http://tools.wmflabs.org/sqid/#/view?lang=de does. However navigating back and forth from there to http://tools.wmflabs.org/sqid/#/view (or similar, stripping the lang param) swaps the language back to en since ViewController calls View.updateLang() and that's the default when no value is given.

What adds to the confusion is that $translationProvider.preferredLanguage('en') is set, which i18n doesn't really seem to take into account but happens to be the same default value. pascalprecht.translate also provides functionality to derive a fitting lang from browser locale settings, which we might want to use.

It's all a bit confusing for me, probably because there is logic handling the (static) interface language and for dynamically retrieved label data. My proposal is to try leverage language handling into a more powerful position. Possibly a "global setup wrapper" controller or something?

P2428, the author identifier from Research Papers for Economics (RePEc), seems to be missing in the rightbar (Identifiers), nor is it present.

Example: http://tools.wmflabs.org/sqid/#/view?id=Q502557 vs. https://www.wikidata.org/wiki/Q502557

Would be great to have it there - at ZBW, we are discussing if we can contribute the mapping to RePEc, in order to also gain indirect mappings to GND and many other identifers.

The query view should keep it's state in run mode when visited again with the same sparql query.

For example when clicking on an entity from the result table and then going back in browser history. Currently this not only reverts the view to initial state but also unnecessarily re-runs the sparql query.

The run parameter currently only works well with queries that have a single result variable called "entity". For the future, it would be good if more result schemas could be supported. More use cases for this interface include:

• Use case 1: Display entities together with additional results. Main usage: run an aggregate query that shows an additional number for every result (the query itself should then contain the group by and sorting directives needed to get the data, so the query interface would not need to know about this).
• Use case 2: Find and display statements. It would be good if we could find, e.g., statements that use a specific property as a qualifier. Statements appear as own resources in SPARQL, so it is not hard to query for them, but it would need a special display to show them.
• Use case 3: Find and display references. This is similar to the queries for statements. Again, the challenge is in displaying references in a form that makes sense to the user. Maybe this could also be done by showing the statement that uses them using the same approach as for use case 2.

Suggestions for addressing these use cases in the run API:

• One could have another URL parameter that specifies the columns that should be shown and how they should be populated. Some columns could be based on results that are found in the query result; in this case the variable name and "type" should be given. Some columns could be created indirectly, e.g., the current "label" and "description" columns that are fetched via the API.
• There could also be a parameter to specify what the "main entity" variable is called. Right now, it is always "entity" but a shorter name might be nicer for shorter URLs. Columns like "label" and "description" would refer to the entity variable. Columns that are supposed to show additional property values would also be based on the main entity.
• Not all kinds of SPARQL result types would need to be supported. The use cases above only need integers.
• To display statements, one could define a "statement variable" that holds the statement URI just as one has the "entity variable" for the case of entities. Statements are using URIs that contain their Statement-UIDs, which are prefixed by the entity that uses the statement. The URIs of statements have the form "wd:statement/Q60-5cc8fc79-4807-9800-dbea-fe9c20ab273b" or "wd:statement/q60-2fad2c45-4646-1e49-89b0-b8e958ffd7cf" (that is: "Q" and "q" may both occur in statements for Q60). The UID (e.g., "q60-2fad2c45-4646-1e49-89b0-b8e958ffd7cf") also occurs in the Web API JSON data, so one could in principle find it in View. Normally, the only incoming properties of statements should be the properties they use, so it is feasible to put them in the query. Example:

SELECT DISTINCT ?statement ?prop
WHERE {
  ?statement pq:P582 ?qvalue .
  ?entity ?prop ?statement
}
LIMIT 10

However, one may not need to use SPARQL for the property if one uses the API anyway to find all the relevant statement data based on its entity and UID. To display statements to the user, one should ideally show the entity that has the statement and all details about the statement (one could use a compact "value list + pop-over qualifiers" style as used in View for classes). Implementing this will be some work (on demand retrieval of statements, adjustments for display), so it may not be fully functional for a while, but the style of URL parameters etc. should be planned to support this in the future.

• References might be supported along a similar scheme, but there one will need more query variables to find the entity, since reference URIs may not contain the entity name at all.
• Since not all queries have an entity or statement variable, and references may even need multiple variables to decode, it might be better to avoid special parameters for setting the "main entity variable". Maybe one could just have this in the signature of the columns (e.g., cols=label(entity),desc(entity) to encode two columns that show the label and the description of the entity that the variable "entity" refers to; the price of such generality would be that the term fetching code is getting more complicated since there could be different entities in each result line -- maybe a simpler solution would also work). This scheme can also apply to property-displaying columns, e.g. prop(entity,P1234) could indicate a column that shows all P1234 values of the entity in variable "entity".

When I navigate to http://tools.wmflabs.org/sqid/#/view?id=P279 chromium logs two times to the console:

Error: [$parse:syntax] Syntax Error: Token 'documentation' is an unexpected token
at column 6 of the expression [Item documentation] starting at [documentation].

This seems to cause the statements table to break. I have not figured out where this bug originates from or whether views of other entities are affected as well.

Browsers are caching the json data files and they might only be updated on an extra-hard reload (something like "clear cache and reload" in Chrome). We should ensure that a normal hard reload suffices. Ideas:

• Use a cache manifest
• Change the file names on update and the HTML to include the current names.
• Make javascript actively check the statistics file once in a while and trigger an update from there (can we bypass the browser cache from javascript somehow? Some caching on browser level would still be useful, e.g., to avoid having to reload the json in every tab)

Only the QID should be displayed. This affects both browse views.

A related issue is that "null" labelled properties are sorted at the end when sorting by label, no matter which ordering is picked.

Multiple SQID browser tabs with different classes and properties all have same title. The title should be adjusted dynamically to the currently selected class or property.

The View view should also show the references for each statement. The information should be hidden/collapsed by default.

It is sometimes handy to show a big number of results per page (e.g., to use browsers text search for a particular string in descriptions). It would be good if the pager could support this and the query vuew could have controls to select how many results to show per page. A few choices would be enough, maybe: 15 (default, fits most screens), 50 (max. number of labels that can be fetched in one API request), 1000 (if this still works fast enough in browsers, otherwise maybe use 500 or 250 as a max).

This choice would be the same no matter how queries are created (run mode or query builder). The control for this should use only little space.

Angular Translate supports loading messages asynchronously from separate files. This would be much better than having messages inline in one file as it is now. To use this functionality, only the registration/setup code for angular translate needs to be changed, but it may be necessary to use another dependency (the file loading feature may not be part of the library as we use it).

It would be good if SQID would defer API calls and queries that are not necessary to create the initial display until they are really needed. For example, one could fetch references of each incoming statement when the user first opens the statements to see them. There are many other things that one could do when a statement is opened, but which should not be done for all statements upfront.

What is the best way to trigger actions that have to happen when a div first becomes visible? Is there a simple JavaScript/angular solution for getting this event? If would of course be possible to trigger this when we change the visibility of a div, but then the parent div needs to know which child elements would like to do something when becoming visible, creating a lot of overhead. It would be nicer if parts of the page could define such behaviour locally, i.e., if they could add (angular) HTML that makes sure a function gets called on first display.

Only a few classes are used to classify properties in Wikidata. It would be useful to have a dropdown for them rather than an auto completing free text input.

To improve discoverability, SEO, and usability, the item label should be exposed in the HTML title tag, e.g.

http://tools.wmflabs.org/sqid/#/view?id=P1341&lang=en

currently displays:
P1341 - SQID

should be something like:
Italian Chamber of Deputies ID (P1341) - SQID

When you are on the last page of the browse result view and there are less than 15 results left, the message "Entities START - END" will still show the maximum END rather than the real one.

This might be an issue for @arsylum if this is done in the pager component.

If SQID has no lang parameter in URL, then link to Wikidata defaults to 'en'. It would be better if it defaulted to nothing, so the user's choice on Wikidata is maintained.

The current css for inserting the right/down arrows that indicate the collapse state of a panel is not ideal because they also appear on non collapsible panels when there is any link in the header.

Please review pull request #49 which should solve this