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
