Unexpected result using LIMIT with CONSTRUCT

Question

Something strange is going on in this CONSTRUCT query using LIMIT. I would expect to receive 1 or 2 solutions for LIMIT 1 and LIMIT 2, respectively, i.e., one or two graphs, but instead I always get two graphs, with either 11 or 12 triples.

CONSTRUCT { 
  ex:sceneResource skos:related ?newSceneSubject.
  ?newSceneSubject a lcx:Scene ;
                   dcterms:subject ?type ; 
                   lcx:hasTitle ?title ;
                   lcx:describedBy ?thumbNail ;
                   lcx:motto ?motto ;
                   lcx:freebaseID ?freebaseID
}
WHERE { 
  { ?newSceneSubject a ex:interestType1 }
  UNION
  { ?newSceneSubject a ex:interestType2 } 
  ?newSceneSubject lcx:hasTitle ?title ;
                   a ?type .
                   lcx:freebaseID ?freebaseID .
  OPTIONAL { ?newSceneSubject lcx:motto ?motto  }
  OPTIONAL { ?newSceneSubject lcx:describedBy ?thumbNail }
}
LIMIT 2

Have I misunderstood LIMIT with CONSTRUCT, or is there a bug in the Jena API?

Answer 1

Your question is a little unclear as to what you were expecting and what you actually got but I will attempt to answer anyway.

The LIMIT applies to the WHERE portion of a query, in the specification there is an example of using LIMIT with CONSTRUCT and it states the following:

the output graph from the CONSTRUCT template is formed from just two of the solutions from graph pattern matching

i.e. it takes at most two rows from the WHERE clause and feeds them to the CONSTRUCT template.

Since the template can generate potentially many triples the actual maximum number of results is the limit multiplied by the number of triple patterns in your template. Since individual patterns in the template may generate invalid triples (and these are discarded per the specification) the actual number of triples you get may be lower:

If any such instantiation produces a triple containing an unbound variable or an illegal RDF construct, such as a literal in subject or predicate position, then that triple is not included in the output RDF graph

So from what you've described and the specification Jena's behavior is perfectly correct.