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
