Catrina;  There is no need for a BranchByAsk.  Just pass the triples
being sent to your IterateOverSelect module to the module(s) specified
in the sm:next of the IterateOverSelect module.  This will ensure that
all of the triples passed to IterateOverSelect module are passed to
modules after IterateOverSelect is executed.

-- Scott

On Nov 24, 8:08 am, Catrina <catrina.pend...@thomsonreuters.com>
wrote:
> Then, you should really have the IterateOverSelect module wrapped in a
> BranchByAsk module (which seems a bit out of ordinary coding practice
> - sort of like wrapping a for loop with an if statement).  Otherwise,
> you'll end up passing through triples that you modified or removed
> during the body of the IterateOverSelect module.
>
> ~Catrina
>
> On Nov 23, 1:37 pm, Scott Henninger <shennin...@topquadrant.com>
> wrote:
>
> > 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 <shennin...@topquadrant.com>
> > 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 <catrina.pend...@thomsonreuters.com>
> > > 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- Hide quoted text -
>
> > - Show quoted text -

--

You received this message because you are subscribed to the Google Groups 
"TopBraid Composer Users" group.
To post to this group, send email to topbraid-composer-us...@googlegroups.com.
To unsubscribe from this group, send email to 
topbraid-composer-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/topbraid-composer-users?hl=en.


Reply via email to