Catrina; A correction on this. Since the result of an IterateOverSelect is the union of the results of all subscripts, if the IterateOverSelect module does not run any subscripts then by definition the result should be the null set. If you want to have the input triples merged with the result, then you will need to merge the input triples with the sm:next from the IterateOverSelect.
Sorry for the confusion, but in the end no damage done. The "workaround" I suggest is what you will need to do to get your desired results. -- Scott On Nov 20, 12:30 pm, Scott Henninger <[email protected]> wrote: > Catrina; Yes, the expectation is that if the IterateOverSelect query > returns no rows, then the input triples should be passed to next. > This is a defect we will fix. > > The workaround is to add a sm:next from the module before the > IterateOverSelect to the sm:next from IterateOverSelect. This will > work whether or not new triples are created in the body of the iterate > module, as the triples will be merged. > > Thanks for the report! > -- Scott > > On Nov 20, 8:41 am, Catrina <[email protected]> > wrote: > > > When I send data through a script that contains an IterateOverSelect > > module, I'm reaching some unexpected results. > > > If my data contains something that meets the select query criteria, > > and the body of the IterateOverSelect module is executed, then the > > IterateOverSelect's next module receives all of the expected triples. > > > However, if my data does NOT contain anything that meets the select > > query criteria of the IterateOverSelect's module, then the next module > > does not receive any of the triples moving through the script. > > > It appears that everything is dropped from the data moving through the > > script if the IterateOverSelect module does not execute at least once. > > > Shouldn't the next module receive all triples that went into the > > IterateOverSelect module? > > > -------------------------------- > > OUTLINED EXAMPLE: > > The body of my IterateOverSelect module is just logging a message (it > > does not manipulate the incoming triples). The select query contains > > SPARQL looking for the virtual property: > > SELECT ?loopTestNode > > WHERE { > > ?loopTestNode <http://www.myURI.com/GSIVocabulary#virtual> ? > > loopTestObj . > > > } > > > INPUT FILE 1: > > <skos:Concept xmlns:skos="http://www.w3.org/2004/02/skos/core"; > > xmlns:gsi="http://www.myURI.com/GSIVocabulary"; gsi:virtual="false" > > gsi:topicName="All Topics" gsi:topicOrder="0" skos:prefLabel="All > > Topics 573"></skos:Concept> > > > INPUT FILE 2: > > <skos:Concept xmlns:skos="http://www.w3.org/2004/02/skos/core"; > > xmlns:gsi="http://www.myURI.com/GSIVocabulary"; gsi:topicName="All > > Topics" gsi:topicOrder="0" skos:prefLabel="All Topics 573"></ > > skos:Concept> > > > As you can see, the only difference between the two input XML is that > > the first one contains a virtual attribute (the second file does not). > > > My RDF output from INPUT FILE 1 contains the expected result of the > > imported skos:Concept from the XML. > > > However, my RDF output from INPUT FILE 2 does not contain any of the > > data imported from the XML. > > > Thanks, > > Catrina -- You received this message because you are subscribed to the Google Groups "TopBraid Composer Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/topbraid-composer-users?hl=.
