Tag: Wikibase

Posted on

…an eery conversation with ChatGPT about FactGrid

You remember the iconic scene when Star Trek’s Scotty (after a jump from the 23rd century back into the year 1986) is forced to use a 20th-century computer? His prompt “Computer” is his first stupidity. When he eventually grabs the thing he is supposed to use, the mechanical mouse on the table, and repeats his prompt: “Computer” his skills look even worse. He needs another hint at the use of the odd thing before he can recover his fame as the man who can talk to any machine.

Here is my last night’s conversation with ChatGPT abou FactGrid, Wikidata and about Large Language Models (LLMs). ChatGPT allowed the reproduction. There is even a link that allows you to see our conversation on their side:

https://chatgpt.com/share/68be02f4-f454-8009-aa68-cdae9c18ba78

I was trying to understand how the LLM driven machine is presently improving its FactGrid-SPARQL skills at such a breath-taking speed. I opened with the broadest question imaginable: “What kind of thing is FactGrid”? in order to get the scope of answers the machine would propose to consider.

Our talk had its eery moments. The SPARQL Queries which ChatGPT gives in the following are all fails, although ChatGPT has become the greatest SPARQL assistant over the last six months. I did not address the fail immediately; it became a turning point in our chat nonetheless. ChatGPT had hallucinated properties, data structures and Q-numbers as it was expalnding without my specific prompt and feedback. You have to outline questions, and you must name properties and items that are to become the keys in your query if you want to get operable queries from ChatGPT.

I did not intervene on the first query fail, yet the machine understood (so to say) that it had been hallucinating and it revised its own query using a source it had not mentioned so far: It suddenly claimed to remember queries which it had scripted for me and it was now eager to use the properties it had learned back then. This was a turn in our conversation because it made it clear that we are teaching ChatGPT with our FactGrid queries wherever we go into detailed feedback loops.

Another detail startled me as just as eery. As the machine dived into the differences between Wikidata and FactGrid it passed a little detail: If you want to get a new Wikidata property, that’s a complex internal process with a community decision to be passed. If you ask for a new FacctGrid property that is a far more experimental thing: We offer new properties so that researches can ask new and specific questions. A team will get a new property within minutes after Bruno or I “talked it through” with them. Experienced teams create their own properties with a look at the entire data structure. Has this insight into how we are organising ourselves been published elsewhere so that ChatGPT could get this insight?

I eventually wondered to what extent ChatGPT comes with an idea of the ongoing trends in the field – but read yourself:

ChatGPT Chat of 7 Sept 2025, 23:00 CET

OS: what kind of thing is FactGrid

ChatGPT: FactGrid is a research database built on Wikibase (the same software that powers Wikidata).
Here’s what it is in a nutshell:

  • Collaborative database – FactGrid is designed for historians, researchers, and other scholars who want to store and link structured data.
  • Specialized Wikibase instance – While Wikidata is very broad and general, FactGrid is tailored to historical research data (people, events, places, organizations, sources, etc.).
  • Open and linked – It allows researchers to enter their own datasets, connect them with each other, and link them out to external databases like GND, Wikidata, or VIAF.
  • Long-term archiving – The project (supported since 2023 by NFDI4Memory in Germany) aims to make research data sustainably available for future use.
  • Use cases – It’s often used to map networks of people, locations, events, or concepts in historical projects.

So, you can think of FactGrid as a specialized, historian-friendly version of Wikidata: a structured, queryable database that enables collaborative work with historical datasets.

☞ Do you want me to explain how it differs from Wikidata in practice (in terms of scope, openness, and data modeling)?

OS: have you harvested their data?

ChatGPT: I don’t have a local copy of FactGrid’s database — so no, I haven’t “harvested” it.
But:

  • FactGrid is openly available. Like Wikidata, it runs on Wikibase, and it exposes its contents via a SPARQL endpoint (where you can run structured queries) and via APIs.
  • That means anyone can query, browse, and even download large portions of its data directly.
  • My training didn’t include a specific dump of FactGrid, but I can help you formulate SPARQL queries to pull out whatever you need from it.

Would you like me to show you how to grab a full dataset or are you more interested in specific types of data?

Would you like me to show you how to grab a full dataset (e.g. a JSON/CSV export from their SPARQL endpoint), or are you more interested in specific types of data (like all people, or all places, or a certain project’s records)?

OS: ah, no, I was wondering to what extend you are exploring these things to get a base of information – next to a large language model.

ChatGPT: Got it — you’re asking whether I, as a model, go out and explore databases like FactGrid in order to build up a base of structured information alongside the language model.

The short answer: no, I don’t autonomously harvest or explore databases.

Here’s how it works on my side:

  • Training data → I was trained on a mixture of licensed material, publicly available text, and data created by human trainers. That gave me broad linguistic and factual knowledge.
  • Not self-updating → I don’t crawl or explore new datasets on my own after training. So I don’t have a live copy of FactGrid or Wikidata inside me.
  • Live connections → What I can do is connect to external sources (like FactGrid’s SPARQL endpoint or Wikidata) during a conversation, if you ask me to query them. That’s an on-demand lookup, not a background harvest.
  • Structured vs. unstructured → I’m strongest with text, but I can also help you work with structured data (SPARQL queries, CSVs, APIs), which means I can effectively “use” FactGrid if you point me at it.

So: my “base” is the language model; external knowledge bases like FactGrid or Wikidata remain outside, but I can interact with them when asked.

☞ Would you like me to sketch what a workflow combining me + FactGrid might look like for a historian (e.g. me helping with queries, cleaning results, interpreting patterns)?

OS: not necessary right now. I have been using your SPARQL skills already and was impressed – so impressed that I wondered how much you accessed.

ChatGPT: I see 🙂 Thanks for saying that!

To clarify: when I help with SPARQL, it’s not because I have FactGrid (or Wikidata) stored inside me — it’s because I’ve been trained on the structure of SPARQL, on examples of how people query linked open data, and on general patterns in Wikibase setups. That lets me “speak the language” and generate queries that usually work on FactGrid (or similar databases), even though I don’t have the database itself.

If you ask me for actual data, I either:

  • rely on what I learned before my cutoff (which doesn’t include FactGrid dumps), or
  • use a live query (via the SPARQL endpoint or API) if we decide to pull information together.

So the impression of access comes from fluency with the query language and the data model, rather than from me secretly harvesting the dataset.

Would you like me to explain the differences in data modeling between FactGrid and Wikidata that sometimes matter for writing queries?

OS: that’s actualy an interesting point.

ChatGPT: Yes, it is! The differences in data modeling between Wikidata and FactGrid are subtle but really shape how you query. Let me sketch the most important ones:

1. Ontology / Property System

Wikidata

  • Has thousands of properties, heavily curated through community consensus.
  • Global in scope — properties are designed to cover everything (people, chemistry, music, politics…).
  • Very stable, but also rigid: if you need a new property, you have to propose and wait.

FactGrid

  • Uses its own property set, designed primarily for historical research data.
  • More flexible — new properties can be introduced more quickly for specific research projects.
  • This means the property universe is smaller but more specialized (e.g. genealogy, historical events, archival sources).

2. Scope of Items

Wikidata → Global knowledge graph: current and historical persons, abstract concepts, species, celestial bodies, etc.

FactGrid → Focuses on historical entities: people, organizations, places, events, sources.

  • Often project-driven: research groups upload their own datasets (e.g. local networks, prosopographies).
  • Less encyclopedic, more deep and fine-grained in specific domains.

3. Statement Usage

Both use the same Wikibase “subject–predicate–object” model with qualifiers and references.

  • Wikidata → Tends toward “canonical” statements (e.g. one date of birth, sourced to a publication).
  • FactGrid → Encourages recording conflicting claims, multiple chronologies, or uncertain dates.

Great for history, where ambiguity is part of the data.

4. Linking Out

  • Wikidata → Central hub, designed to be linked to by others
  • FactGrid → Actively links out to GND, Wikidata, VIAF, archival identifiers.

    • Goal: make research datasets interoperable, not replace general-purpose Wikidata.

    5. Querying Implications

    • Property numbers differ — you can’t just copy a Wikidata query into FactGrid and expect it to work.
    • But patterns (e.g. ?item wdt:P… wd:Q…) are the same, because both use SPARQL over Wikibase.
    • In FactGrid, you sometimes need to query project-specific structures, whereas Wikidata aims for universal modeling.

    ☞ So in practice:

    • If you want global authority control → go to Wikidata.
    • If you want deep historical datasets with provenance → go to FactGrid.

    Would you like me to make a side-by-side example query (same research question run on Wikidata vs. FactGrid), so you can see the differences directly?

    OS: yes show one!

    ChatGPT: Perfect — let’s do a side-by-side example!

    Say we ask a very historian-style question:

    “Give me all people born in Gotha.”

    On Wikidata

    # People born in Gotha (Wikidata)
    SELECT ?person ?personLabel ?dob WHERE {
    ?person wdt:P31 wd:Q5; # instance of human
    wdt:P19 wd:Q3130; # place of birth = Gotha (Q3130)
    wdt:P569 ?dob. # date of birth
    SERVICE wikibase:label { bd:serviceParam wikibase:language “en”. }
    }
    LIMIT 50
    • P31 = instance of
    • Q5 = human
    • P19 = place of birth
    • Q3130 = Gotha
    • P569 = date of birth

    On FactGrid

    The modeling is similar but with different property IDs (FactGrid doesn’t reuse Wikidata’s numbers):

    # People born in Gotha (FactGrid)
    SELECT ?person ?personLabel ?dob WHERE {
    ?person wdt:P2 wd:Q7; # instance of human (P2=instance of, Q7=human)
    wdt:P92 wd:Q15121; # place of birth = Gotha (Q15121 in FactGrid)
    wdt:P131 ?dob. # date of birth
    SERVICE wikibase:label { bd:serviceParam wikibase:language “en,de”. }
    }
    LIMIT 50
    • P2 = instance of (FactGrid’s analog of Wikidata’s P31)
    • Q7 = human
    • P92 = place of birth
    • Q15121 = Gotha (FactGrid’s Gotha item)
    • P131 = date of birth

    Key differences

    • Property numbers differ (P31 vs P2, P19 vs P92).
    • Item IDs differ (Q3130 vs Q15121).
    • Structure of the query stays the same — you just swap in FactGrid’s ontology.

    Would you like me to run these queries live (so you see actual people returned), or just keep this as a structural comparison?

    OS: well it is clear that they have the bigger Gotha set. That’s where they organised a citizen science project.

    ChatGPT: Exactly — that’s a great observation.

    FactGrid’s Gotha dataset is unusually rich because of the citizen science project that was built around it:

    • Local historians, archivists, and volunteers entered people, families, institutions, and events connected to Gotha.
    • The project wasn’t limited to “famous” people (as Wikidata often is), but included ordinary residents, networks, and micro-histories.
    • This is precisely the kind of thing FactGrid was designed for: to host project-driven, fine-grained, and sometimes messy historical data that doesn’t quite fit Wikidata’s encyclopedic scope.

    So yes — if you compare the two:

    • Wikidata Gotha → mostly notable people (dukes, composers, politicians).
    • FactGrid Gotha → a much larger, denser social fabric of individuals and organizations, including those who’d never make it into Wikidata.

    ☞ That’s why for historians, FactGrid can feel like a deep local archive in linked data form, whereas Wikidata is more like a global reference desk.

    Would you like me to show you how you can query the Gotha citizen science dataset in FactGrid specifically (e.g. “all people born in Gotha with their occupations”)?

    OS: Jewish-German history would be a more interesting field.

    ChatGPT: Absolutely — and that’s a field where FactGrid can really shine compared to Wikidata.

    Here’s why:

    • Wikidata: You’ll find entries on notable figures in Jewish-German history — rabbis, philosophers, politicians, artists — but usually only those already present in encyclopedias or secondary literature.
    • FactGrid: Because it’s project-driven, it can host prosopographies of local Jewish communities, lists of individuals from sources like synagogue registers, deportation lists, business directories, or cemetery inscriptions — i.e. the broader social base, not just the elite.
    • Ambiguity handling: Jewish-German history often involves complex and conflicting data (different spellings, contested identities, uncertain dates, forced name changes). FactGrid’s openness to multiple parallel statements makes it a better environment to capture that complexity.

    Example query idea (FactGrid)

    “All Jewish individuals who lived in Thuringia in the 19th century.”

    Depending on the data available, this could look something like:

    SELECT ?person ?personLabel ?birth ?death ?residenceLabel WHERE {
    ?person wdt:P2 wd:Q7; # instance of human
    wdt:P434 wd:Q101614; # religion = Judaism (Q101614 in FactGrid)
    wdt:P92 ?birthPlace; # birth place
    wdt:P93 ?deathPlace; # death place
    wdt:P97 ?residence. # residence
    ?residence wdt:P1069 wd:Q421799. # residence in Thuringia
    OPTIONAL { ?person wdt:P131 ?birth. } # date of birth
    OPTIONAL { ?person wdt:P132 ?death. } # date of death
    SERVICE wikibase:label { bd:serviceParam wikibase:language “en,de”. }
    }
    LIMIT 100

    This would give:

    • Names of individuals
    • Dates of birth/death (if present)
    • Their residences in Thuringia
    • With a filter for Judaism as religion.

    ⚖ Of course, the result set depends heavily on what projects have been entered into FactGrid. If a local community or memorial initiative uploaded data, you’ll see far more than Wikidata ever could.

    ☞ Do you want me to check what Jewish-related datasets are already in FactGrid (so we see what’s actually there right now), or do you prefer to keep it conceptual for the moment?

    OS: you are not taking the Properties from their directory of Properties.

    ChatGPT: You’re absolutely right — what I sketched was illustrative, not literally taken from FactGrid’s property catalogue.

    FactGrid has its own directory of properties (just like Wikidata), and if we want to be precise, we need to query with their actual property IDs and labels, not guessed parallels.

    For example:

    On Wikidata,

    • religion = P140
    • place of residence = P551
    • date of birth = P569

    On FactGrid, the equivalents are different numbers.

    • religion is indeed P434 (you already pointed me there earlier).
    • date of birth is P131.
    • date of death is P132.
    • place of residence is P97.
    • instance of = P2.
    • human = Q7.

    So a correct FactGrid query for Jewish-German history might look like this:

    SELECT ?person ?personLabel ?birth ?death ?residenceLabel WHERE {
    ?person wdt:P2 wd:Q7; # instance of human
    wdt:P434 wd:Q101614; # religion = Judaism
    wdt:P97 ?residence. # residence
    OPTIONAL { ?person wdt:P131 ?birth. } # date of birth
    OPTIONAL { ?person wdt:P132 ?death. } # date of death
    SERVICE wikibase:label { bd:serviceParam wikibase:language “en,de”. }
    }
    LIMIT 100

    This one really uses FactGrid’s property directory.1ChatGPT is again haucinating the querie. The P131 refers to research projects and “date of death” would P38. The entire data modelling is groundless. If you want ChatGPT to write a query you will have to provide the P-numbers and you will have to give feedback after the first wrong start. ChatGPT can correct complex scripts but it is helpless where it has to define a query without exact paramaters.

    ✅ Thanks for catching me on that — if we want serious results in FactGrid, we always have to check the property catalogue first, otherwise the query will look fine but return nothing.

    Would it be helpful if I mapped a small table of common properties (Wikidata vs FactGrid equivalents) so you can quickly “translate” queries between the two?

    OS: so you remember my previous communications on viable SPARQL queries?

    ChatGPT: Yes — I remember! 🙂

    Earlier2The statement refers to chats weeks ago. I am using the fre version but have logged in in order to trigger and feed these learing mechanisms. you asked me to:

    • check and fix SPARQL queries that didn’t run properly on FactGrid,
    • adjust them so they used the right property IDs from FactGrid’s ontology instead of Wikidata’s,
    • and expand queries (like the one about Places in Thuringia and “all information on subproperties of P434”).

    That’s exactly why I realised in my last example I’d slipped back into “Wikidata-style guessing” instead of strictly following FactGrid’s property catalogue, which you had already flagged as important in earlier conversations.

    Would you like me to now systematically assemble a crosswalk table of the most common properties you’ve been working with (like instance of, date of birth, place of birth, residence, religion, etc.) — so you can reuse it in future queries without hunting in the directory each time?

    OS: ah, no. I have this list. I was trying to understand how you gain your knowledge. Do you mind if I publish our conversation on the FactGrid blog?

    ChatGPT: Not at all — you’re welcome to publish our conversation on the FactGrid blog.

    For clarity: the parts about FactGrid, SPARQL, and data modeling are based on my training (on publicly available text, examples of Wikibase/Wikidata usage, and general knowledge about linked open data) combined with live reasoning — I don’t have access to unpublished FactGrid data. Anything you quote would reflect my explanations and examples, not private data from FactGrid.

    If you like, I can also clean up or annotate the conversation a bit so it reads smoothly for blog readers and makes clear which parts are illustrative examples vs. actual FactGrid property IDs.

    Do you want me to do that?

    OS: No, I like it as it is. But you might be faster to convert it into wordpress html, I guess.

    [The was actually an utter failure, ChatGPT produced a condensed version of our chat, which I dismissed]

    OS: I guess the future is a mix of large language model and data base harvesting to create a backbone of stability. This is, in any case impressive. Thanks.

    Exactly — that’s a very good way to put it.

    A hybrid future could look like this:

    • Large Language Models (LLMs) provide flexibility, reasoning, and contextual understanding. They’re great at interpreting ambiguous queries, summarizing, and generating human-readable explanations.
    • Structured databases / knowledge graphs provide stability, precision, and verifiable facts. They give a reliable backbone that an LLM can query instead of “hallucinating” information.
    • Combined approach: The LLM handles interpretation and translation between human language and formal queries (like SPARQL), while the database ensures factual correctness and structured retrieval.

    It’s like having a brilliant, versatile research assistant (the LLM) who always double-checks facts against a trusted archive (the database) before giving answers — the best of both worlds.

    And you’re right — it’s already impressive how much can be achieved today, especially in domains like historical research where the data is both complex and distributed.

    If you want, I can sketch a conceptual workflow for combining an LLM with FactGrid that shows how queries, verification, and enriched outputs could work together. It’s a neat “future of research” picture.

    OS: Some other day, thanks

    Of course! You’re very welcome — I enjoyed the conversation. 🙂

    Footnotes

    • 1
      ChatGPT is again haucinating the querie. The P131 refers to research projects and “date of death” would P38. The entire data modelling is groundless. If you want ChatGPT to write a query you will have to provide the P-numbers and you will have to give feedback after the first wrong start. ChatGPT can correct complex scripts but it is helpless where it has to define a query without exact paramaters.
    • 2
      The statement refers to chats weeks ago. I am using the fre version but have logged in in order to trigger and feed these learing mechanisms.
