Fix construct-matched-person lastName binding

[palagdan]

Resolves #269

[palagdan]

@blcham
I tried using different variables for lastName in the inner and outer queries, and it worked. I’m not sure why this makes a difference. Do you have any suggestions?

[palagdan]

@blcham

I worked on the JSON-LD output and identified several issues that I want to explain below:

1. RDFNode as a Resource: If the RDFNode is a resource, I added "@type": "@id". This change addresses an error I encountered on the frontend, where I needed to retrieve just a URI but instead received a nested object with @id.

   

   Now, it does not nest the object and resolves the URI properly.

   

2. Primitive Types: I removed @type for primitives because adding it for strings broke the JSON-LD, and for other primitives like integers, it did not resolve the prefix at all.

   

   Without the @type, it works correctly:

   

3. Prefix Resolution: I added "ValidationConstraintError": "http://onto.fel.cvut.cz/ontologies/s-pipes/ValidationConstraintError" to the context because the prefix wasn't resolving before:

   

   Now it resolves correctly:

   

[blcham]

@palagdan I believe we discussed that null values are not shown properly so PR should handle it as well. Thus not merging the PR yet.

[palagdan]

@blcham
Currently, the output includes input variables that are null. In the case of the lastName example, when it is null, the context contains information about the variable, but it is not included in the evidence because we don't include these variables in the model

  e.forEach((key, value) -> {
                    if(value != null){
                        model.add(
                                r,
                                getP(key),
                                value);
                    }
             });
            evidenceRe

[blcham]

@palagdan yes, that is correct behaviour. Maybe it will be harder to visualize in backend and thus more appropriate solution would be also to include ordered column list as well ... so think about it if it is not needed to simplify frontend visualization of the table, closing this issue