wikidata / sqid Goto Github PK
View Code? Open in Web Editor NEWA tool to analyse, browse and query Wikidata
Home Page: http://tools.wmflabs.org/sqid/
License: Apache License 2.0
A tool to analyse, browse and query Wikidata
Home Page: http://tools.wmflabs.org/sqid/
License: Apache License 2.0
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
.
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.
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.
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
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.
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.
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.
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="«"
next-text="»"
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 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.
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.
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.
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.
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?
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.
Thoughts:
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:
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)
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:
Suggestions for addressing these use cases in the run API:
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.
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".@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:
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.
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.
The View view should also show the references for each statement. The information should be hidden/collapsed by default.
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.
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 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.
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.
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.
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:
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).
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.
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:
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.
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.
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.
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
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).
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.
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?
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.
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.
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 View view should show links to WIkipedia and other project pages.
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?
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.
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+
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 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.
It seems that the currently selected sorting criterion is not stored in the permanent link.
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.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.