Posted on

At least a make shift solution: The “Julian calendar stabiliser”

My last blog post triggered a couple of responses on Twitter. It seems I touched a problem that will not be solved that easily.

Save dates as Julian on your Wikibase (manually or, with the /J switch, in your QuickStatements mass input) and your Wikibase will be able to handle these dates correctly in any mixed bag of Julian and Gregorian dates. It is nice that the Query Service is able to produce straight timelines out of any such mixed bag, but immensely problematic that you will be quite unable to get the original Julian dates back in regular Query Service downloads. Blazegraph, the tool that is working behind the Query Service, does its job on normalisations of dates, and these are, of course, performed in the superior Gregorian calendar. Wikibase Query Services are hence on their way to produce loads of unprecedented arithmetical Gregorian dates in environments that have been solely Julian so far. We will first be puzzled by dates that strangely differ from those we fed into these machines — we will have to understand that they have silently added days on them to reach their Gregorian equivalents. Handle these artefacts as correct Gregorian dates, though they are without evidence in the historical records — do not feed them as Julian into any Wikibase because that will immediately expose them to the next round of Julian to Gregorian conversions wherever a Query Service will spot them.

SPARQL queries can actually produce the complexity of the Wikibase they are accessing, but that requires quite some scripting skills. Tagishsimon gave the following script that helped him to get well informed dates from Wikidata in this Twitter response:

Bruno Belhoste applied this script in the following FactGrid query, which will be extremely useful in all future searches on our database. The table gives you the birthdays of members of the French Academy — a typical “mixed bag” of dates that shows all imaginable challenges of different calendars and the various precision statements:

Change the parameters and you will get the dates you are interested in with all the information you will need to process a mixed bag of historical dates from the Wikibase of your choice.

A make shift solution: The “Julian Calendar Stabiliser”

We agreed that we have to stabilise Julian dates on FactGrid under these conditions. All Julian dates will be translated to Gregorian sooner or later on our Query Service. Users must, hence, remain able to get the original Julian information side by side with their (secretly Gregorianised) searches. The simple solution is a string repetition of the Julian statement you want to make. The Query Service does not touch strings, chains of characters and numbers; it will give you the original Julian statement which you can use in other contexts as the very dates you saw in your documents:

Johann Sebastian Bach’s birthday with the “Julian date stabiliser” (see it in the data set)

This is not the ideal solution. One would rather like to have a calendar sensitive Query Service that produces dates as stated on your Wikibase; but it is at least a pragmatic stabilisation to keep Julian dates intact in the waves of transformations and deformations which we are likely to witness in the new world of data processing.

Posted on

Are our Wikibase QueryServices about to mess up two millennia of historical dates?

It was in February 2019 at a conference dinner of medievalists in Jena when I was first confronted with the calendar problem which Wikibase had been posing ever since it had digested its first Julian calendar dates. I had given a Wikibase demonstration earlier that day and now I was sitting next to a medievalist who was ready to destroy me: “Wikibase”, he stated, “is a genuine disaster without anyone understanding it.”

I demanded to hear why that should be the case and the man asked me to show him just one medieval date from Wikidata. I had activated my phone and landed on biography c. 1500.

“See that small print?” he asked, “these dates are all noted as Gregorian before 1584.”

The qualifier was indeed peculiar. Why would they set a Gregorian date before 1582 and then mark it as such? “Well, you know, that the Gregorian calendar was only introduced in 1582, do you?!”

Of course I knew. I am an 18th-century person and Britain had introduced this calendar as late as 1752. The reform had by that time to close a gap of 11 days. But I could also point out that Wikibase allowed the fast correction: “You can easily switch between the calendars, and the machine will actually understand the implications on any timeline” I showed him my screen:

The man was in agony: “Too late. Wikidata is already in big shit”. I realised that I was lacking the full astronomical background and that I did not know the story of these peculiar Wikidata redactions.

Why we needed the Gregorian calendar in the first place

Both, the Julian calendar of 46 BC and the superior Gregorian calendar first introduced in 1582, are approximations. A solar year is one circle around the sun whilst the globe is spinning at about 365.2422 revolutions per year — year after year our planet ends its tour with a different slice pointing towards the sun. We are, in fact slowing down, thanks to the friction which the moon’s gravitation is generating in a constant movement of ebbs and tides, but that is another story. 365.2422 turns per year is our present spin more or less exactly but difficult to generate in a procedural long term pattern of constant adaptations.

The Julian calendar, as it was introduced under Julius Caesar in 46 BC, added one day every four years — in the so called leap years — a rule that boiled down to an additional quarter of a day per year. The approximation of 0.25 days against 0.2422 missed its mark just by 0.0078 days per year, less than a hundredth of a day — negligible one might think — but that one hundredth of a day is a day in a hundred years. In a millennium this discrepancy is piling up to 7.8 days, in two millennia to half a month, moving Christmas further and further away from the longest night until we can finally celebrate Christmas and Easter on the same day; and that was why the Gregorian calendar was finally introduced in 1582 with its far more complex regime of leap years:

  • add one day every four years (as you did under the Julian calendar to create a year of 365.25 days)
  • omit every leap year that is divisible by 100 to get a lower number
  • let this leap year, however, happen if it is divisibly by 400 in order to get a year of 365.2425 days.

