User talk:Bruno Belhoste

From FactGrid
Jump to navigation Jump to search

Batch Fragment

Dear Bruno. The following batch fragment might give you an idea ho the input is done to produce just a person. # has to be replaced by the name as it shall appear in headlines, $ has to be replaced by a short bio in French and English. That will be the tough thing. When I have longer lists I just machine generate these bios with birth and death dates, the places.


In the case of your next candidate that would be:

,"Philippe Jacques René de Berstett","Philippe Jacques René de Berstett","*1er octobre 1744 Berstett, +31 mars 1814 Offenburg,  lieutenant au régiment de Nassau-Saarbrück en 1768, dernier Stettmeister de Strasbourg en 1789, président de la noblesse de l'Ortenau jusqu'en 1806","1 October 1744 Berstett, +31 March 1814 Offenburg, lieutenant in the Nassau-Saarbrück regiment in 1768, last Stettmeister of Strasbourg in 1789, president of the nobility of Ortenau until 1806","Philipp Jakob Reinhard von Berstett",Q7,Q18,Q99677

You can just copy this fragment and put it into QuickStatements where you activate the CSV-input. Just a test and inspiration. --Olaf Simons (talk) 13:10, 29 November 2019 (CET)

First mass input

Dear Bruno - yes, the preparation of the input is the ugly part. My recommendation: Do not spend too much time on the Descriptions (Den, Dfr). If you have just dates and a place, that will be fine. You can overwrite these entries at a later time with information from the database.

The same goes for the names. Hard core name information comes with the P247, P248 entries. The headers (above) are only interesting to get the Q-Numbers for the correlation with your database numbers.

Once you know which number on your database is which Q-Number here you can do all the inputs step by step.

The following two searches give you all the given names and all the family names that are on the database right know:

I know how to use Excel to replace existing names with the respective Q-numbers if that helps - but there are other programs that do the same thing. Step 2 is then to create the new names (will be quite some with the first bigger French input). I can create these names for you, it is easy. Things get easier with every item the systems is taught to use. --Olaf Simons (talk) 17:12, 30 November 2019 (CET) (signatures with dates and links are, by the way, left on these pages such as this one with four ~~~~)

After the first input

I have started uploading data about persons. It works well but I have some questions about what I have to insert.

1. about Alias. How can I insert 'Alias' in the system? In fact I think of two kinds of alias: the first one is alias or nicknames like : "duc de Lauzun" for "Armand Louis de Gontaut Biron"; the second one is the name of the person in a different order like : "Gontaut-Biron (de), Armand Louis" for "Armand Louis de Gontaut Biron". Does it comply with the general principles of Factgrid? It seems to me that it would be most convenient for searching a name.

2. At a more general level, I am wondering whether it is better to put in Factgrid all the persons of Harmonia Universalis (about 5000), or only the people who are directly concerned by the mesmerist mouvement (about 800). I have few information about the other people, who are mainly relatives, but they are important for making the network (I discovered many family connections). If I have the choice, I would put all the persons, but I must be consistent with FactGrid rules.

I have another question about the properties: I noticed that some properties are duplicated in Wikidata and in FactGrid, for instance Date of birth, which is P77 (FactGrid) et P569 (Wikidata)? And what is the meaning of Q80513? I don't understand how I should combine P77 and Q80513.

All the best, Bruno Belhoste

This is looking very good. As to the Alias: use them as you find practical. I use them for name variants, also to give the long version while I use the short version (There are a lot of people who are not known by their five given namens). But we have not started to set second names in the beginning.
The second names will be given as statements and then you can do this practical search for all persons of the same family name
Speaking of "unimportant people" - there are no such things. Give them all and you will see that others can suddenly identify them, so my experience since I am on this project. Stuff that is unimportant is simply not used by others until they make it important by using it. I love the margins of knowledge (and think so do all the others on this site).
The reference of parallel Wikidata-Numbers is for the future. We are working on the "federation on Wikibase-Instances" in which it will be easy to quote from other instances (like Wikidata or the GND or the BNF). That requires that we know the vocabularies of these instances. Wikidata has the most extended vocabulary so far (yet not so fine on historical documents). The DNB/GND is experimenting with their own first Wikibase installation. I will see them tomorrow. The BNF will decide this month. The software is presently interesting to many people and that is why we are trying to understand the languages of the first installations. --Olaf Simons (talk) 16:07, 2 December 2019 (CET)
Aliasses are set with Afr, Aen, Ade. If you have more than one separate them with |. You can also set them later. --Olaf Simons (talk) 22:24, 2 December 2019 (CET)

