update change/migration/spec docs, Lint fix

ChangeLog.md

@@ -1,3 +1,8 @@
+# Change Log  2.0.0-beta (2026-04-02) -> 2.0.0 (TBD)
+
+- Make AttributeConstraint.name optional, adjust descriptions in AttributeConstraint and Attribute specs ([PR](https://github.com/NCATSTranslator/ReasonerAPI/pull/563/changes))
+
+
 # Change Log  1.6.0-beta (2025-06-06) -> 2.0.0-beta (2026-04-02)
 
 ### 1. QEdge Constraints Refactor (see [migration guide entry](https://github.com/NCATSTranslator/ReasonerAPI/blob/2.0/ImplementationGuidance/MigrationGuides/MigrationAndImplementationGuide2-0.md#1-qedge-constraints-refactor), [reference doc entry](https://github.com/NCATSTranslator/ReasonerAPI/blob/2.0/docs/reference.md#qedge-))

ImplementationGuidance/DataExamples/2-0_example_response.json

@@ -61,7 +61,6 @@
             "attributes": [
               {
                 "id": "biolink:z_score",
-                "name": "z-score",
                 "operator": ">",
                 "value": 5
               }

ImplementationGuidance/MigrationGuides/MigrationAndImplementationGuide2-0.md

@@ -69,7 +69,7 @@ In 2.0, there is instead one property on a QEdge, `constraints`, that holds all
 * `agent_type`: see above (KL)
    * FYI: if a specified value has descendants (ex: `automated_agent`), the tool MUST treat those descendants (ex: `text_mining_agent`, etc.) as if they were included in the `values` array (i.e. "hierarchy expansion").
 * `sources`: this constrains the Edge `sources`. It has the same keys as KL/AT (`behavior`, `values`) plus the optional `primary_only` (if true, the constraint ONLY applies to the `primary_knowledge_source`). 
-* `attributes`: minItems 1, otherwise the same as previous `attribute_constraints`
+* `attributes`: minItems 1 and `name` no longer required, otherwise the same as previous `attribute_constraints`
 * `qualifiers`: simplified format to an array of objects but preserved previous behavior. Each object represents a qualifier-set, and multiple objects/sets have an `OR` relationship. Within an object, the keys are the "qualifier-type-ids" and their values are the "qualifier values". Multiple key/value pairs in one object/set have an `AND` relationship. 
 
 **NOTE on SUBCLASSING**: we haven't decided yet how QEdge constraints work with subclassing. For now, QEdge constraints should only apply to the bound Edges (constructed in subclassing cases), NOT to the bound Edge's support_graph edges. QNode constraints also has this ambiguity/confusion with subclassing. 
@@ -93,7 +93,6 @@ In 2.0, there is instead one property on a QEdge, `constraints`, that holds all
         "attributes": [
             {
                 "id": "biolink:z_score",    // regular attribute constraint
-                "name": "z-score",
                 "operator": ">",
                 "value": 5
             }
@@ -448,6 +447,7 @@ It was previously required, but never used and its empty arrays bloated response
 
 These properties were changed to not required:
 * `Nodes.attributes`
+* `AttributeConstraint.name` ([PR](https://github.com/NCATSTranslator/ReasonerAPI/pull/563/changes))
 * `QueryGraph` `edges` and `paths`: to accommodate queries with only nodes
 * `KnowledgeGraph.edges`: same reason as above
 * `Result.analyses`: same reason as above

ImplementationGuidance/Specifications/qedge_constraints_specification.md

@@ -109,9 +109,8 @@ The matched Edge's `primary_knowledge_source` should NOT be `infores:semmeddb` o
 
 Attribute constraints are presented as a list of attribute constraint objects. Each attribute constraint object constrains a specific attribute type. Multiple attribute constraints together represent an AND relationship, such that all attribute constraints must be met.
 
-Every attribute constraint must supply a `name`, `id`, `value`, and `operator`:
+Every attribute constraint must supply a `id`, `value`, and `operator`:
 
-- `name`: For human use, this just specifies the intent of the constraint.
 - `id`: This targets the constraint to attributes with a specific `attribute_type_id`.
 - `value`: Provides a value with which the targeted attribute must agree.
 - `operator`: Provides the relationship to the `value` that targeted attributes must fulfill.
@@ -124,7 +123,6 @@ In the most simple case, the operator `===` requires that edges must have an att
 
 ```json
 {
-    "name": "Must have the exact given publication list",
     "id": "biolink:publications",
     "operator": "===",
     "value": ["PMID:1234", "PMID:4567"]
@@ -205,7 +203,6 @@ The only operator for which this behavior is not held is `===` (strict equality)
         "attributes": [
             {
                 "id": "biolink:z_score",    // regular attribute constraint
-                "name": "z-score",
                 "operator": ">",
                 "value": 5
             }

TranslatorReasonerAPI.yaml

@@ -1630,8 +1630,8 @@ components:
           description: >-
             Human-readable name or label for the constraint concept.
             It SHOULD be the term name of the CURIE used
-            as the 'id' and SHOULD NOT supersede the use of AttributeConstraint.id (which
-            is required). This is redundant but recommended for human
+            as the 'id' and SHOULD NOT supersede the use of AttributeConstraint.id 
+            (which is required). This is redundant but recommended for human
             readability.
           examples:
             - molecular mass