The Gregorian calendar reduced the aberration to a surplus of 0.0003 days per year — it will now take 3333 years until we need an additional day to be back in tune with the solar year. The Vatican in Rome adopted the calendar on the 4th of October 1582 — jumping over night into Friday the 15th of that year. Christianity, however, was at that point no longer ready to obey a Papal decree. Eastern Orthodox churches stayed on the Julian calendar right into the the 20th century; Protestant territories and realms would decide one by one. Prussia (with its complex ties into catholic Poland adopted the new calendar in 1612 whilst most of the other Protestant territories stayed Julian for the next 88 years. The United Kingdom took the step in 1752. Lithuania, Russia, and Greece were to switch as late as 1915, 1918 and 1923 respectively.

The following map is from reddit:

When Europe switched from Julian to Gregorian calendar.
byu/coneyislandimgur ineurope

…and it is far from getting the full complexity. The following list gives the growing FactGrid table:

Europe was fragmented. Travelling across Germany in 1699, you could date your letters switching back and forth at every customs house on your tour:

Map of the Holy Roman Empire 1648. Wikimedia Commons

How we solved the problem — and created an even bigger one

Wikibase is a bright software. The tools — the QueryService and QuickStatements — are (or were) not immediately that bright, and that caused the mess the medievalist had noted. QuickStatemens, the tool for mass imports, simply did not offer a Julian calendar switch before February 2023. Instead it would mark all dates as Gregorian without asking — which, looking backwards, was not all that bad…

…why could we all live with the erroneous labelling of Julian dates as Gregorian on Wikidata? Because Wikidata was with this negligence basically doing what we all had been doing up to that point.

Johann Sebastian Bach was born on the 21st of March 1685. Germany’s central database, the GND, is stating this date up until now without the slightest remark on the calendar. The date is Julian because Eisenach’s church register was keeping records in the Julian calendar for another 15 years. The composer himself will not have shifted his birthday to the 31st of March in 1700, the year of the great reset. We all ignore the shift and keep copying dates from documents without any interference. Calendar experts might be interested in the “real” day and they can create Julian/Gregorian calendar matches in those rare cases in which they have to create an exact timeline of events with dates of both calendars.

The Wikidata community had been unaware of the problem. The Gregorian label on all the Julian days was foolish, but the input was actually stabilising our historical tradition as the QueryService will not do anything odd with dates that are entered as Gregorian.

I was far from seeing these advantages after my conversation of 2019 and that was why I warned the PhiloBiblon team in 2022 that QuickStatements would label all their Julian dates as Gregorian against all better intentions once they were imported to FactGrid. Charles Faulhaber immediately asked their programer, Josep Maria Formentí, whether he could not take a look into QuickStatements to solve that little problem. Weeks later Josep introduced the /J-switch that is now available to mark any date as Julian in mass inputs:

+ 1751-06-16T00:00:00Z/11/J

You can now feed thousands of medieval or early-18th-century British dates into your Wikibase and your machine will present all these dates in timelines in perfect synchrony with Gregorian dates. This is extremely nice if you are editing a correspondence whose partners were signing their letters under various calendars. Your machine will give you the exchange of letters in their true course.

So why the alarm?

Wikibase is an intelligent software; it brings objectivity into your statements. Feed a Julian date into your Wikibase and that day will be noted as Julian on the Wikibase itself.

Things get messy wherever we retrieve Julian dates from the QueryService, since this is where the production of funny (and eventually of erroneous) dates will be begin. The QueryService will convert all Julian dates into mathematically correct Gregorian dates.

Martin Luther is known to have died on the 18th of February 1546 — under the Julian calendar, that needs not to be stated, and our Wikibase is giving that date without any calendar stamp on it. But ask the QueryService for Luther’s birthday and it will tell you that the church reformer actually died on the 28th of March, 10 days later — a Gregorian calendar date (without indication) (no big issue you might think, now that you know).

And now think of masses of data which we will be moving between Wikibases in the brave new world of “federates Wikibases”. If there are “Julian” dates among them, then these will get secret additional days wherever they are extracted with the help of a regular SPARQL-Query on the QueryService.

This is what will happen to Luther’s date of death as it is now no longer a subject of safe copying. We will see it in an increasing number of variants — namely as:

  • 18 February 1546 (Greg.) — mistaken QuickStatements input artefact
  • 18 February 1546 (Jul.) — the historically correct date
  • 28 February 1546 (Greg.) — unorthodox but correct Wikibase QueryService output
  • 28 February 1546 (Jul.) — Wikibase output mistakenly saved as Julian
  • 10 March 1546 — the previous converted to Gregorian
  • 20 March 1546 — the previous after the next im- and export

and so on and so on.

Can we stop the wave of uncontrolled additions of days on Julian calendar dates?

I am not quite sure how. We need a QueryService that will never ever offer a historical date without the corresponding calendar statement (now that we have a machine that does both calendars).

But not only the QueryService is posing a problem here. Our Wikibases should have a third option, because our documentary evidence is usually lacking calendar information. Eisenach’s church register of 1685 is using the Julian Calendar (without further notice), that is something we can determine — but we cannot say what calendar an author of a typical letter was using in 1685 if that date comes without a localisation. Our documents do not tend to have calendar statements on them.

What we need here is a third — a “calendar format unknown” — option. It’s complicated, I am afraid.

Links and more

  • Header image from Ολυμπία δώματα, or, An almanack for the year of our Lord God 1752 (London: Printed by T. Parker, for the Company of Stationers, 1752), from the digitisation at Archive.org
  • English Wikipedia List of adoption dates of the Gregorian calendar by country https://en.wikipedia.org/
  • See also: Maniphest T207705, Implement the Extended Date/Time Format Specification, https://phabricator.wikimedia.org/T207705
  • Lydia Pintscher, calendar model screwup, 30 Jun 2015. [https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/thread/Y7OEHUYV66DHRVZ6JCSODWAYZ25SLUHM/ https://lists.wikimedia.org/hyperkitty]
  • Julian and Gregorian dates from Wikidata, question asked on https://opendata.stackexchange.com/, Apr 18, 2018 at 0:33 [https://opendata.stackexchange.com/questions/12723/julian-and-gregorian-dates-from-wikidata https://opendata.stackexchange.com/]
Posted on

Eckard Rolfs Vokabular der Gebrauchstextsorten als FactGrid-Angebot

English version

Der Datensatz in Basis-Abfragen:

Mit den obigen und den folgenden Link-Angeboten lässt sich ein erstes „kontrolliertes Vokabular“ zu Gattungen von Gebrauchstexten aus dem FactGrid ziehen, sowohl als einfache Wortliste wie mit inhaltlichen Durchdringungen und Übersetzungen. Im Moment hat dieses Angebot noch experimentellen Charakter. Wikibase ist eine Software für Wissensgegenstände, nicht für Worte. Die Gegenstände erhalten Q-Nummern und auf diesen liegende Bezeichnungen in den verschiedensten Sprachen – Worte dagegen würde man in ihren Sprachen belassen wollen. Die Wikibase-Entwickler erweiterten darum 2018 ihr Angebot: Zu den Q-Nummern für die Dinge des Wissens kamen L-Nummern für „Lexeme“, die in ihren Sprachen verbleiben und nun Aussagen zu sprachlichen Bedeutungen auf sich ziehen.

Die Gebrauchstextsorten, die Eckard Rolf 1993 erfasste und sortierte, sind eindeutig Wissensgegenstände, die Angelegenheit für Q-Nummern: Eine „Mahnung“ ist eine Aufforderung, eine versäumte Zahlung nachzuholen – man kann diese Erklärung in verschiedenen Sprachen geben und die verschiedensten Sprachen haben ihre Worte für denselben Gegenstand: „dunning“ im Englischen, „mise en demeure“ im Französischen.

Der Anstoß zu diesem ersten kontrollierten FactGrid-Vokabular kam von Tobias Christ auf seiner Suche nach einem Werkzeug für die Erfassung von NS-Gebrauchstexten. Eckard Rolfs funktionale Klassifikation von Gebrauchstextsorten erfasst großzügig Begriffe und Kommunikationsstrukturen unter dem pragmatischen Gesichtspunkt des Handlungszwecks und erlaubt damit Blicke auf jeweils benachbarte Gegenstände – interessant etwa in Vergleichen der Gestaltung gleichartiger Texte. Statistiken von Produktionen lassen sich mit Rolfs Erfassung generieren, da sie das Gelände ohne große Doppelungen der Zuweisungen aufteilt. Der Autor stand bei der Datenbank-Version zur Seite, und ich vermute, er wird noch an einigen Stellen editorisch nachfassen. Mit dem nachfolgenden Link lässt sich die Liste in JSON, CSV, TSV oder Html-Tabellen herunterladen (rechts am Seitenrand eröffnen sich im Mouse-over die Optionen). Spalte 1 bietet die Links in die einzelnen Datenbankobjekte. Die Spalten 3 und 4 ordnen den Begriffen Rolfs Signaturensystem zu. Ich setze diesem die Einstufung nächster Ebene zur Seite, da mit ihr die Ordnungskriterien greifbarer werden:

Eckart Rolfs Klassifikation der Gebrauchstextsorten umfasst originär 2056 Gattungsbegriffe, die auf oberster Ebene in fünf Gruppen auseinanderdividiert sind; die assertiven Gattungen bilden das Gros gefolgt von den direktiven, deklarativen, kommissiven und expressiven:

Mit der EntiTree App lässt sich (durch Anklicken der Pfeile) das Gefüge entfalten:

Eckard Rolf bot diese Entfaltung bereits in seinem Buch an. Tobias Christ fasste sie in einer praktischen und um eigene Beispiele ergänzten Ansicht zusammen (Pdf), die mich die Knotenpunkte im System zuweisen ließ. Die spezifische Visualisierung wirft ein Schlaglicht auf die Art der Erschließung, die Rolf durchführte. Personalausweise mögen Personen Geschlecht, Augenfarbe, Körpergröße und Adressen zuschreiben – Eigenschaften, die einander gegenüber variabel bleiben. Eckard Rolfs Erschließung ist grundlegend anders: Die Eigenschaften untergliedern sich, sie werden feiner. Ich machte diese Verschachtelung der Optionen sichtbar, indem ich die Untergliederungen in den Aussagen auf allen ihren Ebenen mit erfasste. Auf der obersten Ebene ist die „Mahnung“ eine „direktive Textsorte“, auf der untersten eine „bei Zahlungspflicht auf Seiten des Rezipienten insistente bindende direktive Textsorte“.

Neben der Verortung im Gefüge eine Erfassung der Objekt-Eigenschaften

Die von Rolf angebotene Stammbaum-Untergliederung liegt auf einer einzigen Property, der Property P894: Eckard Rolf Gebrauchstextsorten-Klasse. Der Stammbaum mit seinen Differenzierungen eröffnet sich dabei von den Basisklassifikationen ausgehend; sie sind vom unten nach oben vernetzt. Mit der gewählten Property P894 lässt sich damit zwar das gesamte Gefüge wiedergeben und bei guter Skriptkenntnis beliebig gebündelt abfragen, im Umgang mit den einzelnen Begriffen bleibt das jedoch unbefriedigend. Die Aussagen zu jedem Begriff liegen jeweils in den unsichtbaren Knoten über ihm. Zwei Möglichkeiten bestehen, um die Aussagen einzeln zudem auch noch auf die Begriffsebene zu legen: Man kann für jede Ebene der Granularität eine eigene Property aufmachen, oder eine Summarische Sprechakt-Property aufmachen und auf dieser die Eigenschaften einzeln notieren. Ich spielte beide Lösungen durch und entschied mich im Verlauf mit nur einer Sammel-Property zu arbeiten – der Property P912: Sprechaktqualitäten. Es geht bei dieser Lösung nichts verloren, da wir auch auf den jeweiligen Aussagen vermerken können, auf welcher Betrachtungsebene sie gemacht sind und damit dieselben statistischen Auswertungen für jede Betrachtungsebene durchführen können. Die Sammlung der Eigenschaften unter der einen Property P912 ist vorteilhaft, da Nutzer nur bei Abfragen nicht vorab wissen müssen, auf welcher Ebene sich die jeweilige Eigenschaft bewegt. Man sucht nach Texten mit der Eigenschaft unter einer einzigen Property und erhält mehr oder weniger große Bündelungen.

Hier die statistischen Abfragen des gesamten Corpus, wie es Rolf erfasste, auf den einzelnen Eigenschaftsebenen:

  1. Zweckbestimmung
  2. Generelle Zweckanstrebungsweise
  3. Spezielle Zweckanstrebungsweise
  4. Vorbereitende Bedingung
  5. Erfülltheit der Aufrichtigkeitsbedingung

Im beratenden Gespräch spielte Eckard Rolf die Antworten am Beispiel des „Lippenbekenntnisses“ durch, wobei er unversehens mit der „Erfülltheit der Aufrichtigkeitsbedingung des Sprechakts“ eine neue Ebene der Eigenschaften aufmachte, die in seinem Buch so nicht vorkam. Frage der Aufrichtigkeit ist interessant, da sie sich nicht im Stammbaum unterordnet und quer durch das Gefüge der Begriffe greift. Bei Textsorten wie der „Sonntagsrede“ sollte sie wieder aufkommen. Ich machte indes keine Begriffe auf und versuchte keine Zuordnung der P912-Property – Sprachwissenschaftler sollten hier nachdenken und eigene Begriffe und Erwägungen spielen lassen.

Die obigen Suchen sind gleichzeitig Musterabfragen, mit denen sich beliebige Corpora statistisch zergliedern lassen. Im Internet findet sich ein einzelner Anwendungsfall des Rolfschen Vokabulars mit der Statistik, die Stefan Rabanus in seiner Staatsexamens-Arbeit Die Sprache der Internet-Kommunikation, Mainz, Gardez! Verlag, Mai 1996 durchexerzierte. Hier ist besonders Node 37) nit der Auswertung interessant. Die FactGrid-Erfassung macht solche Auswertungen in Zukunft einfacher.

Genauso gut lassen sich unter der einheitlichen P912 Property nun einzelne Aussagen herausgreifen. Die folgende Mustersuche erfasst so etwa „bindende“ Textsorten. Wenn man unter dem i-Symbol den Query Helper öffnet, kann man diese Eigenschaft gegen jede andere aus der Liste aller Eigenschaften austauschen:

Das sich öffnende Projekt

Die in Eckard Rolfs Publikation 1993 ursprünglich genannten 2056 Textsorten sind über die Quellenvermerke notiert und abfragbar. Das erlaubt es, neue Begriffe wie den „PodCast“ wie das „Quibus Licet“ (Q10508), das Illuminaten monatlich bei den Ordensoberen einreichen mussten in das Gefüge aufzunehmen ohne die Ursprungskonfiguration dabei unsichtbar werden zu lassen – man kann das größere FactGrid-Corpus abfragen wie Rolfs ursprüngliches. Aus der abgeschlossenen Buchpublikation von 1993 wird damit ein beliebig erweiterbares Gefüge.

In eine zweite Richtung musste das Projekt im FactGrid umgehend geöffnet werden: Die Datenbank ist auf Übersetzungen aller Termini angewiesen; englische Label sind dabei unabdingbar, um in den Sprachen, die noch nicht bedient werden. Die Übersetzungen sind im Moment noch sehr provisorisch.

Google scheiterte großflächig an den Nuancen der Rolfschen Liste. Bei 230 im Deutschen unterschiedlichen Begriffen kam es auf der englischen Seite zu Konvergenzen. „Rat“ und „Ratschlag“ wurden „Advice“; „Unglücksbotschaft“, „Unglücknachricht“ und „Schreckensnachricht“ wurden erst einmal nur „bad news“. Mitunter wissen wir im Deutschen, wann ein bestimmter Begriff angemessen ist: „Jagdkarte“ ist österreichisch, und „Jagdschein“ deutsch. „Schwur“ und „Eid“ überschneiden sich im Deutschen, doch zeigen „Amtseid“ und „Racheschwur“ Grenzen der Austauschbarkeit: der Schwur ist eher ein emphatisches Versprechen, der Eid formeller. Wenn eine andere Sprache nicht genauso differenziert – im Englischen gibt es nur den „oath“, ob als „oath of revenge“ oder als „oath of office“ – dann erhalten deren Nutzer zwei Items „oath“, zwischen denen sie sich nicht entscheiden können, nur weil auf deutscher Seite hier Unterschiedliches steht. In diesen Fällen ist es eigentlich ratsam, nur ein Item zu bespielen und auf diesem für jede Sprache ins Detail zu gehen und Worte zu listen, die dies meinen, samt qualifizierenden „Nutzungshinweisen“ auf der Property P598. Worte gehen bei solchen Zusammenlegungen nicht verloren, sie erhalten nur einen präziseren Platz als Optionen, die Sprachen unterschiedlich zur Verfügung stellen.

Was zu tun bleibt

Kontrollierte Vokabulare auf einer Wikibase-Instanz anzubieten, dürfte praktisch sein: In der Graph-Datenbank lassen sich Vokabulare im Plural verwalten und komplikationslos auf dieselben Begriffe legen. Wir können im selben Moment sagen, wie sich diese Vokabulare zueinander verhalten, wo sie deckungsgleich sind, wo sie eigene Vernetzungen auftun, und können so zwischen Vokabularen mühelos vermitteln. Man kann im selben Moment externe Datenbanken, die sich eines bestimmten Vokabulars bedienen, egal in welcher Sprache sie das tun, mit dem eigenen Lieblingsvokabular verstehen.

Das vorliegende Vokabular birgt im Moment als deutlich deutsches Produkt mit sehr feiner Nuancierung in der globalen Nutzung Desiderate:

  • Die Property-Label und Beschreibungen sollten noch einmal übersehen werden. Dies sind alle aktuell bestehenden Eigenschaften von Gebrauchstextsorten.
  • Die Übersetzungen müssen noch vollständig überprüft werden.
  • In der gesamten Begriffs-Liste sollten Zusammenziehungen auf „das jeweils Gemeinte“ erwogen werden. Verschiedene Worte für mehr oder minder dasselbe, legt man dabei zum einen auf die Alias Position (das geschieht beim “Merging” automatisch, danach landet man beim Eintippen der beliebigen Alternative auf dem zentral gesetzten Begriff), zum andern kann man die Varianten danach an Ort und Stelle mit „Nutzungshinweisen“ ausstatten. Es ist dies der Weg, der das Instrumentarium mehrsprachig eindeutig macht.
  • Das gesamte Vokabular ist derzeit nur im Ansatz mit Wikidata abgeglichen und kaum mit GND-Nummern ausgestattet. Auch hier ist im Moment noch nachzufassen.

Publiziert im Rahmen des der NFDI4Memory Task Area “Data Connectivity”, Historisches Datenzentrum Halle, Projektnummer 501609550.

Posted on

FactGrid Goes NFDI

Friday week before last, we received the news that so many working groups had been eagerly awaiting: the 4Memory consortium (of historical studies) will become part of the Nationale Forschungsdateninfrastruktur (NFDI), the German National Research Data infrastructure.

This is exciting news for FactGrid, just weeks before its fifth birthday. We will be acting as an official repository for historical data in the upcoming NFDI structure. German projects can now make a good case that FactGrid is the optimal platform for their data.

NFDI4Memory task areas

Changing the rules of our present research data management

The German National Research Data Infrastructure aims to bring transparency and sustainability to all research fields, from microbiology to computational linguistics. Whether researchers are still collecting data entirely for themselves in private Word documents and Excel spreadsheets, or whether they are working on digital platforms that are more or less designed like conventional books, designed to be read and looked at – they will face new questions in their research grant applications: Do they produce data? Do they correct publicly available data? If so, the new questions will be: How do they make sure that others can actually work with their data? The idea that new information ends in footnotes of books and articles will not convince the funding institutions any longer. A CSV or JSON data file located on a library server will not do either. Linked Open Data is the only data that is easily reusable – that is what Wikidata has made clear. New platforms are therefore needed – platforms approved by the National Research Data Infrastructure.

The DFG that pushed the process has acted wisely. The different research disciplines had to determine how they would respond to its call for action. They had to create or join umbrella organisations in order to submit proposals for further funding. NFDI4Culture was one of the first groups in the German humanities to receive funding; Text+, for all textual studies, was also among the first arrivals, in 2021. The historical studies collective founded the 4Memory consortium and received the green light in the second round on Friday 4th. Funding will start in March 2023. The Gotha Research Center the 4Memory “participant” on behalf of the FactGrid community in this process.

An international resource as part of a national infrastructure?

It took us a while to feel comfortable with the invitation to participate in this process – back in 2020. At that time we had created a little more than 100,000 items with a handful of participants. Wikimedia Germany was our natural partner. The German National Library was the first major player to collaborate with us in a joint exploration of the Wikibase software. FactGrid from the beginning had invited international collaboration, with projects from France, the United States, Spain, Hungary, and Switzerland. Could we risk a nationalisation of the platform?

The project partners on FactGrid were open to the idea: It would benefit everyone to take the step. The process would open doors to important discussions. We could discuss data standards used worldwide and be able to think of international alliances on this new stage.

Our asset? – Wikibase

Following the NFDI debates,we soon understood why we had been asked to join: We were using Wikibase, the software platform that all members of the nascent consortia were discussing behind the scenes as the very software that could build the bridges between the working groups.

  • Wikibase invites cooperation. Its data modelling is uniquely flexible.
  • Versioning of all editing processes enjoys unprecedented transparency.
  • Wikidata demonstrates that seemingly incompatible fields of knowledge can be managed together in a single graph database.
  • Getting data from a Wikibase platform is as easy as it is to put data into it.
  • Wikibase instances can be federated – we can diversify the scenery without using one single Wikibase instance.

FactGrid was ahead of its time. We were running a functional Wikibase platform while other groups were simply proposing to evaluate the option.

And yet still at the beginning

Over the last two years we have more than quadrupled to 457,000 items. FactGrid is doubling almost every year and there is no reason to believe that this will change in the near future. Projects that are presently preparing data uploads are in the scope of the entire current platform; with our upcoming projects we remain on a global trajectory – we are becoming more international, the platform is learning new languages.

The NFDI process comes just in time because, despite all that growth, we are still right at the beginning, and in urgent need of technological development, which is where we put the focus in our 2020 and 2021 grant proposals. We are not alone in this situation. Wikidata, our elder sister, is still in its initial phase – a peculiar statement, given the fact that Wikidata is celebrating its 10th birthday these days with more than 100 million database objects.

Wikidata is massive. It has rocked the library world as a revolutionary development, but despite that it is still an unknown giant hiding somewhere behind the Wikipedia curtain. Nobody has ever spoken of the data-technical Pentecost miracle which Wikidata actually is. The very name of the project has remained hidden: “Wikidata – you mean Wikipedia, don’t you?”

It is understandable that Wikidata has remained a virtually unknown child. There is neither a search tool leading a wider public to Wikidata information nor is this information readable once you have reached it. The SPARQL query service is a nightmare for normal users. Even if you know how to read computer code– which most of us do not–, how do you find out what information the database can supply? Right, by asking your first specific question with knowledge of the content (the very knowledge that you still do not have). One day an internet-savvy user contacted us with the note that our Query Service had crashed. The Query Service seemed fine; I suggested a video call to get an idea of what the man was seeing on his screen – and it turned out that he was looking at the regular search script. “Send it off, press that blue button!” – He did and received the requested data set. “Ah, I had seen this code stuff but thought it was an error message…”

Wikibase needs two enhancements: An attractive search interface as simple as the Google search box (though with an additional advanced search engine and a SPARQL-search option on top) and browsing software that generates information from the Wikibase or, better still, from several combined Wikibases. The present Wikibase query engine leads you right to the item-pages in the default Wikibase presentation mode, where you can then manually correct or amplify information, but no one seriously enjoys the reading experience. Magnus Manske’s Reasonator, Markus Krötzsch’s SQID, Michael Ringgaard’s KnolBrowser, and Bruno Belhoste’s FactGrid Viewer have shown how Wikibase information can be presented: in pages that present their information concise, well structured, fast to access and easy to exploit. So far, however, all four browsers have remained patchwork solutions. They do not amalgamate platform information in greater depth, and (this is the larger issue) they are as yet not coupled to intelligent search engines. The problem is that we have not yet arrived at independent new resources, at resources whose pages are Google landing points, with pages that amalgamate information from various Wikibases such as Wikidata and FactGrid, and that keep their users on the platform – providing in depth information on request, generating visualisations on the spot, offering downloads of information which users have been accumulating on their tour.

We will get multilingual and attractive Wikibase aggregates. They will integrate information from various resources and they will offer this information in any language requested, identical across all the cultural and political divides. The German NFDI will have to create prototypes of such instruments if they should actually federate Wikibases in a new broader research oriented structure, even if that should start as a national structure.

Opportunities and risks

“The General Intelligence Machine.” Art by H. Lanos for “When the Sleeper Wakes” by H. G. Wells (1899), Wikimedia Commons

The time for a broader research data infrastructure is ripe. Researchers are still handling “their” data on personal hard discs; they copy and paste dates from Wikipedia pages when they could have complete data sets ready to download. Data correction remains fortuitous. Do you write an email to the producers of an online catalogue which you have been accessing with the request to correct a mistake? Do you give the correct date in a footnote of your next article and expect librarians (and Wikipedians) to take note of your work? – We need online resources that allow researchers to correct mistakes right on the screen, in real time; and these resources should be the same ones, which users employ to organise their research. Wikibase is the software that can help to make this possible. How will we get there? Wikibases will have to become the go-to scholarly resources to consult; that is when they will turn into the workbench for the very projects that are using their data.

The landscape of NFDI-consortia comes with its own internal risks. We will need resources to do highly specialised jobs: resources to store and mine texts, resources for the machine readable information which we need in order to make 3D reproductions of objects, and we need resources for historical statements. FactGrid is focusing on this latter need. It cannot become the all-in-one service for historical research. We need the services of other consortia and we should offer our particular services to the other consortia wherever they handle historical statements.

The much more delicate risk of fragmentation looms on the international stage: Will the German expert on French history find herself asked to store her data on a German platform since her funding is German – while her French colleagues with whom she shares the research objects will be delivering their data into a French database? We could, of course, harvest information from 150 national research data infrastructures but that will not provide the same experience for those who generate the information. Working on FactGrid you are about to notice when a colleague in France or China adds to your data. You will contact the colleague with a note of delight about the archival sources that had escaped your notice. Wikibases are joint platforms and should be used as such.

The question of a plurality of national research data infrastructures becomes even more thorny as soon as we look beyond the privileged horizon. We need global platforms to provide equal access to research and to the debates surrounding research. Wikimedia has created Wikidata with the explicit aim of having a software compound on which users from all over the world can work together – accessing and expanding the same pool of global information. We, the international scientific community, the heirs of the international respublica litteraria, shouldn’t fall behind the Wikimedia project.

The fact that FactGrid, an explicitly internationally oriented resource, has entered the NFDI4Memory structure is an interesting development – a chance to get more than one National Research Infrastructure on board.

Links

Header image source: Robert Charles Dudley (British, 1826–1909) Interior of One of the Tanks on Board the Great Eastern: The [Transatlantic Cable] Cable Passing Out 1865/66, Watercolor over graphite with touches of gouache (bodycolor) https://www.metmuseum.org/art/collection/search/383834

Posted on

Imagine a Graph Query Helper for Graph Databases

[Link für Deutsche Übersetzung]

FactGrid is a graph database. If you run searches in such a database you should rather not think of a resource filled with interrelated tables (of people, places, organizations, documents…) – but of something more spatial, more geometric, more graphic.

Think of your own knowledge. You will not be able to give a table of all the names that have a meaning in your knowledge, or of all the places related to these names. Our knowledge is more like a web of interrelated objects. Nicolaus Copernicus? He is the man who wrote De revolutionibus. What else do you know? Maybe that he was born in Thorn, Polish Toruń, and that he studied at the Universities of Padua and Bolognia. I at least do not immediately know much more about the author who brought about the “Copernican Revolution”. That, of course, is an object that rings many more bells, with all the connections to other items of knowledge it has in my knowledge. I can add that these two universities were good places to study those subjects that were to become the natural sciences – but that again is knowledge on these objects, not on Copernicus, knowldge that got stuck in my knowledge as it added some more colour to my knowledge about Copernicus, the person. Think of interrelated objects hanging together in the wider mesh of your knowledge – of objects that link to each other like atoms in a molecule.

…an object with links to two other objects? That could be someone linked to her two parents. The graph would not look different if that was another person with his two daughters, or Copernicus with links to the two universities mentioned. Well, Copernicus studied at four universities, to be precise – but that is not the problem.

The problem is that the molecular model does not carry particularly well as it puts all the differences into the atoms, hence the various colours in images and the different connectivities of atoms in the typical three dimensional tool kits. In a database like FactGrid all the objects are structurally completely identical. They all are just “Items”: meaningless points, “nodes”, under Q-numbers counted up from 1 to infinity. The various and very specific Properties between the objects make all the differences in a graph database: “Fathers” are in FactGrid Items that have P141 “father” properties referring to them; mothers have P142 Properties linking from other items towards them.

In a triple-based database (which breaks down all knowledge into three-part statements) we will need no more than two sorts of components: You can take spheres for the objects of our knowledge, the “Items”, and arrows for the links that run between them – arrows as we have to express directions in the various statements.

Those who studied at the University of Jena have P160 “educating institution” statements leading from their Items to the University of Jena Item Q21880. This is the SPARQL script (see this link to see what it does):

SELECT ?Item ?ItemLabel WHERE {
   SERVICE wikibase:label { bd:serviceParam wikibase:language “[AUTO_LANGUAGE],en”. }
   ?Item wdt:P160 wd:Q21880.}


SPARQL is a wonderfully versatile language to send searches through graph databases but it is impossible to script even this most simple query without handbook knowledge. What is worse: You will need additional knowledge of our database to know that Jena’s University has this the Q-number Q21880 and that students must have P160 statements on them that will link to this University with the Q21880 indetifier.

The Wikimedia Query Helper is the coolest gadget as soon as you understand what a “Filter” can do for you in your query. Once you realise that this is the input field that will need the university in your specific query you can start to type “Univ…” and the autocomplete will lead you to the Q-number you are looking for. Select the Item you are interested in and the tool will already propose the “who studied here?” Property P160 as this is the most used Property leading to Q21880. It is fair to assume you are looking for people who studied at this university.

You can now ask for more information about these students as far as they are found on their Items, such as the dates of birth and death with both places in separate columns, and the names of their fathers and mothers. This is a search that uses the Query Helper:


And this is where the present Query Helper will leave you. The coordinate locations of the places of birth are on their respective Items (not on the student Items which you have been exploring so far). You need these coordinates to get a map representation, but the Query Helper does not show you how to extend your search into the related objects, nor does it show you how to bring qualifiers into your list (like the matriculation begin and end dates stated with many of the P160 links). It is also difficult to switch to reverse questions. You already know the person and now you want to know more about him, while you are still asked to use a filter…

One should have a graphic – a visual – query editor on a graph database

This is what the open question looks like: Who studied where? I put numbers in the circles to designate table columns.

If you are only interested in Jena University students, you should be able to specify that right on the university’s Item. Click into its sphere and type “University of Jena” into the circle:

You can now expand the query as you wish with clicks into the objects or the arrows, for example by asking for the “fathers” (P141) of these sutudents, who will appear in column 3 (this script):

And it will now be easy to get more information from the fathers – like which schools and universities did the fathers attend, again P160 (script link)?

One could also formulate the short-circuit question to get all the students who studied in Jena just as their fathers had done before:

I gave the arrows in different colours because they are the components that make all the difference in objects. You want to spot identical questions and similar objects in your searches.

Optional / Mandatory

Perhaps a simple exclamation mark on the Property arrows would be enough to mark statements that shall work as filters.

Qualifiers

Qualifying statements are a bright Wikibase invention. Any primary triple can become the object of specific, qualifying statements. That is basically the relative clause we need in such a language (for instance if we have a person who studied at four universities and we want to say from when to when on each case). If we want to keep the graphic repertoire lean, we could simply link the qualifying statements to the Properties – for example, to get two separate columns for the begin and end dates of a specific university matriculation:

Opening the toolbox

The toolbox had been open in these various searches. I used it so far to state where a specific Item had a specific value attached to it. We would use this toolbox for all the more complex visualisations. Imagine you want to get the religious backgrounds of all known Illuminati in a bubble chart. Ask for the Items that have a P91 membership statement connected to the Illuminati, Q10677. Then ask for their religious backgrounds. If you want a bubble chart you need a count of hits on each religion and denomination:

The toolbox should also be the place to create time frames. You could here specify ranges on data you have requested.

Just a thought…

A Postscript on how to use the right and left mouse buttons in the query builder

Visual scripting might be actually quite easy. With the left mouse button you create your first circle. It will come with a question mark in it.

Click into this circle with the left mouse button, and you can put a value into this circle, a label; it will replace the question mark.

Use your right hand mouse button to get a visual context menu from his point. It will come in the form of grey options to select. Two arrows are leading away from your Item, two are leading towards it. Each time you get an open offer with question marks to replace (or to leave there) and two specific arrows that will give you ideas of what is happening here:

With the left mouse button you can select the direction into which you want to move, the selected arrow and circle will switch to colour, the other three arrows will disappear. You are now free to continue with a click into the next Item or Property of your interest. Just as in the current Query Helper, you will always get a preview of 20 table rows, that will give you an idea of the results you are about to get on your search.

Seen only later…

Posted on

Einblicke in das interne Berichtswesen des Illuminaten-Ordens. Aus der Hand Hermann Schüttlers: 71 Dokumente der Jahre 1781 bis 1785

Die folgende Materialpräsentation ist das Ergebnis eines zweimonatigen Praktikums im Forschungszentrum Gotha. Mein Projekt war es, der Forschung Vorarbeiten zu einem unvollendet gebliebenen Buchprojekt Hermann Schüttlers datenbankgestützt auf den FactGrid-Seiten zugänglich zu machen. Es handelte sich hierbei um Transkriptionen von 71 Dokumenten aus dem inneren Machtzirkel des Illuminatenordens der Jahre 1781 bis 1785. Im Gegensatz zu den von Hermann Schüttler und Reinhard Markner zuvor bereits vorgelegten Bänden der Illuminatenkorrespondenz steht hier das interne Berichtswesen des Ordens im Zentrum. Das Corpus birgt:

  • 12 für den Orden verfasste (Auto-)biographien,
  • 26 Inspektionsberichte,
  • 29 Sitzungsprotokolle der bisher wenig bekannten “zweiten” Minervalkirche Frankfurts; zu ihnen kommen drei Protokolle der Gothaer Minervalkirche und eines aus Weimar.

Es galt dabei erstens, die unterschiedlich umfangreich verfußnoteten Transkripte im Gesamtumfang von bislang 237 Seiten von ihren Word-Dateien in Wiki-Seiten des FactGrid zu überführen, sie dabei mit kurzen Einleitungen zu versehen und die Fußnotung an die Datenbank anzukoppeln oder in einem Großteil der Dokumente erst durch eigene Recherche zu erstellen – bei den Inspektionsberichten kamen im Extremfall über 200 Fußnoten im Einzeldokument in den Blick. Zu allen Dokumenten waren im zweiten Schritt Datenbankobjekte anzulegen, die die Transkripte grundlegend erschließen und Datenbankrecherchen zugänglich machen. Zentral war hier die Erfassung von Autor, Entstehungsort und -datum; erwähnten Personen, Orten und Themen. Zu den Protokollen von Sitzungen wurden zudem Ereignis-Datenbankobjekte angelegt, an die sich nun eigene Fragen, etwa zu Nachweisen persönlicher Begegnungen von Sitzungsteilnehmenden, stellen lassen.

Nachfolgend:

  1. Einige erste inhaltliche Ausführungen zu den hiermit zugänglich gemachten Dokumenten
  2. Einige Bemerkungen zur technischen Realisation und zu Problemstellen der Datenbanksoftware, die hier zur Nutzung kommt
  3. Alle Dokumente, Transkripte und Ereignis-Datensätze dieses Projektes chronologisch sortiert

Wissensakkumulation in der Phase des rasant wachsenden Geheimordens

In die erste Phase des Illuminatenordens – die Phase des primär bayerischen Ordens unter der unmittelbaren Führung Adam Weishaupts – gaben 1787 die Aktenveröffentlichungen des Bayerischen Staates Einblick, die den Orden noch im Sommer 1787 im Raum der deutschen und österreichischen Territorien kollabieren ließen. Über die Spätphase des Ordens, in der unter Johann Joachim Christoph Bode Thüringen zum neuen Zentrum wurde, sind wir auf der anderen Seite aus den Dokumenten der Schwedenkiste informiert.

Die Dokumente, die Hermann Schüttler vorliegend transkribierte, stammen vor allem aus dem Nachlass Adam Weishaupts und dem Sonderarchiv Moskau. Einige Dokumente der Schwedenkiste kamen hinzu. Zusammen geben sie einen Einblick in die turbulente Zwischenphase, in der Adolph Freiherr von Knigge für das große Wachstum des Ordens sorgte. Berichterstatter sind dabei unter anderem Johann Martin Graf zu Stolberg-Roßla, Franz Dietrich Freiherr von Ditfurth und am häufigsten Knigge selbst. Gemeinsam präsentieren sie ein multiperspektivisches Bild der mit dem Wachstum kommenden Anforderung, Überblick zu wahren. Noch in diesen Versuchen wird klarer, dass es keine gemeinsame Ordenspolitik mehr gibt und kaum noch eine Chance, intern abzustimmen, wer in diesen Orden aufgenommen wird und Karriere macht. Zerreißproben tun sich mit Einzelfällen auf, über die es zum Streit kommen würde, wenn alle Informationen im Orden öffentlich würden; der Konflikt des Ordens mit Knigge erweist sich dabei als mehr denn ein Konflikt zwischen diesem und Weishaupt, dem Ordensinitiator.

Exemplarische Selbstauskünfte

Alle neuen Mitglieder mussten eine Verschwiegenheitserklärung unterzeichnen: das Revers. Sie beantworteten Fragen zu ihren Erwartungen an die unbekannte Organisation, die sich ihnen damit inmitten der Freimaurerei auftat und waren aufgefordert, autobiographische Selbstauskünfte einzureichen. Zwölf dieser Selbstauskünfte umfasst die Textauswahl. Es handelt sich hierbei überwiegend um kurze Lebensläufe und um einem Frageraster folgende Reflexionen über verschiedene Aspekte der eigenen Person vom physischen Zustand bis zum politischen und moralischen Charakter. Hinzu kamen standardisierte Fragen, beispielsweise für die Aufnahme ins Schottische Noviziat, die in Stichworten beantwortet wurden. Häufig wählten die Verfasser jedoch eine freiere Form und schilderten in Fließtexten mit unterschiedlichen inhaltlichen Schwerpunkten ihre wichtigsten Lebensstationen und zwischenmenschlichen Beziehungen.

In einem offenkundigen Zusammenhang zu den übrigen Dokumenten dieser Materialsammlung stehen die (auto-)biographischen Einlassungen Q175807 und Q175808 zu Christian Gottlob Neefe. Neefe war im hier dokumentierten Zeitraum als Gast der “zweiten” Minervalkirche Edessas/Frankfurts aktiv. Bei den Teilnehmenden aus den drei Sitzungsprotokollen in Gotha gibt es weitere Überschneidungen mit fünf der autobiographischen Texte. Zwei Autobiographien stammen von Mitgliedern aus Neuwied, die dortige Minervalkirche taucht häufig als einflussreiches Zentrum in den Inspektionsberichten auf. Bodes autobiographische Selbstauskunft rundet die Auswahl ab – der zukünftig zentrale Akteur des Ordens ist hier mit im Geflecht der Selbstaussagen vertreten.

Besonders gewinnbringend war die Bearbeitung der autobiographischen Texte im Hinblick auf die Details, die sich aus ihnen für die bestehenden Datensätze ziehen ließen. So konnten bei jeder der Personen Aussagen zu Aufenthalten, Berufen und ähnlichem ergänzt werden. Noch spannender waren ihre Informationen für die Verdichtung von Netzwerken. Durch die Erwähnung von Verwandten, Freunden, Arbeitgebern und anderen Personen, die die eigene Entwicklung prägend tangierten, konnten viele neue Personen angelegt und in Relation zu bereits bestehenden Items gesetzt werden.

Inspektionsberichte: Wie der Orden versuchte, Überblick in der Informationsflut zu gewinnen

Extensive Quellen sind im Set die fünf Inspektionsberichte Stolberg-Roßlas. In ihnen fließen Informationen aus den Minervalkirchen geordnet nach den Provinzen, ihren Präfekturen und deren Minervalkirchen zusammen in einer Berichterstattung, die bis zu den einzelnen Mitgliedern an den verschiedenen Orten hinab reicht.

Dabei steht als größtes strategisches Problem im Raum, dass im Moment mehr Orte auf der illuminatischen Landkarte der geheimen Ordensgeographie als an diesen Orten bereits arbeitende Minervalkirchen zu finden sind.

Alle 92 Orte, die einen Illuminatenordensnamen erhielten [FactGrid Datenbankabfrage]

Der Aufbau der Minervalkirchen verlief über Mitglieder einzelner Logen, die unmittelbar zu hochrangigen Illuminaten “ihrer” Orte wurden. Von ihnen wurde erwartet, dass sie aus ihren Logen die Mitglieder für die lokalen Minervalkirchen gewinnen. Unter den Mitgliedern machten Studenten eine große Gruppe aus. Zu den flächendeckenden Rekrutierungen kamen die individuellen Vorschläge, die alle Ordensmitglieder machen konnten und über die auf höherer Ordensebene konsistent entschieden werden sollte. Aus den Dokumenten sprechen Konflikte zwischen Beteiligten, die von der Aufnahme anderer erfuhren, mit denen sie keineswegs im selben Orden sein wollten. Gleichzeitig wird sichtbar, dass die Verantwortlichen hier längst in einem Spannungsfeld persönlicher Befindlichkeiten und Verbindlichkeiten agierten, in dem sie im Ernstfall nur noch darauf hoffen konnten, dass Konflikte im Raum des Geheimordens nicht vor der inneren Öffentlichkeit sichtbar werden. Knigge berichtet am 26. September 1782 in diesem Gewirr von Aufnahmen, für die er grünes Licht gab, obwohl er ihr Konfliktpotential absehen konnte:

Mein Plan war, den Epictet nach und nach zu stimmen, und jedem in der Provinz eine Laufbahn zu eröffnen, welche sich nicht kreutzen könnte. Den Hrn. W[und] zu gewinnen, war um so nöthiger, da die neue Freymäurerey die Direction der VIII. Provinz nach Heidelberg verlegt, und ihm die Direction gegeben hat. Ich verlangte als erste Probe der Treue, daß er unsre Leute in der Pfalz mit zu der Sache ziehen sollte … [Tanskript]

Deutlich zeigt sich an dieser Stelle ein nicht mehr zu lösender Widerspruch zwischen der Zentralisierung des Informationsflusses und der Freiheit, mit der die mittlere Führungsebene agieren musste und auch agierte.

Das Berichtswesen, das mit den Dokumenten sichtbar wird, erweist sich als ausgefeilt und modern:

Aus den Minervalkirchen trafen zu allen Personen monatliche Zeugnisse ein. Im Orden wurde, um hier den Überblick zu behalten, ein standardisierter Strichcode eingeführt, mit Hilfe dessen man auf einen Blick zu erfassen hoffte, wo sich besonders interessante Personen sammelten. Aus den Inspektionsberichten schimmert jedoch durch, dass man hier eher erfasste, wo Verantwortliche auf der mittleren Ebene ihre eigene Arbeit in ein besonders gutes Licht zu stellen suchten.

Die Transkripte der Inspektionsberichte geben diese Strichcodes für Hunderte von Personen wieder. Greifbar wird im selben Moment der erhebliche Arbeitsaufwand, den dieses Berichtswesen auch in dieser Kondensierung noch bereitete. Die höhere Hierarchieebene musste Protokolle zusammenführen und Korrespondenzen in alle entstehenden und agierenden Filialen unterhalten. Knigge konnte man hier die Überlastung im Wachstum des Ordens anmerken:

Noch einmal wiederhole ich, was ich nicht genug wiederholen kann: wenn wir|
a.) Das ganze System ausgearbeitet haben,
b.) Wenn jede Provinz ihren Provinzial hat,
c.) Wenn über 3 Provinzen ein Inspector gesetzt ist,
d.) Wenn wir in Rom unsere National-Direction haben:
e.) Wenn mit diesen allen die Areopagiten nichts zu thun haben, sondern im Verborgenen das Ruder führen, folglich nicht entdeckt werden können, nicht so sehr mit verdrüßlichen Details überhäuft sind, sondern das System überschauen, verfeinern, in andere Lander ausbreiten, zur rechten Zeit der dirigirenden Classe beystehen können: – Dann, und nicht eher richten wir etwas aus. Wir bedärfen also dann keiner so lärmenden Anstalten, müßen jeden Provincial in seine Gränzen zurückweisen. – Fahren wir aber fort so in die Kreuz und Quere zu operiren, so sind wir in 3 Jahren gesprengt. Nun zu meinen Berichte… [Transkript]

