Change Details

Commons structured data guidelines call to label depicts statement as specific as possible. I.e. an image of a chihuahua should be `depicts=chihuahua`, not `depicts=dog` Still, when searching for "dog", that is a relevant image. We should be able to include it, because the "chihuahua" entity is a subclass of the "dog" entity. We already search for relevant entities that match the search term. [] Figure out which entity matches we want to consider finding subclasses of (how perfect of a match should it be before (e.g. [Q28284645](https://www.wikidata.org/wiki/Q28284645) may not be as relevant for "cat" as [Q146](https://www.wikidata.org/wiki/Q146) is, and not worth traversing the tree for) [] Figure out what entities to traverse (instance of? subclass of?) [] Figure out how many levels deep to go (in terms of when results get too noisy) [] Figure out how to decay the boost based on how many levels deep we go (assuming that going deeper adds more noise) [] Figure out whether there are performance concerns to querying sparkle for these data [] Figure out whether there are performance concerns to including and scoring a massive amount of statement-based matches in elastic (and if so, where to draw the line) [] Given all of the above - is this worth building? Rough estimate on implementation?

Commons structured data guidelines call to label depicts statement as specific as possible. I.e. an image of a chihuahua should be `depicts=chihuahua`, not `depicts=dog` Still, when searching for "dog", that is a relevant image. We should be able to include it, because the "chihuahua" entity is a subclass of the "dog" entity. We already search for relevant entities that match the search term, here's what else we need to figure out: [] Figure out which entity matches we want to consider finding subclasses of (how perfect of a match should it be before (e.g. [Q28284645](https://www.wikidata.org/wiki/Q28284645) may not be as relevant for "cat" as [Q146](https://www.wikidata.org/wiki/Q146) is, and not worth traversing the tree for) [] Figure out what entities to traverse (instance of? subclass of?) [] Figure out how many levels deep to go (in terms of when results get too noisy) [] Figure out how to decay the boost based on how many levels deep we go (assuming that going deeper adds more noise) [] Figure out whether there are performance concerns to querying sparkle for these data [] Figure out whether there are performance concerns to including and scoring a massive amount of statement-based matches in elastic (and if so, where to draw the line) [] Given all of the above - is this worth building? Rough estimate on implementation?

Commons structured data guidelines call to label depicts statement as specific as possible. I.e. an image of a chihuahua should be `depicts=chihuahua`, not `depicts=dog` Still, when searching for "dog", that is a relevant image. We should be able to include it, because the "chihuahua" entity is a subclass of the "dog" entity. We already search for relevant entities that match the search term., here's what else we need to figure out: [] Figure out which entity matches we want to consider finding subclasses of (how perfect of a match should it be before (e.g. [Q28284645](https://www.wikidata.org/wiki/Q28284645) may not be as relevant for "cat" as [Q146](https://www.wikidata.org/wiki/Q146) is, and not worth traversing the tree for) [] Figure out what entities to traverse (instance of? subclass of?) [] Figure out how many levels deep to go (in terms of when results get too noisy) [] Figure out how to decay the boost based on how many levels deep we go (assuming that going deeper adds more noise) [] Figure out whether there are performance concerns to querying sparkle for these data [] Figure out whether there are performance concerns to including and scoring a massive amount of statement-based matches in elastic (and if so, where to draw the line) [] Given all of the above - is this worth building? Rough estimate on implementation?