N.N. for people without given names

Dear Bruno. Just a brief note. It might be good to prefix N.N. on people without given names, so that we do not mix them with family name items such as Item:Q27646 --Olaf Simons (talk) 20:19, 2 December 2019 (CET)

Side remark for Martin Gollasch - we can set German labels and descriptions later in a machine run. --Olaf Simons (talk) 21:27, 2 December 2019 (CET)
Added now German labels to all since I saw, that you, Martin, were offering translations of the descriptions. They will be better than any of my machine made translations. --Olaf Simons (talk) 22:07, 2 December 2019 (CET)
Those were only spot checks, I wanted to get an idea of the "cross border meta data" situation...--Martin Gollasch (talk) 09:53, 3 December 2019 (CET)

100,000 - congratulations, by the way.

I do not now how we celebrate these barriers on FactGrid. Ideas are welcome! --Olaf Simons (talk) 22:10, 2 December 2019 (CET)

double entries

French places

Dear Bruno. This search gives you all places that are in the machine right now - on map. Delete "#defaultView:Map" on top of the input frame and you will have them in a list. I guess you will need far more that those. --Olaf Simons (talk) 14:28, 8 December 2019 (CET)

and you do not have to give coordinates on persons. Just give coordinates to places and the search-input can be written in a way, that the coordinates come with the places. --Olaf Simons (talk) 14:35, 8 December 2019 (CET)

Media-upload and 250 character limit

Dear Bruno. I had a session in Berlin with the software people from Wikimedia and two things might be of immediate interest for you: Properties with a string input as well as descriptions in the header are now open to input of up to 1500 characters (which is nice for title page transcripts).

You can now also upload media files - documents, contemporary engravings. The present wikibase version might not display them on the data sets but that will come with the next version update. --Olaf Simons (talk) 16:07, 17 January 2020 (CET)


What is specifically German in the career of "Arzt"? Would'nt it be better to define "Arzt" as a profession, equivalent to "physician" in English and "médecin" in French?

Nothing, I confess I am somewhat insecure what to do with the career statements and professions. The colleague who is the expert here is Katrin Moeller in Halle, also a DH specialist. She has a full nomenclature which would work in all languages - and she collected contemporary terms to mark historical changes. I should contact her again. You are free to set foreign labels to all the professions. --Olaf Simons (talk) 14:44, 27 January 2020 (CET)

Q36783 ("painter") is both an instance of "profession" and an instance of "carreer statement". As an instance of "profession", it is also a class in the classification of professions (a subclass of "artistic profession")(and the class "painter" has also subclasses, like "painter miniaturist"). The statement date: "1848" makes sense for "painter as a "carreer statement" but certainly not for "painter" as a class in the professions. To avoid this problem, I propose to put the statement date: "1848" as a qualifier of "painter" as an instance of "carreer statement" (or to delete it).--Bruno Belhoste (talk) 15:48, 29 January 2020 (CET)

You are right with this. The story behind it is trivial. I started with "Jobs" hoping for the systematic approach and realised I don't have the time to get it done in a way a historian of that field will appreciate. So I just added the bigger word "career statement" to catch almost everything that needs to be dealt with later. If you want to get into the systematic solution, feel free. (Really, we need specialists of different fields working together. Social historians who publish on such questions should work on a solution which other projects could use, because this is really a wide problem for many platforms dealing with posopographical data. It was not such a problem in the days in which we were just writing articles in one language...) --Olaf Simons (talk) 10:41, 11 March 2020 (CET)

Machine translations

Dear Bruno, I put this here: Grossrat should, of course be be Grand councillor or better even member of the Grand council. All the translations of Jobs are machine work. I pushed it into so that we had less of a problem with them in English and German. They all came from three automatic inputs from German 19th century lists. Before the input I aiming at a professional solution by the expert I knew who has spent part of her life on a system to track professions through the early modern period. Still, I hope she will join the project, although the next conference where we would meet is just about being cancelled because of Corona... Still I am confident we can win her.

