Demo Data from EDBT 2026 / reviewers in the wild / expert
Robert A. Weida
dblp:37/440
· DBLP profile ↗
2ranked-venue papers
1as first author
0since 2021 · last 1992
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Artificial intelligence and machine learning · 1 · 1 first-authorDatabases, data management, data science and information retrieval · 1Theory of computation · 1 · 1 first-author
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Artificial intelligence
1 paper |
Knowledge representation and reasoning · 67% Planning, search and constraint satisfaction · 33% | |
| Databases, data mining, and information retrieval
1 paper |
Transaction processing and concurrency control · 56% Database system architecture and tuning · 44% | |
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Storage systems · 100% | |
| Theoretical computer science
1 paper |
Automated reasoning and model checking · 100% |
Topics — the 8 heaviest of 11, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Knowledge, reasoning and agents › Knowledge representation and reasoning
description logic |
0.0 | 1 | 1992 | Terminological Reasoning with Constraint Networks and an Application to Plan Recognition · KR 1992 |
Knowledge, reasoning and agents › Planning, search and constraint satisfaction
plan recognition |
0.0 | 1 | 1992 | Terminological Reasoning with Constraint Networks and an Application to Plan Recognition · KR 1992 |
Knowledge, reasoning and agents › Knowledge representation and reasoning › description logic
terminological reasoning |
0.0 | 1 | 1992 | Terminological Reasoning with Constraint Networks and an Application to Plan Recognition · KR 1992 |
Database system architecture and tuning
knowledge base management system |
0.0 | 1 | 1991 | A Persistent Store for Large Shared Knowledge Bases · IEEE Trans. Knowl. Data Eng. 1991 |
Transaction processing and concurrency control › versioning
version storage |
0.0 | 1 | 1991 | A Persistent Store for Large Shared Knowledge Bases · IEEE Trans. Knowl. Data Eng. 1991 |
Storage systems › storage architecture
persistent storage |
0.0 | 1 | 1991 | A Persistent Store for Large Shared Knowledge Bases · IEEE Trans. Knowl. Data Eng. 1991 |
Storage systems › storage management
versioned storage |
0.0 | 1 | 1991 | A Persistent Store for Large Shared Knowledge Bases · IEEE Trans. Knowl. Data Eng. 1991 |
Transaction processing and concurrency control › update management
concurrent update |
0.0 | 1 | 1991 | A Persistent Store for Large Shared Knowledge Bases · IEEE Trans. Knowl. Data Eng. 1991 |
Methods — techniques the papers use, named apart from their topics
constraint networks · 0.0versioning · 0.0clustering · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 1992 | Terminological Reasoning with Constraint Networks and an Application to Plan Recognition
Robert A. Weida, Diane J. Litman |
KR | 1 |
| 1991 | A Persistent Store for Large Shared Knowledge BasesabstractA knowledge-base management system (KBMS) with the following goals is proposed: (1) to allow a knowledge engineer to update a knowledge base and have these updates persist on secondary storage, (2) to allow multiple knowledge engineers to have shared access to a knowledge base and modify the knowledge base concurrently, and (3) to maintain consistency of the shared knowledge base as it evolves. At the heart of the KBMS is the version store, which is a persistent storage structure that maintains multiple versions of a knowledge base. Retrieve and update operations are defined on the version store to efficiently access and modify any version. Objects in the version store are clustered to support efficient access of an entire version or some subparts of it. To store the effects of an update requires space proportional to the size of the update and which is independent of the size of the knowledge base. The additional cost of maintaining multiple versions is within a small constant factor of maintaining a single version.> Eric Mays, Sitaram Lanka, Robert Dionne, Robert A. Weida |
IEEE Trans. Knowl. Data Eng. | 4 |