-
Notifications
You must be signed in to change notification settings - Fork 0
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
Revise differences in Transformer.functionToForm implementations #34
Comments
1. Change which statement objects of the function are transformed to sub questions.
Should we consider both selection patterns or the old one is obsolete?
|
2. Changes in sub query instance initialization.
This results
In both implementations Merge ActionUse old implementation.
|
ad 1) This is definitely valid way to define function parameter:
This is not a valid way to define the parameter of a function:
To me it is important to keep old way of doing this. In case you keep new way i do not care, but in the new way you should assume that the ?object is literal. |
More context regarding 1)[2] defines two type of questions generated from triples relevant to this discussion, i.e. Here is an example with a module. I could not find example for a function but it should be the same for functions. Consider the module
According to [2] there should be a Additionally, according to [1] it should be possible to specify any spin expression to a value of a parameter, that includes constant, variable and function call. Here is an example snippet from [3] where the pipeline uses variables as values for the parameters of
ConclusionBoth selection patterns should be considered in the merged implementation of
QuestionsNeither implementations will generate
[1] - spin documentation |
I still do not understand what following means:
Why do you have Moreover, I believe we should seek how to replace:
with something like (I just made it up, but there will be something like this:
Regarding to your question, we should generate StatementQuestions for two types:
Case 2) covers function calls as well. It is any SPARQL expression but written in text. The SPARQL expression can call functions as well. |
Revise differences in
Transformer.functionToForm
implementations:cz.cvut.spipes.transform.TransformerImpl.functionToForm
in s-pipes-forms module in cvut-kbss/s-pipesog_spipes.service.FormService.OwnTransformer.functionToForm
in cvut-kbss/s-pipes-editorThe text was updated successfully, but these errors were encountered: