That's a good idea!  Thanks!

> -----Original Message-----
> From: [email protected] [mailto:topbraid-
> [email protected]] On Behalf Of Holger Knublauch
> Sent: Wednesday, September 16, 2009 9:19 PM
> To: [email protected]
> Subject: [tbc-users] Re: Iterate over select
> 
> 
> Tim,
> 
> if you need global "variables", why don't you just write them to some
> named graph using sml:PerformUpdate. This way you can even increase
> counters.
> 
> But we are (internally) discussing various design alternatives right
> now, to cover the typical use cases of sml:IterateOverSelect. Not sure
> what's the best solution for all these scenarios.
> 
> Holger
> 
> 
> On Sep 16, 2009, at 6:11 PM, Smith, Tim wrote:
> 
> >
> > I've run into this type of scenario before as well.
> >
> > Would it be possible to have thread-safe variables that live outside
> > of the modules of a given script and can be accessed from any
> > module?  Something we could use as counters, etc?
> >
> > Tim
> >
> >
> >> -----Original Message-----
> >> From: [email protected] [mailto:topbraid-
> >> [email protected]] On Behalf Of Barb
> >> Sent: Wednesday, September 16, 2009 7:58 PM
> >> To: TopBraid Composer Users
> >> Subject: [tbc-users] Re: Iterate over select
> >>
> >>
> >> Can you recommend an alternative?
> >>
> >> On Sep 16, 7:22 pm, [email protected] wrote:
> >>> Hello Barb,
> >>>
> >>> The iterations of IterateOverSelect execute independently from each
> >>> other, so "incrementing" a variable inside a loop will not work.
> >>>
> >>> Gokhan
> >>>
> >>> Quoting Barb <[email protected]>:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> I have an iterateOverSelect where I'm querying for the children of
> >>>> the
> >>>> selectedResource.
> >>>> I'm going to be creating a new composite:index for each child and
> >>>> have
> >>>> calculated my ?startIndex to be one less than that of the
> >>>> selectedResource.
> >>>
> >>>> SELECT ?s ?selectedResource ?srIndex ?startIndex
> >>>> WHERE {
> >>>>     ?s skos:broader ?selectedResource .
> >>>>     ?selectedResource composite:index ?srIndex .
> >>>>     LET (?startIndex := (smf:cast(?srIndex, xsd:float) - 1)) .
> >>>> }
> >>>
> >>>> Once I have the above triples, I want to iterate over the results
> >> and
> >>>> insert a new composite:index for each (previously the
> >> composite:index
> >>>> was deleted)
> >>>> My ?startIndex is one less than the parent node ...
> >>>> So for example, if the parent's composite:index was 6, I want the
> >>>> first child's index to be 6 and increment by 1 for each child
> >>>> thereafter. (I will be deleting the parent node later and
> promoting
> >>>> the children)
> >>>
> >>>> INSERT INTO <http://tb-session>
> >>>> {
> >>>> ?s composite:index ?newIndex .
> >>>> }
> >>>> WHERE
> >>>> {
> >>>> ?s skos:broader ?selectedResource
> >>>> LET (?newIndex := (smf:cast(?startIndex, xsd:float) + 1)) .
> >>>> }
> >>>
> >>>> After the insert, I reset my ?startIndex to the ?newIndex and I
> >> want
> >>>> to "repeat the loop".
> >>>
> >>>> SELECT ?startIndex
> >>>> WHERE {
> >>>>     ?s composite:index ?startIndex .
> >>>> }
> >>>
> >>>> Unfortunately, the composite:index is being set correctly for the
> >>>> first child but never increments ... all children have the same
> >>>> composite:index.
> >>>
> >>>> The above is only 3 modules (iterateOverSelect, Update,
> >> BindBySelect)
> >>>> but I'm missing something.
> >>>
> >>>> I'm hoping you can point out my error.
> >>>
> >>>> Barb- 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 [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=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to