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
