You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
The text was updated successfully, but these errors were encountered:
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?
The text was updated successfully, but these errors were encountered: