Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify internal operations #41

Open
nsbgn opened this issue Sep 27, 2021 · 0 comments
Open

Simplify internal operations #41

nsbgn opened this issue Sep 27, 2021 · 0 comments
Labels
enhancement New feature or request performance Optimization issues.

Comments

@nsbgn
Copy link
Contributor

nsbgn commented Sep 27, 2021

The attached notes may help in understanding the following rambling.

Right now, we create an internal operation for every operation-as-parameter, and connect them to all parameter values that may be available to them.

This is relatively straightforward for one level of nesting, but it gets unwieldy for operations that are nested inside parameters. Consider that the internal part of an outer operation has access to parameter values that may be passed along to the beginning of the pipeline of the inner operations. So the inner internals must be fed with data produced by outer internals. Therefore, adding ta:feed connections from outer internals to inner internals is the proposed method for dealing with issue #37; see the red lines in the notes.

However, it may be possible instead to use only a single internal operation as a 'black box' for everything that happens 'inside' an operation. Additional operations-as-parameters, as well as nested operations, would simply reuse that one node.

This solution would require cycles (due to the interaction between the internal operation and the unknown order in which it uses other values available to it), but cycles were already possible (see https://github.com/quangis/transformation-algebra/blob/c3474c6c42ff992a4d760c62662a178d29dd577a/tests/test_rdf.py#L269), albeit only in the case of one operation with multiple operations-as-parameters.

The solution would reduce the number of triples. However, it needs deeper consideration before being implemented. What information would we lose by doing it this way? Is the increased occurrence of cycles a performance concern?

@nsbgn nsbgn added enhancement New feature or request performance Optimization issues. labels Sep 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request performance Optimization issues.
Projects
None yet
Development

No branches or pull requests

1 participant