So if you do find these mistakes just silently mend them, that is what I am doing whenever I see them.

The brightest thing would probably be a real project on these statements using contemporary dictionaries and adding definitions with the property for that. All this is a project for people in this field, since they can win prestige with work devoted to the system of job-nomenclatures and how they changed on the European map. --Olaf Simons (talk) 10:41, 11 March 2020 (CET) --ok, it makes sense Bruno Belhoste (talk) 11:05, 11 March 2020 (CET)

classes and so on

Dear Bruno,

I have just looked into a presumably simple thing (simple for us who have such titles): academic degrees and permissions to teach. But first a word about the class thing.

Your idea to have a P420 referring downwards and a P421 referring upwards in the class hierarchy - left me with the feeling that you will then need a P422 to actually make a specific class statement.

So we could say (Q22224) professor is (P2) a general career statement (Q37073O).

That is nice because you eventually have a broad basin of career statements in which you will be able to follow trends.

We might now use P422 "class" to state that professor is in the class of "academic titles". Now see the spreadsheet. I moved all these titles to the top to get a clearer idea about what to do with P420 and P421.

The "professor of mathematics" - is more precisely an "academic titel and teaching qualification" (well the simple professor also has a teaching qualification, it is just not stated... so change Q37073O to "academic titel and teaching qualification". You could use your classes to organise these people by faculties (in a world of changing faculties... ugly job but possible).

We have some 89 of these (including composite teaching permissions) (we could split those but would loose historical trends of unions). Do you really want to list some 500 which me might get with a P420 option? I would rather use the P309 property to generate a list of content for a class. The look upwards (P421) is more interesting. Level up you state in which field(s) you are with a specific class (and you can still let the machine do the level down search whenever you want the list.

To entertain you a bit with the mess: we have the "professor of mathematics" - that is a title, a permission to teach and it is probably what the man actually did, his job for a time, a career statement.

What was his university degree? A "habilitation" in Germany. Do we want to state that or is it self evident? Let us say it is self evident in order to have a better life. What is the proper P-Number to state "Professor of mathematics" in a person's data set. Just job? My proposal was employment - employed at to be precise.Here I listed the universities and with qualifiers the positions and added dates for employments). But I also had machine run inputs from lists where I just brought the "career statements" into FactGrid with a P165 statement. This was nice for widows, retired people and so on. I just threw in what they had declared where they were put on a list of registered people. And what if you do not know more? You do not need a university to be a professor by rank, once you have taken the step.

So to sum it up:

  • I could live with the binary system of class (P420 [now P422]) and next higher level (P421) because I was ready to use specified database searches for the list of "in this category".
  • a good system might be tested with the 89 academic titles items which we have - one can shift and group them quickly, inputs are easy.
  • the practical use will depend on test cases of people. My decision to list employments and to qualify positions in the employments is good CV practice but not the thing we can always do with the little data we have on persons.
  • I am happy to learn from the lives which you will create and the class systems which you will produce. I avoided classifications (as you realised). --Olaf Simons (talk) 11:58, 29 January 2020 (CET)

Thank you, dear Olaf, for your help. I had a look on the page and I understand now better what the concept of class means in this context. First of all, the concepts of set and group don't exist there. There are only two basic concepts: item and class. An item can be put in a given class by using P2 ("instance of"). The same item can also be a class by using P421 ("subclass of"). That's all. As you explained to me, P420 is useless and can be deleted. Moreover, P422 ("class") is useless too, because it is redundant with P421. In a classification, we need only to define the upper class as an instance of "basic object" (Q22) by using P2. All the other classes in the classification are defined as subclasses of this upper class, directly or indirectly by a chain of "subclass of". Let me take the case of the "FactGrid properties". "FactGrid properties" is an instance of "basic object" and "FactGrid properties for material objects" is an instance of "class of FactGrid properties", which is also an instance of "basic object". That is absolutely correct. However, "FactGrid properties for material objects" is also a subclass of "FactGrid properties". In this case, such a statement is not very useful per se, because there are no sub-subclasses in the classification of "FactGrid properties", but, on the other hand, if you use it, you avoid to create the new item "class of Factgrid properties" and it is probably a better practice. Let me take now the case of (Q22224) professor. It is (P2) a general career statement (Q37073O) but it is also a subclass of (P421) the class "academic titles" and because it is a subclass, it is itself a class (it is the reason why it is not necessary to define Q22224 as a class by using P422 ("class")). I agree completely with your distinction between "job" and "employed at".Bruno Belhoste (talk) 13:50, 29 January 2020 (CET)

Wikidata does not have to be our hero. The interesting thing about Wikibase its that it is completely triple based. So there is no need to think like you would in a relational database. You can make statements as soon as you feel they could help to give an object its shape and size and smell and relationships or whenever you get the data.
What is good about all this is that you can generate classification systems later - the statements are not on a new structural level. So no reason to worry. (Same goes for the jobs: If someone has a system to organise this - my hopes lie on Katrin Moeller - we will just import the system as a class system and map items.) --Olaf Simons (talk) 14:13, 29 January 2020 (CET)
The bottom-up approach is a huge asset of the system, but it's good also to avoid the mess. The concept of class is basic and powerful (for queries) and I still think we'd better follow the rules given by Wikibase, but you know that better than me!--Bruno Belhoste (talk) 14:50, 29 January 2020 (CET)

different languages

The problem is that we do not appear together in the same searches...

I see. I simply made a confusion between P47 and P83. I will change that in my items.--Bruno Belhoste (talk) 20:49, 31 January 2020 (CET)

have a nice evening --Olaf Simons (talk) 20:51, 31 January 2020 (CET)
merged Item:Q140822 into Item:Q99346 just for your record --Olaf Simons (talk) 22:35, 31 January 2020 (CET) --richtig!--22:37, 31 January 2020 (CET)

Gender and Len/Den

Dear Bruno, I think you are mixing Genders again - and putting labels on descriptions. It's ladies first Q17, Q18. --Olaf Simons (talk) 23:25, 13 February 2020 (CET)

I will correct the gender thing.. --Olaf Simons (talk) 23:30, 13 February 2020 (CET)
awful. Thank you to have corrected the problem. I made alos a confusion between Len and Den.... aaaarrkkkk....Bruno Belhoste (talk) 00:31, 14 February 2020 (CET)
I have once replaced 200 names with that confusion. --Olaf Simons (talk) 07:54, 14 February 2020 (CET)

Input of Statements

Dear Bruno, just briefly: If you use a Google spreadsheet for the further input of statements I can help you standardising the columns. The big issue is to match the texts in the fields with the FactGrid Q-Numbers, but I have gained some expertise to help here. --Olaf Simons (talk) 09:44, 24 February 2020 (CET) -- Thank you for this proposition, dear Olaf. I will show you my next input (on a Google spreadsheet) before launching the process. It will be the batch 2500th-3000th person-items.--Bruno Belhoste (talk) 10:51, 24 February 2020 (CET)


Dear Bruno, sth. just goes wrong with your Aliasses when using |. Create individual statements --Olaf Simons (talk) 12:51, 14 April 2020 (CEST) ok I will do that --12:59, 14 April 2020 (CEST)

la mobilisation générale de...

Dear Bruno, if I were more of a Romantic spirit, I would see the latest input with dark anticipations. The entire French army is mustering at the horizon. Instead I am delighted. Imagine one had the names of all those who met in these units... that would be a great thing. --Olaf Simons (talk) 05:55, 19 May 2020 (CEST) -- I don't like the army either but unfortunately most of my guys are military officers... and it's exactly what happened: they met in their unit. In fact, I needed only some regiments, but I put in (almost) all of them to be exhaustive. --Bruno Belhoste (talk) 12:00, 19 May 2020 (CEST)

Data modeling for biographies

Dear Bruno, dear Martin and dear Germania Sacra team - something we might discuss together:

Dear Olaf, you're right, it's a crucial point, and not easy at all. I will think about it. My own project is on the verge of including many biographical pieces of information involving events, institutions, timespans, locations and so on. -- Bruno Belhoste (talk) 18:43, 22 May 2020 (CEST)

Merging items

Dear Bruno, before merging items, check with "What links here" which of them has got more links and link - preferably to the one with the biggest number of links, so that it remains easy to correct the links to the new direction. Correcting links is a good practice since SPARQL searches will continue to list the Q-numbers now without labels. (Correcting such links is particularly ugly where they lead to qualifiers... yet it is good that you discover all these double records. I regret I could still not win Katrin Moeller in Halle for the professions.) --Olaf Simons (talk) 11:43, 29 May 2020 (CEST) -- Thank you for the advice. I will do it --Bruno Belhoste (talk) 13:10, 29 May 2020 (CEST)

French Identifyers

Sorry, I had not realized that BnF was not working anymore in Factgrid... Do you actually have a preference either in SUDOC or in BnF?--Martin Gollasch (talk) 09:48, 20 July 2020 (CEST) I think Data BnF is the best French reference -- 09:54, 20 July 2020 (CEST) But BnF ID is still working too -- Bruno Belhoste (talk) 09:59, 20 July 2020 (CEST)

I try to reduce duplicate pages in Factgrid by setting external identifyers. The hardest is the wikidata QNr., which barrs other pages from setting this number. Actually you dont need an explanation for an Item like "Physician" otherwise. If I dont find a GND-identfyer I will set "Data BnF" from now on, especially in Items connected with France.--Martin Gollasch (talk) 10:48, 20 July 2020 (CEST)

-- ok -- Bruno Belhoste (talk) 11:03, 20 July 2020 (CEST)

Capital initials/ aristocratic family names

Dear Bruno,

two stupid topics: When I began creating Properties and items on FactGrid I felt like this is a kind of natural language to write statements in. That is why I used lowercase letter in statements like "instance of" (P2), "human" (Q7).

(1) The ugly thing about these letters is that they give split results in SPARQL queries. I wonder whether we should gradually change these, wherever we work on an item or property. I hesitated since it would be such a tedious project but then: it will be even more tedious in the future...

(2) Family names - I gave people different Family names for "Goethe" and "von Goethe" - but I often regret this because of the sorting in SPARQL queries. Would it make sense to rearrange all these names to get proper listings? And would it be better to turn "von Goethe" into "Goethe, von" or just "Goethe" with an additional qualifier for these name components (von, de la...). I hesitate with steps into these directions as we have all sorts of composite names in German, Dutch, French, that are not necessarily aristocratic at all. It remains desirable to get nice alphabetical listings in queries... quiet undecided --Olaf Simons (talk) 12:49, 11 November 2020 (CET)

-- sorry, I don't understand the problem (1). I'm aware of the problem with family names. There is no simple good solution, I'm afraid. In the project Harmonia Universalis I failed to set a consistent rule for the name prefixes. But alphabetical listings in queries are not so important, because sorting is a process you can do after downloading the data.Bruno Belhoste (talk) 16:10, 11 November 2020 (CET)

Data model for masonic items

I spent the morning on this page as we are getting some more people on board who are dealing with lodges and Freemasons: FactGrid:Freemasonry data model. Your advice will be, as always, most welcome. --Olaf Simons (talk) 12:52, 11 November 2020 (CET)

-- Fantastic! It's a model for the data models of all the other projects of FactGrid. Worth to be listed in FactGrid:The Global Genealogy of Lodges. Bruno Belhoste (talk) 15:36, 11 November 2020 (CET)

You have seen my questions in the sections above? --Olaf Simons (talk) 15:48, 11 November 2020 (CET)

model for price tags

Dear Bruno, this might be the model to use with a search (was too lazy to find out how we get the units into the same table --Olaf Simons (talk) 22:09, 14 January 2021 (CET)):

-- I guess it's not the right query (this one is about Masonic degrees)-Bruno Belhoste (talk)

The l-s-d last three columns, were not drug related... But I am not happy with the result. I have just added, for a test, a second price tag to Item:Q145063 and I do not just get one line for the second statement...] The qualifiers are now all messed up. --Olaf Simons (talk) 10:17, 15 January 2021 (CET)

misleading statements

Item:Q221318 inexact - there should be something nicer for that in French. Pierre Marteau in Cologne is not exactly inexact. It is apparently misleading, déroutant? bluffing? ...and some statements look real, but are misleading nonetheless. My feeling with "inexcat" is that it just lacks a bit of precision (but I do not have a feeling for French words, regrettably) --Olaf Simons (talk) 09:48, 3 March 2021 (CET)

I propose "trompeur". Elsewhere in FactGri misleading seems to be closer to inexact.--Bruno Belhoste (talk) 09:59, 3 March 2021 (CET)

P181/ P189

Dear Bruno, I realised that I created a Property-double - starting first with a a differentiation for Portraits and other images and then adapting P189 to the use that was made of it (befor I eventually reacted on the graves and memorials and created a new differentiation for that...)

  • P181 has 385 links
  • P189 has 676 links

Some items have answers on both Properties. I wonder whether I shall move the statements to single property, and which one you'd prefer for the viewer. --Olaf Simons (talk) 09:43, 12 March 2021 (CET)

no problem for the viewer. Tell me only the property you have chosen. --.

Bruno Belhoste (talk) 15:25, 12 March 2021 (CET)

well, will be P189 then, the bigger one. Next week as it is stupid work with all the bloody special characters of the links that have to be changed for human eye special characters. Do not know how to make this easier... --Olaf Simons (talk) 16:08, 12 March 2021 (CET)
a sparql query might be the solution; be aware anyway that the viewer can work with two properties as well. --16:51, 12 March 2021 (CET)
Well, of course I do this via SPARQL. The problem is that the SPARQL-output is not excactly the Quickstatements input. This is what I get form SPARQ - but I cannot feed it back into QuickStaments like this: ErnstKurf%C3%BCrstvonSachsen%2C1441-1486%28ATKHMGG4795%29.jpg If there is nothing clever on tis I must run some 20 replacements to get ü, ö, ò ( etc. --Olaf Simons (talk) 16:59, 12 March 2021 (CET)
You must decode the encoded URL. The simplest way is to use web tools like [1] or [2]. It seems that there are some characters which resist to the decoding process because wikibase uses a old version of the url encoded-format .--Bruno Belhoste (talk) 18:36, 12 March 2021 (CET)

superb, all in a second. --21:11, 12 March 2021 (CET)

Where were FactGrid people born - where did they die?

a picture of our present data - and projects:

This was the complex Wikidata search: that added curious filters for a very specific search...
nice idea and beautiful sparql query, but we see the limitation of the rendering by the wikibase map tool : unicolor, straight lines and not curves, no distinction between birthplaces and deathplaces, compare with [[3]]. Bruno Belhoste (talk) 12:46, 19 March 2021 (CET)
I know (and I would love to see historical maps... --Olaf Simons (talk) 12:57, 19 March 2021 (CET)

Mesmerists,_Hugo_Franz_Altgraf travelled to Straßburg to get in touch...--Martin Gollasch (talk) 23:03, 4 July 2021 (CEST) -- Thank you for this piece of information. I never heard of this follower of animal magnetism and I will try to have more information on him. --Bruno Belhoste (talk) 18:35, 5 July 2021 (CEST)

I found him, when I did small research in the net on Franz Hugo Reichsgraf zu Salm-Reifferscheid (Q253255) here and I am still undecided whether they are ident or not...--Martin Gollasch (talk) 18:48, 5 July 2021 (CEST)

Paris to download

Imagine we could offer the entire dataset of (historical) streets and houses of Paris all geo-referenced free to download... for all projects who want to map things on their own databases and as an invitation to just use this infrastructure on site with us. You are creating something incredibly cool. --Olaf Simons (talk) 15:26, 25 August 2021 (CEST)

-- It's exactly what we will have, but only for the early Nineteenth century. Street numbers are different before and after (it would be possible to have the geolocalisation for the period 1847-1860 but it would need more work).Bruno Belhoste (talk) 15:36, 25 August 2021 (CEST)

You can locate all houses? (We need a software to run FactGrid on historical maps...) --Olaf Simons (talk) 16:36, 25 August 2021 (CEST)
Yes. It would be nice to have historical maps on FactGrid. The historical map of Paris with all the parcels (early Nineeteenth century) is available.17:03, 25 August 2021 (CEST)
A dream could be, to have a city model in three dimensions, which you can move through the centuries to explain the single building history and the development of the city structure as well... I have experimented in collaborating with Open Street mappers and their surveyors found it interesting to try to match 18th-century maps with open street maps. But I believe now, it would need a professional task force to come to real results worth publishing. So I gave up. One problem I remember; it was not that easy to communicate the demands and necesseties from the historians view to the mappers who actually walk the roads.--Martin Gollasch (talk) 23:42, 25 August 2021 (CEST)


Dear Bruno, are you sure that was the move you wanted to make. --Olaf Simons (talk) 22:57, 4 September 2021 (CEST)

it seems to be ok. I am trying to shift the statements about careers from P164 to P165 but I realize it is not easy because of the qualifiers. If the profession is the same (for instance "surgeon") but with different qualifiers (for instance with different organisational contexts) it does'nt work. --23:18, 4 September 2021 (CEST)
Really, I do not mind creating specific statements that include both the position and the institution. Create them. I just fear the repositioning of all the items. I am considering something similar for membership: Items that states an individual membership: "J.J.C Bode's Membership in the Illuminati Order" as one item to collect membership information - and again I fear the re-modelling and postpone it.
On Item:Q176269 I wonder why ist the Physician of the Charity Hospital of Lyon in te context of Toulon's hospital? Its strangely far away as an organisational roof. (I am positioned in Gotha but Erfurt's University is my employer...) --Olaf Simons (talk) 09:38, 5 September 2021 (CEST)
I think I have removed any reference to the Charity Hospital of Lyon in Q17629, have I not?
Using qualifiers is not a problem per se if the position they qualify is specific. The problem comes when the position is too general. For instance if the career is "pastor" and the qualifiers specify the location, it becomes a mess in case of a list of positions "pastor" for the same person. I am wondering whether the rule could be: "do not use a general position if you can use a more specific position". It is not easy with a position like "pastor" because there is no specific organisation to refer to in this case. Maybe "pastor in Zweibrücken" like in Item:Q100020 is a solution. -- Bruno Belhoste (talk) 10:09, 5 September 2021 (CEST)
Ah, now I realise. You did not change the English Label (which is my view) and I did not check what you did with the French...
As to the business of more specific items: I still wonder what to do if I do not have the specific information. Like on Member of Freemasonry. That's redundant if I have the lodge membership - but I do not know the lodge in all cases. (and I do not know how to run the searches that do the same job). Same with the Illuminati: Sometimes we know specific Minerval Churches, but sometime we just know the place without documents of actual meetings, and sometimes we just have Illuminati membership acknowledged in a list with the Order names. --Olaf Simons (talk) 10:32, 5 September 2021 (CEST)
We would need searches that give both answers. --Olaf Simons (talk) 10:35, 5 September 2021 (CEST)
It is possible by combining two clauses with UNION. See [4]. Your solution for the problem of lodge membership is good. It is redundant but efficient because you use Item:Q10678 without any qualifier.-- Bruno Belhoste (talk) 11:11, 5 September 2021 (CEST)
I have shifted all the data from P164 to P165. It's done. I keep P164 for a while. If you find by chance something wrong or strange, tell me please.--Bruno Belhoste (talk) 16:20, 5 September 2021 (CEST)


Dear Bruno, I have just been looking through Wikidata, wondering whether it would not make sense to import all German "writers" with basic data (that's some 21,000). The French parallel search compiles 14339 people. Importing these people in totals should have the advantage of well organised entries with all the basic information (e.g. external identifiers) without copy and paste errors - and it saves a lot of work where we are trying to interconnect information. What do you think? --Olaf Simons (talk) 10:34, 8 September 2021 (CEST)

It's a good idea. I only see two problems: 1. What about the contemporary authors? I am not sure it's a good idea to include them in the database (which is not a clone of Wikidata); 2. What about the duplicates? Checking whether the name is already in FactGrid is very easy when you deal with an author, but it's much more tricky if you have to check a lot of people before uploading a batch. In this case, Openrefine would be very helpful to make a reconciliation between your data and FactGrid. It's another good reason to have it as a tool on the site. --Bruno Belhoste (talk) 11:26, 8 September 2021 (CEST)