Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Shelly Rogov

dblp:160/9937 · DBLP profile ↗
← Back
2ranked-venue papers
0as first author
0since 2021 · last 2017
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Artificial intelligence and machine learning · 2Graphics, computer vision, multimedia, augmented reality and games · 1

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
2 papers
Knowledge representation and reasoning · 100%
Theoretical computer science
1 paper
Computational complexity · 100%

Topics — the 2 heaviest of 2, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Knowledge, reasoning and agents › Knowledge representation and reasoning › diagnosis
model-based diagnosis
0.522017
How many diagnoses do we need? · Artif. Intell. 2017
How Many Diagnoses Do We Need? · AAAI 2015
Computational complexity › complexity of reasoning
diagnosis complexity
0.112017
How many diagnoses do we need? · Artif. Intell. 2017

Methods — techniques the papers use, named apart from their topics

bayesian estimation · 0.2
YearPublicationVenuePosition
2017 How many diagnoses do we need?
Roni Stern, Meir Kalech, Shelly Rogov, Alexander Feldman
Artif. Intell.3
2015 How Many Diagnoses Do We Need?
abstract
A known limitation of many diagnosis algorithms is that the number of diagnoses they return can be very large. This raises the question of how to use such a large set of diagnoses. For example, presenting hundreds of diagnoses to a human operator (charged with repairing the system) is meaningless. In various settings, including decision support for a human operator and automated troubleshooting processes, it is sufficient to be able to answer a basic diagnostic question: is a given component faulty? We propose a way to aggregate an arbitrarily large set of diagnoses to return an estimate of the likelihood of a given component to be faulty. The resulting mapping of components to their likelihood of being faulty is called the system's health state. We propose two metrics for evaluating the accuracy of a health state and show that an accurate health state can be found without finding all diagnoses. An empirical study explores the question of how many diagnoses are needed to obtain an accurate enough health state, and a simple online stopping criterion is proposed.
Roni Stern, Meir Kalech, Shelly Rogov, Alexander Feldman
AAAI3