Identifiers as filters

[mbaudis]

A filter sent to a beacon as part of the request is defined as

    anyOf:
      - $ref: '#/$defs/OntologyFilter'
      - $ref: '#/$defs/AlphanumericFilter'
      - $ref: '#/$defs/CustomFilter'  

... where an OntologyFilter has the description to Filter results to include records that contain a specific ontology term.; and the OntologyFilter.id is the Term ID to be queried, using CURIE syntax where possible..

However, this leaves the problem of stable identifiers which are not part of ontologies on the "classical sense" but essential for many types of queries and fulfill the CURIE part with registration at identifiers.org et al. Examples:

• pubmed:35297548
• cellosaurus:CVCL_0030 (cell line identifiers - have actually a hierarchy...)

Action Item

• Option A: Extend the definition of OntologyFilter to ... ontology term or identifier - easy and implementers do it like that anyway
• Option B: Define a dedicated '#/$defs/IdentifierFilter' ... which follows the OntologyFilter definition (I guess minus "similarity")

In practice both options would be non-breaking changes.

[mbaudis]

@tb143 @zykonda Comments?

[jrambla]

Which would be the consequences in the ontologyTerm schema, if any?

[redmitry]

IMO the filter identifier hadn't be the ontological term in a first place. There should have been the:

"id" - the filter id e.g. "age_of_disease_onset"
"term" - ontological term for the age

D.

[mbaudis]

@redmitry No - filters were originally designed as being self scoped, basically only ids.

[mbaudis]

@jrambla If we just say that "CURIE ... e.g. ontology term ids or prefixed identifiers" that's fine but as you experienced the filteringTerms endpoint then could flood the response (as I demonstrated involuntarily w/ pubmed:.. instances). So it might be better to have an identifierFilter which only is a CURIE or DOI (no expansion, negation etc.). But right now just treating object identifiers the same as ontology identifiers is totally fine.

[jrambla]

I assume that "resource" would be ignored or not needed in this case, or would it?

[mbaudis]

No; you want to point to the source for resolving the identifier and see e.g. info from identifiers.org for pubmed.

Although the Resource definition in the beaconFilteringTermsResults is misleading/overdoing it since the CURIE should be used by clients for lookups. Beacons should not provide some separate definition which might diverge per resource; there is no use case for maintaining a separate data structure (unless describing private filters but then the parts like iriPrefix etc. don't apply).

[mbaudis]

Picking this up again. Additional thoughts:

• if we accept (and document) that OntologyFilter applies to anything "hierarchical classification system" (see e.g. my example for cellosaurus cell line identifiers - hierarchy shown here) we are already halfway there
• ... in which case we can limit IdentifierFilter

IdentifierFilter:
    type: object
    description: >-
      Filter results to include records that reference to a given reference such as a publication or data resource.
    required:
      - id
    properties:
      id:
        type: string
        description: >-
          Resource ID to be queried, using CURIE or DOI syntax
        examples:
          - pubmed:28966033
          - doi.org/10.1159/000134448