Andy, thank you very much for your time and input. I will go with either VALUES or ( (TERM TERM VAR) 2 ) depending on which is faster.
-Wolfgang -----Original Message----- From: Andy Seaborne <[email protected]> To: users <[email protected]> Sent: Mon, May 27, 2013 3:43 pm Subject: Re: Unexpectedly slow query On 27/05/13 11:54, [email protected] wrote: > Thanks for the info! > > Just to sum up my options: 1. Use fixed.opt instead of stats.opt (I > am currently doing that. Works fine, but other queries are a little > slower than before, but acceptable) > > 2. Add Bind (1 as ?x) whenever I am using the dynamic subPropertyOf > relationships Ugly. > > 3. Add ( (TERM TERM VAR) 2 )to the stats file > > > 4. How about I add: VALUES ?dynProp { ec:Has_Dyspnea_Score > ec:Has_Dysphagia_Score } ?pat ?dynProp ?finding . That should work as should: FILTER(?findingProp IN ( ec:Has_Dyspnea_Score, ec:Has_Dysphagia_Score)) > Would that work and be stylistically acceptable? I am leaning towards > option 4 since I do not have to manipulate the TDB store and it can > be easily understood by other developers. Only downside is that if the data changes, then the query will not see a new rdfs:subPropertyOf. > On a more philosophical note: You mentioned that this use of sub > properties is "unusual" since the property is often assumed to be > something constant. That raises the question: If this is not one of > the proper/expected uses of sub-properties, what is their purpose? Using rdfs:subPropertyOf then a property variable is uncommon - not wrong, just low frequency. > I am trying to allow for queries that either ask for Dyspnea and/or Dysphagia scores explicitly or all types of Findings in general. IMO I have two options: > 1. Just use "Has_Finding". If the user wants only Dyspnea scores, I can restrict the object. > ?pat ec:Has_Finding ?finding . > ?finding rdfs:subClassOf* nci:Dyspnea_Score > > 2. Use sub-properties as outlined so far. I went with this one since I need to know the possible sub-types of findings at design-time, when no data triples are asserted. And I need to be able to tell that "Dyspnea_Score" is an "entity" or property of Patient, but its sub-classes are real-life values for that entity, e.g. "Dyspnea_Score_1". > > My current use-case is fairly hierachical/relational. I am using the ontology for query expansion. But in the future we do want the additional semantic information and easy incorporation of other ontologies. > > Am I trying to squeeze something into a triple store that I should not? No - it's just the optimizer needs improving. I think it can simply add ( (TERM TERM VAR) 2 ) automatically either in stats generation or when it reads a stats file in, my pref is the former because it can be edited out as well, but it's needs investigation. > > -Wolfgang Andy
