FactGrid:Troubleshooting: Difference between revisions

From FactGrid
Jump to navigation Jump to search
Line 57: Line 57:
== Specific problems of our Wikibase Installation ==
== Specific problems of our Wikibase Installation ==
=== "Item:Q123" or direct "Q123"===
=== "Item:Q123" or direct "Q123"===
Unlike Wikidata FactGrid states Items as "Item:" in the headline. 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.
Unlike Wikidata FactGrid states Items as "Item:" in the headline. 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  
 
* https://database.factgrid.de/reasonator/#/Q123 click the link into the database item to see the problem.


=== GND Identifiers do not link ===
=== GND Identifiers do not link ===

Revision as of 07:08, 22 April 2019

Advice: best practice data structures

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.

I am otherwise not 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 sheets of information different retrievals. 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 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.

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).

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).

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?

Scholia

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)

Specific problems of our Wikibase Installation

"Item:Q123" or direct "Q123"

Unlike Wikidata FactGrid states Items as "Item:" in the headline. 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

GND Identifiers do not link

See Item:Q133. Why does the GND number not linkt to the GND as in Wikidata?

We have the same problem with PND book numbers that should refer into to GBV catalogue.

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.

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.

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.

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".<

Wikidata context help when creating an entry not available on FactGrid

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?

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.

Foreign Language Labels

Our database is on English as the default language. Those who feed data into the base are - presently - mostly German. An English label is visible and searchable in German. Can we have the same additionally vice versa: i.e. that a missing English label is automatically substituted by an existing German label?

QueryService related problems

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.

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

QueryService example searches are actually Wikidata searches

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

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...

Weird Results No.2

We are trying to step from "given names" as string Property:P88 to given names as individual items Property:P248. In order to get the names which we have to change we need a search for all P88 names with place in sequence information Property:P101 information. Our searches fail:

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

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.

Requests for search scripts

Organisations that share members

It would be interesting to get an idea of organisations and their vicinity or adversity - also: their potential to succeed each other.

Cumulative personal Timeline

A cumulative timeline that which pieces together all the information we have on a person: Documents by this person per day, letters sent to this person, mentionings, meetings he/she took part in, events he/she witnessed etc.

Specific FactGrid wishes

Important in joint ventures.

FactGrid-Logo.svg

Skin

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

An interface to move the The Gotha Illuminati Research Base into the FactGrid

The The Gotha Illuminati Research Base https://projekte.uni-erfurt.de/illuminaten/Main_Page 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

Data we should like to have

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