Specify some canonical API for possibleValuesFromApi

[Ostrzyciel]

In the nanopub vocabulary there is this property: https://peta-pico.github.io/npo/ntemplate/index-en.html#https://w3id.org/np/o/ntemplate/possibleValuesFromApi

It looks very useful, and I'd gladly use it with my application, but it's not clear at all what kind of API is expected here. I had a look at Nanodash's source code, and the best I've found is this: https://peta-pico.github.io/npo/ntemplate/index-en.html#https://w3id.org/np/o/ntemplate/possibleValuesFromApi

...which appears to be a series of hardcoded behaviors for different specific endpoints. This is obviously not very sustainable. The last block in the chain of else ifs seems to be the "default" behavior – something that I could potentially use. But the schema of this is not clear to me. I can of course reverse-engineer this, but then I still would have no guarantee that this behavior won't change in the near future.

My proposal here is to specify in the vocabulary what kind of API is expected, at least as a textual description, but of course, something like an OpenAPI spec would be better :) Then we would have some "canonical" behavior that Nanodash would implement by default, while maintaining its special cases that are already there.

For what it's worth, my use case is that I want to point Nanodash to get the list of possible values from static file published on GitHub Pages, published automatically by CI. This way the possible values in the Nanodash template would be automatically updated whenever I add/remove a term in my ontology. I could alternatively publish these terms in CI to a dedicated nanopub and use the possibleValuesFrom property, but it would be way more complex and I'd also need to update the template itself every time. Not very sustainable.

[tkuhn]

Yes, you are right. It seems you pasted the same link twice. You probably meant this one as the second link: https://github.com/knowledgepixels/nanodash/blob/master/src/main/java/com/knowledgepixels/nanodash/LookupApis.java

It's a big hack and should be improved at some point. But it also works reasonably well for now, so it's not a very high priority at this point.

But we can definitely make sure that your case of a static file from GitHub Pages works.

The catch-all part expects a JSON file like this (if I remember correctly):

{ [
  { "uri": "http://example.com/apple", "label": "Apple" },
  { "uri": "http://example.com/banana", "label": "Banana" }
] }

You could try serve such a file from GitHub Pages. But if it doesn't work or if you need a different format, we can look how to make it work with some more hacked-together code in Nanodash :)

[Ostrzyciel]

Ah, ok, thanks! I'll try that and see if it works.