[QUESTION] Clarifications on expected behavior of constraints

[brettasmi]

1. What do >, <, <=, and >= mean with an array type? I remember this was discussed at some point, but I don't think it's in the implementation rules or TRAPI spec.

2. Does UnsupportedConstraint return a 200 ("understood but unsupported") or 400 ("I advertised this in my MetaKG, so your request is bad") edit: or 501? 🤔

3. If we have multiple attributes on a node / edge that map to the same CURIE as specified in the QueryConstraint.id, do we constrain across all of our internal attributes or just leave the relevant attributes unsupported for constraints at the moment? Ideally we'll get fine enough resolution of these concepts in biolink such that is never the problem, but that's not the case yet.

[edeutsch]

1. It is in the spec, in great detail:

       operator:
         type: string
         description: >-
           Relationship between the database value and the constraint value
           for the specified id. The operators ==, >, and < mean
           is exactly equal to, is greater than, and is less than,
           respectively. The 'matches' operator indicates that the value
           is a regular expression to be evaluated. If value is a list type,
           then at least one evaluation must be true (equivalent to OR).
           This means that the == operator with a list acts like a SQL 'IN'
           clause. The 'not' property negates the operator such that not
           and == means 'not equal to' (or 'not in' for a list), and not >
           means <=, and not < means >=, and not matches means does not
           match. The '==' operator SHOULD NOT be used in a manner that
           describes an "is a" subclass relationship for the parent QNode.
         enum:
           - ==
           - '>'
           - <
           - matches
       value:
         example: 57.0
         description: >-
           Value of the attribute. May be any data type, including a list.
           If the value is a list and there are multiple items, at least one
           comparison must be true (equivalent to OR). If 'value' is of data
           type 'object', the keys of the object MAY be treated as a list.
           A 'list' data type paired with the '>' or '<' operators will
           encode extraneous comparisons, but this is permitted as it is in
           SQL and other languages.

2. Although I'm a fan of not trying to shoehorn meaning into HTTP codes (and just always return TRAPI that carefully explains the problem), it seems like the general consensus is to return 400

3. Sorry, I don't understand this question.

[brettasmi]

Thanks @edeutsch! I think the sentence following the OR definition: "This means that the == operator with a list acts like a SQL 'IN' clause" made me think that it was specific to the == operator. So to confirm, for a constraint defined as

  'operator': '<',
  'value': [3, 4, 5],
...

any value less than 5 is valid?

I don't think I need a response on question 3, because I'll just leave them unavailable for constraint at the moment. To clarify a bit what I mean though in case it's helpful for anyone else: we have a situation on some edges where multiple attributes end up with the same biolink slot type, e.g. biolink:has_evidence. The attributes are different internally, e.g. co-occurrence score, fisher, etc, but finer-grained biolink slots are not yet available to describe them exactly.

I was asking how to handle requests with constraint on biolink:has_evidence to an edge that has multiple biolink:has_evidence attributes. I think the answer is to handle them as 'OR' , but I think the best course of action is probably to wait until a newer version of biolink supports these attributes at a finer level before offering to constrain them to the caller.

[edeutsch]

Thanks @edeutsch! I think the sentence following the OR definition: "This means that the == operator with a list acts like a SQL 'IN' clause" made me think that it was specific to the == operator.

Just an example of the most likely scenario. A list is not exclusive to ==.

'operator': '<', 'value': [3, 4, 5], any value less than 5 is valid?

correct. Or more formally the SQL equivalent would be: where value < 3 or value < 4 or value < 5 which is a bit silly, but is legal SQL and legal Python and legal TRAPI.

[brettasmi]

Thanks again @edeutsch.

Closing the issues since my questions have been answered.