FactGrid:Troubleshooting: Difference between revisions

From FactGrid
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
=== Repeated information ===
=== Repeated information - avoid it or go for it? ===
We have some 7000 documents in the database. Each document has a author - 375 documents are thus written by Johann Joachim Christoph Bode [[Item:Q133]]
We have some 7000 documents in the database. Each document has an author, most documents have recipients and most documents mention other persons.


* 375 documents are written by Johann Joachim Christoph Bode [https://database.factgrid.de/query/#SELECT%20%3FDokument%20%3FDokumentLabel%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20%3FDokument%20wdt%3AP2%20wd%3AQ10671.%0A%20%20%3FDokument%20wdt%3AP21%20wd%3AQ133.%0A%7D search].
*  1123 documents have Bode as first recipient [https://database.factgrid.de/query/#SELECT%20%3FDokument%20%3FDokumentLabel%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20%3FDokument%20wdt%3AP2%20wd%3AQ10671.%0A%20%20%3FDokument%20wdt%3AP28%20wd%3AQ133.%0A%7D search]
* 108 documents refer to Bode as third person [https://database.factgrid.de/query/#SELECT%20%3FDokument%20%3FDokumentLabel%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20%3FDokument%20wdt%3AP2%20wd%3AQ10671.%0A%20%20%3FDokument%20wdt%3AP33%20wd%3AQ133.%0A%7D search]


=== Membership information ===
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 would like to offer the greatest variety of contact information.
I am otherwise not to eager to begin this because this was the reason why we left the Wiki and went for the database: The ideal situation is that we have every fact only once in the database. A data sheet on Bode should fill the "Bode as Author" section with a look into the database. Once we start creating lists we have to make sure that they are all constantly up to date and well organised - and a Bode data sheet with a list of 1123 documents he received will no longer be funny.  


* We are presently presenting some 9.000 documents with information about senders and the respective receivers
The ideal situation is a split of functions: A Bode page is created in data base retrievals. You geht the list as soon as you click at "more" freshly made from the data base. (There is a tendency to use Wikibase much like a Wikipedia page: have everything on Bode on "his page" and understand that the dataset [[Item:Q133]] is all we know about Bode...)
* We are listing some 300 events with information about participants
* We could add specific contact information in the form of "A meets B" statements - we could just as well create items for any known meeting.


How do we organise such information in a way that database queries can offer us contact information with the greatest ease? How do we avoid recursive statements ("Person A meets Person B" - do we have to repeat the statement as "Person B meets Person A", and if so, how do we ensure the congruence)?
=== Membership information ===


The same problem is created by membership: we have 1350 Illuminati. Ist to be an Illuminati a personal thing? Is it a thing on the account of the Order - or shall we create 1350 new items for each membership and refer to these - under what P-function?
The same problem is created by membership: we have 1350 Illuminati. Ist to be an Illuminati a personal thing? Is it a thing on the account of the Order - or shall we create 1350 new items for each membership and refer to these - under what P-function?


== Changing names in business succession? Use the redirect? Create different items? ==
=== Changing entities and cuts through time ===


See [https://de.wikipedia.org/wiki/M%C3%BCnchner_Buchhandel_1500%E2%80%931850 Münchner Buchhandel 1500–1850] at Wikipedia for the problem.
See [https://de.wikipedia.org/wiki/M%C3%BCnchner_Buchhandel_1500%E2%80%931850 Münchner Buchhandel 1500–1850] at Wikipedia for the problem.
Line 25: Line 26:
* Should we use the Wikipedia redirect function (via merge items) to create various items that are all leading the the once central item?
* Should we use the Wikipedia redirect function (via merge items) to create various items that are all leading the the once central item?
* should we create different items for each imprint and state how these items are interconnected? (if so: how do we make sure that people using the QueryService know our complex data structures?
* should we create different items for each imprint and state how these items are interconnected? (if so: how do we make sure that people using the QueryService know our complex data structures?
== How should we organise items that are not yet fully consolidated? ==
We will face a particular need to organise unconsolidated personal information and a fuzzy search for them: Documents do often just state last names. We have a place, a year, perhaps an occupation but no further information. We will need a system that gives us hints of potential matches.
* Was it good to state names as strings?
* Would it be more clever to create n item for each family name and to organise variants around the item (in order to understand how families belong together)?


=== Recipients 1, 2, 3 - a good idea? ===
=== Recipients 1, 2, 3 - a good idea? ===
Line 43: Line 38:
::It all boils down to the question of best search results and optimal linking. One would love to see the bundling of information on higher levels of personal power. Search results again are a question of expectations: User have to get the information even if they do not know more about the availability. (That's why recipient 1-2-3 was probably bad - you do not know that these exist...)
::It all boils down to the question of best search results and optimal linking. One would love to see the bundling of information on higher levels of personal power. Search results again are a question of expectations: User have to get the information even if they do not know more about the availability. (That's why recipient 1-2-3 was probably bad - you do not know that these exist...)


==GND Identifyer ==
== Specific problems of our Wikibase Installation ===
 
=== GND Identifiers do not link ===


Why does it not work like a link as in Wikidata? Why can't we click at the number and access the dataset on the GND database?
Why does it not work like a link as in Wikidata? Why can't we click at the number and access the dataset on the GND database?


==Query Service and full years ==
=== Query Service and full years ===
If we enter full years with the appropriate distinction 1761-00-00etc. - why do we still get a January 1 date?
If we enter full years with the appropriate distinction 1761-00-00etc. - why do we still get a January 1 date?


== [[Item:Q22976]] or just [[Q22976]] ==
== [[Item:Q22976]] or just [[Q22976]] ==
FactGrid Items have an Item: prefix.
Question 1: Wikidata has a function that allows quoting items - via template, can we do that as well?
Question 2: We are in need of a good place to offer scans.Would it [[Q22976]] be a good match to [[Item:Q22976]] or could there be a better place for transcripts (and possibly for image files)?
== tiffs and pdfs not supported ==
That must be in local settings php...
== How would we organise contemorary sets? ==

Revision as of 10:20, 20 November 2018

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.

  • 375 documents are written by Johann Joachim Christoph Bode search.
  • 1123 documents have Bode as first recipient search
  • 108 documents refer to Bode as third person search

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: The ideal situation is that we have every fact only once in the database. A data sheet on Bode should fill the "Bode as Author" section with a look into the database. Once we start creating lists we have to make sure that they are all constantly up to date and well organised - and a Bode data sheet with a list of 1123 documents he received will no longer be funny.

The ideal situation is a split of functions: A Bode page is created in data base retrievals. You geht the list as soon as you click at "more" freshly made from the data base. (There is a tendency to use Wikibase much like a Wikipedia page: have everything on Bode on "his page" and understand that the dataset Item:Q133 is all we know about Bode...)

Membership information

The same problem is created by membership: we have 1350 Illuminati. Ist to be an Illuminati a personal thing? Is it a thing on the account of the Order - or shall we create 1350 new items for each membership and refer to these - under what P-function?

Changing entities and cuts through time

See Münchner Buchhandel 1500–1850 at Wikipedia for the problem.

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 - especially with the early modern practice to use the publishers' personal names in the imprints. Our system must be able to make sense of practically any imprint we find - and it should at the same moment understand how the changing imprint information is actually connected to existing companies. Munich does not have 57 companies from 1500 to 1850 but six and these are interconnected through family ties.

  • How do we give the proper picture in time segments?
  • How do we best organise data on an item that goes from 1500 to the present?
  • Should we use the Wikipedia redirect function (via merge items) to create various items that are all leading the the once central item?
  • should we create different items for each imprint and state how these items are interconnected? (if so: how do we make sure that people using the QueryService know our complex data structures?

Recipients 1, 2, 3 - a good idea?

Regular communication from members into the Illuminati Order was a complex thing. Members met one a month in their local Minerval Church and handed in their monthly Quibus Licet ("to whom it may concern"), letters into the Order. The "local superior" would be the first reader. He would pass the letter to the Provincial leader who would answer as Basilus, the "Unknown Superior". The local superior of Gotha would be Christian Georg Helmolt (the first recipient), he would send the package of Gotha's "QQLL" (the abbreviation for the plural) to Johann Joachim Christoph Bode in Weimar (recipient 2) who could in turn pass the letters to Gotha's duke Ernest II. (recipient 3 in this case).

In order to link the respective places to which the letters were sent to the recipients I created different recipients which could now be spotted in different places.

One could organise this differently. User:Daniel Mietchen proposed to create an item for each transportation process. Would this be clever? How should we organise things with the aim to facilitate searches? --Olaf Simons (talk) 21:42, 6 August 2018 (CEST)

Alternative again proposed by User:Daniel Mietchen: take a look at Wikidata's P1545, series qualifier.
It all boils down to the question of best search results and optimal linking. One would love to see the bundling of information on higher levels of personal power. Search results again are a question of expectations: User have to get the information even if they do not know more about the availability. (That's why recipient 1-2-3 was probably bad - you do not know that these exist...)

Specific problems of our Wikibase Installation =

GND Identifiers do not link

Why does it not work like a link as in Wikidata? Why can't we click at the number and access the dataset on the GND database?

Query Service and full years

If we enter full years with the appropriate distinction 1761-00-00etc. - why do we still get a January 1 date?

Item:Q22976 or just Q22976