Die Protokolle der “zweiten” Frankfurter Minervalkirche und der Konflikt mit Knigge

Die vorgelegten Protokolle aus Frankfurt ermöglichen es, den Konstituierungsprozess einer Minervalkirche exemplarisch nachzuvollziehen und geben einen vertiefteren Einblick in die Geschichte der zwei Minervalkirchen Frankfurts, zwei nacheinander aktiven, verschiedenen Gruppen mit größtenteils denselben Mitgliedern. Die Protokolle der “zweiten” Frankfurter Minervalkirche zeichnen sich dabei in der Anfangsphase durch die Regelmäßigkeit und Ausführlichkeit sowie formelle Konsistenz aus. Wie später in Gotha traf man sich monatlich in der Minervalkirche und, die höheren Mitglieder, im exklusiven Magistrat. Die Treffen lassen sich mit der Datenbank auf einen Zeitstrahl projizieren und dabei bis auf die Wochentage heranzoomen. Die Frankfurter Teilnehmendenlisten zeugen von Kontinuität und erlauben Rückschlüsse auf die Mitgliederstruktur in diesem Zeitraum. Eingehend erfasst sind in den ersten Monaten jeweils Programmpunkte wie die Planung von gemeinsamen Lesungen und inhaltlichen Diskussionen über Grundsätze der Leitlinien des Ordens, die förmliche Initiation der neuen Magistraten auf einer eigens dafür organisierten, ordentlichen Versammlung und die pünktliche Abgabe schriftlicher Ausfertigungen sowie der Austausch der Quibus Licet und Reprochen, die sich sehr ausführlich dokumentiert in den Transkripten zur weiteren Vertiefung nachlesen lassen.

