syntactic sugar for RDF lists not supported with `type: "stringSource"`

[smessie]

syntactic sugar for RDF lists not supported with `type: "stringSource"`

[surilindur]

Sorry about the delay, I was busy with other things. It seems the issue could be a mismatch between the prefix in the SPARQL query and the base IRI that gets passed for the data source parsing.

I used the data that was linked earlier, with the same prefix as in the live version linked above. So the query looked like this:

PREFIX ui: <http://www.w3.org/ns/ui#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX : <https://solid.smessie.com/private/tests/forms/solid-ui-books.ttl#>

SELECT ?field WHERE {
    :this ui:parts ?list .
    ?list rdf:rest*/rdf:first ?field .
}

And the source definition in the JavaScript code (following your example earlier) looked like this:

const source = {
  type: 'stringSource',
  value: sourceString,
  mediaType: 'text/turtle',
  baseIRI: 'https://solid.smessie.com/private/tests/forms/solid-ui-books.ttl', // <- this is where it failed, I guess
}

And it worked with the latest Comunica (v2.6.9 at the time of writing). Maybe the base IRI that gets assigned to the source does not match what the SPARQL query contains in your application? If the IRIs in the data (after parsing, taking into account the base IRI) are different from the ones in the SPARQL query it will not find the data (obviously). I guess that is the problem.

Hopefully that helps. At least it does not seem like a bug in the string source actor, thankfully. 😅

[github-actions]

Thanks for reporting!

[rubensworks]

Probably a similar issue as the bnode issue fixed in 4a0992d

n3Schema that does work because I rewrote the syntactic sugar to triples with rdf:first and rdf:rest:

Are you using blank nodes in that case?

@surilindur @constraintAutomaton Perhaps you two may have some insights into this issue?

[smessie]

Are you using blank nodes in that case?

