From FactGrid
Jump to: navigation, search


Specific problems of our Wikibase Installation

lua not installed

Wikidata has a function that allows quoting items via {{}} template, can we do that as well?

  • We can set a Q123 link (that refers to a non existing page.
  • We can set an Item:Q123 link - and sometimes we get the title on the ink - but not necessarily (works wel after moving a page and ends after saving it again)
  • A {{}} template does not work.
Hast du ein Beispiel auf Wikidata, wo es so funktioniert wie du es haben willst? Dann schau ich es mir an. Das sollte gehen. --User:Lydia Pintscher

Time: Hours and Minutes cannot be stated

We could actually give events (like conference papers) on individual days. The software has the option but it does not work in Wikidata or on our platform.

Die Eingabe von genauen Zeiten ist noch nicht möglich weil das eine Menge Komplexität mit Zeitzonen mit sich bringt. https://phabricator.wikimedia.org/T57755 ist das Ticket dafür. Dem müssen wir uns mal annehmen. --User:Lydia Pintscher

Time: Format

Currently it says on the bottom of that page "This page was last edited on 6 July 2019, at 18:05." and on in the history "18:05, 6 July 2019" - two different formats no statement found what for. Furthermore in the FG blog and other places formats based on ISO 8601 appear. Proposal: standardize on ISO 8601.

Time: Seconds not shown in page history

In the contributions lists seconds are not shown, so one cannot see in which order edits have been made, even worse, a change that is labeled "current" comes before another one on the same page:

18:05, 6 July 2019 (diff | hist) . . (+236)‎ . . FactGrid:Troubleshooting Range ‎ (→‎"Item:Q123" or "Item:123")
17:50, 6 July 2019 (diff | hist) . . (+63)‎ . . Example (Q...) ‎ (‎Added [en] description: human)
17:50, 6 July 2019 (diff | hist) . . (+64)‎ . . Example (Q...) ‎ (‎Added [de] description: Mensch) (current)
17:49, 6 July 2019 (diff | hist) . . (+1)‎ . . Property talk:P163 ‎ (...)

Wikidata context help when creating an entry not available on FactGrid

Property suggester

Wikidata offers complex context help when users want to create items like a biography - questions one would like to answer as well. Can we have the same?

Da weiß ich nicht, was du meinst leider. --User:Lydia Pintscher
Creating a person on Wikidata, screenshot

Ich gebe hier eine Person ein und Wikidata is in der Lage mir die relevanten nächsten Aussagen vorzuschlagen - das ist eigentlich weit besser als ein Formular zu erstellen (wie wir das zuerst vorhatten). Kann man die Vorschläge lenken? Kann man einen Vorschlagpfad generieren? Wenn Du eine Persion hast, dann geht es mit diesen Fragen los. Wenn die schon beantwortet sind, dann gehe mit folgenden weiter... Bei uns jedenfalls erscheint bei Eröffnung einer neuen Aussage kein Vorschlag in irgendeine Richtung. --Olaf Simons (talk) 08:42, 23 May 2019 (CEST)

Commons images not displayed on FactGrid-Item Views

...though we can integrate them in Wiki pages we create - the item-pages won't offer them.

Hast du ein Beispiel das ich mir anschauen kann? --User:Lydia Pintscher
Soll mit dem nächsten Software-Update kommen. --Olaf Simons (talk) 16:14, 17 January 2020 (CET)

Wikidata has map views on geo-coordinates

would be nice to have these too. --Olaf Simons (talk) 09:09, 14 January 2020 (CET)

Soll mit dem nächsten Software-Update kommen. --Olaf Simons (talk) 16:15, 17 January 2020 (CET)


Problems with adding units


error code says it is looking into Wikidata for Q164536. Might be still hard coded.

Open Refine

Seen a demonstration of Open refine and it seems it needs an integration on our wikibase installation before one can use the program to prepare data. Another task for someone with a clearer idea of the installation. --Olaf Simons (talk) 11:07, 26 October 2019 (CEST)

--The reconciliation service of Open refine works with FactGrid. You must install the extension RDF of Open refine ([1]) in your computer and add a SPARQL-reconciliation service for FactGrid (follow the instructions). It is very useful, but unfortunately rather slow, I don't know why. -- Bruno Belhoste (talk) 12:41, 8 May 2020 (CEST)

QueryService related problems

SPARQL Script Requests

QueryService gives January 1 as default answer for full year dates

If we give a full year (e.g. on "date of birth") the Query Service will state January 1 as the date instead of leaving the day and month unspecified.

Das Ticket dazu ist https://phabricator.wikimedia.org/T159160. Ich weiß leider gerade nicht was da der letzte Diskussionsstand ist. --User:Lydia Pintscher
Date precision still does'nt work on FactGrid QueryService and it's a pity. It's seems to work on Wikidata Queryservice (through time nodes which don't seem to exist in FactGrid). --Bruno Belhoste (talk) 17:08, 2 May 2020 (CEST)

QueryService gives output with wd:Q123 numbers

though the links do actually go into the FactGrid resource. This problem occurs on all levels: our Q-numbers are displayed in SPARQL searches as wd numbers. Tiny-urls open when activated with a Wikidata welcome page before we get the FactGrid results: http://tinyurl.com/y8zwjosq

Der erste Teil ist glaube ich https://phabricator.wikimedia.org/T194180. Ich habe ein Ticket für den zweiten Teil aufgemacht: https://phabricator.wikimedia.org/T223582. --User:Lydia Pintscher

QueryService example searches are actually Wikidata searches

...and do not help you on our database.

Das ist seit kurzem konfigurierbar. https://phabricator.wikimedia.org/T223586 habe ich aufgemacht um das für Factgrid zu konfigurieren. --User:Lydia Pintscher

