/types now returns: 'label', 'id' (curie), 'iri' and 'frequency' whereas the /predicates shows 'id', 'name' and 'definition'.
It may make sense to 1) harmonize the /types and /predicates calls to return similar metadata
2) also return Biolink metadata for /predicates
The Biolink Model YAML file does provide term descriptions which could be reported (maybe the Biolink-model-java submodule form beacon-ontology may need more code to return them... not sure). Such descriptions could be returned for both /types and /predicates(?).
/predicates could also return 'frequency' of usage of those predicates in statements in a given knowledge base (since such frequency statistics are visible in a form in /kmaps already!)
/predicates fields returned could perhaps be harmonized with /types: i.e. 'label', 'id' (curie), 'iri' and 'frequency' plus the suggested 'description' (instead of 'definition'?)
We've also been discussing the addition of two new fields: 'local_id' and 'local_label' which could hold the CURIE and name of a term as it is locally defined defined or used in the knowledge source, (e.g. RO or SIO term?)
/types now returns: 'label', 'id' (curie), 'iri' and 'frequency' whereas the /predicates shows 'id', 'name' and 'definition'.
It may make sense to 1) harmonize the /types and /predicates calls to return similar metadata 2) also return Biolink metadata for /predicates
The Biolink Model YAML file does provide term descriptions which could be reported (maybe the Biolink-model-java submodule form beacon-ontology may need more code to return them... not sure). Such descriptions could be returned for both /types and /predicates(?).
/predicates could also return 'frequency' of usage of those predicates in statements in a given knowledge base (since such frequency statistics are visible in a form in /kmaps already!)
/predicates fields returned could perhaps be harmonized with /types: i.e. 'label', 'id' (curie), 'iri' and 'frequency' plus the suggested 'description' (instead of 'definition'?)
We've also been discussing the addition of two new fields: 'local_id' and 'local_label' which could hold the CURIE and name of a term as it is locally defined defined or used in the knowledge source, (e.g. RO or SIO term?)