2

I have a SPARQL CONSTRUCT like:

CONSTRUCT
{
  ?address
    schema:addressLocality ?city;
    schema:addressCountry ?country;
    schema:streetAddress ?addressLine;
    schema:postalCode ?zip;
    schema:addressRegion ?region.
}
WHERE
{
  ?address
    schema:addressLocality ?city;
    schema:addressCountry ?country. 

  OPTIONAL { ?address schema:streetAddress ?addressLine }
  OPTIONAL { ?address schema:postalCode ?zip }
  OPTIONAL { ?address schema:addressRegion ?region }
}

I'm getting fewer triples this way, than when the CONSTRUCT lists all the triple patterns explicitly, without omitting the subject for variables that are optional (ie, possibly unbounded):

CONSTRUCT
{
  ?address
    schema:addressLocality ?city;
    schema:addressCountry ?country.

  ?address schema:streetAddress ?addressLine.
  ?address schema:postalCode ?zip.
  ?address schema:addressRegion ?region.
}
...

I was assuming that the two forms can't influence the result, but now I'm gathering that instead the implicit subject syntax actually means something like "I want all the graph rooted on this subject or nothing at all for it". Is it like that? Is this behaviour specified by SPARQL, or is it the way it's implemented in certain engines (I'm on top of Virtuoso)?

Joshua Taylor
  • 84,998
  • 9
  • 154
  • 353
zakmck
  • 2,715
  • 1
  • 37
  • 53
  • This sounds like a bug. Some sample data that reproduces this problem would be nice, too. – Joshua Taylor Apr 19 '17 at 14:40
  • I'm not sure I understand your experience. Sample data, both input and output, as well as the exact version of Virtuoso, including whether it's Open Source or Commercial Edition, would help analysis a lot. If Open Source, you might [report an issue against the project](https://github.com/openlink/virtuoso-opensource/issues/). If Commercial or under Support Contract, you might [create a Support Case](http://support.openlinksw.com/support/online-support.vsp). (ObDislaimer: I work for [OpenLink Software](http://www.openlinksw.com/), maker of [Virtuoso](http://virtuoso.openlinksw.com/).) – TallTed Apr 19 '17 at 15:40
  • 4
    Sorry, you guys are right in asking for a use case, but I see this only on a reserved endpoint, which I cannot disclose. I've done tests against Fuseki and DBPedia, to try to reproduce the case, but they all work as per my initial assumption. I'm starting to think it's some kind of other problem, such as Virtuoso timing out the query and returning just what it achieved until the time went out, silently. The two graph pattern forms maybe influence the speed, so that could explain the different results, but I'm just guessing. – zakmck Apr 19 '17 at 17:20
  • Note that the DBpedia endpoint also runs on Virtuoso... Conversation is not appropriate here, but assistance with troubleshooting your private endpoint is available through the [Virtuoso Users mailing list](https://sourceforge.net/p/virtuoso/mailman/virtuoso-users/) or a [Support Case](http://support.openlinksw.com/support/online-support.vsp). – TallTed Apr 19 '17 at 21:07
  • Seems to clearly be a bug. I'd suggest follow up with Virutoso per @TallTed. – scotthenninger Apr 20 '17 at 04:17

1 Answers1

0

Not an ultimate answer, but at least what I've learned so far. As comments above say, SPARQL should return the same from either form.

I suspect that the problem arises from the fact that Virtuoso doesn't trigger an error when the query execution times out, it instead silently returns the results it achieved up to the time deadline. But I'm not sure of that either, since I don't see any special HTTP header in the response, as they suggest in the link I've mentioned.

zakmck
  • 2,715
  • 1
  • 37
  • 53