How should the API for this work? I was thinking that it would make sense to think about it as:
1) increased depth from an entry point (finding derived_from elements).
2) decreased depth from an entry point (derived_using, not a real tag but derived_from in reverse).
3) find all paths to/from some file. (-[:DERIVED_FROM*1..n]-)
4) find all files with provided label(s) and parameter(s).
All will accept both GET for single value and POST for JSON objects with parameters. The URLs will be constructed as api/v1/<DATA_TYPE|METHOD>/[<SUBMETHODS/TYPES>]/ for GETs and
api/v1/<DATA_TYPE|METHOD>/[<SUBMETHODS/TYPES>] for POSTs
This outline solves the issue of taking a file(s) and finding its/their "relatives". Other problems may arise that we can then design solid queries against.
How should the API for this work? I was thinking that it would make sense to think about it as:
1) increased depth from an entry point (finding derived_from elements). 2) decreased depth from an entry point (derived_using, not a real tag but derived_from in reverse). 3) find all paths to/from some file. (-[:DERIVED_FROM*1..n]-) 4) find all files with provided label(s) and parameter(s).
All will accept both GET for single value and POST for JSON objects with parameters. The URLs will be constructed as api/v1/<DATA_TYPE|METHOD>/[<SUBMETHODS/TYPES>]/ for GETs and
api/v1/<DATA_TYPE|METHOD>/[<SUBMETHODS/TYPES>] for POSTs
This outline solves the issue of taking a file(s) and finding its/their "relatives". Other problems may arise that we can then design solid queries against.