In den Protokollen werden nicht minder interne Konflikte greifbar, wie sie die Aktivität des Ordens immer wieder nachhaltig prägten. Interessant ist dabei der sich noch vor dem Zerwürfnis zwischen Weishaupt und Knigge aufzeigende Konflikt vor Ort: Am 15. Juni 1783 sollte Johann Ludwig Hetzler nach einer Anweisung der Oberen ein Treffen der vormals aktiven Mitglieder der Minervalkirche Edessa initiieren, um diese nach einem großen internen Streit, der schließlich zur Inaktivität der Gruppe führte, wiederzubeleben. Knigges Wirken stand, so lässt sich in Umrissen ersehen, im Zentrum dieses Konflikts. Nach den Aussagen der anwesenden Mitglieder hatte er versucht, heimlich alle Ordensgeschäfte vor Ort unter seine Kontrolle zu bringen und darüber hinaus eine gänzlich neue Minervalkirche unter Ausschluss der bisher Aktiven zu errichten. Die Konstituierung der neuen Minervalkirche wurde daher auch nur unter der Versicherung der Oberen vollzogen, dass Knigge nichts mehr mit der Präfektur zu tun haben werde (Vgl. J.P.C. Müllers Bericht vom 15.6.1783).

Ihr Gegengewicht finden diese Dokumente in der vorliegenden Textauswahl mit den vier von Frankfurt aus verfassten Inspektionsberichten Knigges aus den Jahren 1781 und 1782. Im Juli 1781 berichtet er bereits, dass die meisten Mitglieder der örtlichen Minervalkirche, die beinahe ausnahmslos deckungsgleich mit den Aktiven und der Führungsebene 1783 sind, unbrauchbar für den Orden seien. Einzig lobend hebt er Simon Friedrich Küstner und Johann Friedrich Piehl hervor (Vgl. Knigge, Inspektionsbericht vom 11.7.1781). Während Ersterer später in der “zweiten” Frankfurter Minervalkirche im Amt des Sekretärs aktiv im Magistrat der Gruppe mitwirkt, erklärte Letzterer noch zu Beginn der neu konstituierten Kirche, dass er, ehemaliger Censor und Teil der bisherigen lokalen Führungsriege, künftig nichts mehr mit dem Orden zu tun haben wolle (Vgl. J.P.C. Müllers Bericht vom 23.6.1783).

Im September 1781 schien sich die Lage noch deutlicher zugespitzt zu haben, denn nun verkündete Knigge, dass er wegen einer generellen Nachlässigkeit aller Mitglieder der Minervalkirche diese verlassen habe und keine Quibus Licet mehr von ihnen annehmen werde, bis eine deutliche Besserung eingetreten wäre. Darüber hinaus hoffe er mit der Hilfe Leonhardis und Küstners, bald eine neue Gruppe ohne die anderen bisherigen Mitglieder aufbauen zu können (Vgl. Knigges Inspektionsbericht vom 10.9.1781). Beide sollten zwei Jahre später höhere Ämter in der “zweiten” Minervalkirche innehaben.

