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. 

qid,Lfr,Len,Dfr,Den,P2,P154,P131
,"#","#","$","$",Q7,Q18,Q99677

In the case of your next candidate that would be: 

qid,Lfr,Len,Dfr,Den,Aen,P2,P154,P131
,"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)

Occupations

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 www.deepl.com 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 https://www.wikidata.org/wiki/Wikidata:WikiProject_Ontology/Classes 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)

Aliasses

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:

https://database.factgrid.de/wiki/FactGrid:Data_modeling#A_cohesive_data_model_for_people_.28and_careers.29

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: https://twitter.com/medi_cago 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

https://de.wikisource.org/wiki/BLK%C3%96:Salm-Reifferscheid-Krautheim,_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)

Toulon/Lyon

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)

authors

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)

Item:Q385293

Are you sure this was the item you wanted to address with a career statement? --Olaf Simons (talk) 08:18, 21 December 2021 (CET)

Thank you to have checked. It's certainly a mistake but where? I don't find the wrong statement.--Bruno Belhoste (talk) 09:15, 21 December 2021 (CET)
Well it seems you wanted to put that career statement on a person - but who - I could not tell. --Olaf Simons (talk) 09:25, 21 December 2021 (CET)
Strange. I see nothing: https://tinyurl.com/y4fweyqu.Bruno Belhoste (talk) 09:53, 21 December 2021 (CET)
I do not quite get the aim of this search (preparing a meeting). Item:Q385293 is on annates, payments - and has a career statement that is designed to say something about an author, and the man who wanted it is probably missing it. --Olaf Simons (talk) 10:01, 21 December 2021 (CET)
Finally I got it. The wrong statement has been cancelled. Thank you for your help. --Bruno Belhoste (talk) 10:37, 21 December 2021 (CET)

Gil Blas

Dear Bruno, was there anything wrong with my edits on the biography of Gil Blas? I am thinking of a test case on a fictional life. --Olaf Simons (talk) 16:27, 9 January 2022 (CET)

