Try this:

CONSTRUCT{
    ?subj ?pred ?obj .
    ?pred rdfs:domain ?type
}WHERE{
    LET (?pred := vocab:Objects_Type) .
    vocab:Objects_Type rdfs:domain ?type .
    ?subj vocab:Objects_Type ?obj .
} 

In general, you want the first parts of you queries to filter out as many 
triples as possible so subsequent parts have less data to muck through to 
perform further filtering.  Order DOES matter.




-----Original Message-----
From: donundeen [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 16, 2008 9:57 AM
To: TopBraid Composer Users
Subject: [tbc-users] Re: Properties as subjects in SPARQL Queries


Hm, I tried flipping the triples around in the query, to:
CONSTRUCT{
    ?subj ?pred ?obj .
    ?pred rdfs:domain ?type
}WHERE{
    ?pred rdfs:domain ?type .
    FILTER(?pred = vocab:Objects_Type) .
    ?subj ?pred ?obj .
}

and I'm not percieving much of a difference in execution time.

I'd love to find some more detailed documentation on how to write optimal 
SPARQL queries.
Anyone have any links?

On Oct 16, 9:29 am, donundeen <[EMAIL PROTECTED]> wrote:
> Good Idea, Ill try that for sure.
> But I was never clear on how the order of triples in my where clause 
> affect performance. I guess I assumed that the query would be 
> optimized for me.
>
> any resources out there that give more details on how to optimize my 
> SPARQL queries? I'm running sesame/mulgara.
>
> On Oct 15, 5:01 pm, "Schmitz, Jeffrey A"
>
> <[EMAIL PROTECTED]> wrote:
> >  Not to make this a SPARQL message board, but have you tried re-ordering 
> > your query?  That first line:
>
> >    ?subj ?pred ?obj
>
> > is I think going to build your entire model before moving on to the next 
> > line.  Try something like:
>
> > CONSTRUCT{
> >     ?subj ?pred ?obj .
> >     ?pred rdfs:domain ?type}WHERE{
>
> >     ?pred rdfs:domain ?type .
> >     FILTER(?pred = vocab:Objects_Type) .
> >     ?subj ?pred ?obj .
>
> > }
> > -----Original Message-----
> > From: donundeen [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, October 15, 2008 2:52 PM
> > To: TopBraid Composer Users
> > Subject: [tbc-users] Re: Properties as subjects in SPARQL Queries
>
> > well, ultimately I'd export all those triples, hence the construct.
>
> > hmm, maybe I'm confused, but a predicate can be the subject of a 
> > triple, like ?predicate rdfs:domain ?domain
>
> > this query works:
> > CONSTRUCT{
> >     ?subj ?pred ?obj .
> >     ?pred rdfs:domain ?type
> > }WHERE{
> >     ?subj ?pred ?obj .
> >     ?pred rdfs:domain ?type .
> >     FILTER(?pred = vocab:Objects_Type) }
>
> > but takes forever to return.
> > Is there a reason these kinds of queries are so slow? it just seems to 
> > perform significantly worse than similar queries that don't use predicates 
> > as subjects.
>
> > thanks
>
> > don
>
> > On Oct 15, 2:48 pm, Scott Henninger <[EMAIL PROTECTED]>
> > wrote:
> > > Don;  I am not clear on what you mean by "...whenever I try to use 
> > > a predicate as the subject of a query".  SPARQL uses triple 
> > > patterns to match a graph, such as:
> > >   ?subj ?pred ?obj
>
> > > If you then try in the same query to do
> > >   ?pred ?x ?y
>
> > > ...you won't find a match because the first pattern bound ?pred to 
> > > a predicate and the second is looking for ?pred as a subject of a 
> > > triple.
>
> > > So for example, if you had the following:
> > >   :xyz vocab:ObjTitles_Title :abc
> > >   :xyz vocab:ObjTitles_Title :uvw
>
> > > then a query with the following:
> > >  ?obj ?outPred ?outObj .
>
> > > The result would be bound in two result sets:
> > >  ?obj=:xyz ?outPred=vocab:ObjTitles_Title ?outObj=:abc
> > >  ?obj=:xyz ?outPred=vocab:ObjTitles_Title ?outObj=:uvw
>
> > > If you tried a query with the following:
> > >  ?obj ?outPred ?outObj .
> > >  ?outPred ?x ?outPredProps .
>
> > > It won't match anything because vocab:ObjTitles_Title is defined 
> > > in the data as a predicate and cannot appear as a subject or an object.
>
> > > If that's not the issue you are getting at, then maybe some sample 
> > > data would help.  I'm also not clear what purpose the CONSTRUCT 
> > > triples are serving, given that you seem to just want to get data, 
> > > not map it to another structure.
>
> > > -- Scott
>
> > > On Oct 15, 12:27 pm, donundeen <[EMAIL PROTECTED]> wrote:
>
> > > > Hi,
> > > > I'm trying to do some queries, to gather all data "around" some 
> > > > resource.
> > > > Basically, questions like "Get me all triples pointing in and 
> > > > out of this resource, and all triples connected to THOSE resources."
>
> > > > So I put together a query like:
> > > > CONSTRUCT {
> > > > ?obj ?outPred ?outObj .
> > > > ?inObj ?inPred ?obj .} WHERE  {
>
> > > > ?x vocab:ObjTitles_Title ?objTitle .
> > > > FILTER fn:matches(?objTitle, 'madame x' ,'i') .
> > > > ?x vocab:ObjTitles_ObjectID ?obj .
> > > > ?obj ?outPred ?outObj .
> > > > ?inObj ?inPred ?obj .
>
> > > > }
>
> > > > That query works fine.
> > > > However, Now I want to do two additional things:
> > > > 1. go an additional hop out, in either direction (ie, get all 
> > > > triples connected to the ?outObj and ?inObj resources) 2. Get 
> > > > all triples connected to the PREDICATES themselves. (this would 
> > > > usually be ontological information, like domain, subproperty, 
> > > > etc)
>
> > > > Attempting to add either 1 or 2, leads to queries that don't 
> > > > seem to ever complete.
> > > > Here's the query I have now:
>
> > > > CONSTRUCT {
> > > > ?obj ?outPred ?outObj .
> > > > ?inObj ?inPred ?obj .
> > > > ?inPred ?y ?inPredProps .
> > > > ?outPred ?x ?outPredProps .
> > > > ?outObj ?outOutPred ?outOutObj .
> > > > ?inObj ?inOutPred ?inOutObj .} WHERE  {
>
> > > > ?x vocab:ObjTitles_Title ?objTitle .
> > > > FILTER fn:matches(?objTitle, 'madame x' ,'i') .
> > > > ?x vocab:ObjTitles_ObjectID ?obj .
> > > > ?obj ?outPred ?outObj .
> > > > ?inObj ?inPred ?obj .
> > > > OPTIONAL {?outPred ?x ?outPredProps}.
> > > > OPTIONAL {?inPred ?y ?inPredProps } .
> > > > OPTIONAL { ?outObj ?outOutPred ?outOutObj } .
> > > > OPTIONAL { ?inObj ?inOutPred ?inOutObj . }
>
> > > > }
>
> > > > I'm wondering if my querying is creating loops somehow, and 
> > > > that's why trying to go extra hops on the graph is making the 
> > > > query fail to complete?
> > > > Or is it just that there's too much data to sift through?
>
> > > > Also, I seem to notice a big reduction in performance whenever I 
> > > > try to use a predicate as the subject in a query. Is there a 
> > > > difference internally (Sesame/Mulgara) in how predicates are 
> > > > indexed, that would be the cause of it?
>
> > > > perhaps there's a better approach to this problem, which is that 
> > > > I want to extract a connected graph, centered around some node 
> > > > or group of nodes.
>
> > > > thanks!


--~--~---------~--~----~------------~-------~--~----~
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