FactGrid:Troubleshooting/archive

From FactGrid
Jump to navigation Jump to search

Repeated information - avoid it or go for it?

We have some 7000 documents in the database. Each document has an author, most documents have recipients and most documents mention other persons.

Organising Bode's data set Item:Q133: Should we list all these documents in three sections? It might be interesting to do this because this is the point at which we show that we have far more information on the man than any other database.

We should otherwise not be to eager to begin this because this was the reason why we left the Wiki and went for the database: We do not want to constantly mirror information in various data sets. We do not want the user to keep in mind on which pages a certain fact has to be mirrored.

The ideal situation is that we have every fact only once in the database - and that we fill pages of information with asking the database to tell us. A data sheet on Bode should have a section "Bode as author" and a section with "Bode mentioned" and a section with "Bode as receiver". The visitor gets the full list of documents on each request. (I was tempted to offer a SPARQL link for ach question...)

One could think of the Reasonator (or an equivalent) asking the right questions. (Documents would in this case be our primary source material to explore by the database when asked about a person or an event).

In diesem Fall würde ich die Information nicht duplizieren. Das wird zu viel und nicht gut wartbar. Eine elegante Lösung könnte ein Gadget sein das die Ergebnisse einer Abfrage in die Item-Seite integriert wenn ihr das da zeigen wollt. Das müsste jemand coden. Es gibt ein Gadget auf Wikidata das in die Richtung geht. Du kannst es in deinen Einstellungen anstellen. Es heißt Easy Query. Wenn es angestellt ist bekommst du so 3 graue Punkte in Statements. Wenn du da drauf klickst geht ein kleines Queryergebnis auf.

Membership information: How should we organise this?- create special Q-items? create more and more P-Numbers?

We have about 1350 with an Illuminati background. A simple membership list would be stupid. We know of some 1350 people that they were proposed. Some 1200 signed a declaration of loyalty. Some climbed into higher ranks.

One way to organise this is by creating a Q-Item for "regular events" - that is for events many people can go through - like signing the declaration:

The grammar is Q [Person] P91 (Affilliations) Q38780 (signed a Revers for the Illuminati)

This is the option to put the load on a singe P and to create masses of Qs for this P but one could just as well create a regular triple with Q (Person) P (signed a Revers for) Q10677 (Order of the Illuminati) - which would open the door to millions of P-statements.

Both options can be substantiated with the same qualifiers.

Which is the better system to organise and to search with SPARQL? (Our present solution has the beauty of keeping all kinds of membership information in one block. We can do the same with jobs and family relationships - and depart from Wikidata).

Ich verstehe die Daten noch nicht ganz. Kannst du mir 3 Beispiele mit allen Daten geben die das Statement deiner Meinung nach haben sollte? --User:Lydia Pintscher

"Item:Q123" or direct "Q123"

Unlike Wikidata FactGrid states Items as "Item:" in the URL. This might be the cause of incompatibilities as we see them in our Reasonator interface. (Reasonator apparently expects the Q123 link where we have the "Item"-link

Dafür habe ich dir ein Ticket aufgemacht: https://phabricator.wikimedia.org/T223548 --User:Lydia Pintscher

In the headline of item pages that Item ID is shown, but not the name space, e.g. "human (Q7)". In the project name space the name space is shown "FactGrid:Troubleshooting Range", in the main name space and special name space it is not.

Das ist ein Wikibase default und man muss eine Version des Reasonator darauf adaptieren. --Olaf Simons (talk)

"Item:Q123" or "Item:123"

The "Q" is present in every item ID and therefore does not contain extra information. It should probably be removed. Also, it would be easier for international use to only have numbers in the item ID.

Description 250 character limit

Many imports failed since they had descriptions of more than 250 signs. Daniel Mietchen said we can modify the character limits on our own Wikibase instance - would be good to allow perhaps 500-1000 characters.

Die Descriptions sind vor allem zur Disambiguierung gedacht zum Beispiel im Suchfeld rechts oben oder wenn du ein anderes Item in einem Statement verlinkst um sicherzustellen dass du den richtigen Fritz Müller auswählst wenn es 10 davon gibt. Deshalb sind die sehr kurz gehalten und die Beschränkung ist von unserer Seite aus gewollt bisher. Kannst du etwas genauer erklären was du machen willst mit den Descriptions und was da rein soll? Vielleicht ist es besser als ein Statement aufgehoben aber das kann ich noch nicht sagen.
Soweit ich weiß ist das im Moment nicht konfigurierbar. --User:Lydia Pintscher
Wurde von Lucas auf 1500 erhöht.

pdf and other uploads

that should be a switch in the LocalSettings but might also be a database issue to be resolved in Erfurt:

Uploads fail with this note >Could not open lock file for "mwstore://local-backend/local-public/6/65/test.jpg".<

Bin nicht sicher was da das Problem ist. Da kannst du Lucas glaube ich kurz ansprechen und ihn fragen ob das was ist was im Rechenzentrum gemacht werden muss oder in den Einstellungen. --User:Lydia Pintscher
The problem ist treated here yet I do not get the solution. --Olaf Simons (talk) 19:40, 10 September 2019 (CEST)
Wurde von Lucas auf Installationsebene gelöst

German default switch to English

would be better to have that in English.

hängt vom Browser ab. --Olaf Simons (talk) 16:17, 17 January 2020 (CET)

Weird Results No.1

The following search should show us where Gotha's bakers were living

works fine with the master bakers but here the same on merchants with a totally messy result...

Ich habe keine Ahnung. Lucas könnte helfen. --User:Lydia Pintscher
Needs to be: second OPTIONAL nested --Lucas Werkmeister (talk) 12:54, 17 January 2020 (CET)