Not at all, but in my view Gil Blas is a a fictional character. I may be wrong.-- Bruno Belhoste (talk) 16:39, 9 January 2022 (CET)
Sure but I felt on the safe side if I term him a human being in a particular understanding of contexts. On the level of the novel he was born in Santillana. Will he pop up among real human beings? Not as long as we filter their searches on Q7. We have done the same with biblical people and it was of no harm. (Things will of course get tricky if real people occur in novels - that will be the challenge I would like to be able to solve.) --Olaf Simons (talk) 16:46, 9 January 2022 (CET)
Anyway, there is no inconvenient to define Gil Blas both as a fictional character and as a human being in a particular understanding of contexts and it can be useful in order to distinguish between fictional characters and real people occuring in a novel -- Bruno Belhoste (talk) 17:19, 9 January 2022 (CET)
Well, I rely on your superior data modelling skills - but imagine you bring Balzac or Zola novels onto your map. --Olaf Simons (talk) 17:34, 9 January 2022 (CET)
Another challenge: see the movements of Gil Blas on the map... (I'll supply the data - reading the book with my son, who is greatly amused though not always able to take the lessons.) --Olaf Simons (talk) 17:36, 9 January 2022 (CET)
It's what Melanie Conroy did, I guess, with Balzac and Proust. See her book: [5]. She might be interested in putting her data on FactGrid. -- Bruno Belhoste (talk) 17:52, 9 January 2022 (CET)

Consistency checks

Dear Bruno, I was doing some consistency checks (double mothers and not yet finished...). We created hundreds, but one falls into your realm: Item:Q100012. Ah, I should also write you an extra mail. will do so. --Olaf Simons (talk) 14:12, 1 April 2022 (CEST)

Thank you. Done --Bruno Belhoste (talk) 16:16, 1 April 2022 (CEST)

Item:Q400000

nice pick, spiking out. --Olaf Simons (talk) 21:37, 25 April 2022 (CEST)

The French guillotine

I wonder whether whether anyone ever created the entire set... we have got 40 people. --Olaf Simons (talk)

French Wikipedia has this a list of their victims of the terreur - and the English Wikipedia-article gives an estimate of 17.000. That would create a massive data set (where did this happen? how did it spread on the French map? Do we have trials of all of these?) If there already exists a list of these 17.000 that would be worth the negotiation to make it publicly available for statistical searches. --Olaf Simons (talk) 08:49, 17 May 2022 (CEST)
This list, published by Louis Marie Prudhomme in 1797, has given birth to a commercial searchable database.--Bruno Belhoste (talk) 17:27, 17 May 2022 (CEST)

Dear Bruno, that's an impressive book. He should have had our database! How he states the organisational setting and then goes into this list... I am baffled. --Olaf Simons (talk) 17:49, 17 May 2022 (CEST)

Monetary units

Hi Bruno. I just saw your Item:Q394593 - which reminded me that I always wanted to hear your thoughts about the representation of sums of money. You choose the qualifier Basic unit. You could also have chosen the unit option that comes with Wikibase: Item:Q14615 what is preferable? --Olaf Simons (talk) 16:13, 23 May 2022 (CEST)

You're right. The unit option is better. --Bruno Belhoste (talk) 16:24, 23 May 2022 (CEST)
Well I am not quite sure how to do it with all the non-decimal values of previous times - in a way that we can finally teach machines to calculate with such information. --Olaf Simons (talk) 16:27, 23 May 2022 (CEST)
The only solution I see is to create qualifiers with a property "sub-unit": for instance for an angle of 15° 30' 15": 15 unit option: degree with two qualifiers: (1) sub-unit: 30 unit option: minute; (2) sub-unit: 15 unit option: second. It's far from perfect --Bruno Belhoste (talk) 16:53, 23 May 2022 (CEST)

P2 Organisation

Good afternoon! I have followed the corrections that have been happening since this morning and I was just wondering, why the P2 : Organisation has been removed? Just asking... I will avoid it in my next items. Sunny greetings from Weimar Isabella Schwaderer 16:57, 22 June 2022 (CEST)

or, rather it has been substituted with different items... is there a list available? Isabella Schwaderer 17:01, 22 June 2022 (CEST)
Hi Isabella. Thank you for your question. I try to make the data model simpler and more systematic and it's not easy. For instance, P2:Organisation (Q12) is redundant if you have stated P2:Learned society (Q153558) because "Learned society" is a subclass of "Organisation" (more precisely "Learned Society" is a subclass of "Society", which is a subclass of "Organisation"). It is the reason why I removed the redundant P2:Organisation. It is possible that I accidentaly removed some statements P2:Organisation which are necessary (in case there are no other P2). I know it happened in some cases and I will put these necessary statements back in the machine. In a query, you must use a property path wdt:P2 /wdt:P3* wd:Q12, instead of wdt:P2 wd:Q12, to search all items which are in subclasses of the class Organization.--Bruno Belhoste (talk) 17:23, 22 June 2022 (CEST)
Thank you! I understand a little better, but maybe not completely. I usually deal with learned societies or academies, so in that case, I should state P2:Learned society (Q153558) ? In the era I'm working, there is a whole range of institutions/organisations organised in the form of an association (Verein), and different subtypes, which I would prefer to label as "learned societies", because they are public, but not state-funded such as the academies. How would you differentiate? Thank you! Isabella Schwaderer 18:16, 22 June 2022 (CEST)
The best solution, I think, would be to both state (for instance) P2:Learned society and P2:Verein. It makes sense in this case because Verein and Learned society are both subclasses of Organisation but not subclasses of each other. In the query you use ?item wdt:P2 wd:Q153558; wdt:P2 wd:Q266834, or you create a variable VALUES ?learnedVerein { wd:Q153558 wd:Q266834 } and use ?item wdt:P2 ?learnedVerein. --Bruno Belhoste (talk) 18:29, 22 June 2022 (CEST)
In fact, ?item wdt:P2/wdt:P3* wd:Q12 should work.--Bruno Belhoste (talk) 19:10, 22 June 2022 (CEST)

Revert

Good morning Bruno, - what was wrong with this edit?

Sorry, nothing wrong. I don't even know how I made this change, which is totally inadvertent! --Bruno Belhoste (talk) 14:58, 3 July 2022 (CEST)
Can happen, the rollback button is just a trembling finger away. I wonder if ever I will block someone by accident. Have a nice day. --Olaf Simons (talk) 15:13, 3 July 2022 (CEST)

Address

not sure about the geo-coordinate in this particular case: Item:Q16200 --Olaf Simons (talk) 14:41, 27 July 2022 (CEST)

right --Bruno Belhoste (talk) 15:03, 27 July 2022 (CEST)

Emigrants

Dear Bruno, ...so grateful that you took care of all the emigrants that had gone lost between Mademoiselle Scylla of interesting topic and Mademoiselle Charybdis of far too many to deal with --Olaf Simons (talk) 16:48, 2 August 2022 (CEST)

my pleasure, it's what I love with FactGrid: collective work. I just come back from US and still jet lagged. -- Bruno Belhoste (talk) 17:44, 2 August 2022 (CEST)

Cooking recipes

Dear Martin, dear Bruno, dear Jens. Jens Bemme asked me whether we could no organise historical cooking recipes in FactGrid and I was immediately delighted. The thing is, of course, difficult - especially as any such process creates substances that are suddenly new objects in the game. I experimented with a 1715 recipe that has a farce created in the process: Item:Q436785 - and I am not quite happy with the result. I eventually separated Ingredients from steps and used the P499 property in this. I am not sure whether this is already bright. Your views and experiments are welcome. --Olaf Simons (talk) 19:48, 12 August 2022 (CEST)

The unpleasant part of my data model is that I moved the procedural items into the qualifier level - where it will be difficult to search them. I did this so that machine inputs in Quickstatemets to not create heaps of statements on a single procedure - but maybe that won't happen anyway... --Olaf Simons (talk) 21:04, 12 August 2022 (CEST)
Gave an alternative with the steps as immeduiate statements. This would allow users to ask for all recipes where a bird is stuffed between meat and skin - which I guess would be the cool option for the historian of cooking --Olaf Simons (talk) 21:17, 12 August 2022 (CEST)
I agree it's the best option --Bruno Belhoste (talk) 21:25, 12 August 2022 (CEST)

Statistics

Dear Bruno,

I am trying to help User:Marie Gunreben with some sample searches. They do their job as expected (I have learned from you), but the buble chart breaks down as soon as I insert a time filter (1700-1730) in this example:


The perplexing thing is that this worked while I was scripting but fails otherwise. Somehow the chart does not like my filter.

I am wondering at the same moment whether it might be possible to give a line graphic (I remember, yo even accumulated lines) that shows how the "political" gives way to the "galant" around 1700. Can you help me with the scripts? Best, --Olaf Simons (talk) 11:42, 5 September 2022 (CEST)

The problem for the bubble chart comes from the condition OPTIONAL on Fashion which makes the "group by" impossible. So remove OPTIONAL on Fashion, it will work:

Count with time filter, 1700-1730 Bubble-Chart "galant" versus "politisch"

Dear Bruno, you are bright, and I am still walking in the dark - piecing searches together in a terrible way of trial and error. Maybe you know an additional thing in this sphere: The empty counts are actually interesting. Is there a way to get a bubble for the line that appears in the table without a hit? It is the biggest number, and that should be part of our knowledge... --Olaf Simons (talk) 15:56, 5 September 2022 (CEST)
Dear Olaf, I also use trial and error and also the "help". Maybe you have to learn first the principles of the SPARQL language. It's not very difficult. Here is an attempt with area chart: https://tinyurl.com/2jg6n5w9. It is not very convincing in this case, but with more fashions it might be the best display for your data.--Bruno Belhoste (talk) 16:11, 5 September 2022 (CEST)
You can add a label with BIND to the items which are not "Galant" or "Politisch". It does work (I confess I was surprised) : https://tinyurl.com/2jmvmzzc --Bruno Belhoste (talk) 16:46, 5 September 2022 (CEST)
Extremely useful (I am looking at long lists with "no statement" entries, and it is elegant to work just with the statements. Nice! --Olaf Simons (talk) 17:20, 5 September 2022 (CEST)

Get a the connection between statement and qualifier right

Dear Bruno, I am still making stupid mistakes with qualifiers. Can I bother you with two simple searches (I assume I can do my complex ones with the knowledge the simple ones should give me)

The following search is the one which I want to run in the end:

thank you for all your patience. --Olaf Simons (talk) 13:33, 16 September 2022 (CEST)

Dear Olaf, your problem is indeed tricky. You use property path with the statement node "p:P572: ?Prose_fiction (p:P572/pq:P166) ?Stats" instead of the regular syntax for qualifiers: "?Prose_fiction p:P572[pq:P166 ?Stats]"; it works in some cases, but not in all; especially when you have several objects for the same predicate, as in your case, it fails because the clause is not able to catch the right object with the right qualifier. In your case, you have to specify the object before adding the qualifier. It means : you have to write: "p:P572[ps:P572; pq:P166 ?Stats]". Thus you get the right object with ps and its qualifier with pq.
See : https://tinyurl.com/2qxyqhy7
Hope I answer your question. --Bruno Belhoste (talk) 17:57, 16 September 2022 (CEST)
Dear Bruno, wes indeed, that solves the problem. Where do your read to get such solutions? The pages I visited were too trivial. We need our own tutorial of sample searches and statements about the problems the solve. --Olaf Simons (talk) 18:40, 16 September 2022 (CEST)
Read:
Tutorial Sparql: qualifiers. It's quite clear --Bruno Belhoste (talk) 18:46, 16 September 2022 (CEST)
This is what I did with your help
Just some first searches of the table (of the Google spreadsheet). The Spreadsheet itself is not really done by an ontological mind. You might like my playing with EntiTree to create a model for all this.
The weekend begins, I'll still have to think of line graphs to get developments (wondering about an equivalent to Ecel's moving averages, or (better still in this case:) decade statistics.
All in all this has been a test for me. What happens if users provide such data? They cannot really generate data models, nor can they create searches - nor can we (I fear) create a standard which future projects can use. So somehow at the limits. FactGrid is a cool place for biographical data, but this gave me headaches.
If you have ideas what we can learn from this, I'll be grateful. Wikibase is super flexible, theotretical an ideal software for flexible solutions that fit on unique customer wishes. Theoretically... --Olaf Simons (talk) 19:56, 16 September 2022 (CEST)

January 1

Dear Bruno, I am trying to find out how to get dates from Wikidata with the indication whether a person was really born on January 1 1650 or just in 1650:

This is my search: https://w.wiki/5iZo

and this https://www.wikidata.org/wiki/Help:Dates#January_1_as_date tells me that I just might not be able to get this information. Have you solved this in your searches? --Olaf Simons (talk) 12:18, 19 September 2022 (CEST)

The only way I know is to get the time precision of the date. If it is 9, it means that the date is a YYYY (a year), if it is 11, it means that the date is a DD-MM-YYYY. See https://w.wiki/5ia8 Bruno Belhoste (talk) 12:34, 19 September 2022 (CEST)
Dear Bruno, thanks, that helped. I noted the required search on the Sample queries page. I also opened a section on early modern learned Societies, just to collect basic lists wherever we reach something useful. Let's see how it grows... --Olaf Simons (talk) 15:53, 19 September 2022 (CEST)

Charles Pougens et alia

Its a pleasure to work with the data you provided and I hope you dont mind me popping in once in a while, even if I might produce one or the other mistake by the wikimedia-principle "edit first, filter later". Have a nice weekend!--Martin Gollasch (talk) 14:53, 24 September 2022 (CEST)

Thank you for your contributions, dear Martin. I appreciate it a lot. Feel free to go on!--Bruno Belhoste (talk) 15:46, 24 September 2022 (CEST)

Friends and enemies...

Dear Bruno, would you like to give your thoughts on our present data modelling at User talk:Jean-Baptiste Pressac#PRELIB Person migration to FactGrid? Best, --Olaf Simons (talk) 12:12, 30 September 2022 (CEST)

P820 is a identical with P703 which the PhiloBiblon people had demanded. --Olaf Simons (talk) 21:57, 2 October 2022 (CEST)
Sorry for this duplicate. P820 can be reuse for another property. --Bruno Belhoste (talk) 23:17, 2 October 2022 (CEST)


P277

Dear Bruno, I am thinking about bringing more coherence into some of our properties - with a look at Wikidata. Our Property:P277 - could we say it is mostly Wikidata:Property:P2868? They have two properties Object has role and subject has role, and I am beginning to feel that this is bright, as we do need to specify the directions of relationships... --Olaf Simons (talk) 00:06, 4 October 2022 (CEST) (We will have to transform some statements like life long membership to life long member, but that would be a minor issue. --Olaf Simons (talk) 00:07, 4 October 2022 (CEST)

Dear Olaf, can you give an example of use of Property:P820? --Bruno Belhoste (talk) 10:56, 4 October 2022 (CEST)
Louis XI of France - a wikidata example, look for the confessor. (would be pointless to say that Louis was the King, but possible to say that he was confessing... --Olaf Simons (talk) 11:36, 4 October 2022 (CEST)
I assume we will rarely use P820 but it brings us into line with Wikidata. This is the sort of statement we are usually making with P277 on a Wikidata item: wikidata:item:Q1596590. --Olaf Simons (talk) 12:14, 4 October 2022 (CEST)
I see. If we decide to use a generic property like Property:P703 instead of specific properties like Property:P192, Property:P820 is mandatory. In case we want to state an interaction (like friendship), it's seems natural to privilege the role of the object Property:P820 over the role of the subject Property:P277. Sometime, both qualifiers on the same statement might be useful (???). We must be very careful not to make things too complex to keep some model homogeneity in FactGrid.--Bruno Belhoste (talk) 13:29, 4 October 2022 (CEST)
Yes, I agree. New groups that call me for their guidance prefer lots of specific properties in order to feed tables just as they have column by column into the machine and I am trying to be restrictive here. Katharina Brunner gave me some thoughts why going along with Wikidata is useful as long as we do not loose our own complexities. She made it possible to run federated queries throgh FactGrid and Wikidata and that was only possible where we had equivalents, so she spent some time establishing these equivalents. The EU Knowledge Graph (Q434373) people came with the same arguments (I had contected them with the wish to cooperate - where possible). They are running their database solely with bots, and they run bots on Wikidata that make sure that all the mutual items are interconnected. I was trying to achieve this cohesion manually so far... I wonder what will happen with the development of a federated wikibase infrastructure (and I assume that we will see some pressure towards standardisations - connected with the chance to bring our information into the widest imaginable circulation). --Olaf Simons (talk) 14:00, 4 October 2022 (CEST)

Dijon

Dear Bruno, I am wondering whether the student's matriculation register of the Law Faculty of Dijon (Q23104) for the period 1808 to 1816 is kept with the Archives départementales de la Côte-d'Or (Q465126)‎‎ or elsewhere like in Paris. Since many German law students especially from Northern Germany attended classes there to study the new Code Civil I would like to have them for this period in FactGrid completely. Perhaps you have an idea, how to get a copy if they are preserved or published?--Martin Gollasch (talk) 15:10, 26 November 2022 (CET)

Dear Martin, I guess everything is at the Archives Nationales in Paris. The files are here: [6] : p. 98 - F/17/1669 et 1670 Etats des inscriptions dans les Facultés de Dijon; p. 99 - F/17/1684. Demandes, classées par académies, de grades universitaires. An XIV-1830 ; pièces justificatives antérieures; p. 101 - F/17/1972 à 1975. Écoles, puis facultés de droit: affaires diverses. 1793-1849. Unfortunately, I doubt you can get a copy of these documents and I'm afraid you'll have to go to Paris ....--Bruno Belhoste (talk) 15:54, 26 November 2022 (CET)
THX Bruno, I will look into the link these days.--Martin Gollasch (talk) 16:30, 26 November 2022 (CET)

Merry Xmas!

308 Paris based radical translators: https://radicaltranslations.org/database/agents/?page=1&page_size=50&anonymous__term=no&meta__term=person&main_place__term=Paris --Martin Gollasch (talk) 20:56, 26 December 2022 (CET)

Thank you for the link, dear Martin. I did'nt know Radical Translations which is an interesting project. Happy holidays season! Bruno Belhoste (talk) 12:23, 27 December 2022 (CET)


Brevet

Dear Bruno, just stumbling over the translations of fr. "Brevet" / en. "Voucher" / de "Attestat" which do not really meet. What exactly is a French brevet?

The fast way towards harmonisation could be Certificate in all four languages. --Olaf Simons (talk) 14:57, 20 March 2023 (CET)
Brevet in this case, which is specific, is a certificate. The problem is that the word "brevet" was used by Mesmer for the certificates of certain members of the Society of Universal Harmony and I would like to keep it. Maybe the right way is to put quotation marks "brevet" instead of brevet in every langage.--Bruno Belhoste (talk) 15:14, 20 March 2023 (CET)
Sure, you should keep it. I was just reading "Voucher" in English and that is a coupon in German, i.e. you get something free of charge gratis - and I felt that was not what you were looking for.

Have you seen this page FactGrid:Authentic translation help - I created it to look for contemporary translations (the 1844 dictionary is here of no help, however). Martin, in this case did take the right German translation... I could go for "medical testimonial", "medical report" in English, medical attestation to move closer to Martin's choice... --Olaf Simons (talk) 16:05, 20 March 2023 (CET)

I'm struggling with all the qualifiers I have to put in the same statement, in this case different types of membership for the Society of Universal Harmondy associated with different dates and modifiers and so forth, and I have not yet found the right solution, if it exists... I know that you already experienced the same kind of problem. Maybe you have interesting solutions (for instance for putting different dates related to different qualifiers in the same statement) __Bruno Belhoste (talk) 16:19, 20 March 2023 (CET)
I created Item:Q499325 for the Brevet.
I know your struggle (looking at data produced in Halle and Jena). The answer might be a second wikibase. I called it the Claim-Base. It creates an item for each claim. Like you have a list of members produced by an association and you turn each entry into one item. Then you branch out: 1) who is involved in which role? what kind of claim is this? what are objects in the claim... And you create data models for different sorts of claims. The properties refer to possible identifications. We will at least create it and play with it as several people asked me for such a base. And then you can also refer to statements in FactGrid. Maybe in the summer. --Olaf Simons (talk) 16:27, 20 March 2023 (CET)
I am not sure I understand what you mean. There is anyway the limitation of the qualifier system, because it is not possible to create second-order qualifiers. Is it a way to get around it? --Bruno Belhoste (talk) 17:23, 20 March 2023 (CET)

Bruno, could you describe, which specific informations you want to combine with a stated membership? We have been dealing with quite a few different types of membership here. Usually we have beginning and in some cases the end. Then we use the different three types of notes for further explanations or citations... Besides future options we should figure out, what kind of solutions are presently available.--Martin Gollasch (talk) 16:32, 20 March 2023 (CET)

Dear Martin, in the case of the Society of Universal Harmony, there are two waves of membership, with different status and different dates: the first wave in 1784 and early 1785 with two status: student of Mesmer and correspondent; the second wave after novembre 1785 with two other status: founding member and member. The same people can be in the first and the second waves (for instance student of Mesmer and member). There are other pieces of information but I think it is easier to deal with them. --Bruno Belhoste (talk) 16:45, 20 March 2023 (CET)
In short: four different roles (P164)... I suggest under the membership 1. beginning, 2. end or alt. 1. date; then 3. place of event (if necessary because its not the usual place of residence), 4. role (since you can add more than one role, its up to your creativity to define roles including a time indication as the year or so... 5 notes (we should use the three to five different types of notes more consciously... perhaps we have to work on definitions there...) --Martin Gollasch (talk) 19:09, 20 March 2023 (CET)
Thank you, Martin, for your suggestions. I agree with your scheme. The only problem is how to relate dates with roles (it is possible to indicate the connection in a note but it does not help when you make a query). So I suggest, every time it is possible, to use different time properties (date, begin date, etc.). For the member of the Society of Universal Harmony I finally decided to make two distinct statements:one for the membership and one for the teaching of Mesmer in the context of this society --Bruno Belhoste (talk) 17:17, 21 March 2023 (CET)

Conference in Nuremberg on Virtual Cities

Dear Bruno (my mail might have gone lost), I will attend a conference on virtual cities in Nuremburg tomorrow and Thursday. I will take a look into your searches at FactGrid:Paris to download. If there are stranger searches to show by now, you might feed them into the page and I will show them. (Did I see you doing things with image integration? Were you experimenting with the weight of dots?)

I can also add a bit of commentary on particular searches... I will add the movements of Heine and Comte - if you have other People with interesting moving patterns let me know, as you have far too much in the machine for me to understand that quickly. A good night in Paris, --Olaf Simons (talk) 00:20, 22 March 2023 (CET)

students of the Universitiy of Erfurt

Dear Dr. Belhoste, I am a history student at Friedrich-Schiller-Universität in Jena and am currently working on my bachelor thesis about the matriculation register of the University of Erfurt. We are trying to assess, where the students came from. I would love to visualize the data from seperate decades in different colours in one map. Olaf told me, You might have some insight, on how to achieve this goal. This is the query for the data of the first decade, for Your better understanding: 1392-1400: https://tinyurl.com/2qz9vbb8

Greetings, Kathleen Schnabel (talk) 11:41, 12 May 2023 (CEST)

One of the things Kathleen was wondering about: How to bring two maps of birthplaces (created by students of different decades) into one picture - by giving their dots different colours. --Olaf Simons (talk) 11:50, 12 May 2023 (CEST)

Books on Animal Magnetism

Hi Bruno, coning back to your bibliography: Would it be interesting/difficult to note the stance towards the topic? I noted it on Bode's books Item:Q401611 with a P823 Qualifier. It might be an interesting move to see how the position towards a topic is changing. --Olaf Simons (talk) 11:59, 3 June 2023 (CEST)

It's a good idea, but I don't know whether it would be possible. I put the bibliography on FactGrid but I did not make it. It's the work of some students of Jean-Luc Chappey who were paid for that, I believe.--Bruno Belhoste (talk) 15:59, 3 June 2023 (CEST)
In that case I will have less inhibitions to add (Place: Publisher, Year) information where I can do this more or less automatically. (The book historians curiosity...) --Olaf Simons (talk) 22:31, 3 June 2023 (CEST)
of course yes, it would be great; publishers are on my list to do as well -- Bruno Belhoste (talk) 23:32, 3 June 2023 (CEST)

Franz Josef Anton von Thun und Hohenstein (Q636066)

Another follower of Mesmer for your collection. Source is BLKÖ via wikisource. And connected with him and Lavater the Gablidone’sche Gesellschaft (Q636067) ... Have a nice weekend!--Martin Gollasch (talk) 14:48, 13 October 2023 (CEST)

thank you, Martin --Bruno Belhoste (talk) 17:57, 14 October 2023 (CEST)

Concatenate

Dear Bruno, I am again struggling with SPARQL. The Church Archive in Gotha asked me to modify their standard search:

but they want to have the persons in one cell - so concatenate. I took a look at this search https://tinyurl.com/yltnyu9g but was too dumb to understand.

The rdfs thing makes things difficult, but it seems I cannot concatenate values without it, so my dumb empirical testing of SPARQL (where understanding would be better). I regret that sort of empirical intelligence which I have been endowed with - it does not solve all imaginable problems equally well. --Olaf Simons (talk) 12:45, 23 November 2023 (CET)

Dear Olaf, it is not because you are too dumb to understand. It is really difficult and, in my view, even impossible to obtain what they want with a SPARQL query. Here is the best I can do:

query. As you notice, I just can concatenate the titles of the documents. I don't see how it would be possible to merge the labels of values from several columns into a single one. I guess it is simply impossible with SPARQL.-- Bruno Belhoste (talk)

Dear Bruno, I miscopied something above. This is the search that is quite to my satisfaction:
My problem is that I do not understand how to continue from here, for instance with the column of the numbers:
I just want to add the other columns of this search https://tinyurl.com/yqqelng3 - and I feel it is possible
Could one do this search https://tinyurl.com/ypz2yxpq without the rdfs lines? or could one extend the lines 8 and 9 of the script so that I can bring line 5 into a new column? I feel it has to do with this rdfs stuff in the script and fear it is trivial, I just do not get what the rdfs statements in 8 and 9 are doing. --Olaf Simons (talk) 16:19, 23 November 2023 (CET)
You need to add ?Number etc. to GROUP BY : query -- Bruno Belhoste (talk) 17:15, 23 November 2023 (CET)
Ah, how stupid of me - to waste my time on the rdfs lines. --Olaf Simons (talk) 17:25, 23 November 2023 (CET)
don't worry, everybody makes this kind of blunder! -- Bruno Belhoste (talk) 18:36, 23 November 2023 (CET)
even better: query -- Bruno Belhoste (talk) 18:52, 23 November 2023 (CET)

Ah, nice you got rid of the 1st January dates. Do you know how "Group by" reacts on "Order by"? the following search is immediately deleting cell information (the archive wants to create a print version of this...) Maybe it need brackets - will experiment with this later. https://tinyurl.com/yorhnque

I suppose it's because some items have no number -- Bruno Belhoste (talk) 20:14, 23 November 2023 (CET)
Right. That was the problem. All my thanks also in the names of the archive team, you solved their problem. https://tinyurl.com/yp8tb9fx

Descriptions as Labels

Dear Bruno, I feel your present Input is not what you wanted.

Thank you for the remark. It is fixed. --Bruno Belhoste (talk) 15:17, 27 November 2023 (CET)

Georg Steindorff

Dear Professor Belhoste,

I recently started working on FactGrid and today have found a first tiny intersection of our work in the person of Georg Steindorff, who is on my focus list as a contributor to Roscher's Lexicon of Greek and Roman Mythology. I enhanced the item which you initially created a bit, I hope it is to your liking.

Best wishes for the 2nd advent, Jonathan Groß (talk) 09:52, 10 December 2023 (CET)

Thank you for your contribution to this item. It is exactly how FactGrid works: with the collaboration of all the contributors. -- Bruno Belhoste (talk) 11:45, 10 December 2023 (CET)

OhdAB Link

Dear Bruno, following my mail - this is Katrin Moeller's complete list (you can switch to English, but the decent source is German) - so far without variants and sources. 

https://kurzelinks.de/OhdAB

I am matching our 6000 - manually after a first automatic run. Still 2000 go. --Olaf Simons (talk) 22:22, 19 December 2023 (CET)

It looks very complex. I have to admit I don't understand the why and the how. But I have no doubt you will explain it for the users! -- Bruno Belhoste (talk) 23:57, 19 December 2023 (CET)

P161/ P633 clash

Dear Bruno, User:David Löblich brought to my attention that we might have a double property with Property:P161/ Property:P633. My first thought was that these were reciprocal but they are not (the reciprocal Property is Property:P190. We could go for a differentiation - I felt that Property:P633 might be designed for the disciples of Jesus, but I assume there is not enough substance in such a differentiation. What do you think? --Olaf Simons (talk) 10:12, 16 January 2024 (CET)

I already noticed this point and made the French labels of Property:P161 (élève de) and Property:P633 (disciple de) almost the same. In my opinion, it is not essential to have two properties with almost the same meaning. A qualifier Property:P277 or Property P820 can be added if necessary. -- Bruno Belhoste (talk) 17:31, 16 January 2024 (CET)

Postal connections

Dear Bruno - just as you have stumbled over the post halt:

We are using the Item:Q740385 to refer to the stops that are noted in the existing records. I am not quite user whether all these stops have a post "bureau" or Item:Q499331 "Post house". So may be this is just a halt. The documents listed in these books do not really tell us what to assume. There is probably research on this or even a data set. We just jumped into it to get a clearer picture. --Olaf Simons (talk) 17:22, 3 February 2024 (CET)

Dear Olaf, thanks for the data. I am in the plane, ready to go back to Paris. I look at that when I arrive at home. --Bruno Belhoste (talk) 03:05, 4 February 2024 (CET)

John Campbell Colquhoun (Q523831)

Dear Bruno, it seems to me that you might have picked a wrong one there. GND https://d-nb.info/gnd/116645210 and wikidata prefer the one, who was in Göttingen from 10.1802, also a lawyer.--Martin Gollasch (talk) 14:24, 11 February 2024 (CET)

Dear Martin, thank you for drawing my attention to this error; I've just corrected it. -- Bruno Belhoste (talk) 13:20, 12 February 2024 (CET)

3/4 Million

Dear Bruno, you did it again. Item:Q750000 - the person is also one of the people with the longest life span... --Olaf Simons (talk) 09:56, 20 February 2024 (CET)

Longue vie à FactGrid! --Bruno Belhoste (talk) 10:21, 20 February 2024 (CET)
Item:Q226850 Perhaps it would make sense to set the p499 statements as qualifiers on the specific membership-statements they are referring to. --Olaf Simons (talk) 11:54, 21 February 2024 (CET)
Don't worry. I will cancel all of them. It's only a temporary tool to facilitate alignments -- Bruno Belhoste (talk) 12:05, 21 February 2024 (CET)
But its good to have them (if they are chronological) for a coherent list output .... but it's not the case, unfortunately!

Places missmatched

Dear Bruno,

I just see you are adding geocoordinates to places in Kanton Bern and I noticed for some a mistake may have happened. Places like https://database.factgrid.de/wiki/Item:Q283437 , https://database.factgrid.de/wiki/Item:Q283651 or https://database.factgrid.de/wiki/Item:Q83164 are as their original items state places in Saxony-Anhalt or Thuringia in Germany and not Switzerland. I hope this didn´t happen to more than these 3 places where I noticed it and the mistake can be corrected easily. Greetings, David Löblich (talk) 21:39, 25 March 2024 (CET)

Or this one: https://database.factgrid.de/wiki/Item:Q779524 actually in Kaliningrad Oblast

Dear David, Thank you for pointing out these errors. I know there are mistakes. Not a lot, but some. I will eliminate them when the uploading will be finished. --Bruno Belhoste (talk) 21:49, 25 March 2024 (CET)

Property:P315 employer

Dear Bruno. I am also wondering about best solutions. If we change P315 from primary statement to qualifier (on the P165 career statement) this will have consequences in machine inputs. I am, let us say, a historian and I am such a thing for various succeeding employers. How do I make sure that begin and end dates will be correctly attributed? See this mess here: item:Q752642, where they had organisational context statements piling up.

On your other proposal: simplify localisations; I am actually carrying this around with me and wonder. My main anxiety is the mess Wikidata is creating with places that have various P2 statements on them without a real ontology.

The escape route we might take is work with Property constraints to make sure which statements we get exactly on certain properties.

On the practical side: We have a move towards unified career statements and I find it difficult to get real life structures represented. The present project planning on German army careers is tearing my brain into pieces. I feel I do not have a good solution for them so far. --Olaf Simons (talk) 20:58, 28 April 2024 (CEST)

Dear Olaf, thank you to have taken the time to reply to my observations.
I agree that the qualifiers are not very easy to deal with, but they are extremely useful. They are especially convenient for defining (1) dates and time periods, (2) localisations, (3) contexts. In item:Q752642 I suspect there are several mistakes (about dates and probably contexts) and problems of data modelling. I also used qualifiers for military careers but I created items for each grade in each regiment to avoid complex context qualifiers (see Item:Q22384). On the other hand, for actors, I used a single context qualifier and its works well (see Item:Q374929).
In any case, the fact that the user creates several time the same context qualifier in the same statement seems to indicate an imperfect data modelling. In the case of item:Q752642, I suggest to use Property:P164 as a qualifier for Regimentsstab.
About localisation, yes, we need a good ontology. It will solve all the problems. But adding specific properties like Property:P297 introduces useless complexity. Note that for France, departements are now considered by FactGrid as countries (for example see Item:Q133944).
Another point: making queries is a difficult task for the users. Until we get a user-friendly system (maybe with AI), a simple solution would be to create ready-made queries (they still exist by the way) and put them in dedicated items. Dedicated portals with these queries can be easily created by usung the javascript technology behind the viewer (like https://database.factgrid.de/viewer/harmonia_universalis). If you have some ideas in this direction, please share them with me. --Bruno Belhoste (talk) 11:12, 29 April 2024 (CEST)

Houses

Dear Bruno, I am beginning to create hundreds of items for houses and I am considering how to model them. I have created a property for street and urban district/neighbourhood and proposed this model: FactGrid:Buildings data model. Any your comments are mostly welcomed.

I see that for now, items for houses (such Q385847) has all the statements (city, neighbourhood, and street) in P47 (locality) property. If you are not against, we should split it to the street and neighbourhoods properties. --Daniel Baránek (talk) 12:44, 7 May 2024 (CEST)

Discussion moved to FactGrid talk:Buildings data model#Bruno Belhoste. --Daniel Baránek (talk) 14:36, 7 May 2024 (CEST)

Valcher / Walcher

Dear Bruno, I started from the German side of this German/French artist family. You might want to look over it, espec. in Gadet must be some more info. I will finish the complex from my side, when you made your comments. In Niderviller I tried to clear a little mess, since the first owner shared the meta's of his son. I had to spend a new wd-QNr... I hope, I did not mix up anything... Are there two Christoph Jacob, one with V and one with W? Martin.

Dear Martin, It's great. Yes, Christoph Jacob Valcher and Christoph Jacob Walcher are the same person. Have you seen the Geneanet file Philippe Walcher? --Bruno Belhoste (talk) 10:43, 13 May 2024 (CEST)
No, thx for the link.--Martin Gollasch (talk) 11:01, 13 May 2024 (CEST)
Retrieved from "https://database.factgrid.de/w/index.php?title=User_talk:Bruno_Belhoste&oldid=8612352"