reference libraries do not provide access to CURIEMap and InformationProvider for CURIE resolution

[schristley]

The singleton objects CURIEMap and InformationProvider are not obviously accessible to external tools. To use them in order to resolve CURIEs would require access and parsing of the schema file. The larger question though is should external tools perform their own CURIE resolution, or should the reference libraries provide functions to do that?

My initial thought is that encapsulation of the details about CURIEMap and InformationProvider is likely a good thing. That allows the structure of those objects to change over time if needed. A single function that accepts a CURIE string and returns a fully qualified URL would be base functionality. Maybe some parameters are needed if there are multiple providers to choose from? I can think of a couple other convenience functions that might be helpful too.

[bussec]

I agree that such a functionality would be useful, as it will provide a reference implementation showing how we expect the CURIE resolution to work. @schristley What exactly makes CURIEMap and InformationProvider singleton objects according to OpenAPI?

[schristley]

What exactly makes CURIEMap and InformationProvider singleton objects according to OpenAPI?

Nothing, that's just the terminology I use. You might call them global instances. OpenAPI doesn't support things like that in its spec, if you were to include the AIRR schema file as-is in an OpenAPI file, it would generate errors. That's because OpenAPI expects to see JSON schema definitions, i.e. contains stuff like type: object and properties: and so on.

The Info object at the top schema file is another example, that's not supported by OpenAPI either but it's useful documentation. The reason the ADC API spec works is because it doesn't include the AIRR schema file as whole, instead it includes only the specific schema definitions like Repertoire, Rearrangement and so on.