On 6 Apr 2009, at 17:31, Corydodt wrote:
> Can you provide any tips on how to run the tests to verify that things
> actually work?
It certainly works with 2.4.0, I haven't had a chance to test it with
the new 2.4.1 release.
As for running tests, you might get some use out of:
http://bitbucket.org/gjhiggins/shabti/src/tip/shabti/templates/rdfalchemy/+package+/
I haven't yet managed to produce a test suite for the companion
auth'n'auth template:
http://bitbucket.org/gjhiggins/shabti/src/tip/shabti/templates/auth_rdfalchemy/
but the authentication works as expected when the app is served.
Give me a couple of days and I should be able to let you know one way
or another about running under rdflib 2.4.1
Which version of Python are you using?
HTH.
Cheers,
Graham
http://www.linkedin.com/in/ghiggins
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAknaOVgACgkQOsmLt1NhivyVjACg6OR/0RbgbROuaqGYRNC5MwfF
lYYAoJf7bsV3j/Azgkcfb7qq6/RaSWwhiQCVAgUBSdo5WFnrWVZ7aXD1AQJonAP/
bwbbkoBfzWOm5PbJr4wF2uXmL7j/R1PUVPBBjYsmalrMB0Y1qQmyKy5892Kipu72
ZoIOHRPQRlKy1F2aziyIv1bZE+T5zjomsffHYhgEcbFhgtgeBB+hMVS9lz3PuFjD
8XuuU/1xelmBUxDDpLWGN3fYh6ZJNVrx6bF2ESPyTLo=
=D1OJ
-----END PGP SIGNATURE-----
Seems to be OK. The only failures I get with python 2.4 and rdfbli2.4.1
relate to SPARQL parameter mapping of the Decimal Literal type. That's
not of much general interest buy I'll fix shortly since I work primarily
with financial apps.
> I don't see any obvious
> documentation on how the tests should be run
I used nose tests. from the install dir (somewhere in site-packages?)
just run "nosetests" at the command prompt
I guess that assumes you have nosetests installed ("easy_install nose"
if not)
> I'm looking at the current subversion trunk
> right now.
>
I've updated the svn trunk to allow 2.4.1 (used to require rdflib ver ==
2.4.0 and not allows 2.4.0-2.9.9) Used to be restrictive because a
previous easy-install grabbed a 3.0 trunk of rdflib which was incompatable.
Bottom line: rdflib2.4.1 and rdfalchemy look ok. I'll clear a couple of
old tickets and post another ver on Cheeseshop
On a seperate note: I'm glad to see some of the rdflib disucssion about
sleepycat issues which have dogged me forever. Maybe with the new
"with" syntax in python I can heal some of my (probably self-inflicted)
Sleepycat wounds.
--
Phil
--
Phil
Corydodt wrote:
> Hi, I'm hoping this project is still alive.
Let me know if something disappoints as I'm getting my hands dirty in
this project right now anyway.
Hmm, Not sure if this is a schema that you are developing or if you
have to play the hand you have been dealt.
There are a number of ways I might approach this:
OPTION 1:
If StackableFeat is just a boolean then it could just be placed in the
graph as such (i.e. perhaps there should be a c:isStackable predicate
that stores a boolean)
issue:
rdflib is currently not returning an XSD.boolean for `Literal(True)`.
that seems wrong and I will post a suggestion to the rdflib group and if
there is no interest I can fix up Literal processing in rdfalchemy. a
boolean Literal can be generated with Literal(True,datatype=XSD.boolean)
untill Literal(True) is 'fixed'.
this option makes sense if the `stackable` state changes from time to
time but is not consistent with the taxonomy you have described.
OPTION 2:
is c:StackableFeat a subclassOf c:Feat ?
perhaps creating an instance of class StackableFeat is the right
thing... then check isinstance(x,StackableFeat) if what you want.
This might not work if the `Stackable` state is dynamic.
OPTION 3:
you can keep the most pythonic behavior with a descriptor. In the
rdfalchemy.descriptors.py file, if you used rdfSingle as a template,
you(or I) could create a new descriptor type.
Something like
class rdfIsInstance(rdfAbstract):
def __init__(self, class_to_check, implied=False):
self.klass = class_to_check
# do you want to check for subclass inferencing??
def __get__(self,obj,cls):
#code to check for obj a self.klass
return bool result
def __set__(self,obj, true_false):
#code to check for true_false and to set or delete the relevant
triple
def __delete__(self,obj):
# code to remove the stackable triple if you want to use
# del x.isStackable
the descriptor could then be part of your class like:
class Feat(rdfSubject_or_Subclass):
isstackable = rdfIsInstance(c.StackableFeat)
##other descriptors here
then using: var.isstackable and var.isstackabel=True and
var.isstackable=False all would behave as you described.
I haven't put this in because I don't use the class membership in the
way you describe. If its a tbl suggestion maybe I should go there.
Let me know if you want to go this way and need some help with the
descriptor.
>
> 2) How do I construct queries on the verb? I was able to do this:
>
> :angel
> a c:Family;
> p:sense :standardDarkvision;
> p:immunity c:acid, c:cold, c:petrification;
> p:resistance [ c:electricity 10 ], [ c:fire 10 ];
> .
>
> class Resistance(S.SparqItem):
> """A resistance possessed by monsters"""
> attackEffect = S.Ref(AttackEffect, "SELECT ?ae { $key ?ae [] }")
>
> Notice that it's the verb position that I'm querying here. I can do
>
> print angel.resistances[0].attackEffect
> # prints "electricity"
>
an ORM is designed to keep you from needing to go to SQL/SPARQL... Just
map your predicates wisely.
Something like
class Resistance(rdfSubject):
resistnaces = rdfMultiple(p.resistance)
angel.resistances[0] would return the bnode of interest.
Your return type might want to have
p:resistance [ attackEffect c:electricity ; RDF.value 10 ], [
attackEffect c:fire;RDF.value 10 ]; # `restype` or maybe just `a`
then angel.resistances[0].attackEffect would work well
Again if you want to(or have to) query the predicate (verb) then you
could create a descriptor to do that. But again I would tend to have the
thing you want to return be in the object part of the triple. Are you
sure about your setup?
> I don't need to be able to set this one, though, just get it. Does
> rdfalchemy allow me to assign a property to the object that is
> determined through a custom query?
you should be able to assign to arbitrary uri's or literals to any
predicate with the
angel[xxx.newPred]=someResult syntax
Best of luck. You can email me directly if you have a more specific
need or want to share your ontology for specific advice.
--
Phil
Cory Dodt wrote:
> On Mon, Apr 6, 2009 at 12:55 PM, Philip Cooper
> <philip...@openvest.com <mailto:philip...@openvest.com>> wrote:Hmm, Not sure if this is a schema that you are developing or if you
>
> I have some questions now.
>
> 1) From a suggestion by timbl, I have boolean fields specified like this:
>
> :weaponSpecialization a :Feat;
> a c:StackableFeat;
> :description "When you take this feat, you gain +1 to hit and
> damage with this type of weapon";.
have to play the hand you have been dealt.
There are a number of ways I might approach this:
[...]
OPTION 3:
you can keep the most pythonic behavior with a descriptor. In the
rdfalchemy.descriptors.py file, if you used rdfSingle as a template,
you(or I) could create a new descriptor type.
Something like
class rdfIsInstance(rdfAbstract):
[...]
class Feat(rdfSubject_or_Subclass):
isstackable = rdfIsInstance(c.StackableFeat)
##other descriptors here
> 2) How do I construct queries on the verb? I was able to do this:
> (dumb thing)
Your return type might want to have
p:resistance [ attackEffect c:electricity ; RDF.value 10 ], [
attackEffect c:fire;RDF.value 10 ]; # `restype` or maybe just `a`
then angel.resistances[0].attackEffect would work well
Best of luck. You can email me directly if you have a more specific
need or want to share your ontology for specific advice.
You should check out Protege ( http://protege.stanford.edu/ ). Java
based (go with ver3.4) and use basic+OWL. Don't worry too much about
ontology fine-tuning and OWL compliance. It does help IMHO to get in
the habit of defining domain and range for you predicates (RDFS) and
this tool will give you a better ontology.
>
> One problem, and this is again with the schema design because I have
> no idea what I'm doing. There is only supposed to be one
> "electricity" resistance, one "fire" resistance, and so on. With
> electricity as the predicate and the number as a value, this happens
> naturally. With attackEffect as the predicate, I'll have to put this
> constraint into the application. Any way to specify at the vocabulary
> level that there should be at most one
> resistance-attackEffect-electricity?
Right, And from looking at your sample (subsequent email) this might be
a predicate although grouping resistances into a container bnode might
improve your structure and performance. As far as declaring this is one
and only one "electricity" resistance, look at the Protege tool above
and you will be able to add this in (at most one at least one functional
predicates cardianlity control...). Triple-stores that enforce those
rules are hard to come by. Think of yourself as working in the early
days of SQL when the enforcement of referential integrity was spotty at
best.
--
Phil