Class DatasetsWebService.StatementCommit

java.lang.Object
ubic.gemma.rest.DatasetsWebService.EntityRef
ubic.gemma.rest.DatasetsWebService.StatementCommit
Enclosing class:
DatasetsWebService
public static class DatasetsWebService.StatementCommit extends DatasetsWebService.EntityRef
One statement (subject / predicate / object triple with an optional category).
Author:
tesarst

  • Constructor Details

    • StatementCommit

      public StatementCommit()

  • Method Details

    • getCategory

      @Nullable public DatasetsWebService.OntologyTermRef getCategory()

    • getSubject

      @Nullable public DatasetsWebService.OntologyTermRef getSubject()

    • getPredicate

      @Nullable public DatasetsWebService.OntologyTermRef getPredicate()

    • getObject

      @Nullable public DatasetsWebService.OntologyTermRef getObject()

    • getSecondPredicate

      @Nullable public DatasetsWebService.OntologyTermRef getSecondPredicate()
      The second predicate-object pair, for a statement that makes two claims about one subject.

      Why these are on the REQUEST type and hidden on the response

      StatementValueObject's second* slots carry @WithheldFromApi because a compound statement is SERIALIZED flattened — two statements[] entries sharing one id, the second putting its clause under the generic keys (#814, dff752727c). That contract governs reads. This is the request type, so it is free to say the thing plainly, and a writer no longer has to reproduce the flattening to be understood.

      🛑 A Statement row holds exactly TWO pairs, so there is no third. Both halves or neither: a predicate with no object is not a pair and is refused rather than half-stored.

      The flattened form still works for a statement that already has an id — ExpressionExperimentServiceImpl.unflattenStatements re-joins it — but it could never express a pair on a NEW statement, because the re-join keys on a non-null id and id-less rows pass through as two separate single-clause statements. 9,031 production rows carry a pair that no client could create until these fields existed (cab, 2026-09-08). Sending both forms for one statement is a 400, not a merge.

    • getSecondObject

      @Nullable public DatasetsWebService.OntologyTermRef getSecondObject()

    • getSupportingEvidence

      @Nullable public com.fasterxml.jackson.databind.JsonNode getSupportingEvidence()
      Verbatim provenance for this statement — a JSON array of {quote, source, location, …} items. Stored and served opaquely; the agents repo owns the schema.

      The statement is the level that matters most for composed patterns, where the operative claim lives in the triple rather than in the parent factor value: two factor values whose labels are byte-identical and differ only by a zygosity statement cannot be told apart by evidence hung on the value.

      Null / omitted leaves any evidence already recorded untouched, so a client that does not carry provenance cannot wipe provenance somebody else recorded.

      🛑 An EMPTY ARRAY is the same as omitting it, NOT an erase. A payload built from a reference file stamps [] on every entity that has no evidence, and reading that as "clear it" would wipe stored provenance on every entity such a write touches while reporting an ordinary success. There is deliberately no way to clear evidence through this route.

    • getEvidenceCode

      @Nullable public String getEvidenceCode()
      How this statement was arrived at, as a GOEvidenceCode name. Accepted case-insensitively; an unrecognised code is a 400 on the commit and on the preflight, never a silent drop.

      Omitting it preserves the behaviour this route has always had, which differs by where the statement lands: a statement under design.factors[].factorValues[].statements keeps whatever code it carries (none, for a new one), while a statement-shaped tags item takes the IC the add path fills in. Nothing changes for a caller that does not send the field.

    • setCategory

      public void setCategory(@Nullable DatasetsWebService.OntologyTermRef category)

    • setSubject

      public void setSubject(@Nullable DatasetsWebService.OntologyTermRef subject)

    • setPredicate

      public void setPredicate(@Nullable DatasetsWebService.OntologyTermRef predicate)

    • setObject

      public void setObject(@Nullable DatasetsWebService.OntologyTermRef object)

    • setSecondPredicate

      public void setSecondPredicate(@Nullable DatasetsWebService.OntologyTermRef secondPredicate)
      The second predicate-object pair, for a statement that makes two claims about one subject.

      Why these are on the REQUEST type and hidden on the response

      StatementValueObject's second* slots carry @WithheldFromApi because a compound statement is SERIALIZED flattened — two statements[] entries sharing one id, the second putting its clause under the generic keys (#814, dff752727c). That contract governs reads. This is the request type, so it is free to say the thing plainly, and a writer no longer has to reproduce the flattening to be understood.

      🛑 A Statement row holds exactly TWO pairs, so there is no third. Both halves or neither: a predicate with no object is not a pair and is refused rather than half-stored.

      The flattened form still works for a statement that already has an id — ExpressionExperimentServiceImpl.unflattenStatements re-joins it — but it could never express a pair on a NEW statement, because the re-join keys on a non-null id and id-less rows pass through as two separate single-clause statements. 9,031 production rows carry a pair that no client could create until these fields existed (cab, 2026-09-08). Sending both forms for one statement is a 400, not a merge.

    • setSecondObject

      public void setSecondObject(@Nullable DatasetsWebService.OntologyTermRef secondObject)

    • setSupportingEvidence

      public void setSupportingEvidence(@Nullable com.fasterxml.jackson.databind.JsonNode supportingEvidence)
      Verbatim provenance for this statement — a JSON array of {quote, source, location, …} items. Stored and served opaquely; the agents repo owns the schema.

      The statement is the level that matters most for composed patterns, where the operative claim lives in the triple rather than in the parent factor value: two factor values whose labels are byte-identical and differ only by a zygosity statement cannot be told apart by evidence hung on the value.

      Null / omitted leaves any evidence already recorded untouched, so a client that does not carry provenance cannot wipe provenance somebody else recorded.

      🛑 An EMPTY ARRAY is the same as omitting it, NOT an erase. A payload built from a reference file stamps [] on every entity that has no evidence, and reading that as "clear it" would wipe stored provenance on every entity such a write touches while reporting an ordinary success. There is deliberately no way to clear evidence through this route.

    • setEvidenceCode

      public void setEvidenceCode(@Nullable String evidenceCode)
      How this statement was arrived at, as a GOEvidenceCode name. Accepted case-insensitively; an unrecognised code is a 400 on the commit and on the preflight, never a silent drop.

      Omitting it preserves the behaviour this route has always had, which differs by where the statement lands: a statement under design.factors[].factorValues[].statements keeps whatever code it carries (none, for a new one), while a statement-shaped tags item takes the IC the add path fills in. Nothing changes for a caller that does not send the field.

    • toString

      public String toString()
      Overrides:
      toString in class DatasetsWebService.EntityRef

    • equals

      public boolean equals(Object o)
      Overrides:
      equals in class DatasetsWebService.EntityRef

    • canEqual

      protected boolean canEqual(Object other)
      Overrides:
      canEqual in class DatasetsWebService.EntityRef

    • hashCode

      public int hashCode()
      Overrides:
      hashCode in class DatasetsWebService.EntityRef