Thanks, Holger. I was afraid that was what you’d say.
Another option I could use would be to unleash my second set of rules only when the first set of rules has finished iteratively firing. The only way I can think of doing this at present is to invoke the reasoner from a SPARQLMotion script or SWP code, which could then do the second import of rules and invoke the reasoner again. However, I want to be able to use the TBC development environment to examine the results. If I use SPARQLMotion or SWP, I think I lose that, right? - Steve Steven R. Ray, Ph.D. Distinguished Research Fellow Carnegie Mellon University NASA Research Park Building 23 (MS 23-11) P.O. Box 1 Moffett Field, CA 94305-0001 Email: [email protected] Phone: (650) 587-3780 Cell: (202) 316-6481 Skype: steverayconsulting cid:[email protected] From: [email protected] [mailto:[email protected]] On Behalf Of Holger Knublauch Sent: Wednesday, March 30, 2016 10:06 PM To: [email protected] Subject: Re: [topbraid-users] Unexpected behavior of spin:constructor On 31/03/2016 9:52, Steve Ray (CMU) wrote: Hi, I just wanted to check if I’m misunderstanding the behavior of spin:constructor. I built a toy system with one class (Thing_1) containing a spin:constructor that creates a single triple: CONSTRUCT { ?this rdfs:label ?type . } WHERE { ?this a ?type . } So far so good. I can go to Instance view and create an instance, and sure enough, it gets created with the label set to the rdf:type. Here’s the problem: I create a separate file that declares a single triple: data:Thing_1_1 rdf:type constructorTest:Thing_1 ; . If I import that file into the class-declaration file, I expect the constructor to fire. But no, nothing happens. My question is, why not? What constitutes the act of creating a new instance? Constructors are not run when you add an import statement - figuring out all consequences of such a global action would be quite difficult. They do get run when you create a new instance from the TBC editors and menu actions. I have attached the two toy files in case that makes it easier to understand my question. (My motivating goal is, given a large data file, I want a bunch of properties to get populated when I import it. I had been using spin:rules to do that, but I want to reserve the rules for subsequent calculations, once all those initial properties get created.) I guess spin:rules are the only real solution here. You could mark all instances that you have already "seen", e.g. by inferring another flag (either directly at the resource or as another object pointing at your instances). Holger -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to [email protected] --- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to [email protected] --- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
