Revise differences in Transformer.functionToForm implementations

[kostobog]

Revise differences in Transformer.functionToForm implementations:

1. (old implementation) cz.cvut.spipes.transform.TransformerImpl.functionToForm in s-pipes-forms module in cvut-kbss/s-pipes
2. (new implementation) og_spipes.service.FormService.OwnTransformer.functionToForm in cvut-kbss/s-pipes-editor

[kostobog]

1. Change which statement objects of the function are transformed to sub questions.

• old implementation selects objects as follows:

  ?function spin:constraint ?constraint .
  ?constraint spl:predicate ?object .

• new implementation selects objects as follows:

  ?function sp:varName ?object .

Should we consider both selection patterns or the old one is obsolete?

• We use the spin:constraint selection pattern in at least one script, see script aircraft-maintenance-planning-system/aircraft-maintenance-planning-model/data/data-lib.ttl

[kostobog]

2. Changes in sub query instance initialization.

• old implementation creates and initializes question with:

  Question q = createQuestion(st.getObject().asResource());
  ...
  private Question createQuestion(Resource resource) {
      Question q = new Question();
      initializeQuestionUri(q);
      q.setLabel(resource.getURI());
      ... // extracting description from rdfs:label and rdfs:commnt statements.
      q.setDescription(...)
      return q;
  }

This results

• new implementation creates and initializes question with this code :

  
  Question q = new Question();
  initializeQuestionUri(q);
  q.setLabel(st.getObject().toString());

In both implementations `st.getObject` is the **object** as defined in comment [1. Change which statement objects of the function are transformed to sub questions.](https://github.com/kbss-cvut/s-pipes-editor-ui/issues/34#issuecomment-1699107705)

### Merge Action
Use old implementation.
Considerations:
  * old and new implementation uses a different method to set question label. The new implementation does not assume the **object** node is a resource. 
    * Is it possible that the selected **object** is a literal?
  * old implementation sets description of generated question. The new implementation does not.

[blcham]

ad 1)

This is definitely valid way to define function parameter:

?function spin:constraint ?constraint .
?constraint spl:predicate ?object .

This is not a valid way to define the parameter of a function:

?function sp:varName ?object .

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.

[kostobog]

@blcham

More context regarding 1)

[2] defines two type of questions generated from triples relevant to this discussion, i.e. StatementQuestion and SchemaQuestion. The SchemaQuestions are created only when there is a defined parameter for the function/template for which there is no statement.

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 kbss-module:rdf4j-update defined with two parameters p-rdf4j-server-url and p-rdf4j-repository-name. The following example shows statements of a module configuration of type kbss-module:rdf4j-update. The configuration specifies a value for the parameter p-rdf4j-server-url but not for p-rdf4j-repository-name.

:remove-old-statistics
  a kbss-module:rdf4j-update ;
  sm:next :mark-relevant-questions ;
  km-rdf4j:p-rdf4j-server-url "http://localhost:7200/repositories/some-repo-id" ;
  # p-rdf4j-repository-name  - not specified

According to [2] there should be a StatementQuestion generated for the p-rdf4j-server-url parameter and a SchemaQuestions generated for the km-rdf4j:p-rdf4j-repository-name parameter.

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 kbss-module:rdf4j-update module:

:bind-rdf4j-server-url
  a sml:BindWithConstant ;
  sm:next :bind-repository-name ;
  sm:outputVariable "rdf4jServerUrl" ;
  sml:value "http://localhost:8080/rdf4j-server" ;
.

:bind-repository-name
  a sml:BindWithConstant ;
  sm:next :remove-old-statistics ;
  sm:outputVariable "rdf4jRepositoryName" ;
  sml:value "record-manager-app" ;
.

:remove-old-statistics
  a kbss-module:rdf4j-update ;
  sm:next :mark-relevant-questions ;
  # binds variable expression to the 'p-rdf4j-server-url' parameter
  km-rdf4j:p-rdf4j-server-url [ sp:varName "rdf4jServerUrl" ;] ;
  # binds variable expression to the 'p-rdf4j-repository-name' parameter
  km-rdf4j:p-rdf4j-repository-name [ sp:varName "rdf4jRepositoryName" ; ] ;
...

Conclusion

Both selection patterns should be considered in the merged implementation of Transformer.functionToForm:

• old implementation selects objects - for the generation of SchemaQuestions

  ?function spin:constraint ?constraint .
  ?constraint spl:predicate ?object .

• new implementation selects objects - for the generation of StatementQuestions with a variable as the answer

  ?function sp:varName ?object .

Questions

Neither implementations will generate StatementQuestion for parameters with constant and function call expression values.

• Should we implement generation of StatementQuestion for parameters with constant expression value ?
• Should we implement generation of StatementQuestion for parameters with function call expression value ?

[1] - spin documentation [2] - Figure 26: Module configuration form generation in 2018-Doroshenko-Yan-thesis.pdf [3] - statistics-extraction.sms.ttl.gz

[blcham]

The script2form schema from [2]:

[blcham]

I still do not understand what following means:

?function sp:varName ?object .

Why do you have ?function variable?

---

Moreover, I believe we should seek how to replace:

km-rdf4j:p-rdf4j-repository-name [ sp:varName "rdf4jRepositoryName" ; ] ;

with something like (I just made it up, but there will be something like this:

km-rdf4j:p-rdf4j-repository-name [ a sp:expression; sp:text "?rdf4jRepositoryName" ; ] ;

---

Regarding to your question, we should generate StatementQuestions for two types: 1) km-rdf4j:p-rdf4j-repository-name "my-repository" ; 2) something like km-rdf4j:p-rdf4j-repository-name [ a sp:expression; sp:text "?rdf4jRepositoryName" ; ] ;

Case 2) covers function calls as well. It is any SPARQL expression but written in text. The SPARQL expression can call functions as well.