Don,
your first row iterates over all triples in the model. In your query
below you can replace ?pred with the constant vocab:Objects_Type and
it will become lightning fast.
Holger
On Oct 15, 2008, at 12:52 PM, donundeen wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
