Suppose I had to prove that I truly received a PhD. The photo below can be used as part of the evidence. People familiar with the Dutch academic ceremony would recognise that this is a picture taken after a PhD ceremony, presumably with the candidate's parents and PhD supervisor. There are people who believe the Apollo landings were filmed on Earth, so there is always a likelihood that such a photo could have been staged. And obviously there are much stronger forms of evidence, such as a copy of the diploma – although even that could be forged unless it is certified.
Photo taken after I received my PhD, with my thesis advisor and my parents, 11 February 1991.
Now suppose we want to build a "PhD resolver": a system that uses artificial intelligence – which is after all a surrogate for "sources familiar with the domain" – and subject-matter experts to find out whether someone really did receive a PhD. The first thing we have is the photo, which is a piece of evidence. We call it an exhibit. We would use face-recognition software to detect four people, four occurrences of the person entity, on the photo. The face-recognition algorithm could get it wrong: it could detect only three people because one is facing the wrong way, or mistake a face in a framed painting as an additional face. After this step we would match the faces with our reservoir of known people entities. The matching software would make a confident match of the face on the right with the entity that represents the candidate.
All in all, we collected the following relevant assertions:
- Exhibit of type "photo" acquired by harvester at time T0
- Occurrence of a person with face F4 detected on photo by face-recognition software with confidence X at time T1
- Occurrence matched with the candidate by person-matcher with confidence Y at time T2
- Occurrence of a person with face F4 meets criteria for PhD candidate, as concluded by PhD-resolver AI with confidence Z at time T3
Pity that the person-matcher confused the candidate with his father 😃.
The principles outlined above are exactly the ones that form the foundations of a modern research data platform. Harvesters acquire data that is used as evidence that an entity exists. The type and provenance of the data matters a great deal in determining the credibility of the evidence. That evidence is an exhibit.
An exhibit for a Works entity – a published article, a conference paper, a book chapter – can be a file downloaded from a publisher (high credibility), a mention in a news article (low credibility), a record received from a bibliographic aggregator, or even a bibliographic reference in another work. An exhibit for a Funding entity can be an acknowledgement of funding in an article, or the text of a grant award notice. A core problem in older data models is the lack of separation between the exhibits and the entities: the material harvested from a funding agency is treated as the award itself, when in fact it is only a notice of an award – an exhibit that must be linked to the funding entity. The more exhibits the better., or in other words: "duplicates are good".
The next step is to identify occurrences of entities on the exhibit. A harvested piece of evidence can double as exhibit for many entities: an article exhibit contains author names, affiliations, references, and therefore also serves as exhibit for those occurrences. Recognising occurrences on an exhibit is also referred to as "tagging" or "structuring". This is the second place where a degree of confidence enters, because these tools are good but not perfect.
The subsequent step is to match the occurrences of entities on the exhibits with the known reservoir of entities in our graph and, if we believe there is no match, to create a new entity. These are the entity-resolver components. Again this matching takes place with a degree of confidence.
Forming the entities is not just triggered by the arrival of new exhibits: we stir the pot continually, detecting new or breaking old connections. This is why it is dangerous to fall into the trap of starting from the inflow. Those close to the inflow know how dangerous it is out there on the waves. Those who are looking at the ocean – the entire corpus as seen through the knowledge layer – perceive the waves as a mere ripple. In a data platform, we have to embrace both.
Lastly, since our entities are emergent out of a huge pool of exhibits, it is our job to form a context view that all products can rely on. We can be flexible: consumers can have looser ideas about confidence levels, but there is only one way in which this looseness creates meaningful results.
We now know:
- Exhibit X harvested by harvester … at time …
- Occurrence O found on X by entity-recognition module … at time … with confidence …
- O matched with known entity E by entity-resolver module … at time … with confidence …
- X is an exhibit for E
Each of these statements can be overruled or negated by a data operator – a human in the loop. And each statement is made available through a knowledge-discovery layer, allowing data products to be built on top of it.
In the world of journal and book publishing, everything is a little more "real" than in the world of research intelligence, which hangs together from probabilities. In publishing we cannot produce an article with a degree of confidence. The people involved – authors, editors, reviewers – are real customers with an ongoing live interaction. This more real-world area deals with manifestations of the work entity, and comes with versions, workflow, and customer-interaction aspects. Manifestations can act as exhibits, but not the other way around.