Some SPARQL queries fail on Virtuoso - create a VirtuosoSparql dialect ?

[tfrancart]

When using a connection to a Virtuoso-backed SPARQL endpoint, some queries fail :

SELECT * FROM <http://data.legilux.public.lu/resource/authority/legal-institution-history/graph>
WHERE {
  SELECT ?object ?label (GROUP_CONCAT(?dir) as ?direct)
  WHERE {
    <http://data.legilux.public.lu/resource/authority/legal-institution-historique/147> a skos:Concept .
    OPTIONAL {
      <http://data.legilux.public.lu/resource/authority/legal-institution-historique/147> skos:broader* ?object .
      OPTIONAL {
        ?object skos:broader ?dir .
      }
    }
    OPTIONAL {
      ?object skos:prefLabel ?label .
      FILTER (langMatches(lang(?label), "fr"))
    }
    OPTIONAL { ?object skos:prefLabel ?label }
  }
  GROUP BY ?object ?label
}
LIMIT 1000

This query can be tested at http://data.legilux.public.lu/sparql

Virtuoso requires a separator argument :

SELECT * FROM <http://data.legilux.public.lu/resource/authority/legal-institution-history/graph>
WHERE {
  SELECT ?object ?label (GROUP_CONCAT(?dir; separator=' ') as ?direct)
  WHERE {
    <http://data.legilux.public.lu/resource/authority/legal-institution-historique/147> a skos:Concept .
    OPTIONAL {
      <http://data.legilux.public.lu/resource/authority/legal-institution-historique/147> skos:broader* ?object .
      OPTIONAL {
        ?object skos:broader ?dir .
      }
    }
    OPTIONAL {
      ?object skos:prefLabel ?label .
      FILTER (langMatches(lang(?label), "fr"))
    }
    OPTIONAL { ?object skos:prefLabel ?label }
  }
  GROUP BY ?object ?label
}
LIMIT 1000

Should I subclass GenericSparql with a VirtuosoSparql maybe ?

[osma]

That's strange. Path expressions have been in SPARQL 1.1 for a long time. Are you using some old version of Virtuoso? I have minimal experience with it but I'd think this would be a pretty basic feature. It's hard to substitute by rewriting queries since * means a property can be chained any number of times.

[osma]

Go ahead and create a VirtuosoSparql class if it helps solve your problem. Note that we rely on class autoloading so you need to run composer update after adding a new class.

[osma]

Hmm, did you already resolve the transitive operator issue this was originally about?

The separator argument could be simply added to GenericSparql. No need to create a subclass just for that.

[tfrancart]

I initially jumped at the conclusion too fast : the problem was indeed with the separator, and not with transitive operator. I will create a PR to fix GenericSparql for this. Thanks 2017-10-26 19:22 GMT+02:00 Osma Suominen <[email protected]>:

…

Hmm, did you already resolve the transitive operator issue this was originally about? The separator argument could be simply added to GenericSparql. No need to create a subclass just for that. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#644 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACmj8XAJ8ld1ezWG2Ab6VQpsxgn4k8hZks5swL_jgaJpZM4QHuij> .

-- *Thomas Francart* -* SPARNA* Web de *données* | Architecture de l'*information* | Accès aux *connaissances* blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart tel : +33 (0)6.71.11.25.97, skype : francartthomas