With the syntactic sugar (so that's the case that it is not working), it is written as

:this
    a ui:Form ;
    ui:parts (
        :titleField
        :authorField
        :ratingField
        :reviewField
    ).

So yes, this uses blank nodes under the hood.

Without syntactic sugar (which works), I rewrote it with named nodes as

:this
    a ui:Form ;
    ui:parts :i1.

:i1 rdf:first :titleField; rdf:rest :i2.
:i2 rdf:first :authorField; rdf:rest :i3.
:i3 rdf:first :ratingField; rdf:rest :i4.
:i4 rdf:first :reviewField; rdf:rest rdf:nil.

[smessie]

Any update on this @rubensworks ?
I'm encountering the same issue in another place for my thesis so I'm stuck again :/

Now it's for blank nodes in general and not only lists

Example here which is working in the live version but not with type: "stringSource".

Data:

@prefix ex: <http://example.org/>.
@prefix ncal: <https://www.semanticdesktop.org/ontologies/2007/04/02/ncal/>.
@prefix pol: <https://www.example.org/ns/policy#>.
@prefix fno: <https://w3id.org/function/ontology#>.

ex:CompletedPolicy pol:policy [
   a fno:Execution ;
   fno:executes ex:toggleCompleted ;
   ex:insertTriples [
       ncal:completed "2023-03-11T16:34:38.015Z";
       ncal:todoStatus ncal:completedStatus
   ] ;
   ex:deleteTriples [
      ncal:todoStatus ncal:inProcessStatus
   ]
] .

Query:

PREFIX ex: <http://example.org/>
PREFIX pol: <https://www.example.org/ns/policy#>
PREFIX fno: <https://w3id.org/function/ontology#>

SELECT ?id ?policy ?executionTarget ?insertTriples ?deleteTriples ?ip ?io ?dp ?do WHERE {
  ?id pol:policy ?policy .
  ?policy a fno:Execution .
  ?policy fno:executes ?executionTarget .
  OPTIONAL {
    ?policy ex:insertTriples ?insertTriples .
    ?insertTriples ?ip ?io .
  } .
  OPTIONAL {
    ?policy ex:deleteTriples ?deleteTriples .
    ?deleteTriples ?dp ?do .
  } .
}

[rubensworks]

Pining @surilindur and @constraintAutomaton again.

[constraintAutomaton]

I'm not sure what is the problem, I will look into it Wednesday, sorry @smessie for the silence I was busy with the writing of a paper.

[smessie]

Thanks for looking into this @surilindur and sorry if this was due to a problem from my side!

Did you confirm getting this to work with changing the baseIRI? I am trying this but did not manage to get this working yet, but I'll keep trying in the meantime.

For completeness, my stringSource:

@base <https://solid.smessie.com/private/tests/todos/ncal-todos.ttl#> .
@prefix cal: <http://www.w3.org/2002/12/cal/ical#>.
@prefix ex: <http://example.org/>.
@prefix schema: <http://schema.org/>.
@prefix ncal: <https://www.semanticdesktop.org/ontologies/2007/04/02/ncal/>.
@prefix log: <http://www.w3.org/2000/10/swap/log#>.
@prefix pol: <https://www.example.org/ns/policy#>.
@prefix fno: <https://w3id.org/function/ontology#>.

ex:CompletedPolicy pol:policy _:sk_0.
_:sk_0 a fno:Execution.
_:sk_0 fno:executes ex:updateResource.
_:sk_0 ex:insertTriples _:sk_1.
_:sk_1 ncal:completed "2023-03-16T09:14:09.110Z".
_:sk_1 ncal:todoStatus ncal:completedStatus.
_:sk_0 ex:deleteTriples _:sk_2.
_:sk_2 ncal:todoStatus ncal:inProcessStatus.
_:sk_0 ex:subject <https://solid.smessie.com/private/tests/todos/ncal-todos.ttl##t1>.

My query:

PREFIX ex: <http://example.org/>
PREFIX pol: <https://www.example.org/ns/policy#>
PREFIX fno: <https://w3id.org/function/ontology#>

SELECT ?s ?p ?o WHERE {
  ?id pol:policy [
    a fno:Execution ;
    fno:executes ex:updateResource ;
    ex:subject ?s ;
    ex:insertTriples [
      ?p ?o
    ]
  ] .
}

My baseIRI: https://solid.smessie.com/private/tests/todos/ncal-todos.ttl#

[surilindur]

When I execute the query on the data as it is in your previous message, I get the following bindings out:

{
  "p": "https://www.semanticdesktop.org/ontologies/2007/04/02/ncal/completed",
  "o": "2023-03-16T09:14:09.110Z",
  "s": "https://solid.smessie.com/private/tests/todos/ncal-todos.ttl##t1"
}
{
  "p": "https://www.semanticdesktop.org/ontologies/2007/04/02/ncal/todoStatus",
  "o": "https://www.semanticdesktop.org/ontologies/2007/04/02/ncal/completedStatus",
  "s": "https://solid.smessie.com/private/tests/todos/ncal-todos.ttl##t1"The `@base` in the data 
}

Maybe there is something else happening with the way the query and the data are set up that breaks it for your setup?

[smessie]

After some more offline discussion with @surilindur we found out that he is using @comunica/query-sparql (latest version being 2.6.9) while I'm using @comunica/query-sparql-solid (latest version available being 2.4.0).

When I'm trying with @comunica/query-sparql: 2.6.9 it all works as expected, so I guess @comunica/query-sparql-solid will need an update so the patched @comunica/actor-rdf-resolve-quad-pattern-string-source gets included @rubensworks

[rubensworks]

so I guess @comunica/query-sparql-solid will need an update so the patched @comunica/actor-rdf-resolve-quad-pattern-string-source gets included

Just resetting your lockfile and node_modules, and re-installing should give you the latest version of @comunica/query-sparql.

[smessie]

Just resetting your lockfile and node_modules, and re-installing should give you the latest version of @comunica/query-sparql.

Removing both package-lock.json and node_modules and rerunning npm i actually do not seem to fix it while using @comunica/query-sparql-solid. Is this only for me?

[rubensworks]

Can you try with yarn? It's possible npm doesn't pull in the latest possible version in the semver range.

In any case, we should update the comunica version in https://github.com/comunica/comunica-feature-solid (PR is welcome).

Closing this issue in any case.