In den Berichten Knigges vom Oktober 1781 und August 1782 findet sich kein Wort mehr zu der Minervalkirche in Frankfurt, obwohl er in beiden Fällen noch vor Ort lebte und im Orden für die Provinz zuständig war. Ab Februar 1783 kamen seine Inspektionsberichte aus Heidelberg. An diesen Weggang knüpfen jedoch drei Inspektionsberichte Stolberg-Roßlas ab März 1783 an. Dieser erwähnt explizit in dem ersten Inspektionsbericht vom 5. März 1783 über den vorherigen Monat, dass sich Knigge künftig nicht mehr mit Edessa abgebe (Vgl. Stolberg-Roßlas Inspektionsbericht vom 5.3.1783.

Stolberg-Roßlas Berichte geben weiteren Aufschluss über die Entwicklung vor Ort. Auch er kritisiert die lokale Niederlassung und die aktiven Mitglieder stark und spricht ihnen direkt oder indirekt durch die Einschätzungen Dritter den Wert für den Orden ab. Besonders deutlich wird dies durch Zeilen wie:

Alles lesen wollen, über alles lachen, alles tadeln und doch nichts thun, ist, nach Valerius [i.e. Ditfurth], der Geist der Edesser. [Stolberg-Roßla, Inspektionsbericht vom 27.3.1783]

oder

Das alte Elend! Alles ist confus. […] Alle Bbr. sind gegen einander, fast alle kalt, aufgebracht. Mittelmäßige Leute stehen oben, und andre, die ich aus Briefen als kluge und wohldenkende Männer habe kennen lernen, stehen unten und werden versäumt. Kurz der Geist der Verwirrung herrscht da im höchsten Grade. [Stolberg-Roßla, Inspektionsbericht vom 5.3.1783]

Konkreter werden die Konfliktlinien und die Probleme vor Ort indes nicht benannt, es findet sich nur eine Andeutung Hetzlers, dass in der Gruppe zu viele Reformierte seien, die herrschen wollten und ein vager Verweis auf Schwierigkeiten mit München. Im selben Bericht schreibt Stolberg-Roßla, dass alles so schön angelegt sei, den Orden auf ewig aus dieser Stadt zu verbannen und ergänzt im folgenden Bericht, Ditfurth und er kämen darüber hinaus zu dem Schluss, dass keinem Edesser, insbesondere nicht Hetzler, der Priester- und Regenten-Grad gegeben werden solle. Dem steht entgegen, dass Knigge nach Stolberg-Roßlas Kenntnisstand schon längst für diese um Erlaubnis gebeten hatte (Vgl. Stolberg-Roßlas Inspektionsbericht vom 27.03.1783). Im April 1783 berichtet Stolberg-Roßla weiter, dass Johann Leopold Bleibtreu, wie schon im März angekündigt, nun vor Ort sei und sein Möglichstes versuche, Ordnung zu schaffen (Vgl. Stolberg-Roßla, Inspektionsbericht vom 18.4.1783).

Berichte zum Konvent von Wilhelmsbad

Eine Gelenkfunktion gewinnen im hier vorgelegten Materialcorpus die Berichte rund um den Konvent von Wilhelmsbad bei Hanau im Sommer 1782. Für die kontinentaleuropäische Hochgradfreimaurerei wurde der mehrwöchige Kongress zur inneren Zerreißprobe, die die Strikte Observanz – gestützt auf nicht länger haltbaren Behauptungen von Wurzeln im Templerorden der Kreuzzugszeit, war sie das große Hochgradsystem der letzten beiden Jahrzehnte gewesen – nicht überleben sollte. Um das Geschichtsangebot, welches die Ursache des Streits war, ging es dabei nur zum Teil. Die Darlegungen drehen sich um Betrüger in der Freimaurerei, um Schwärmerei und damit um bislang in den Konfessionen ausgetragene Konflikte. All dies überlagert von persönlichen Befindlichkeiten zwischen hochrangigen Teilnehmern, die sich gegenseitig nicht angemessen respektiert sahen und mitten im Zusammenbruch der Strikten Observanz um den Zuschnitt zukünftiger Provinzen rangen.

Im ausgewählten Materialkomplex stehen hier Knigges Beobachtungen unmittelbar neben denen Franz Dietrich Freiherr von Ditfurths. Beide waren hochrangige Illuminaten, die mit ihren Berichten direkt an Weishaupt rapportierten – und die, wie aus den Dokumenten sichtbar wird, einander mit deutlicher Skepsis beobachteten. Knigge sollte am Rand des Konvents bahnbrechend J.J.C. Bode für den Orden gewinnen, der im Auftrag Ernst II. von Gotha am Konvent teilnahm, und Bode sollte wiederum im Verlauf Ferdinand von Braunschweig und Carl von Hessen-Kassel, die führenden Repräsentanten der Strikten Observanz auf dem Konvent, in den Illuminatenorden bringen und damit den Orden in eine innere Zerreißprobe führen.

In Ditfurths Bericht tauchen all diese Beteiligten auf – nun kritisch von Ditfurth beobachtet, dessen Wirken Knigge kritisch kommentiert. Ditfurths Bericht wird sich so schnell nicht zusammenfassen lassen. Auf 34 Seiten Manuskript wurde hier, ohne sichtbare Gliederung, eine Aneinanderreihung von Augenblickswahrnehmungen und Gesprächsfetzen, die den Autor aufrüttelten, sowie Charakterisierungen der Teilnehmer Weishaupt vorgelegt. Bode erscheint in diesem Gewirr als pragmatischer Politiker, der den ganzen Kongress rettet, als er allen nahelegt, hier erst einmal frei zu sprechen und später für sich zu entscheiden, welchem maurerischen System sie in Zukunft anhängen wollen. Mit Ferdinand von Braunschweig und Carl von Hessen-Kassel gerät Ditfurth in den unter höflichen Repliken verborgenen offenen Konflikt. Knigge als über Dritte informierter Beobachter nimmt Ditfurth inmitten dieser Konflikte als jemanden wahr, der sich öffentlich unmöglich macht.

Für den Illuminatenorden wurde der Konvent ein heimlicher Wendepunkt. In Knigges Bericht für den Januar 1783 wird das spektakulär deutlich. Während Ditfurth sich, so Knigges (mit Vorsicht zu lesende) Darstellung, mit seinem konfrontativen Auftreten erst einmal unmöglich machte, soll doch seltsam verbreitet bekannt gewesen sein, dass es den Orden gab, so bekannt, dass er, Knigge, am Rande von allen möglichen Seiten aus kontaktiert und mit Aufnahmeanträgen überhäuft worden sei:

Mit den Cheffs des Zinnendorfischen Systems nahm ich Gelegenheit, einen Briefwechsel anzufangen, den ich auch noch jetzt fortsetze. Die Emissarien anderer Gesellschaften forschte ich theils durch andere Wege aus, theils hatten sie selbst das Zutrauen zu mir, sich mir zu entdecken, weil sie von mir wußten, daß ich mich nicht aus Eigennutz, sondern aus Eifer für die gute Sache dabey interessiere. Die Deputierten im Wilhelmsbad aber kamen fast alle zu mir, und da sie | (ich weiß nicht woher) Nachricht von der Existenz unsrer Verbindung hatten; so bathen sie mich alle, auch der [Prinz Carl] von H[essen], um die Aufnahme. Nun hielte ich es am beßten gethan, daß ich die Mehrsten einen Revers unterschreiben ließ, ihnen also Stillschweigen auferlegte, aber keinem einzigen von ihnen, während der Convent-Zeit das geringste schriftlich mittheilte. Dieß that ich, und redete nur im allgemeinen mit ihnen. [Transkript]

Wollte Weishaupt seine Organisation eher aus reinem machtpolitischen Kalkül mit der Aura großer Geheimnisse ausgestattet haben, um das gegnerische Lager zu infiltrieren, so wird aus diesem Kalkül unter der Hand ein kaum kontrollierbares Anliegen – der Orden verändert sich mit der rasanten Aufnahmepraxis und droht unregierbar zu werden, nun nachdem er Regenten aufnimmt und ein ganzes, soeben scheiterndes, von “Schwärmerei” durchdrungenes System als Führungsebene importiert.

Die Sitzungsprotokolle aus Gotha und Weimar

Die Sitzungsprotokolle aus Gotha und Weimar tun Schritt in die letzte Phase des Ordens. Knigge hatte Bode für den Orden am Rand des Konvents von Wilhelmsbad gewonnen. Im Herbst 1782 hatte dieser Ernst II. dazu bewegt, sich auf das Experiment Illuminatenorden einzulassen. Gothas Minervalversammlung sollte der Testfall und Zentrum der Ordensarbeit in der neuen Provinz Ionien werden, die Bode binnen zweier Jahre aufbaute, und die nach seinen Planungen von Weimar regiert bis nach Berlin im Norden und Dresden im Osten reichen sollte. Während das Experiment in Gotha und im Verlauf in Erfurt, Rudolstadt und Jena glückte, sollte es in Weimar scheitern, trotz oder vielleicht gerade wegen der berühmten Teilnehmer, die hier mit Goethe und Herder die hohen Ränge der Weimarer Minervalkirche hätten bekleiden sollen. Diese Entwicklungen zeichnen sich in den ausgewählten Protokollen noch nicht ab. Sie geben Einblick in die konkreten ersten Schritte mit denen in Gotha und Weimar Minervalkirchen geplant wurden. Man agierte jeweils aus dem Magistrat von oben herab. Die Gothaer Magistratsberichte werfen dabei ein Licht auf die Infiltration, die der Orden meisterte. Es geht hier en passant um Konflikte zwischen der Gothaer und der Loge Altenburger Freimaurer-Loge. Die Freimaurerei gewinnt eine geheime Dachebene über die der Orden Einblicke erhielt. Das Protokoll vom Dezember 1784 gibt einen Einblick in die Themen der auf den Minervalsitzungen gehaltenen Vorträge und eine kurze Schilderung der Neuaufnahmen. Das Protokoll aus Weimar berichtet von der Sitzung am 17. März 1785, auf der die Verfolgungen Weishaupts, die Gründung einer Filiale in Jena, die studentische Freimaurer aufnehmen solle, und die Konstituierung der eigenen Minervalkirche in Weimar Thema waren. Die hier gegebene Auswahl ist dabei mittlerweile eingeholt von der Erschließung, mit der Markus Meumann, Olaf Simons und Christian Wirkner sämtliche Sitzungsprotokolle des 15. Band der Schwedenkiste auswerteten, um hier die behandelten Aufsätze genauer zu lokalisieren.

Einige Bemerkungen zur technischen Realisation und zu Problemstellen der Datenbanksoftware, die hier zur Nutzung kommt

Die Aktenlage des Illuminatenordens war für mich zu Beginn des Praktikums so neu wie die hier zum Einsatz kommende Technik. Desiderate der Plattform, die nun Zugriff auf die eingebrachten Transkripte und die mit ihnen korrespondierenden Datenbankobjekte erlaubt, sind bereits im Blog, in dem dieser Beitrag erscheint, notiert:

Desiderat 1: Eine Präsentationssoftware, die Transkripte und Objektdaten sichtbar macht

Wikibase verbindet ein konventionelles Media-Wiki, wie es die Wikipedien zum Einsatz bringen, mit einer Wikibase Datenbank. Das FactGrid nutzt beide Bereiche integrativ, das heißt, ich legte für die Transkripte MediaWiki Seiten mit dem aus den Wikipedien bekannten Text Markup an und koppelte diese an Datenbankobjekte, im Konkreten zu den Dokumenten und den nachweisbaren Ereignissen.

Die Koppelung erlaubt es zwar, in der Volltextsuche auf beides, also die Datenbankobjekte zu den Dokumenten und Transkriptseiten, zuzugreifen, aber beide sind lediglich mit wechselseitigen Links aneinander gebunden. Befindet man sich auf einer Textseite, muss man über den Metadaten-Link im Seitenbeginn in den Datensatz hinüberschalten, erst dort stehen die Angaben zu Datum, Autor, Quelle und allen weiteren Informationen.

Was der Software an dieser Stelle fehlt ist eine Präsentationssoftware, die die Informationen aus den Datenbankobjekten geordnet lesbar macht und die dabei in der Lage ist, die Transkripte sichtbar zu machen und auf Wunsch des Lesers zur Gänze einzuspielen.

Desiderat 2: Eine Vorbefüllung der Datenbank, die großflächig Personen zur Verfügung stellt, auf die nun nur noch verlinkt werden muss

Das wohl zeitintensivste Arbeitshemmnis des FactGrid im gegenwärtigen Zustand ist die immer noch zu geringe Anzahl der bereits vorhandenen Datenbankobjekte. Die Dichte bereits vorhandener Personen ist zwar im Projektfeld Illuminatenorden ausgesprochen hoch, doch fehlen im selben Moment kontinuierlich Personen, die hier nur am Rand auftauchen, eigentlich jedoch Schlüsselfiguren der deutschen Geschichte des 18. Jahrhunderts sind. Die Recherche dieser Personen in der GND und Wikidata war in der Regel kein Problem, die Personen mit den hier auffindbaren Daten im FactGrid als aussagekräftige Objekte anzulegen blieb jedoch mühselig und fehleranfällig. Das Problem scheint seit den ersten Editiervorgängen allen in der Datenbank vertraut – das Projekt, die gesamte GND zu importieren, trägt ihm Rechnung, doch bleibt die nützliche breite Datenlage im Moment ein Desiderat.

Desiderat 3: Eine Benutzeroberfläche, die zu guten Datenstrukturen Rat gibt

Wikibase ist konsequent Triple-basiert, theoretisch lassen sich ganz beliebige Aussagen zu ganz beliebigen Objekten formulieren. Tatsächlich lassen sich damit identische Sachverhalte jedoch nicht minder auch ganz unterschiedlich ausdrücken – etwa in sehr definierten Tripeln oder in allgemeineren Tripeln, bei denen man mit Qualifikatoren Kontexte näher bestimmt. Verschiedene Formulierungen von parallelen Aussagen finden sich in der Folge. Zu ihrer Vielzahl kam es offenbar vor allem, weil die Quellenlage mal die eine und mal die andere Variante einer Formulierung nahelegte und von hier aus dann als Muster auf weitere Bearbeiter wirkte.

Dadurch, dass es keine einheitlichen Standards bei der Erstellung von Statements gibt, kam es häufiger zu uneindeutigen oder inhaltlich identischen Aussagen oder Redundanzen, deren Erfassung eine gewisse Zeit im Arbeitsprozess beansprucht. Auch gibt es keine klaren Vorgaben, welche Informationen aus Texten in welcher Form in Triples verwandelt und an anderer Stelle rezipiert werden sollen. Diese freie Gestaltungsmöglichkeit kann gleichzeitig als Vor- und Nachteil betrachtet werden, da die Software der eigenen Arbeit und Weiterentwicklung schon bestehender Arbeit in ihrer sehr offenen Komplexität kaum Grenzen setzt, jedoch im Vergleich zu sehr standardisierter Arbeit deutlich voraussetzungsreicher ist und laufende Seitenblicke auf bestehende Objekte einfordert, um einen passenden Umgang zu finden. Man lernt hier eher eine Sprache möglicher Aussagen, die jederzeit erweitert und präzisiert werden kann, als dass Eingabeschablonen abgearbeitet werden. Das Desiderat könnte an dieser Stelle ein Sowohl-als-auch sein, eine Plattform, die für erste Objekterschließungen Eingabeschablonen gibt, die grundlegend konsistente Datenobjekte in den Basisdaten herstellen, während man bei weiterer Erforschung jederzeit dazu übergehen könnte, Aussagen nach eigenem Interesse und Nutzen bei der Materialdurchdringung frei zu formulieren.

Alle Dokumente, Transkripte und Ereignis-Datensätze dieses Projektes chronologisch sortiert

Datum Dokument Transkript Ereignis
1 1781-02-01 Johann Georg Wendelstadt, Autobiographisches für den Illuminatenorden, Neuwied, 1781-02. Transkript
2 1781-02-20 Amand Philipp Ernst von Ebersberg, Autobiographisches für den Illuminatenorden, Mainz, 1781-02-20 Transkript
3 1781-07-01 Christian Carl Kröber, Autobiographisches für den Illuminatenorden, Neuwied, 1781-07 Transkript
4 1781-07-11 Adolph von Knigge, Inspektionsbericht für den Illuminatenorden, Frankfurt am Main, 1781-07-11. Transkript
5 1781-09-10 Adolph von Knigge, Inspektionsbericht für den Illuminatenorden, Frankfurt am Main, 1781-09-10. Transkript
6 1781-10-01 Adolph von Knigge, Inspektionsbericht für den Illuminatenorden, Frankfurt am Main, 1781-10-01. Transkript
7 1781-12-31 Johann Ludwig Carl Graf von Cobenzl, Bericht für die Provinz Franken und Schwaben des Illuminatenordens, Eichstädt, 1781-12-31. Transkript
8 1782-01-01 Johann Leopold Bleibtreu, Autobiographisches für den Illuminatenorden, Neuwied, 1782 Transkript
9 1782-02-01 Otto von Gemmingen, Autobiographisches für den Illuminatenorden, Wien, 1782-02. Transkript
10 1782-02-02 Costanzo Marchese di Costanzo, Inspektionsbericht für den Illuminatenorden, München, 1782-02-02. Transkript
11 1782-07-05 Friedrich Joseph Roth von Schreckenstein, Inspektionsbericht für den Illuminatenorden, Immendingen, 1782-07-05. Transkript
12 1782-08-01 Adolph von Knigge, Inspektionsbericht für den Illuminatenorden, Frankfurt am Main, 1782-08. Transkript
13 1782-08-01 Johann Martin Graf zu Stolberg-Roßla, Autobiographisches für den Illuminatenorden, Neuwied, 1782-08 Transkript
14 1782-08-07 Franz Dietrich Freiherr von Ditfurth, Inspektionsbericht für den Illuminatenorden, Wetzlar 1782-08-07. Transkript
15 1782-08-10 Franz Dietrich Freiherr von Ditfurth, Anhang zu Inspektionsbericht für den Illuminatenorden, Wetzlar, 1782-08-10. Transkript
16 1782-09-26 Adolph von Knigge, Inspektionsbericht für den Illuminatenorden, Heidelberg 1782-09-26. Transkript
17 1782-09-30 Christian Gottlob Neefe, Autobiographisches für den Illuminatenorden, Frankfurt am Main, 1782-09-30 Transkript
18 1782-10-01 Johann Joachim Christoph Bode, Autobiographisches für den Illuminatenorden. Transkript
19 1782-11-24 Georg Ernst von Rüling, Inspektionsbericht für den Illuminatenorden, Hannover, 1782-11-24. Transkript
20 1782-12-11 Johann Benjamin Koppe, Inspektionsbericht für den Illuminatenorden, Göttingen, 1782-12-11. Transkript
21 1782-12-31 Christian Carl Kröber, Provinzialbericht Thessalien (Westfalen) für den Illuminatenorden, Neuwied, 1782-12-31. Transkript
22 1782-12-31 Johann Georg Wendelstadt, Inspektionsbericht für den Illuminatenorden, Neuwied, 1782-12-31. Transkript
23 1783-01-04 Johann Martin Graf zu Stolberg-Roßla, Illuminaten-Inspektionsbericht für den Monat Abenmeh 1152 [November 1782], Neuwied, 1783-01-04. Transkript
24 1783-01-29 Johann Martin Graf zu Stolberg-Roßla, Illuminaten-Inspektionsbericht für den Monat Adarmeh [Dezember 1782] , Neuwied, 1783-01-29. Transkript
25 1783-02-01 Adolph von Knigge, Ordensbefehl, 1783-02. Transkript
26 1783-02-05 Adolph von Knigge, Inspektionsbericht über die Provinz Ionien für den Monat Dimeh 1152 [Januar 1783], Heidelberg, 1783-02-05 Transkript
27 1783-03-07 Johann Martin Graf zu Stolberg-Roßla, Illuminaten-Inspektionsbericht für den Monat Dimeh 1152 [Januar 1783], Neuwied, 1783-03-07. Transkript
28 1783-03-25 Johann Martin Graf zu Stolberg-Roßla, Illuminaten-Inspektionsbericht für den Monat Benmeh [Februar 1783], Neuwied, 1783-03-25. Transkript
29 1783-04-18 Johann Martin Graf zu Stolberg-Roßla, Illuminaten-Inspektionsbericht für den Monat Asphandar [März 1783], Neuwied, 1783-04-18. Transkript
30 1783-06-15 Johann Peter Clemens Müller, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1783-06-15. Transkript Ereignis
31 1783-06-23 Johann Peter Clemens Müller, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1783-06-23. Transkript Ereignis
32 1783-06-26 Johann Peter Clemens Müller, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1783-06-26. Transkript Ereignis
33 1783-06-27 Johann Peter Clemens Müller, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1783-06-27. Transkript Ereignis
34 1783-07-03 Johann Peter Clemens Müller, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1783-07-03. Transkript Ereignis
35 1783-07-24 Christian Heinrich Wehmeyer, Autobiographisches für den Illuminatenorden, Gotha, 1783-07-24 Transkript
36 1783-07-27 Johann Peter Clemens Müller, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1783-07-27. Transkript Ereignis
37 1783-07-30 Johann Peter Clemens Müller, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1783-07-30. Transkript Ereignis
38 1783-07-30 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1783-07-30. Transkript Ereignis
39 1783-08-01 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, Magistratsversammlung, 1783-08-01. Transkript Ereignis
40 1783-08-06 Christian Georg von Helmolt, Curriculum vitae, 1783-08-06 Transkript
41 1783-08-25 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1783-08-25. Transkript Ereignis
42 1783-08-28 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, Magistratsversammlung, 1783-08-28. Transkript Ereignis
43 1783-09-07 Friedrich Christian Rudorf, Bericht: Versammlung der Minervalkirche Gotha, Magistratsversammlung, 1783-09-07 Transkript Ereignis
44 1783-09-25 August Gottlob Dörrien, Autobiographisches für den Illuminatenorden. Transkript
45 1783-09-30 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, Magistratsversammlung, 1783-09-30. Transkript Ereignis
46 1783-10-25 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, Magistratsversammlung, 1783-10-25. Transkript Ereignis
47 1783-11-10 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1783-11-10. Transkript Ereignis
48 1783-11-12 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, Magistratsversammlung, 1783-11-12. Transkript Ereignis
49 1783-11-17 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1783-11-17. Transkript Ereignis
50 1783-12-02 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1783-12-02. Transkript Ereignis
51 1783-12-06 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, Magistratsversammlung, 1783-12-06. Transkript Ereignis
52 1784-01-06 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1784-01-06. Transkript Ereignis
53 1784-01-07 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, Magistratsversammlung, 1784-01-07. Transkript Ereignis
54 1784-01-30 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1784-01-30. Transkript Ereignis
55 1784-02-02 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, Magistratsversammlung, 1784-02-02. Transkript Ereignis
56 1784-02-23 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1784-02-23. Transkript Ereignis
57 1784-03-23 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1784-03-23. Transkript Ereignis
58 1784-03-23 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, Magistratsversammlung, 1784-03-23. Transkript Ereignis
59 1784-04-03 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, Magistratsversammlung, 1784-04-03. Transkript Ereignis
60 1784-04-30 Friedrich Christian Rudorf, Bericht: Versammlung der Minervalkirche Gotha, Magistratsversammlung, 1784-04-30 Transkript Ereignis
61 1784-05-07 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1784-05-07. Transkript Ereignis
62 1784-06-04 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1784-06-04. Transkript Ereignis
63 1784-06-25 Simon Friedrich Küstner, Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1784-06-25. Transkript Ereignis
64 1784-08-13 Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1784-08-13. Transkript Ereignis
65 1784-10-01 Friedrich Christian Rudorf, Mein Leben und Charakter, Gotha, 1784-10 Transkript
66 1784-12-21 Friedrich Christian Rudorf, Bericht: Versammlung der Minervalkirche Gotha, 1784-12-21. Transkript Ereignis
67 1785-03-01 Bericht: Versammlung der Minervalkirche Frankfurt am Main, 1785-03-01. Transkript Ereignis
68 1785-03-17 J.J.C. Bode, Bericht Illuminatenversammlung, Weimar 1785-03-17. Transkript Ereignis
69 1785-11-01 Heinrich August Ottokar Reichard, Autobiographisches für den Illuminatenorden, Gotha, 1785-11 Transkript
70 1785-12-24 Schack Hermann Ewald, “Schilderung meines Charakters” und “Mein Lebenslauf” Informationen für den Illuminatenorden, Gotha, 1785-12-24 Transkript
71 1799-03-06 Susanna Maria Neefe, Neefes Lebensgeschichte von seiner hinterlassenen Wittwe fortgesetzt, 1799-03-06. Transkript
Posted on

Filling a Wikibase instance with millions of data

As more and more Wikibase instances are cropping up we are seeing attempts to start them with masses of data from already existing data bases that want to switch to the new software.

Experimenting I tried to find a faster way to insert a huge amount of items into a Wikibase instance. I have not been able to insert more than two or three statements per second using the ‘official’ tools, such as QuickStatements or the WDI library.

Therefore, I am inserting the data directly into the MySQL database used by Wikibase.

The process consists of these steps:

  • generate the data for an item in JSON
  • determine the next Q number and update the JSON item data accordingly
  • insert data into the various database tables

However, if you do this without a transaction it is still terrible slow. In my setup only 120 items per minute. However, if I wrap the inserts into a transaction I was able to insert 33,000 items/minute.

Steps to run the experiment

  mysql:
    image: mariadb:10.3
    restart: unless-stopped
    ports:
      - "3306:3306"
    volumes:
  • Start the containers: docker-compose up and wait until you see lines ending like:
[main] INFO  o.w.q.r.t.change.RecentChangesPoller - Got no real changes
[main] INFO  org.wikidata.query.rdf.tool.Updater - Sleeping for 10 secs

For me it took a minute to insert 100 items without a transaction and 25 seconds to insert 10,000 items with a transaction.

first published at https://github.com/jze/wikibase-insert/

Posted on

FactGrid GYIK – Miért használjam a FactGridet a kutatási projektemhez?

Jack Kirby, "The Fourth Dimension is a many splattered thing!" from Alarming Tales, 1 (September 1957).

in English
auf Deutsch
en français

  1. Mi a FactGrid?
  2. Miért használjam a FactGridet a saját kutatásomhoz?
  3. Miért ne egyből a Wikidatát használjam?
  4. A FactGrid ingyenes – hogy működik ez?
  5. Mihez kezdhetek az unortodox kutatási témákkal?
  6. Milyen segédeszközöket biztosít a szoftver?
  7. Mit tegyek, ha a saját platformomon szeretném megjeleníteni az adatvizualizációm?
  8. A FactGrid CC0-licenc alatt teszi közzé az adatokat – ez azt jelenti, hogy lemondok a kutatásom jogairól?
  9. Mi történik, ha szeretném az adataimmal egy másik platformon folytatni a munkát?
  10. Mi történik, amikor FactGrid-felhasználók a “helyes” dátumról vitatkoznak?
  11. Miért kockáztassam meg az átláthatóságot rögtön a projektem kezdetétől?
  12. Mi kell ahhoz, hogy a FactGrid befogadja a projektem?

Mi a FactGrid?

A FactGrid egy Wikibase-alapú platform történeti adatokkal dolgozó projekteknek számára, amely egyszerre hagyományos wiki és adatbázis. Az oldalon állításokat rögzíthetsz az általad feltöltött vagy téged érdeklő elemekről, majd ezeket szinte bármilyen nyelven tudod használni és megjeleníteni.

A platform szervezője a Gotha Kutatóközpont, a szervert pedig ThULB Jena biztosítja.

Együttműködésben a Wikimédia Németországgal és a Német Nemzeti Könyvtár GND-adatbázisával szeretnénk elhelyezni a platformot mint kutatási adatokra építkező erőforrást a kialakulóban lévő, összekapcsolt Wikibase-oldalak rendszerében.

Miért használjam a FactGridet a saját kutatásomhoz?

A fő érv a FactGrid mellett a verhetetlenül rugalmas szoftver, a Wikibase, amelyet a Wikimédia Németország segítségével, elsődleges felhasználási helyén, a Wikidatán kívül, egy kísérleti projekt keretében implementáltunk:

  • Egy olyan szoftvert keresel, amely gyakorlatilag bármilyen nyelven tud beszélni? Egy platformot, ahol felvihetsz adatokat a saját nyelveden, mások pedig a saját anyanyelvükön olvashatják ugyanezt, és fordítva? Ez a szoftver a Wikibase.
  • Egy olyan szoftverre van szükséged, amivel átlátható módon koordinálhatsz egy egész kutatói csapatot? A Wikibase-zel ez ugyanolyan könnyű, mint a Wikipédia szoftverével, a MediaWikivel.
  • Egy olyan adatbázisszoftvert keresel, amely tud mindent, amire egy digitális bölcsészeti adatbázisnak szüksége lehet: kapcsolatháló-elemzés, térképes megjelenítés, komplex összekapcsolt keresések, megjelenítés többféle idővonalon? Egy szoftver, amely szinte emberi nyelvként működik, és még teljes körű adatbázis szolgáltatással is rendelkezik? A Wikibase ez a szoftver.
  • Szeretnél egy előző projektedből származó adatgyűjteményre építeni? A Wikibase-en lehetséges a nagy mennyiségű, automatizált adatbevitel.
  • Szeretnél biztosra menni, hogy más projektek is hozzáférnek az adataidhoz, és ténylegesen fel is tudják használni azokat? A platformról könnyen letöltheted az összes adatot, hogy offline, Excelben vagy bármilyen más online projektben dolgozhass velük.
  • Szeretnél teljesen új kérdéseket feltenni a kutatásodban? A Wikibase-en bármelyik elemet összekapcsolhatod bármiféle állítással.
  • Aggódsz, hogy mi történik majd az adataiddal miután véget ér a kutatásod finanszírozása? Támaszkodj egy platformra, ahol nem egyedül dolgozol, ami olyan licenc alatt működik, amely lehetővé teszi másoknak is, hogy folytassák a munkát az adataiddal és eszközeiddel.

Ha hosszú távú perspektívát keresel, akkor ezt szeretnénk nyújtani a Német Nemzeti Könyvtárral való együttműködésünkkel. A platform egyik támpillére a GND-adatgyűjtemény lesz, ami által széles körben használható eszközként működhetünk. Továbbá célunk ezzel, hogy fontos szereplőjévé váljunk az összekapcsolt Wikibase-rendszerek kialakuló világának.

Miért ne egyből a Wikidatát használjam?

Ez egy teljesen jogos kérdés. Vannak olyan projektek (amelyek elsősorban csak felhasználják adatokat), amelyekhez a Wikidata megfelelőbb platformot nyújt. Az FH Potsdam “Archivführer zur deutschen Kolonialzeit” nevű projektje remekül illusztrálta annak szépségét, amikor közvetlenül Wikidatára dolgozunk – erről beszélgettünk Uwe Junggal, aki bemutatta, milyen technikai megoldásokat használtak Potsdamban.

Ugyanakkor alapvetően két dolog van, amiket nem fogsz tudni sem a Wikidatán, sem egy GND-hez hasonló platformon csinálni: a Wikimédia-projektek (és a GND) szigorú szabályokkal rendelkeznek arról, hogy nem közölhető saját kutatómunka, és döntéseiket nevezetességi kritériumok alapján hozzák meg, ami nem enged teret tetszőleges adatbázis-elemek létrehozásának vagy tárgyak közötti kísérleti kapcsolatok tesztelésének.

A Wikidata és a GND olyan információkra koncentrálnak, amelyeket már korábban publikáltak és a kutatást nem végző alkalmazottak már közzétett kutatásokból viszik fel az adatokat. Ezeken a platformokon nem tudsz létrehozni munkahipotézisként szolgáló állításokat a kutatásodhoz. Nem hozhatsz létre elemeket kizárólag azzal a céllal, hogy majd statisztikai elemzést végezhess rajtuk a munka egy jóval későbbi szakaszában.

A FactGriden bátorítjuk a platform használatát heurisztikus kutatási eszközként.

  • Létrehozhatsz elemeket az adatbázisban függetlenül attól, milyen relevanciájuk lenne egy enciklopédiában vagy könyvtári katalógusban.
  • Megkockáztathatsz ideiglenes kronológiákat, egyéni feltevéseket kiinduló hipotézisként.
  • Használd a FactGridet nem konvencionális állításokhoz, amelyek jelenleg csak a saját kutatási projekted számára érdekesek – a szoftver lehetővé teszi ezt a fajta szabadságot.
  • Hozz létre adatbázis elemeket, amelyek részletezik, a kutatásod során milyen adatgyűjteményeket módosítottál jelentős mértékben. Ezáltal könnyen benyújthatod ezt az adott elemet mint a kutatásodat összegző “mappát” a téged finanszírozó intézménynek.
  • A platformon megkockáztathatsz bármilyen új tézist, és egy saját adatbázis elemben összegezheted mint “mikro-publikációt”, ezáltal is láthatóvá téve a hozzájárulásod.

A FactGrid ingyenes – hogy működik ez?

A szoftver ingyenesen használható, és folyamatosan fejlesztik a Wikimédia projektek közösségei, illetve a Wikibase-t használó intézmények.

A FactGrid platformot a Gotha Kutatóközpont szolgáltatja az Erfurti Egyetem virtuális szerverén. A német URL évi 36 eurós költséget jelent, ezt a Gotha Kutatóközpont fedezi.

Az összes Wikidata-segédeszköz a felhasználóink rendelkezésére áll. Ezek biztosítják az átlag digitális bölcsészeti projekthez szükséges összes funkciót.

Mivel mind a szoftver, mind az eszközök nyílt forráskóddal rendelkeznek, bármilyen általad kedvelt szoftverrel módosíthatod őket, ha új alkalmazási módra van szükséged.

Ha saját eszközeiddel is hozzájárulsz a nyílt rendszerhez, biztosíthatod, hogy jövőbeli projektek is használhatják és fejleszthetik ezeket.

Amennyiben olyan technikai megoldásokra törekszel, amelyeket később anyagi haszonért értékesíthetsz, a szoftver licence ebben sem fog meggátolni. Szabadon kereskedelmi alapokra helyezhetsz bármit, amit nyílt forráskóddal építettél.

Mihez kezdhetek az unortodox kutatási témákkal?

A Wikidata úttörő adatmodellel rendelkezik. A felhasználó gyakorlatilag csak kapcsolatokat hoz létre Q-számok között (vagy kapcsolatokat Q-számok és időpontok, Q-számok és földrajzi koordináták, Q-számok és médiafájlok, Q-számok és URL-ek között).

A szoftver maga nem tudja, milyen típusú kapcsolatokat hozol létre – ezek szintén csak P-számok: a Q1 – P1 – Q2 egy ún. “triple”, ami jelentheti, hogy “Johann Sebastian Bach (Q1) fia (P1) Carl Philipp Emanuel Bach (Q2)”, de azt is, hogy “Az archívumban talált, XY raktári jelzetű levél (Q1) állítólagos feladási helye (P1) München (Q2).”

Q-számokat bármihez hozzárendelhetünk – emberekhez, dokumentumokhoz, eseményekhez, eszmékhez… Te döntöd el, milyen P-számokra van szükséged az általad kívánt állításokhoz. Az elemeket nem egy rögzített, módosíthatatlan kategóriarendszerben kell meghatároznod, a létrehozott állításaid pedig új árnyalatot és szilárdságot adnak az új vagy meglévő elemekhez. Ne aggódj, ha nem rögtön az első napon áll össze az adatmodelled. Hozd létre folyamatosan az állításokat, amikor csak szükséged van rájuk, közben figyeld, hogy érik el a kritikus tömeget, amellyel kiértékelhetővé válnak.

Minden állítás “minősíthető” – “Johann Sebastian Bach (Q1) felesége (P2) Maria Barbara Bach (Q2) házasság kezdete (P2) 1707. október 7. (dátum),  házasság vége (P3) 1720. július 5 körül (dátum).” Ezeket az állításokat ugyanakkor hivatkozásokkal is elláthatjuk: “erre bizonyíték (P4) XY egyházi évkönyv (Q3)”,”állítás forrása (P5) XYZ Bach-életrajz (Q4)”.

A rendszerben lehetséges egymással versengő értékeket megadni, mindössze külön-külön forrásmegjelölést kapnak, illetve rangsorolni is lehet őket.

Ilyen mélységben meghatározott triple-ekkel gyakorlatilag bármilyen állítást létrehozhatsz, ami viszont még fontosabb, ezzel lehetőséged nyílik állításokat létrehozni bármely nyelven. A rendszer Q- és P-számokkal működik, minden egyéb pedig címke, amit azon a nyelven adhatsz meg, amelyet fel szeretnél kínálni a felhasználónak. Ezen felül a szoftver automatikusan lefordítja a dátumokat és mértékegységeket az adott nyelv által használt formátumra. Ez a titka annak, hogy a Wikibase-platformokat mindenki a saját nyelvén szerkesztheti, miközben az egész világon olvasható szinte bármilyen nyelven.

Milyen segédeszközöket biztosít a szoftver?

Készíthetsz adatbázis-bejegyzéseket egyesével: nyisd meg a szerkeszteni kívánt elemet, menj a beviteli lap aljára, és kattints az “állítás hozzáadása”-linkre. Itt kell megadnod, milyen állítást szeretnél létrehozni. Nem szükséges fejből tudnod a P-számot, kezdd el begépelni a tulajdonság nevét a saját nyelveden, majd válassz a felkínált lehetőségek közül az automatikus befejezéshez. A platform tudni fogja az adott állítás P-számát. Az állítás második részét a következő szövegdobozban adhatod meg, szintén elég elkezdeni begépelni.

Excel- és CSV-listákból, automatikus bevitellel is készíthetsz adatbázis bejegyzéseket. (Itt találod a beviteli felületet, itt pedig egy rövid útmutatót hozzá.)

Az adatbázis-lekérdezéseket SPARQL nyelven kell megfogalmazni. Ez (sajnos) nem egy könnyű keresőnyelv, de végső soron annyira komplex, mint a futtatni kívánt keresések.

A SPARQL-t használók nem feltétlen tudnak SPARQL-forráskódot írni. Általában keresési mintákat tudsz használni, amik megmutatják, hol kell változtatnod a bevitt szövegen, hogy lefuttathasd a saját keresésed.

Amennyiben pontosan tudod, milyen típusú keresési lekérdezést kell futtatnia a felhasználóidnak, készíthetsz a könyvtárak megszokott online felületeihez hasonló, egyéni beviteli maszkokat, amelyek majd SPARQL-ben kommunikálnak az adatbázissal.

A szoftvercsomag tartalmaz illusztrációs lehetőségeket térképekhez, idővonalakhoz, hálózatokhoz, genealógiai kapcsolatokhoz, grafikonokhoz, stb. Nem kell letöltened egyéb, külső alkalmazásokat. A SPARQL-en keresztül kérheted az általad kívánt reprezentáció létrehozását. Gyönyörű bemutatót láthatsz vizualizációkból, ha felkeresed a Wikidata Scholia-projektjét.

Mit tegyek, ha a saját platformomon szeretném megjeleníteni az adatvizualizációm?

Ennek nincs technikai akadálya. Uwe Jung demonstrálta, hogyan használja az FH Potsdam felülete a Wikidatát adattárként úgy, hogy közben a felhasználók nem látják a háttérben lévő adatbázist.

Nincs semmi gond azzal, ha a FactGridet külső adattárként használod, és a saját kutatási projekted az egyetemed szerverén építed fel, ahol célzott adatbázis-hozzáférést teszel lehetővé saját keresősablonon keresztül.

A FactGrid CC0-licenc alatt teszi közzé az adatokat – ez azt jelenti, hogy lemondok a kutatásom jogairól?

Ha a Creative Commons 0-licencet választod, továbbra is teljes szabadsággal használhatod az adataidat, amire csak szeretnéd  – te irányítasz, és nem a kiadó vagy az adatokat kezelő platform. Ezen felül a CC0 azt jelenti, hogy az adataid szabadon felhasználhatóvá válnak mások által is. Mivel a közösség így bármikor kijavíthatja az észrevétlenül maradt hibákat, csökken annak a kockázata, hogy hosszabb távon elavuljon a kutatásod.

Néhány megfontolandó tényező: Tudósok számára első pillantásra a CC BY 4.0-licenc tűnik kedvezőnek. Ez engedélyezi az ingyenes felhasználást, amennyiben az megfelelően módon megjelöli a forrást. A gyakorlatban ez működhet szövegeknél (mint ez a blogposzt), mivel itt egyértelmű, hogy milyen hivatkozást szeretnénk látni: a nevünk megadásával, a publikáció címével, a kiadás helyével és dátumával. De szeretnéd, hogy az adataid idézetként szerepeljenek, például egy vizualizációban? Egy 1753 júniusában Párizsból Berlinbe küldött levél a térképen egy vonalként szerepel – hogyan lássuk el ezt megfelelő jegyzetekkel? Hogyan idézzenek téged, ha csak javításokat végeztél egy adathalmazon? Az “Így add tovább”-licencek még problematikusabbak: ezek az adatok szabadon hozzáférhetők bárki számára, amennyiben a további felhasználók is ugyanezekkel a feltételekkel osztják meg. Ez úgy hangzik, mint a szabad felhasználás melletti határozott kiállás. De egy al-felhasználó hogyan tudja biztosítani, hogy az ő al-felhasználói is betartják a licencbe foglalt feltételeket (főleg ha ez az al-felhasználó CC0 alatt teszi közzé az adatokat)? Az al-felhasználóknak általában azt tanácsolják, ne használjanak adatokat CC-BY vagy CC Így add tovább licenccel rendelkező platformokról.

A Wikidatával és a Német Nemzeti Könyvtárral közös vállalkozásunk egyetlen lehetőséget hagyott számunkra: hogy partnereinkhez hasonlóan szabadon felhasználhatóvá tegyük az adatainkat. A CC0-licenc által nem biztosított, hogy a további felhasználók is feltüntetik majd, ki gyűjtötte az adatokat, illetve felhasználásuk feltételeit.

A gyakorlatban a legtágabb nyílt licenc nem jelenti azt, hogy a FactGrid-adatok szerző nélküliek, épp ellenkezőleg. Mi azt szorgalmazzuk, hogy hivatkozzunk a kutatásra, és megelőlegezzük, hogy a Wikidata és a GND is boldogan feltünteti, ha a kutatás a mi platformunkról származik.

A FactGriden minden szerkesztéshez kapcsolva van a szerző neve. Ha egy kutatási projekt lényeges mértékben járult hozzá egy adatgyűjteményhez, akkor ezt jelezhetik egy külön jegyzetben, amelyet tovább lehet adni adatátvitelnél.

A Wikidatához vagy a GND-hez hasonló adatbázisok amúgy érdekeltek is a kutatások hivatkozásában – ez hozzájárul az adataik szilárdságához. A FactGrid abban a különleges helyzetben van, hogy mindkét szervezet számára olyan platformot szolgáltat, ahol a felhasználók olyasmiket csinálhatnak, ami saját, nagyobb platformjaikon nem engedett.

Mi történik, ha szeretném az adataimmal egy másik platformon folytatni a munkát?

Mivel szerzői jogi korlátozások nélkül vitted fel az adatokat, szabadon dolgozhatsz velük bárhol máshol. Valójában örülünk is, ha afféle inkubátor lehetünk kutatási adatok számára.

Mi történik, amikor FactGrid-felhasználók a “helyes” dátumról vitatkoznak?

A szoftver lehetővé teszi az egymásnak ellentmondó adatok kezelését – ez különösen fontos a történelmi kutatás területén, ahol gyakran találunk egymásnak ellentmondó forrásokat anélkül, hogy biztosan tudjuk, melyikük állítása igaz. A szoftverrel reprodukálhatjuk az ellentmondásos helyzetet, az állításokat pedig külön-külön alátámaszthatjuk hivatkozásokkal. Az eltérő állításokat súlyozhatjuk is egymáshoz képest – például a jelenleg irányadó állítást az egyéb variánsokkal szemben, vagy akár minősítőkkel az egyéni kiértékeléshez.

Tekintsük inkább érdekes helyzetként arra, amikor két kutató eltérő eredményekre jut. Sokkal rosszabb, amikor egy olyan platformon hibázol, ahol sosem lesznek kijavítva, és hitelteleníthetik az egész munkádat.

Miért kockáztassam meg az átláthatóságot rögtön a projektem kezdetétől?

Ez kemény dió, valószínűleg ez gátolja meg a legtöbb projektet, hogy használja a FactGrid erőforrásait. Az alternatíva egy platform, amihez csak a jelszóval rendelkező csapat férhet hozzá a projektet lezáró publikáció határidejéig. Így, szól az érv, semelyik versengő projekt sem tudja elcsaklizni a kutasi eredményeket. Senki sem látja, hol hibáztál az elején. Senki sem rögzíti, melyik adatot vitték fel asszisztensek és melyiket a projektvezető – ehhez hasonlók a feltételezett előnyei a nem átlátható munkának egy olyan platformon, amely csak a finanszírozás végével lesz online elérhető.

Az átlátható kutatás saját biztosítékokkal rendelkezik. Ha egy találsz egy minden eddigit felülíró dokumentumot vagy rögzítesz egy úttörő kapcsolódási pontot, akkor itt a lehetőség, hogy a saját nevedhez és projektedhez kösd az állítást. Ha holnap valaki ellátogat ugyanabba az archívumba és szintén felfedezi, amit te – pech, hiába. Te már rögzítetted a megfigyelést a platformon, amit a laptörténetben lekövethető változtatás minden kétséget kizáróan bizonyít.

Mindeközben a kollektív platform  meghívásként is működik az együttműködésre. Tedd egyértelművé a többi csapat számára, min dolgozol, hogy felvehessék veled a kapcsolatot.

Egy elméletileg biztonságos, csak a projekt végén nyilvánosságra hozott weboldal kockázatai komolyak. A felhasználókkal ekkor már nem lehetséges ötleteket cserélni. Az internetes jelenlét időzítése a projekt rohanós utolsó heteire esik, amikor már nem lehetséges semmiféle, koncepciót érintő változtatás. Ha a kutatást kizárólag egy könyves publikációhoz végeztétek, bizonytalan marad, mihez kezdjen a csapat a Word- és Excel-fájlokban összegyűjtött adatokkal. Senki sem tudja ekkor felvinni az adatokat egy nagyobb erőforrásba – egy ilyen késői fázisban a harmonizáció szinte megugorhatatlan akadály. Csak reménykedni lehet, hogy a könyv olvasói beszkennelik az összes lábjegyzetet, hogy a bennük lévő korrigálások elérhessék a könyvtári katalógusokat és a különféle Wikimédia-projekteket. A kockázatot itt a könyv jelenti, amely semmiféle hatással nincs a kollektív adatbázisra, illetve a digitális bölcsészet projektek, amelyek publikáció után elavulnak.

A jövő inkább egy újfajta hozzáállásban kell keresni egy közös, nyilvános adatbázis felé. A kutatóknak képesnek kell lenniük javítani és bővíteni ezt az adatbázist bárhol, bármikor hozzáférve. Az szükséges motivációt és biztonságot a kutató környezet jelenti, ahol megjelölhetik és idézhetővé tehetik saját munkájukat. Erre a Wikibase bármely más szoftvernél alkalmasabb.

Mi kell ahhoz, hogy a FactGrid befogadja a projektem?

A FactGrid-platformnak nincs láthatatlan mélyrétege. Bárki lekérdezhet az adatbázisból, és ugyanazt az eredményt fogja kapni akár be van jelentkezve, akár nincs. A személyes felhasználói fiók annyi előnnyel jár, hogy kiválaszthatod a kívánt nyelvet, miközben az adatokat böngészed, illetve lesz egy “szerkesztés”-link minden állítás alatt.

Ha szeretnéd betáplálni az adataid a FactGridbe, és ha szeretnél egy projektet futtatni a platformon, akkor szükséged lesz felhasználói fiókra. Ezt a valódi neved megadásával kaphatsz az adminisztrátoroktól. Ehhez az oldalon találsz egy “Request account” (felhasználó fiók igénylése) szövegű linket. E-mailben is felveheted velünk a kapcsolatot. Projektvezetők kaphatnak adminisztratív fiókokat, amivel kijelölhetnek csapattagokat, projekthez kapcsolódó személyeket.

Miután bejelentkeztél, felvihetsz adatokat nagy mennyiségben vagy végezhetsz meghatározott javításokat bármelyik elemen. Minden változtatásod a felhasználói fiókodhoz lesz kapcsolva. Mások visszavonhatják a szerkesztéseid, de nem nyomtalanul, dokumentálva lesz az elem történetében, mindenki láthatja.

Ha egy összetettebb projekten szeretnél dolgozni, —

  • ami lehet személyes családkutatás,
  • lehet egy egyszeri vizualizáció egy szemináriumi dolgozathoz,
  • vagy akár több ezer tételnyi adat bevitele egy 5 éves projekt folyamán

— egyeztess a többi felhasználóval és a platform szervezőivel. Nem (feltétlen) fogunk egy nyilvános egyetértési nyilatkozatot aláírni, de a blogunkon hírt adhatunk a projektedről, hogy eljusson mindenkihez a platformon. A munka akkor válik igazán izgalmassá, amikor mások befejezett munkáját módosítod, illetve amikor más projektek résztvevőit inspirálod az általad bevezetett modellezés használatára. Nem kötelező átbeszélni az adatmodelleket a többiekkel, de a modellek megosztása segíthet a kutatásodnak új embereket elérni, illetve felhasználhatók lesznek mások által létrehozott lekérdezésekben vagy vizualizációkban.

A szoftvert arra tervezték, hogy kezelni tudja mind az olyan állításokat, amelyek csak számodra érdekesek, mint azokat, amelyek az eredeti kutatási témádnál jóval távolabbra elérnek majd.

Jack Kirby, "The Fourth Dimension is a many splattered thing!" from Alarming Tales, 1 (September 1957).
Jack Kirby, “The Fourth Dimension is a many splattered thing!”, Alarming Tales, 1 (1957. szeptember).
Posted on

The first volume of the Thuringian pastor’s book (1500–1920) as a Wikibase data set

auf Deutsch

In a tremendous effort of a year’s work, Heino Richard of the Genealogical Society of Thuringia e.V., step by step translated the first volume of the Thuringian Pastors’ Books (the volume for the former Duchy of Gotha) into data which we could now feed into FactGrid: More than 13,300 database objects are stemming from this work allowing now entirely new explorations of the territory’s social and religious history. We as curious about the joint ventures this work might inspire. There is no reason to fear that the database version will render all further work on the paper-based volumes obsolete; the platform might, however, offer itself to the editors of the Pfarrerbuch as an unexpected aid.

The eight volumes cover all the parishes of the former Thuringian territories from the Reformation to the 20th century. A first survey is opening each volume with a tour through all the parishes and offices giving the lists of the pastors and auxiliaries who held the respective offices. The main part is in each volume devoted to the individual biographies. Genealogy is key: Pastor after pastor we get the parents with their professions, their wives (with their respective parents and backgrounds), and eventually the children (with information about their professions and the families they married into).

“Things, not strings” – database objects instead of names to be merely spelled out

Translating the volumes into FactGrid-Wikibase data became an ordeal with software’s call for database objects to be connected – where the printed volume was just stating names in various strings of letters. One would have wished to get persistent identifiers with these names since almost all these names reappeared in various contexts – as office holders, as the targets of individual biographies and in various related functions as fathers, sons, sons-in-law or fathers-in-law in the other biographies – without any further clarification of the hard identities behind the mentionings. All this was tricky since names were passed across the whole range from fathers to son, or from grandfathers and uncles to grandsons and nephews to name the closer options that would become most difficult to set apart.

1953 church dignitaries became the stock to start with – almost all connected to more than one of the 142 parishes. The set doubled, tripled and quadrupled with the wives, parents and children and their new relatives to a total of 13,344 data records (as of today). All the records had to be connected to birth and death dates, places, information about marriages, terms of office and occupations.

The entire data is still flawed here and there – it will straighten out the the use it will find. A simple check sheds light into the abyss: We still have some 200 personal data records connected to more than one father and one mother. The double records have sprung unto existence wherever we failed to understand that people were the same – a given name missing or an alternative spelling would render the automatic identification impossible. Things are just as tricky where we supposed that we were dealing with a single person whilst we were actually fusing information of two different lives into a single data record.

Merging data sets remains as painful as the reversal since the software does not take much of an effort to keep track of all the consequences to observe when entire branches of families have been duplicated in the course of the input.

Software features one would love to have

The input of genealogical data calls for a module that understands what basically is. The module should generate family trees and warn you before any input that it has found identical family fingerprints: Children from two families are unlikely to share their birthdays; just as they are unlikely to marry into the same families or to share fathers with the same background data. When entering data, the software should highlight congruent structures and help to merge them with look at the entire overlap which it can track far better than any human eye.

The lack of the stand-alone frontend is even more grievous. Those who want to read the database are not interested in the input pages that list the various triples and qualifiers just as we happened to enter them.

Magnus Manke’s “Reasonator” and Markus Krötzsch’s “SQID” demonstrate what Wikidata and Wikibase should receive: an interface that is solely geared towards the display of data. The next generation of such interfaces will do more than just display the statements made on a single item in a better order. Configurable interfaces will gather information from items referring to your query. It is precarious to list 800 letters and publications of a person you are exploring on the person’s item, if you have already created 800 items for all these titles all with in-depth information on the authors, collaborators, publishers, performances, recipients, archival holdings and so on. It should suffice to note a person’s father and mother on the person’s item — once you start giving reciprocal information on the parents’ pages and siblings you are in the middle of a mess of data which you will inevitably fail to keep in congruence.

Lacking a more cohesive interface it remains difficult to present a data set like this one.

So how can one see what’s in it?

What we can do in the present situation is to give first searches that enable readers to start their own more specific searches – knowing that SPARQL will be a huge put off for the majority of readers. The most practical first search to start with will be the query for all the Protestant parishes of the former Duchy, to appear on a map:

Click the red dots to access to the records of the individual parishes with the lists of pastors registered on the each item.

The table version allows the data to be downloaded as JSON, TSV and CSV data records. TSV, “Table Separated Values”, can be processed in data sheets, whether Excel or Google. The search is sent off with the blue arrow key:

You will have to study an exemplary personal data record before you start your own searches as you need to know how we formulated the triples, i.e. the miniature statements stored in the database, in order to run effective searches as SPARQL queries:

The following query generates a table of all pastors with their birth dates, death dates and parents. With the input help (press the i-Icon to activate it) you can add more table columns to the search in order to get the additional information on children, wives, offices, memberships etc.:

All 13,484 database objects that are using information from the first volume of the Pastors’ Book can be bundled with the P12 (literature) + Q43361 (the first volume of the Thuringian Pastors’ Book) filter.

What is in it to learn?

The Thuringian Pastors’ Book genealogical focus opens up a first interesting perspective: Religion becomes after the territorial decisions of the Reformation increasingly a family institution: You take your religion with you as you receive it at birth. This is even more so with the church hierarchy that evolves. Families become the partners of the territorial churches supplying the students of theology and the pastors for generations. With the database we should become able to ask the more specific questions:

  • What was the exact influence of individual family positions: father, mother, grandfathers, uncles? How did that influence accumulate with more than one pastor in the family?
  • Did the family influence on becoming a pastor decrease over time – with the compulsory education becoming the central provider of professional decisions and career options in the course of the 19th century (and when exactly did such an influence become more noticeable)?
  • To what extent was marrying into a rectory household an advantage – for one’s own career, for the careers of the children?
  • Were local networks as valuable as relationships across spatial distances?
  • To what extent did the ecclesiastical appointments open – geographically? Where did the pastors come from over time?

A project looking for partners

We will have to bring people and institutions together to make our data sets more accessible and the CC0 license is not the threshold here.

(1) It would be an immense gain if could get Wikidata and Histropedia people on board. They are the people who understand the technical side far better than the FactGrid community of the historians; and somehow we should become able to work hands in hands.

(2) It would be a huge win if the resource attracted the team behind the Thuringian pastors books. The software we are using is not really a tool to digest books – it is a tool to facilitate your research. We have the ideal platform one would use to set identifiers and to collect and accumulate information – on the platform with the sources you will not be able to link in the volumes. FactGrid is a team’s tool to be used in the process that prepares a volume.

(3) We would be pleased if we could win the Eisenach State Church Archives for the project. For two years now we have been working with the Church Archive of the City of Gotha, which has started to use the database as its own repository. It would be exciting to widen this project an to get a clearer picture of the whereabouts of archival materials from the 142 parish we have been exploring with this project.

(4) A far broader data networking should add complexity and depth to the work done so far: Our 2000 pastors have written sermons, books, and letters. The Gotha Research Library will keep more of these publications than any other institution. We should be able to match our records to fuse the next layer of networking – the layer of public and private networking via letters and publications into the database with its present genealogical focus. The entire production of books and the links to digitisations is now increasingly done by the VD16, VD17 and VD18 online catalogues and the Kalliope-Database. It would be interesting to connect these records to allow the swift step from personal records to online documents. The Gotha Research Centre will not be able to organise such a projects – it will need partners who adopt the work we did here in a pilot study of the database’s potentials.

If you get interested in the data set and start exploring it, let us know and share your research with us right here on the blog.