Tools/features one would like to have

Our Reasonator as Standard Interface

We would like to offer our Reasonator-Installation as standard interface for people who are just looking for information. So far it does not really seem to work...

One of the problems is that our instance looks for Item:Q969 instead of Q969

Das genannte Problem können wir hoffentlich mit dem Ticket von 2.1. lösen. --User:Lydia Pintscher

A tool to grab and import (selected) Wikidata information

If we have data on a FactGrid Item on Wikidate - could on think of a tool that can be used to grab these data as a set and to convert selected statements into FactGrid statements?

A multilingual interface to just offer information

The ideal development would be an additional tab on all wikibase-items. If you search for "Johann Sebastian Bach" you get a person's page that extracts information from the J.S. Bach data set and through additional searches. Bach's works will be listed on request - not from the information the specific Q-item is providing but from a database search: list all items with Bach as composer. List all documents with J.S. Bach as author. List all documents with J.S. Bach as receiver... Users get these lists only on request. The J.S. Bach display tells us that we can run this search and feed the information under the present header.

An option to feed information into historical maps

One would love to offer links to Gotha addresses of different centuries and decades and one would have to use different maps for this purpose. Gotha today has housing areas for about 50.000 inhabitants. Gotha in 1800 ended basically with the city walls that were just torn down. We do not yet have the expertise to present visual information on maps other than the default Open Street Map interface.

A recipe how to create Info-Boxes based on FactGrid Information

We need these Boxes for pages like this one (imported from our old Wiki): Q6611. The header information on author, title, source etc., is here handwritten so far. The cool solution will be a standard table with central metadata from the respective data set (of the same Q-number), so that changes of information will only be done in the database and spread from there to pages.

Das sollte jemand gut machen können der sich mit MediaWiki Templateprogrammierung und Wikidata auskennt. --User:Lydia Pintscher

Specific FactGrid wishes

Important in joint ventures.



Important gain a more independent position in the eyes of university, library and archive people.

We would need someone with Skin expertise...

An interface for the The Gotha Illuminati Research Base into the FactGrid

The The Gotha Illuminati Research Base was/is a conventional media wiki and we should win a superior functionality here on the FactGrid.

A clearer idea of how we would like to be quoted

FactGrid datasets have specific research statements - but how do we want them to be referred to in footnotes? See Item:Q11305

Website security

https://observatory.mozilla.org/analyze/database.factgrid.de : "D-", CSP, HSTS, XFO, XSS missing.

Data we should like to have

  • Matrikel of German universities
  • Logis-Verzeichnisse Göttinger Studenten (halbjährlich)

Advice: best practice data structures

Changing entities and cuts through time

The Publishing House of Moritz Georg Weidmann becomes eventually the Olms Verlag - if we treat this as one company - how do we create different references for different times? Books have different imprints decade after decade with changing owners who give the company names. Our system must be able to make sense of practically any imprint - and it should at the same moment understand how the changing imprint information is actually connected to one and the same company. Munich does not have 57 companies from 1500 to 1850 but six under changing names in this genealogy Münchner Buchhandel 1500–1850 - and this is an image we want to give on a clear sighted SPARQL-search.

  • Should we create different items under each name and state how these items are related?
  • Should we create one idem and state the changing names with begin/end information (sound better because a lot of information like the location might be stable)?

The same problem occurs with addresses. A city quarter can be torn down, the new quarter gets old street names - but are these still the same addresses? (They might have new geographic coordinates).

Daran scheiden sich die Geister... Das ist ein klassisches Ontologieproblem. Man kann es so oder so machen. Denny könnte eine gute Person sein das mal für deinen genauen Fall durchzudiskutieren und zu schauen ob eins mehr Sinn macht. --User:Lydia Pintscher

What should we do with our 1500 transcripts of documents?

We have started to put the transcript of Item:Q22976 on D-Q22976. Was that a good idea? (we want the transcript to appear in full text search), yet we would rather have it on one page with all the meta data.

Could the reasonator (as a standard unser interface) grab transpripts from such wiki pages?

Could we use the Wikisource extension to offer scans side by side?

Ich kenne mich leider mit Wikisource nicht aus. Tpt (thomas@pellissier-tanon.fr) hat davon und von Wikidata sehr viel Ahnung und kann wahrscheinlich am sinnvollsten was sagen. --User:Lydia Pintscher
Ich würde die Handschriften erst einmal erfassen, zB bei Kalliope. Kalliope wird der

Staatsbibliothek zu Berlin betrieben, also einer "Schwester" des Geheimen Staatsarchivs. Und dort müsste ja ein großes Interesse daran bestehen, das blattweise zu normieren. Deutsche Wikidata wird wegen des hohen dortigen Korrekturstandards nicht gehen, aber eine Factgridsource, warum nicht? Während die deutsche WS auch nur in Ausnahmefällen WS-Anmerkungen in Texten zulässt, könnte man hier ja liberalere Herangehensweisen im Vorfeld diskutieren.--Martin Gollasch (talk) 18:17, 19 January 2020 (CET)


Daniel Mietchen hinted at Scholia https://tools.wmflabs.org/scholia/ and how that could change many of our problems. We could here use a software solution that embeds SPARQL queries. It could also embed the transcripts of texts which we have to present. We would basically decide how many sorts of database objects we have and compose templates of the searches they are supposed to embed. Question remains: who would compose this for us. (On the design front: it is not as cohesive as Magnus Manske's Reasonator.) --Olaf Simons (talk) 16:34, 27 November 2018 (CET)

Sowas sollte jeder vernünftige php coder hinbekommen. --User:Lydia Pintscher