On 8/2/2014 2:28, [email protected] wrote:
At present I've just add the owl imports for SPIN etc and opened my
SPINConstraints.ttl file in TopBraid FE.
(I assume you mean SPINConstraintChecks.ttl, at least on the version
that I see.
In the SPIN overview tab I see only the constraint for
bioj:ArticleSoftwareLink, but not the constraints
for bioj:SoftwarePackage (which are all spl:Attribute).
Yes, this is intentional - the code behind this feature (Model > Display
SPIN rules and constraints) is simply running the template
spl:SPINOverview, which suppresses any spl:Argument or spl:Attribute
definitions. This was done under the assumption that Argument and
Attribute are mostly used for "system" concepts such as defining other
templates. We are using spl:Attribute a lot in SPARQLMotion, but I can
see why you would want to see them in your example too.
To see everything, just navigate to spin:constraint and hit "Find
References" (and you'll see quickly why we filter out the Arguments).
may be some local paths in there, sorry!) and I run the
constraints via mvn -Dtest=AppTest#testSPINConstraints test
I'm using the output code from the Kennedy's example, edited to
use getCustomizedLabel rather than getLabel (although using just
getLabel doesn't work as I'd expect either):
for(ConstraintViolation cv : cvs) {
System.out.println(" - at " +
SPINLabels.get().getCustomizedLabel(cv.getRoot()) + ": " +
cv.getMessage());
I've tried to follow the code through cv.getMessage() but I got
lost in abstract interfaces somewhere :)
This is the constraint:
bioj:SoftwareMention a rdfs:Class ;
spin:constraint
[ a spl:Attribute ;
rdfs:comment "Must have one and exactly one
classification "^^xsd:string ;
spl:predicate citec:mention_category ;
spl:minCount 1 ;
spl:maxCount 1 ;
# spl:valueType citec:MentionClassification ;
# spl:defaultValue ex:Red
] ;
.
Originally I was working with 1.3.1 and I was getting the
Resource ID but no message:
- at citec:a2007-36-BMC_PLANT_BIOL-B03-mention:
Now I've upgraded to 1.4.0 and I'm getting a generic message
(progress!):
- at citec:a2007-36-BMC_PLANT_BIOL-B03-mention: Attribute
citec:mention_category : [1,1]
Yes I had fixed this bug in 1.3.3 because several users complained
that the message was empty. It now behaves more consistently with
TopBraid. If the template has a spin:labelTemplate then it will
use that.
Hmmm, I think I understand, but the spin:labelTemplate wouldn't be
something that I would define, would it? Perhaps the
spin:labelTemplate defines how the cv.getMessage should be constructed?
Once you are in TopBraid, please open TopBraid > Examples > spinsquare.
This is a "Hello World" example that illustrates most SPIN features with
a simple example. Look at ss:PositivePropertyValueConstraint and see
that it defines a spin:labelTemplate. Navigate to ss:Rectangle to see
how this template is used - to limit the range of ss:height and
ss:width. This is being displayed as
using the spin:labelTemplate defined for the template. Now go to
ss:TestRectangle and change its ss:height to -6. Activate the button
"Display constraint violation warnings" in the main tool bar. It
displays the complex warning created in the CONSTRUCT part of the
template. Now go back to ss:PositivePropertyValueConstraint and delete
the 4th line of the CONSTRUCT, which sets the rdfs:label. If you now go
to the TestRectangle, you will see that it uses the generic label
derived from the spin:labelTemplate. And the SPIN API should work just
like this.
But how would I output the rdfs:comment from the constraint?
I see that TopBraid also creates the spin:constraints as I have, but
the rdfs:comment doesn't output when running the cv.getMessage() code?
For:
spin:constraint [ a spl:Attribute ;
rdfs:comment "Does this show
up?"^^xsd:string ;
spl:maxCount 1 ;
spl:minCount 1 ;
spl:predicate rdfs:label
] ;
I get - at bioj:a2009-51-MOL_THER-BioEdit: Attribute rdfs:label : [1,1]
I guess what I expect is:
- at bioj:a2009-51-MOL_THER-BioEdit: Attribute rdfs:label : [1,1]
Does this show up?
which I think is just a matter of adding the content of the
rdfs:comment on the spin:constraint?
No, the rdfs:comment would need to be at the template itself (here:
spl:Attribute). In the running example, delete the spin:labelTemplate
from the constraint template and see that it will fall back to the
rdfs:comment of ss:PositivePropertyValueConstraint.
Right, got yah, I had thought that the sp:text would be converted
to the sp:Ask SPIN RDF first and so the comment would go to the
rdfs:label. I like the sp:text a lot because I can copy and
paste the queries as I work them up in a SPARQL engine or use
them in other pieces of code.
Yes I agree sp:text is more user-friendly and also preserves the
formatting. If you have a query that uses sp:text only, no automatic
translation into the SPIN RDF triples happens - I would not want to
modify a graph under the hood, and furthermore it is a bit tricky to
extract the comment from the query string because the parser throws it away.
That's great, although FWIW I find it confusing that the rdfs:label of
the ConstraintViolation created in this way outputs from
cv.getMessage() but that other constraints like sp:Ask or
spl:Attribute don't output either their rdfs:comment or their
rdfs:label through the java cv.getMessage() call. Seems a bit
confusing that CONSTRUCT ConstraintViolations are treated differently
in their Messages than (what I presume are) ConstraintViolations
created in other ways. FWIW, the docs suggest that rdfs:comment
(rather than rdfs:label) is where the human readable description of
the purpose of the spin:constraint should go.
Maybe my previous comments have explained the background behind all this.
Righto, I'd have thought that the root resource would be the
individual that violated the constraint?
Yes this is correct, and I am not really sure why your example doesn't
have a root.
I played around a little trying to make a minimal example from scratch
in Top Braid FE, but ran out of time. As I wrote up top, just adding
the imports doesn't seem to work that well. Appreciate your help,
happy to make changes but a little lost as to how to make these Top
Braid friendly.
Not just TopBraid friendly, but generally OWL friendly. I know many in
the RDF community prefer to not have explicit imports, but overall I
think it's a good idea to hint tools at other graphs (e.g. the schema)
that are required to understand a given file.
HTH
Holger
--
-- 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.
