Class AnnotationRelationDao.RelationQuery

java.lang.Object
ubic.gemma.persistence.service.common.description.AnnotationRelationDao.RelationQuery
Enclosing interface:
AnnotationRelationDao

public static class AnnotationRelationDao.RelationQuery extends Object
What to look for. Every field narrows; an empty collection means "do not constrain on this".

At least one of the subject or object legs must be populated. Enumerating the whole relation table is not a question anyone is asking, and would be an expensive way to find that out.

  • Constructor Details

    • RelationQuery

      public RelationQuery()
  • Method Details

    • getSubjectValueUris

      public Collection<String> getSubjectValueUris()
    • subjectValueUris

    • getSubjectValues

      public Collection<String> getSubjectValues()
    • subjectValues

    • getObjectValueUris

      public Collection<String> getObjectValueUris()
    • objectValueUris

    • getObjectValues

      public Collection<String> getObjectValues()
    • objectValues

    • getPredicateUris

      public Collection<String> getPredicateUris()
    • predicateUris

    • getSubjectCategoryUris

      public Collection<String> getSubjectCategoryUris()
    • subjectCategoryUris

      public AnnotationRelationDao.RelationQuery subjectCategoryUris(Collection<String> v)
    • getExcludedSubjectCategoryUris

      public Collection<String> getExcludedSubjectCategoryUris()
    • excludedSubjectCategoryUris

      public AnnotationRelationDao.RelationQuery excludedSubjectCategoryUris(Collection<String> v)
      Subject categories to leave out, for a caller that wants everything except one kind of implying term. The complement of subjectCategoryUris(Collection), which cannot express this: naming the categories to keep means enumerating every category the store holds and revisiting that list whenever one is added.

      A relation whose subject has no category is kept — an unknown category is not the excluded one, and the alternative silently drops every uncategorised subject alongside the target.

    • getObjectCategoryUris

      public Collection<String> getObjectCategoryUris()
    • objectCategoryUris

      public AnnotationRelationDao.RelationQuery objectCategoryUris(Collection<String> v)
    • getBases

      public Set<AnnotationRelationBasis> getBases()
    • bases

    • getExcludedExperimentIds

      public Collection<Long> getExcludedExperimentIds()
    • excludedExperimentIds

      public AnnotationRelationDao.RelationQuery excludedExperimentIds(Collection<Long> v)
      Hold experiments out of the evidence.

      This is what makes "the tag on this dataset is inferable, so it can be dropped" an honest claim rather than a circular one: exclude the dataset and ask whether the rest of the corpus still recovers the relation. Without it, a dataset is shown its own annotation as independent support for itself.

      Expected to be long, and it has to be done here. A scored evaluation holds out its whole panel, not one dataset, because precedent drawn from the other panel experiments is leakage into the same benchmark. A caller cannot do this filtering for itself afterwards: what comes back is an aggregate count, not the list of datasets behind it, so a client holding a relation with support 5 has no way to know which five contributed and no way to subtract its own. The list is sorted and deduped before binding so a long hold-out reuses one prepared statement rather than minting a plan per distinct length.

    • getTaxonId

      @Nullable public Long getTaxonId()
    • taxonId

      public AnnotationRelationDao.RelationQuery taxonId(@Nullable Long v)
    • getSeedFromExperimentId

      @Nullable public Long getSeedFromExperimentId()
    • seedFromExperimentId

      public AnnotationRelationDao.RelationQuery seedFromExperimentId(@Nullable Long v)
      Seed from every annotation an experiment carries, instead of from a list of terms.

      Matched inside the query as an exists against EE2C rather than by fetching the experiment's annotations into Java first. A round trip per experiment page is exactly the kind of cost that makes an endpoint slower the more it is used, and the seed set is already indexed where it sits.

      Pass the same id to excludedExperimentIds(Collection) unless you specifically want the experiment counted as evidence for itself.

      🛑 Setting this narrows the read in two ways nothing else does, because seeding from an experiment is asking what the experiment's terms IMPLY and the other seeds are not:

      • Only forward walks come back. The seed must be the end that implies — the subject of a RelationInferenceDirection.SUBJECT_IMPLIES_OBJECT row, the object of an OBJECT_IMPLIES_SUBJECT one — so a row whose implying end is not the side seedDirection(Direction) named is dropped, as is one that implies nothing either way.
      • Conclusions the experiment already carries are dropped. Being told what you just said is not an inference.

      Both are confined to this path deliberately. A subject/object lookup is a browse — the row is true read from either end and both ends are worth showing — and the membership read has its own direction gate at its own callsite.

    • getSeedDirection

      public AnnotationRelationDao.Direction getSeedDirection()
    • seedDirection

      Which side of the relation an experiment seed is matched against.

      Both directions are real and which one a caller wants depends on what it holds. A curated statement puts the disease in the subject and the gene in the object (disease model: autism spectrum disorder - has_genotype -> Mef2c), so an experiment carrying a genotype matches on the object side and the disease is what comes back; an experiment carrying the disease matches on the subject side and the genotype comes back.

    • getMinimumSupport

      public int getMinimumSupport()
    • minimumSupport

      public AnnotationRelationDao.RelationQuery minimumSupport(int v)
    • getMinimumSpecificity

      public double getMinimumSpecificity()
    • minimumSpecificity

      public AnnotationRelationDao.RelationQuery minimumSpecificity(double v)
      Off by default, deliberately: no threshold has been tuned against curator judgement, and the shape of the distribution is worth seeing before one is fixed in the API.
    • getMaximumObjectBreadth

      public int getMaximumObjectBreadth()
    • maximumObjectBreadth

      public AnnotationRelationDao.RelationQuery maximumObjectBreadth(int v)
      Drop relations whose object relates to more than this many distinct subjects. Zero, the default, does not filter.

      No default is imposed because the right bar depends on the question. A suppression gate wants something small — an object shared by hundreds of diseases implies all of them and is useless for deciding whether one of them is redundant. A curator browsing what a dataset's annotations relate to may well want the dose and the duration.

      See Also:
    • getMaximumSubjectBreadth

      public int getMaximumSubjectBreadth()
    • maximumSubjectBreadth

      public AnnotationRelationDao.RelationQuery maximumSubjectBreadth(int v)
      Drop relations whose subject relates to more than this many distinct objects under the same predicate. Zero, the default, does not filter.

      The other end of maximumObjectBreadth(int), and it catches a different shape: a subject enumerating a list rather than saying something about itself. Measured on gemma2 2026-08-27 over the forward walk of ?dataset= for 36 datasets, 214 of the 303 rows were CHEBI's has role closure (dimethyl sulfoxide carries 8 roles, biotin 15). Counting each row's siblings within that read, a bar of 3 leaves 9 of the 214 and every row of every other predicate present: has disease 31/31, derives from anatomic part 12/12, derives from patient having disease 11/11, derived from cell 11/11, derived from cell line 8/8, derives from part of 7/7, is disease model for 3/3. maximumObjectBreadth(int) at 25 over the same rows keeps 43 of the 214 while taking derives from anatomic part to 1, derives from patient having disease to 1 and is disease model for to 0 — it separates a topic from a dose, which is not this.

      No default is imposed here for the reason none is imposed there: a curator browsing a term may well want all fifteen of biotin's roles, which the ranking already orders specific-first.

      See Also:
    • isIncludeRefuted

      public boolean isIncludeRefuted()
    • includeRefuted

      public AnnotationRelationDao.RelationQuery includeRefuted(boolean v)
      Also return relations a source states do NOT hold. Off by default.

      🛑 A refuted row is not a weak assertion, it is the opposite of one, so it must never arrive where a caller expects support. Asking for it is asking a different question — "does anything actively deny this?" — and only a caller posing that question should see one.

    • isTermLevelOnly

      public boolean isTermLevelOnly()
    • termLevelOnly

      public AnnotationRelationDao.RelationQuery termLevelOnly(boolean v)
      Keep only relations that say something about the subject term, dropping per-experiment parameters. On by default, which is a change of behaviour made deliberately: the bookkeeping is roughly four rows in five, none of it is what a reader of a term wants, and every consumer was about to write its own list of predicates to exclude.

      Set false to get everything the harvest stored. Nothing is dropped from the table.

    • getMaxResults

      public int getMaxResults()
    • maxResults

      public AnnotationRelationDao.RelationQuery maxResults(int v)
    • isSeeded

      public boolean isSeeded()