Open fmigneault opened 4 years ago
@dbyrns @tomLandry Adding you guys for any docs/planing of projects and/or ideas.
We have a task in DACCS project to explore the catalog aspect of process listing. NLP should indeed be involved.
Ok understood. Aside from DACCS, I'll be on the lookout for good practices or recommendations from OGC in the testbeds. This might materialize late summer by itself, so let's keep in touch.
We have a task in DACCS project to explore the catalog aspect of process listing. NLP should indeed be involved.
This is why this entry is there 😉
At least up to version
1.5.x
, only 4 variants of process listing are available :GET /providers/{provider-id}/processes
which lists all remote & visible processes of that providerGET /processes
which lists all local & visible processesGET /processes?providers=true
which lists all local+remote & visible processes (essentially equivalent to combining previous two requests with iteration over all providers)detail=false
which returns only IDs instead of full descriptionsIn every case with detail turned on, we can get extremely verbose responses depending on the number of deployed processes. It is very hard in this case to search of a given use case or suitable process (even more so if doing paging as described in #55). On the other hand, with
detail=false
, only IDs often do not provide sufficient information to know if the process is appropriate for a given task/use-case.We should allow further requests parameters to support more advanced searches. A few ideas:
[ ] Support
keywords
which are usually provided in the processes description.,
for AND and|
for OR... (can't use&
that separates request parameters).!
or~
.[ ] Support
description
andtitle
search[ ] #626
[ ] #640
[ ] #645
[ ] #642
[ ] #627
[ ] #644
[ ] #643
[x]
datetime
to search for deployment/creation time (see #236 for format references)[ ] #641
[ ] #646 (must be listed for all above)