I believe when you remove the impact:hasValue triple from the
SystolicBloodPressure instance, then the second basic graph pattern in
the WHERE clause
(?h impact:hasValue ?v )
does not match and the rule therefore does not fire.
Holger
On 4/11/2014 9:56, William Van Woensel wrote:
Hi Holger,
Thanks for the reply. Yes, I was using the SPIN API programmatically.
And indeed, your code sample works properly, thanks! However, I'm not
fully understanding what went wrong in my code; it's based on the SPIN
code samples
from http://www.w3.org/Submission/2011/SUBM-spin-sparql-20110222/,
where syntax such as sp:arg1 and spin:_arg1 are used to declare and
reference passed parameters, respectively. In particular, I thought
they were built-in ways of working with function parameters.
At any rate, I tried removing / repositioning some of the code in your
file to see what made it work (as compared to my code), and looks like
it no longer works when I move either of the two statements below:
impact:hasLatestDate "true"^^xsd:boolean ;
impact:hasValue "142.84"^^xsd:double ;
Into the code block directly above the rule definition, e.g.,
impact:PatientProfileChart0
impact:hasSystolicBloodPressure impact:SystolicBloodPressure41 ;
impact:hasValue "142.84"^^xsd:double ;
While for instance moving the rdf:type statement on the same
impact:SystolicBloodPressure41 to that code block does *not *break
it.. Which sounds weird, right?
In attachment a file with an example re-positioning that breaks the code.
Regards,
William
On Wednesday, 9 April 2014 23:12:51 UTC-3, Holger Knublauch wrote:
Hi William,
let me guess that you are using the SPIN API programmatically? I
have (re)constructed your example in a Turtle file (attached for
your reference) which works fine when run inside of TBC, so I
assume you are executing this differently.
With the API, you need to make that when using spin:_arg1 etc,
that your function's graph includes the SPIN system triples, so
that it knows that spin:_arg1 is indeed a sp:Variable. But it
seems that you have already excluded that possibility. In any
case, using named properties from the arg: namespace is probably a
better choice, making the query more readable. I have done that in
the attached copy if you want to try it out if it makes a difference.
If this does not help, I would need more details of the Java code,
ideally a self-contained scenario.
Thanks
Holger
On 4/9/2014 5:06, William Van Woensel wrote:
Hi,
I can't seem to get a very basic thing right, namely passing
parameters to custom defined functions..
The data:
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
<http://www.w3.org/2000/01/rdf-schema#> .
@prefix sp: <http://spinrdf.org/sp#> <http://spinrdf.org/sp#> .
@prefix spl: <http://spinrdf.org/spl#>
<http://spinrdf.org/spl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>
<http://www.w3.org/2001/XMLSchema#> .
@prefix spin: <http://spinrdf.org/spin#>
<http://spinrdf.org/spin#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix impact: <http://www.dal.ca/nichegroup/impactaf#>
<http://www.dal.ca/nichegroup/impactaf#> .
@prefix owl: <http://www.w3.org/2002/07/owl#>
<http://www.w3.org/2002/07/owl#> .
impact:PatientProfileChart0 impact:hasSystolicBloodPressure
impact:SystolicBloodPressure41 .
impact:SystolicBloodPressure41 impact:hasValue
"142.84"^^xsd:double .
impact:SystolicBloodPressure41 rdf:type
impact:SystolicBloodPressure .
impact:SystolicBloodPressure41 impact:hasLatestDate
"true"^^xsd:boolean .
impact:hasLatestDate rdf:type rdf:Property .
The rule (attached to the proper class):
impact:SystolicBloodPressure
spin:rule
[ a sp:Construct ;
sp:templates ( [ sp:object
impact:HighSystolicBloodPressure ;
sp:predicate impact:hasDSSFinding ;
sp:subject [ sp:varName "p"^^xsd:string ]
] [ sp:object "DiaryHighSystolicBloodPressure" ;
sp:predicate impact:hasTriggeredRule ;
sp:subject impact:HighSystolicBloodPressure
] [ sp:object "Patient's systolic
bloodpressure is uncontrolled" ;
sp:predicate impact:hasLabel ;
sp:subject impact:HighSystolicBloodPressure
] [ sp:object impact:DSSFinding ;
sp:predicate rdf:type ;
sp:subject impact:HighSystolicBloodPressure
] ) ;
sp:where ( [ sp:object [ sp:varName
"h"^^xsd:string ] ;
sp:predicate impact:hasSystolicBloodPressure ;
sp:subject [ sp:varName "p"^^xsd:string ]
] [ sp:object [ sp:varName "v"^^xsd:string ] ;
sp:predicate impact:hasValue ;
sp:subject [ sp:varName "h"^^xsd:string ]
] [ a sp:Filter ;
sp:expression [ a impact:latest2 ;
sp:arg1 [ sp:varName
"h"^^xsd:string ]
]
] [ a sp:Filter ;
sp:expression [ a sp:ge ;
sp:arg1 [ sp:varName
"v"^^xsd:string ] ;
sp:arg2 135
]
] )
] .
And finally, the custom function:
impact:latest2 a spin:Function ;
rdfs:comment "Checks whether the given resource
is the 'latest' of its type" ;
rdfs:label "latest"^^xsd:string ;
rdfs:subClassOf spin:Functions ;
spin:body [ a sp:Ask ;
sp:where ( [ sp:object
"true"^^xsd:boolean ;
sp:predicate impact:hasLatestDate ;
sp:subject spin:_arg1
] )
] ;
spin:constraint [ a spl:Argument ;
rdfs:comment "The resource to
check for 'latestness'."^^xsd:string ;
spl:predicate sp:arg1
] .
Nothing is returned, although it should infer some triples. In
fact, when I replace the "spin:_arg1" by the concrete resource
(impact:SystolicBloodPressure41), the triples /are correctly
/inferred. I tried a bunch of things, such as replacing the "[
sp:varName "h"^^xsd:string ]" by spin:_h, the spin:_arg1 by "[
sp:varName "arg1"^^xsd:string ]", etc, but to no avail..
PS: I know the latest function is trivial and can be replaced by
a triple pattern, but the actual function has been simplified for
the purposes of this example.
Any ideas?
Thanks,
William
--
-- You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include
Enterprise Vocabulary Network (EVN), TopBraid Composer, TopBraid
Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to
[email protected] <javascript:>
To unsubscribe from this group, send email to
[email protected] <javascript:>
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
<http://groups.google.com/group/topbraid-users?hl=en>
---
You received this message because you are subscribed to the
Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected] <javascript:>.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
-- You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include Enterprise
Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid
Insight, SPARQLMotion, SPARQL Web Pages 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
Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
-- You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary
Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL
Web Pages 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 Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
