Thanks Scott and Holger, Yes those were typos. My mother called as I was typing the message.
The model is basically a bunch of classes that are each a subclass of a restriction on a property such as 'hasPrice' to a particular value, a string in this case. I wanted instances to have that value for the property in question. (and there is only one property in the model, other than the standard ones) Thanks for the tips. It all boiled down to the order of the triple patterns. The debugger is handy too. Best, Leonard On Tue, Sep 6, 2011 at 7:27 PM, Scott Henninger <[email protected]>wrote: > Leonard; I believe the basic issue is that ?y and ?Y are different. > Given that. CLHV1 will do nothing. But there are a number of other > errors in your queries, so I can only guess that these are typos, and > it's very unclear to me what you are working with that is causing the > problems. > > So, first, before running any set of SPIN rules, I'd suggest first > running the query in the SPARQL view. ?this will be bound to whatever > is in the Resource Form, meaning that you can fully validate the > CONSTRUCT query on examples before running as a SPIN rule. I.e. to > create a SPIN rule: > 1) Select an instance of the class the rules is designed for > 2) debug the query using the SPARQL view. > > This is really a nice feature. Once the query has been executed you > can choose different instances and the SPARQL View automatically re- > binds ?this to whatever is selected. A very convenient way to see how > the query will execute against members of the class. > > Pondering your query a bit, I'm guessing that you are looking to cls- > hv2 (owl:hasValue restriction) against all members of some class, > including subclass of entailments. If so, try the following query > (note the syntax is correct because it was copied from the SPARQL > View): > > CONSTRUCT {?this ?p ?y} > WHERE > { ?x owl:hasValue ?y. > ?x owl:onProperty ?p . > ?cls rdfs:subClassOf ?x . > ?this a ?cls . > } > > In terms of an optimizer for RDF queries, keep in mind that unlike > relational data RDF is a graph. Hence traditional relational query > optimizations can't apply. Also, the order of graph and triple > patterns in SPARQL cannot matter. The end result needs to be the same > no matter what order they are executed. In practice the patterns have > to be executed in some order, and the ARQ engine will execute the > triple patterns from top to bottom. There are details, and you can > explore some of these using the SPARQL debugger (see bug icon in > SPARQL View), which will show the SPARQL algebra created for a query. > > Lastly, given the above, about only real optimization available is to > modify the ordering of the graph patterns to ensure that the search > space is reduced as much as possible early in query execution. This > means somehow knowing how many potential triples match each pattern in > the query for the data it is executed against. This isn't feasible > without some prior knowledge of the data. > > So the advice I'd give is to carefully debug the query and if > performance problems persist (again, for the size you have cited, if > it runs for more than a couple of minutes, something is amiss) use the > debugger to optimize the order of triple patterns. > > -- Scott > > On Sep 6, 5:11 pm, Leonard Jacuzzo <[email protected]> wrote: > > Hi Guys, > > > > So, when I got to the office this morning, it was still working on the > > inferences. I have a fairly simple model, though many classes. I was > using > > these rules. > > > > CLHV1 > > CONSTRUCT {?this ?p ?Y} > > WHERE { > > ?x owl: hasValue ?y. > > ?x owl: onProperty ?p > > ?this a ?x} > > > > and > > > > CONSTRUCT {?this a ?c2} > > WHERE{ ?c1 rdfs:subClass Of ?c2. > > > > ?this a c1} > > > > However when I changed the rules to > > CONSTRUCT {?this ?p ?Y} > > WHERE { ?this a ?x > > ?x owl: hasValue ?y. > > ?x owl: onProperty ?p > > > > } > > > > and > > > > CONSTRUCT {?this a ?c2} > > WHERE{ ?this a c1 > > ?c1 rdfs:subClass Of ?c2. > > > > } > > > > It worked in a minute or so, even with a few hundred thousand randomly > > generated triples. > > > > So I am wondering, would it be possible to create a query optimizer for > TBC? > > > > Best wishes, > > Leonard > > > > On Fri, Sep 2, 2011 at 7:50 PM, Holger Knublauch <[email protected] > >wrote: > > > > > Leonard, > > > > > please send an example excerpt of your model and your rules. Even with > 73k > > > classes it should easily work. Maybe the system hasn't been configured > to > > > have enough memory (the -Xmx option) so that it ends up swapping memory > to > > > disc - even then I am surprised to see such slowness. > > > > > Another thing to look at is to open the Window > Show View > SPIN > > > Statistics view that will measure the duration of each rule. > > > > > Holger > > > > > On Sep 3, 2011, at 5:56 AM, Leonard Jacuzzo wrote: > > > > > Hello list, > > > > > I would like to make a request/suggestion. > > > > > I have enjoyed learning from the TQ blogs and from this list. In fact, > I > > > learned a bit last week. > > > > > However, when I attempt to apply what I have learned I find that TBC is > > > very slow with reasoning. > > > > > For example, I have a model with 73,000 classes, each class is a > subclass > > > of a restriction on a property with 'hasValue' ( much like the example > with > > > the price of an orange). > > > > > Instead of using RL, I used only two rules that were required. (I have > the > > > correct one's thanks to Scott and Irene). I put two instances in so > that I > > > can test it out. > > > > > I left it running on "reason" yesterday when I left work. After > dropping in > > > just now, TBC is still working on the task. > > > > > The model I am working with is fairly simple, but has lots of classes. > The > > > only task I am attempting is to get two instances to classify based > upon > > > which class they are instances of. For example, I made them instances > of > > > orange and I want the price classified. > > > > > So my request is for a blog about tips for scalability. If there is > such a > > > blog, that is not about SPIN, please let me know. If not, I could > really use > > > some help with constructing models facilitate scalability. How many > classes > > > is too many? > > > > > If I can't get things to work more quickly, nobody will want to use > this > > > technology for our tasks. So any help will be appreciated. > > > > > Thanks a lot, > > > > > Best wishes, > > > Leonard > > > > > -- > > > You received this message because you are subscribed to the Google > > > Group "TopBraid Suite Users", the topics of which include TopBraid > > > Composer, > > > TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. > > > 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-users?hl=en > > > > > -- > > > You received this message because you are subscribed to the Google > > > Group "TopBraid Suite Users", the topics of which include TopBraid > > > Composer, > > > TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. > > > 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-users?hl=en > > -- > You received this message because you are subscribed to the Google > Group "TopBraid Suite Users", the topics of which include TopBraid > Composer, > TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. > 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-users?hl=en > -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. 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-users?hl=en
