pywrapper-devel — PyWrapper Developers mailing list

[PyWrapper-devel] Problem with Tapir and Outputmodel.

[<rp...@in...>]

Hi all,
=20
This is Ram=F3n P=E9rez of GBIF Spain. We are using tapir provider in a p=
roject
with Inbio (Costa Rica). We want to integrate information about species
and specimens. =20
=20
I have configured a tapir provider but it doesn't do what I expect it to
do.
=20
I attach a compress file with the config file, two outputModel
(pcore2.xml and pcore3.xml) and the pywrapper results
(pywrapperpcore2.xml and pywrapperpcore3.xml).
1. Outputmodelpcore2.xml: the pywrapper does the query and returns the
results.
2. Outputmodelpcore3.xml: the pywrapper does the query and informs me
that it has 3 results. But it can't return me the schema defined by the
outputmodel.
=20
I have revised the output model but I can't see the error. I think that
it is an error of the pywrapper :-(
=20
I would be very grateful if you may help me. It is very important for
me.
=20
Best regards,
=20
Ram=F3n.

Re: [PyWrapper-devel] Managing the concept server

[<wi...@go...>]

Milko,

comment #1: try not to use :: in the full concepts but make them look like a
simple URL. for example
http://www.ipgri.org/schemas/mcpd_eurisco/1.00/NICODE

comment #2: the error says: "biocase.CNS.NonUniqueConceptError". so it looks
as if the aliases or qualified names are not unique. check. another problem
could be that the alias.txt should have "=" between an alias and the
qualified concept. But I think its not required.

commen #3: the idea is that the server CANNOT start up with conflicting or
broken alias files. this shoulkd be fixed before. dont you agree with that?
otherwise you could get unforseen weird results.

markus


On 11/13/06, Skofic A. Milko (IPGRI) <M.S...@cg...> wrote:
>
> Hi guys, I am trying to create an alias file to use other schemas and test
> mapping and output models. I have created a schema, run it through TAPIR's
> schema parser and tried to set up another concept server.
> I get an error whenever I startup TAPIR, and I am sure it has to do with
> the alias file and its other related files.
> The error is:
>
> Traceback (most recent call last):
>   File "../webapp/start_server.py", line 56, in ?
>     import root, page
>   File "/Library/WebServer/Services/pywrapper/webapp/root.py", line 17, in
> ?
>     import page, biocase.configuration
>   File "/Library/WebServer/Services/pywrapper/webapp/page.py", line 24, in
> ?
>     class Page(object):
>   File "/Library/WebServer/Services/pywrapper/webapp/page.py", line 26, in
> Page
>     _dsaObjDict = biocase.pywrapper.datasource_factory.getDsaDict()
>   File
> "/Library/WebServer/Services/pywrapper/lib/biocase/pywrapper/datasource_factory.py",
> line 49, in getDsaDict
>     dsaObj.readPrefsFile()
>   File
> "/Library/WebServer/Services/pywrapper/lib/biocase/pywrapper/datasource.py",
> line 218, in readPrefsFile
>     parse(filename, handler)
>   File
> "/Library/WebServer/Services/pywrapper/tools/python/lib/python2.4/site-packages/_xmlplus/sax/__init__.py",
> line 31, in parse
>     parser.parse(filename_or_stream)
>   File
> "/Library/WebServer/Services/pywrapper/tools/python/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py",
> line 109, in parse
>     xmlreader.IncrementalParser.parse(self, source)
>   File
> "/Library/WebServer/Services/pywrapper/tools/python/lib/python2.4/site-packages/_xmlplus/sax/xmlreader.py",
> line 123, in parse
>     self.feed(buffer)
>   File
> "/Library/WebServer/Services/pywrapper/tools/python/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py",
> line 216, in feed
>     self._parser.Parse(data, isFinal)
>   File
> "/Library/WebServer/Services/pywrapper/tools/python/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py",
> line 312, in start_element
>     self._cont_handler.startElement(name, AttributesImpl(attrs))
>   File
> "/Library/WebServer/Services/pywrapper/lib/biocase/pywrapper/datasource_handler.py",
> line 73, in startElement
>     self._lastConceptObj = buildConceptFromAttrs(attrs,
> ns=self._lastSchemaNS)
>   File
> "/Library/WebServer/Services/pywrapper/lib/biocase/pywrapper/filter/concept.py",
> line 215, in buildConceptFromAttrs
>     conceptObj = buildConcept(qname, ns)
>   File
> "/Library/WebServer/Services/pywrapper/lib/biocase/pywrapper/filter/concept.py",
> line 239, in buildConcept
>     CNServer = createCNServer(aliasList=cfgObj.ConceptNameServer.AliasList,
> cachedir=cfgObj.cacheLocator)
>   File "/Library/WebServer/Services/pywrapper/lib/biocase/CNS.py", line
> 433, in createCNServer
>     CNS.addAliasLocation(alias)
>   File "/Library/WebServer/Services/pywrapper/lib/biocase/CNS.py", line
> 168, in addAliasLocation
>     self._read(fh)
>   File "/Library/WebServer/Services/pywrapper/lib/biocase/CNS.py", line
> 241, in _read
>     self.addConcept( c, additionalAliases=[] )
>   File "/Library/WebServer/Services/pywrapper/lib/biocase/CNS.py", line
> 346, in addConcept
>     raise NonUniqueConcept(conceptObj)
> biocase.CNS.NonUniqueConceptError in atexit._run_exitfuncs:
> Traceback (most recent call last):
>   File
> "/Library/WebServer/Services/pywrapper/tools/python/lib/python2.4/atexit.py",
> line 24, in _run_exitfuncs
>     func(*targs, **kargs)
>   File
> "/Library/WebServer/Services/pywrapper/tools/python/lib/python2.4/logging/__init__.py",
> line 1333, in shutdown
>     h.close()
>   File
> "/Library/WebServer/Services/pywrapper/tools/python/lib/python2.4/logging/__init__.py",
> line 674, in close
>     del _handlers[self]
> KeyError: <logging.StreamHandler instance at 0x1385418>
> Error in sys.exitfunc:
> Traceback (most recent call last):
>   File
> "/Library/WebServer/Services/pywrapper/tools/python/lib/python2.4/atexit.py",
> line 24, in _run_exitfuncs
>     func(*targs, **kargs)
>   File
> "/Library/WebServer/Services/pywrapper/tools/python/lib/python2.4/logging/__init__.py",
> line 1333, in shutdown
>     h.close()
>   File
> "/Library/WebServer/Services/pywrapper/tools/python/lib/python2.4/logging/__init__.py",
> line 674, in close
>     del _handlers[self]
> KeyError: <logging.StreamHandler instance at 0x1385418>
>
> This listing comes from the terminal. I am sure I did something wrong with
> the files, however it should not crash like this. Anyways here are the
> files:
>
> The alias file is at http://eurisco.ecpgr.org/schemas/alias.txt
> The schema file is at:
> http://eurisco.ecpgr.org/schemas/MCPD_EURISCO_1.00.xsd
> And the model file is at:
> http://eurisco.ecpgr.org/schemas/MCPD_EURISCO_1.00.xml
>
> I have now removed the reference to that alias file so the system can
> work.
> Looking at the alias file I see a strange syntax: is that correct? I only
> changed the label, alias and added the models section.
>
> Thanks!
>
> Milko
>

[PyWrapper-devel] FW: Call: Taxonomic Data Provider Tool Developer

[<m.d...@BG...>]

FYI

If anyone is interested in this,
please go ahead with the application!


-----Original Message-----
From: dh...@gb... [mailto:dh...@gb...]=20
Sent: Freitag, 10. November 2006 12:24
To: All users
Cc: dh...@gb...
Subject: Call: Taxonomic Data Provider Tool Developer


  Call: Taxonomic Data Provider Tool Developer
--------------------------------------------

GBIF is seeking to simplify the integration of data relating to=20
nomenclature (scientific names) and taxonomy (classification of=20
organisms using scientific names) by developing tools to connect such=20
data more easily to the GBIF network.

GBIF is addressing this issue in several ways:

1. Working with the Species 2000 & ITIS Catalogue of Life partnership=20
(http://www.sp2000.org/) to promote the development of a network of=20
global species databases
2. Enhancing the GBIF data portal (http://www.gbif.net/) to index=20
nomenclatural and taxonomic resources served over the web as=20
tab-delimited data sets
3. Developing a data provider tool based on TDWG (http://www.tdwg.org/)=20
data standards to support dynamic query of nomenclatural and taxonomic=20
data sets over the web (more complex for data providers than 2. above,=20
but offering a search interface)

GBIF is seeking the services of a software developer to develop the data =

provider tool (item 3 above).

The tool should have the following features:

1. Relational database (two version of same model in Access and MySQL)=20
corresponding to TDWG Taxon Concept Schema (TCS) v. 1.01=20
(http://www.tdwg.org/subgroups/tnc/tcs-schema-repository/)
2. Customised provider tool using either the Python implementation=20
(pyWrapper, http://trac.pywrapper.org/) or the PHP implementation=20
(forthcoming) of the TAPIR protocol, with five endpoints configured, one =

for each class of data obect in TCS (Specimen, Publication, TaxonName,=20
TaxonConcept, TaxonRelationshipAssertion)
3. Customisation of TAPIR configuration interfaces as required 4. =
Interface to import tab-delimited file formats adopted by GBIF (see=20
item 2, above) into the TCS relational database

The developer should have the following skills:

1. Experience in web development using PHP or Python.
2. Experience in modeling data structures using a relational database=20
(specifically MySQL and/or Access)
3. Familiarity with TAPIR or one of the earlier TDWG data access=20
protocols (DiGIR, http://digir.sourceforge.net/, or BioCASe,=20
http://www.biocase.org/products/protocols/index.shtml)
4. Ability to plan and organise development work

Familarity with the TDWG Taxon Concept Schema and general understanding=20
of the principles of nomenclature and taxonomy will be an advantage.

The GBIF Secretariat expects to place a contract for a period of=20
approximately four months' work.

How to apply
------------

Interested applicants should send the following by e-mail to Donald=20
Hobern, GBIF Deputy Director for Informatics (dh...@gb...) by 30=20
November 2006:

1. Curriculum vitae
2. Description of relevant experience and skills
3. Details on availability
4. Expected remuneration

------------------------------------------------------------
Donald Hobern (dh...@gb...)
Deputy Director for Informatics
Global Biodiversity Information Facility Secretariat Universitetsparken =
15, DK-2100 Copenhagen, Denmark
Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480
------------------------------------------------------------

Re: [PyWrapper-devel] Accessing HTTP data from pywrapper

[<m.d...@BG...>]

That was easy.
Its just another way of attaching the hook. Its done like this now with =
saveHttpBody being the callback function:

cherrypy.request.hooks.attach('before_request_body', saveHttpBody, =
failsafe=3DNone, priority=3DNone)

So go ahead with moby, javi!
Markus


> -----Original Message-----
> From: pyw...@li...=20
> [mailto:pyw...@li...] On=20
> Behalf Of D=F6ring, Markus
> Sent: Montag, 13. November 2006 10:20
> To: PyWrapper Developers mailing list
> Subject: Re: [PyWrapper-devel] Accessing HTTP data from pywrapper
>=20
>=20
> I will try to investigate later today. But really there=20
> shouldn't be a change. Try to dump all parameters for the=20
> request and see what gets into CP.
>=20
> The parameter should be created here:=20
> http://trac.pywrapper.org/pywrapper/browser/trunk/webapp/pywrapper.py
>=20
> In line 22 "def saveHttpBody():"
>=20
>=20
> Ahh! Line 37 is commented out!
> This is where the function above is assigned as a hook that=20
> gets executed before the body is being read.
> 	#cpg.request.hooks['before_request_body']=3DsaveHttpBody
>=20
> And that's something that has changed in CP3. you cannot=20
> declare a hook like this anymore I think. Shouldn't be hard:=20
> http://www.cherrypy.org/wiki/WhatsNewIn30#Hooks
>=20
> Markus
>=20
>=20
>=20
> > -----Original Message-----
> > From: pyw...@li...
> > [mailto:pyw...@li...] On=20
> > Behalf Of Javier privat
> > Sent: Sonntag, 12. November 2006 20:09
> > To: PyWrapper Developers mailing list
> > Subject: [PyWrapper-devel] Accessing HTTP data from pywrapper
> >=20
> >=20
> > Hey Markus,
> >=20
> > I am trying to debug biomoby in my machine, but I get a very strange
> > behaviour I think since we moved to cherrypy 3.0
> >=20
> > When I do this in the biomoby request class
> >=20
> >              stdin, length =3D self.getPara
> > (cfgObj.PyWrapper.httpBodyParameter, (None,None))
> >              if stdin is None:
> >                  log.warn("No request message found.")
> >                  raise RequestParsingError("No SOAP message=20
> found in =20
> > the request")
> >=20
> > Seems that I always get stdin is None and therefore can not
> > catch the =20
> > biomoby request... Any idea?
> >=20
> > I am trying with dashboard so I suppose I am really sending
> > something =20
> > to pywrapper, but I lost the little program I was using to debug =20
> > traffic, do you remember the name of the tool for mac os x=20
> to trace =20
> > traffic?
> >=20
> > Cheers.
> >=20
> > --------------------------------------------------------------
> > -----------
> > Using Tomcat but need to do more? Need to support web
> > services, security? Get stuff done quickly with=20
> > pre-integrated technology to make your job easier Download=20
> > IBM WebSphere Application Server v.1.0.1 based on Apache=20
> > Geronimo=20
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
> dat=3D121642
> _______________________________________________
> PyWrapper-devel mailing list PyW...@li...
> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel
>=20
> --------------------------------------------------------------
> -----------
> Using Tomcat but need to do more? Need to support web=20
> services, security? Get stuff done quickly with=20
> pre-integrated technology to make your job easier Download=20
> IBM WebSphere Application Server v.1.0.1 based on Apache=20
> Geronimo=20
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
dat=3D121642
_______________________________________________
PyWrapper-devel mailing list PyW...@li...
https://lists.sourceforge.net/lists/listinfo/pywrapper-devel

Re: [PyWrapper-devel] Accessing HTTP data from pywrapper

[<m.d...@BG...>]

I will try to investigate later today. But really there shouldn't be a =
change.
Try to dump all parameters for the request and see what gets into CP.

The parameter should be created here:
http://trac.pywrapper.org/pywrapper/browser/trunk/webapp/pywrapper.py

In line 22 "def saveHttpBody():"


Ahh! Line 37 is commented out!
This is where the function above is assigned as a hook that gets =
executed before the body is being read.
	#cpg.request.hooks['before_request_body']=3DsaveHttpBody

And that's something that has changed in CP3. you cannot declare a hook =
like this anymore I think.
Shouldn't be hard:
http://www.cherrypy.org/wiki/WhatsNewIn30#Hooks

Markus



> -----Original Message-----
> From: pyw...@li...=20
> [mailto:pyw...@li...] On=20
> Behalf Of Javier privat
> Sent: Sonntag, 12. November 2006 20:09
> To: PyWrapper Developers mailing list
> Subject: [PyWrapper-devel] Accessing HTTP data from pywrapper
>=20
>=20
> Hey Markus,
>=20
> I am trying to debug biomoby in my machine, but I get a very strange =20
> behaviour I think since we moved to cherrypy 3.0
>=20
> When I do this in the biomoby request class
>=20
>              stdin, length =3D self.getPara=20
> (cfgObj.PyWrapper.httpBodyParameter, (None,None))
>              if stdin is None:
>                  log.warn("No request message found.")
>                  raise RequestParsingError("No SOAP message found in =20
> the request")
>=20
> Seems that I always get stdin is None and therefore can not=20
> catch the =20
> biomoby request... Any idea?
>=20
> I am trying with dashboard so I suppose I am really sending=20
> something =20
> to pywrapper, but I lost the little program I was using to debug =20
> traffic, do you remember the name of the tool for mac os x to trace =20
> traffic?
>=20
> Cheers.
>=20
> --------------------------------------------------------------
> -----------
> Using Tomcat but need to do more? Need to support web=20
> services, security? Get stuff done quickly with=20
> pre-integrated technology to make your job easier Download=20
> IBM WebSphere Application Server v.1.0.1 based on Apache=20
> Geronimo=20
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
dat=3D121642
_______________________________________________
PyWrapper-devel mailing list PyW...@li...
https://lists.sourceforge.net/lists/listinfo/pywrapper-devel

[PyWrapper-devel] Accessing HTTP data from pywrapper

[Javier de la T. <ja...@gm...>]

Hey Markus,

I am trying to debug biomoby in my machine, but I get a very strange  
behaviour I think since we moved to cherrypy 3.0

When I do this in the biomoby request class

             stdin, length = self.getPara 
(cfgObj.PyWrapper.httpBodyParameter, (None,None))
             if stdin is None:
                 log.warn("No request message found.")
                 raise RequestParsingError("No SOAP message found in  
the request")

Seems that I always get stdin is None and therefore can not catch the  
biomoby request... Any idea?

I am trying with dashboard so I suppose I am really sending something  
to pywrapper, but I lost the little program I was using to debug  
traffic, do you remember the name of the tool for mac os x to trace  
traffic?

Cheers.

Re: [PyWrapper-devel] FW: PyWrapper and Species 2000

[Peter B. <p.w...@re...>]

Sure... I'll make sure all discussion is on list - it's just handy to 
have a 'hotline' text chat to solve some ID10T errors that I'd rather 
not publicise! ;-)

Cheers

Pete


Javier de la Torre wrote:
> jaja,
>
> Sorry, I thought that was Markus sending me a private email :D
>
> By the way... we have 5 days left if we wanna ask the TDWG TIP  
> project to fund a developers meeting... and probably IPGRI would also  
> be happy to collaborate on the organization of the meeting. What  
> about a meeting in IPGRI, Rome?
>
> Javi.
>
> On 10/11/2006, at 10:58, Döring, Markus wrote:
>
>   
>> -----Original Message-----
>> From: Döring, Markus
>> Sent: Freitag, 10. November 2006 10:08
>> To: 'Peter Brewer'; Torre de la, Javier
>> Subject: RE: PyWrapper and Species 2000
>>
>>
>> Peter,
>>
>> We are happy to hear that interest from species2000. The current  
>> version of the pywrapper that works with TAPIR and BioMOBY  
>> unfortunately doesn't implement SPICE at all. But I don't hink this  
>> will be hard to add (I will come back to it later). The previous  
>> version, pywrapper 1.x, that run with biocase supported SPICE. So I  
>> know pretty well how the specification works.
>>
>> With TAPIR there are more powerful configurations possible, mainly  
>> through the use of "output models". Using this for SPICE will make  
>> it much easier to implement it. The only thing we would need is an  
>> up to date XML Schema. Then we will have to create a separate  
>> output model for each request-type - we could entirely reuse the  
>> SPICE schema.
>>
>> Then there would need to be a small and newly developed "protocol"  
>> layer for SPICE in pywrapper. That also shouldn't be too bad.  
>> Overall I would expect something like 2 weeks for the  
>> implementation and another week for testing and configuring a  
>> database like the berlin model.
>>
>> The only real problem with having a generic and configurable  
>> wrapper is that taxonomic data is build on tree hierarchies. This  
>> is often represented as self-references in databases but not  
>> always. SO inorder to "map" your local database to the SPICE schema  
>> it usually takes quite some transformation which you often have to  
>> do with views, cause generic wrappers like pywrapper cant handle  
>> this (you cannot simply add some custom SQL). So all I wanted to  
>> say here is that there still remains a bit of the complexity. But  
>> you can be sure the wrappers do understand SPICE correctly and  
>> respond properly - just the data they carry might not be making  
>> sense if they were badly configured.
>>
>> Anyway. I would be very happy if we can make pywrapper SPICE  
>> compliant again. Unfortunately there is not much manpower left from  
>> Javier and myself this year, so we could only do little things. But  
>> we would be very happy to assist someone trying to get into the  
>> python code and do it himself. Its not that hard. Would that be a  
>> possibility?
>>
>> With thanks,
>> Markus
>>
>>
>>
>>     
>>> -----Original Message-----
>>> From: Peter Brewer [mailto:p.w...@re...]
>>> Sent: Freitag, 10. November 2006 09:32
>>> To: Döring, Markus; Torre de la, Javier
>>> Subject: PyWrapper and Species 2000
>>>
>>>
>>> Dear Markus and Javier,
>>>
>>> I'm currently at a Species 2000 meeting in Amsterdam and one of the
>>> issues that has been raised is that of assisting Global
>>> Species Database
>>> managers to provide wrappers for their databases.  As the new Species
>>> 2000 Systems Manager that responsibility apparently falls on
>>> my shoulders!
>>>
>>> It seems clear to me that the best approach is for me to
>>> assist with the
>>> development of PyWrapper by adding support for the SPICE protocol.
>>>
>>> I've downloaded your latest development snapshot and I'm very
>>> impressed
>>> - especially with the excellent level of documentation!  It's such a
>>> relief to come across a piece of scientific software with a
>>> installation
>>> manual more than 3 lines long.  :-)
>>>
>>> What is the current level of support for SPICE in the PyWrapper?  Has
>>> anything been done yet?  I'd be quite surprised if there has
>>> because the
>>> level of documentation of SPICE is very poor - something I'm
>>> also going
>>> to work on over the next couple of months.
>>>
>>> I'll get in touch again next week once I get back to Reading
>>> and hope to
>>> make progress with this quite quickly.
>>>
>>> Best wishes
>>>
>>> Peter Brewer
>>>
>>>
>>>
>>>
>>>
>>>       
>> ---------------------------------------------------------------------- 
>> ---
>> Using Tomcat but need to do more? Need to support web services,  
>> security?
>> Get stuff done quickly with pre-integrated technology to make your  
>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>> Geronimo
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> PyWrapper-devel mailing list
>> PyW...@li...
>> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel
>>     
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> PyWrapper-devel mailing list
> PyW...@li...
> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel
>   

Re: [PyWrapper-devel] FW: PyWrapper and Species 2000

[Javier de la T. <ja...@gm...>]

jaja,

Sorry, I thought that was Markus sending me a private email :D

By the way... we have 5 days left if we wanna ask the TDWG TIP =20
project to fund a developers meeting... and probably IPGRI would also =20=

be happy to collaborate on the organization of the meeting. What =20
about a meeting in IPGRI, Rome?

Javi.

On 10/11/2006, at 10:58, D=F6ring, Markus wrote:

>
>
> -----Original Message-----
> From: D=F6ring, Markus
> Sent: Freitag, 10. November 2006 10:08
> To: 'Peter Brewer'; Torre de la, Javier
> Subject: RE: PyWrapper and Species 2000
>
>
> Peter,
>
> We are happy to hear that interest from species2000. The current =20
> version of the pywrapper that works with TAPIR and BioMOBY =20
> unfortunately doesn't implement SPICE at all. But I don't hink this =20=

> will be hard to add (I will come back to it later). The previous =20
> version, pywrapper 1.x, that run with biocase supported SPICE. So I =20=

> know pretty well how the specification works.
>
> With TAPIR there are more powerful configurations possible, mainly =20
> through the use of "output models". Using this for SPICE will make =20
> it much easier to implement it. The only thing we would need is an =20
> up to date XML Schema. Then we will have to create a separate =20
> output model for each request-type - we could entirely reuse the =20
> SPICE schema.
>
> Then there would need to be a small and newly developed "protocol" =20
> layer for SPICE in pywrapper. That also shouldn't be too bad. =20
> Overall I would expect something like 2 weeks for the =20
> implementation and another week for testing and configuring a =20
> database like the berlin model.
>
> The only real problem with having a generic and configurable =20
> wrapper is that taxonomic data is build on tree hierarchies. This =20
> is often represented as self-references in databases but not =20
> always. SO inorder to "map" your local database to the SPICE schema =20=

> it usually takes quite some transformation which you often have to =20
> do with views, cause generic wrappers like pywrapper cant handle =20
> this (you cannot simply add some custom SQL). So all I wanted to =20
> say here is that there still remains a bit of the complexity. But =20
> you can be sure the wrappers do understand SPICE correctly and =20
> respond properly - just the data they carry might not be making =20
> sense if they were badly configured.
>
> Anyway. I would be very happy if we can make pywrapper SPICE =20
> compliant again. Unfortunately there is not much manpower left from =20=

> Javier and myself this year, so we could only do little things. But =20=

> we would be very happy to assist someone trying to get into the =20
> python code and do it himself. Its not that hard. Would that be a =20
> possibility?
>
> With thanks,
> Markus
>
>
>
>> -----Original Message-----
>> From: Peter Brewer [mailto:p.w...@re...]
>> Sent: Freitag, 10. November 2006 09:32
>> To: D=F6ring, Markus; Torre de la, Javier
>> Subject: PyWrapper and Species 2000
>>
>>
>> Dear Markus and Javier,
>>
>> I'm currently at a Species 2000 meeting in Amsterdam and one of the
>> issues that has been raised is that of assisting Global
>> Species Database
>> managers to provide wrappers for their databases.  As the new Species
>> 2000 Systems Manager that responsibility apparently falls on
>> my shoulders!
>>
>> It seems clear to me that the best approach is for me to
>> assist with the
>> development of PyWrapper by adding support for the SPICE protocol.
>>
>> I've downloaded your latest development snapshot and I'm very
>> impressed
>> - especially with the excellent level of documentation!  It's such a
>> relief to come across a piece of scientific software with a
>> installation
>> manual more than 3 lines long.  :-)
>>
>> What is the current level of support for SPICE in the PyWrapper?  Has
>> anything been done yet?  I'd be quite surprised if there has
>> because the
>> level of documentation of SPICE is very poor - something I'm
>> also going
>> to work on over the next couple of months.
>>
>> I'll get in touch again next week once I get back to Reading
>> and hope to
>> make progress with this quite quickly.
>>
>> Best wishes
>>
>> Peter Brewer
>>
>>
>>
>>
>>
>
> ----------------------------------------------------------------------=20=

> ---
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?=20
> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642
> _______________________________________________
> PyWrapper-devel mailing list
> PyW...@li...
> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel

Re: [PyWrapper-devel] FW: PyWrapper and Species 2000

[Javier de la T. <ja...@gm...>]

Thanks, got that....

I agree with you, enforce the use of the mailing lists as much as =20
possible!! No private like with Milko, discussions everything public.

Javi.

On 10/11/2006, at 10:58, D=F6ring, Markus wrote:

>
>
> -----Original Message-----
> From: D=F6ring, Markus
> Sent: Freitag, 10. November 2006 10:08
> To: 'Peter Brewer'; Torre de la, Javier
> Subject: RE: PyWrapper and Species 2000
>
>
> Peter,
>
> We are happy to hear that interest from species2000. The current =20
> version of the pywrapper that works with TAPIR and BioMOBY =20
> unfortunately doesn't implement SPICE at all. But I don't hink this =20=

> will be hard to add (I will come back to it later). The previous =20
> version, pywrapper 1.x, that run with biocase supported SPICE. So I =20=

> know pretty well how the specification works.
>
> With TAPIR there are more powerful configurations possible, mainly =20
> through the use of "output models". Using this for SPICE will make =20
> it much easier to implement it. The only thing we would need is an =20
> up to date XML Schema. Then we will have to create a separate =20
> output model for each request-type - we could entirely reuse the =20
> SPICE schema.
>
> Then there would need to be a small and newly developed "protocol" =20
> layer for SPICE in pywrapper. That also shouldn't be too bad. =20
> Overall I would expect something like 2 weeks for the =20
> implementation and another week for testing and configuring a =20
> database like the berlin model.
>
> The only real problem with having a generic and configurable =20
> wrapper is that taxonomic data is build on tree hierarchies. This =20
> is often represented as self-references in databases but not =20
> always. SO inorder to "map" your local database to the SPICE schema =20=

> it usually takes quite some transformation which you often have to =20
> do with views, cause generic wrappers like pywrapper cant handle =20
> this (you cannot simply add some custom SQL). So all I wanted to =20
> say here is that there still remains a bit of the complexity. But =20
> you can be sure the wrappers do understand SPICE correctly and =20
> respond properly - just the data they carry might not be making =20
> sense if they were badly configured.
>
> Anyway. I would be very happy if we can make pywrapper SPICE =20
> compliant again. Unfortunately there is not much manpower left from =20=

> Javier and myself this year, so we could only do little things. But =20=

> we would be very happy to assist someone trying to get into the =20
> python code and do it himself. Its not that hard. Would that be a =20
> possibility?
>
> With thanks,
> Markus
>
>
>
>> -----Original Message-----
>> From: Peter Brewer [mailto:p.w...@re...]
>> Sent: Freitag, 10. November 2006 09:32
>> To: D=F6ring, Markus; Torre de la, Javier
>> Subject: PyWrapper and Species 2000
>>
>>
>> Dear Markus and Javier,
>>
>> I'm currently at a Species 2000 meeting in Amsterdam and one of the
>> issues that has been raised is that of assisting Global
>> Species Database
>> managers to provide wrappers for their databases.  As the new Species
>> 2000 Systems Manager that responsibility apparently falls on
>> my shoulders!
>>
>> It seems clear to me that the best approach is for me to
>> assist with the
>> development of PyWrapper by adding support for the SPICE protocol.
>>
>> I've downloaded your latest development snapshot and I'm very
>> impressed
>> - especially with the excellent level of documentation!  It's such a
>> relief to come across a piece of scientific software with a
>> installation
>> manual more than 3 lines long.  :-)
>>
>> What is the current level of support for SPICE in the PyWrapper?  Has
>> anything been done yet?  I'd be quite surprised if there has
>> because the
>> level of documentation of SPICE is very poor - something I'm
>> also going
>> to work on over the next couple of months.
>>
>> I'll get in touch again next week once I get back to Reading
>> and hope to
>> make progress with this quite quickly.
>>
>> Best wishes
>>
>> Peter Brewer
>>
>>
>>
>>
>>
>
> ----------------------------------------------------------------------=20=

> ---
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?=20
> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642
> _______________________________________________
> PyWrapper-devel mailing list
> PyW...@li...
> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel

[PyWrapper-devel] FW: PyWrapper and Species 2000

[<m.d...@BG...>]

-----Original Message-----
From: D=F6ring, Markus=20
Sent: Freitag, 10. November 2006 10:08
To: 'Peter Brewer'; Torre de la, Javier
Subject: RE: PyWrapper and Species 2000


Peter,

We are happy to hear that interest from species2000. The current version =
of the pywrapper that works with TAPIR and BioMOBY unfortunately doesn't =
implement SPICE at all. But I don't hink this will be hard to add (I =
will come back to it later). The previous version, pywrapper 1.x, that =
run with biocase supported SPICE. So I know pretty well how the =
specification works.

With TAPIR there are more powerful configurations possible, mainly =
through the use of "output models". Using this for SPICE will make it =
much easier to implement it. The only thing we would need is an up to =
date XML Schema. Then we will have to create a separate output model for =
each request-type - we could entirely reuse the SPICE schema.

Then there would need to be a small and newly developed "protocol" layer =
for SPICE in pywrapper. That also shouldn't be too bad. Overall I would =
expect something like 2 weeks for the implementation and another week =
for testing and configuring a database like the berlin model.

The only real problem with having a generic and configurable wrapper is =
that taxonomic data is build on tree hierarchies. This is often =
represented as self-references in databases but not always. SO inorder =
to "map" your local database to the SPICE schema it usually takes quite =
some transformation which you often have to do with views, cause generic =
wrappers like pywrapper cant handle this (you cannot simply add some =
custom SQL). So all I wanted to say here is that there still remains a =
bit of the complexity. But you can be sure the wrappers do understand =
SPICE correctly and respond properly - just the data they carry might =
not be making sense if they were badly configured.

Anyway. I would be very happy if we can make pywrapper SPICE compliant =
again. Unfortunately there is not much manpower left from Javier and =
myself this year, so we could only do little things. But we would be =
very happy to assist someone trying to get into the python code and do =
it himself. Its not that hard. Would that be a possibility?

With thanks,
Markus



> -----Original Message-----
> From: Peter Brewer [mailto:p.w...@re...]
> Sent: Freitag, 10. November 2006 09:32
> To: D=F6ring, Markus; Torre de la, Javier
> Subject: PyWrapper and Species 2000
>=20
>=20
> Dear Markus and Javier,
>=20
> I'm currently at a Species 2000 meeting in Amsterdam and one of the
> issues that has been raised is that of assisting Global=20
> Species Database=20
> managers to provide wrappers for their databases.  As the new Species=20
> 2000 Systems Manager that responsibility apparently falls on=20
> my shoulders!
>=20
> It seems clear to me that the best approach is for me to
> assist with the=20
> development of PyWrapper by adding support for the SPICE protocol.
>=20
> I've downloaded your latest development snapshot and I'm very
> impressed=20
> - especially with the excellent level of documentation!  It's such a=20
> relief to come across a piece of scientific software with a=20
> installation=20
> manual more than 3 lines long.  :-)
>=20
> What is the current level of support for SPICE in the PyWrapper?  Has
> anything been done yet?  I'd be quite surprised if there has=20
> because the=20
> level of documentation of SPICE is very poor - something I'm=20
> also going=20
> to work on over the next couple of months.
>=20
> I'll get in touch again next week once I get back to Reading
> and hope to=20
> make progress with this quite quickly.
>=20
> Best wishes
>=20
> Peter Brewer
>=20
>  =20
>=20
>=20
>=20

Re: [PyWrapper-devel] pywr versioning

[Javier de la T. <ja...@gm...>]

The second.

Javi.

On 07/11/2006, at 7:57, Markus D=F6ring wrote:

> javi,
> another question.
> I will generate a release script that updates a stable branch, =20
> keeps track of version and updates the version where its being used =20=

> throughout pywrapper.
> how should we handle version? I will always include the revision - =20
> probably as build(895) - so we know exactly what people are using. =20
> but do we need to use a minor version number which is being =20
> increased automatically everytime we call the release script? that =20
> would be pretty often I suspect. so we would have 2.1.34 etc. or we =20=

> would just have 2.1 build(895)
>
> what do you think? any preferences?
> markus
>
>
>

Re: [PyWrapper-devel] pywrapper errors

[Javier de la T. <ja...@gm...>]

If you think we can reuse the existing one then it would be great...

Do you think you can make the biocase one be built as an expandable =20
tree?

I am gonna look iof there is any code snippet in internet for =20
browsing xml schemas...

Javi.

On 31/10/2006, at 11:46, D=F6ring, Markus wrote:

> AJAX is fine, but it would probably much easier to reuse the =20
> existing biocase one.
> The latest version does use anchors to find back where you were =20
> editing.
> Lets see how much time there is to spend.
> M
>
>
>> -----Original Message-----
>> From: pyw...@li...
>> [mailto:pyw...@li...] On
>> Behalf Of Javier privat
>> Sent: Dienstag, 31. Oktober 2006 08:33
>> To: PyWrapper Developers mailing list
>> Subject: Re: [PyWrapper-devel] pywrapper errors
>>
>>
>> Good morning,
>>
>>> Well, there was always the idea to allow mapping to canonical
>>> models using the schema tree hierarchy we used in biocase. But
>>> that's for a new version for sure!
>>>
>> Yes yes, thats a new version. I had the requests from Milko for a
>> better mapping to canonical models. By the way this will also
>> help us
>> supporting other protocols-schemas.
>> His requests are pretty much what we had in biocase:
>>
>> -Show the schema as a tree.
>> -Show mandatory fields in red
>> -Indicate if a field is repeatable and be able to set up
>> dontRepeat -Show documentation behind the name of the concept
>>
>> And do all this with AJAX without having to refresh the page or at
>> least controlling very well the scroll after a refresh (this one is
>> easy!)
>>
>>> Alright, lets set the max repeating number to 1000 by default, ok?
>>> Markus
>>
>> Fine!
>>
>> Javi.
>>
>> --------------------------------------------------------------
>> -----------
>> Using Tomcat but need to do more? Need to support web
>> services, security? Get stuff done quickly with
>> pre-integrated technology to make your job easier Download
>> IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
> dat=3D121642
> _______________________________________________
> PyWrapper-devel mailing list PyW...@li...
> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel
>
> ----------------------------------------------------------------------=20=

> ---
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?=20
> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642
> _______________________________________________
> PyWrapper-devel mailing list
> PyW...@li...
> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel

Re: [PyWrapper-devel] pywrapper errors

[Javier de la T. <ja...@gm...>]

Hey I have a javascript function that saves the exact scrolling =20
position before submission and then goes exactly there... the effect =20
is like if you hadnt actually refresh the page, kind of =20
pseudoajax :D, it is very neat. I took it from Renatos tapirLink

Cheers.

On 31/10/2006, at 11:46, D=F6ring, Markus wrote:

> AJAX is fine, but it would probably much easier to reuse the =20
> existing biocase one.
> The latest version does use anchors to find back where you were =20
> editing.
> Lets see how much time there is to spend.
> M
>
>
>> -----Original Message-----
>> From: pyw...@li...
>> [mailto:pyw...@li...] On
>> Behalf Of Javier privat
>> Sent: Dienstag, 31. Oktober 2006 08:33
>> To: PyWrapper Developers mailing list
>> Subject: Re: [PyWrapper-devel] pywrapper errors
>>
>>
>> Good morning,
>>
>>> Well, there was always the idea to allow mapping to canonical
>>> models using the schema tree hierarchy we used in biocase. But
>>> that's for a new version for sure!
>>>
>> Yes yes, thats a new version. I had the requests from Milko for a
>> better mapping to canonical models. By the way this will also
>> help us
>> supporting other protocols-schemas.
>> His requests are pretty much what we had in biocase:
>>
>> -Show the schema as a tree.
>> -Show mandatory fields in red
>> -Indicate if a field is repeatable and be able to set up
>> dontRepeat -Show documentation behind the name of the concept
>>
>> And do all this with AJAX without having to refresh the page or at
>> least controlling very well the scroll after a refresh (this one is
>> easy!)
>>
>>> Alright, lets set the max repeating number to 1000 by default, ok?
>>> Markus
>>
>> Fine!
>>
>> Javi.
>>
>> --------------------------------------------------------------
>> -----------
>> Using Tomcat but need to do more? Need to support web
>> services, security? Get stuff done quickly with
>> pre-integrated technology to make your job easier Download
>> IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
> dat=3D121642
> _______________________________________________
> PyWrapper-devel mailing list PyW...@li...
> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel
>
> ----------------------------------------------------------------------=20=

> ---
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?=20
> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642
> _______________________________________________
> PyWrapper-devel mailing list
> PyW...@li...
> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel

Re: [PyWrapper-devel] pywrapper errors

[<m.d...@BG...>]

AJAX is fine, but it would probably much easier to reuse the existing =
biocase one.
The latest version does use anchors to find back where you were editing.
Lets see how much time there is to spend.
M


> -----Original Message-----
> From: pyw...@li...=20
> [mailto:pyw...@li...] On=20
> Behalf Of Javier privat
> Sent: Dienstag, 31. Oktober 2006 08:33
> To: PyWrapper Developers mailing list
> Subject: Re: [PyWrapper-devel] pywrapper errors
>=20
>=20
> Good morning,
>=20
> > Well, there was always the idea to allow mapping to canonical
> > models using the schema tree hierarchy we used in biocase. But =20
> > that's for a new version for sure!
> >
> Yes yes, thats a new version. I had the requests from Milko for a =20
> better mapping to canonical models. By the way this will also=20
> help us =20
> supporting other protocols-schemas.
> His requests are pretty much what we had in biocase:
>=20
> -Show the schema as a tree.
> -Show mandatory fields in red
> -Indicate if a field is repeatable and be able to set up=20
> dontRepeat -Show documentation behind the name of the concept
>=20
> And do all this with AJAX without having to refresh the page or at =20
> least controlling very well the scroll after a refresh (this one is =20
> easy!)
>=20
> > Alright, lets set the max repeating number to 1000 by default, ok?=20
> > Markus
>=20
> Fine!
>=20
> Javi.
>=20
> --------------------------------------------------------------
> -----------
> Using Tomcat but need to do more? Need to support web=20
> services, security? Get stuff done quickly with=20
> pre-integrated technology to make your job easier Download=20
> IBM WebSphere Application Server v.1.0.1 based on Apache=20
> Geronimo=20
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
dat=3D121642
_______________________________________________
PyWrapper-devel mailing list PyW...@li...
https://lists.sourceforge.net/lists/listinfo/pywrapper-devel

Re: [PyWrapper-devel] pywrapper errors

[Javier de la T. <ja...@gm...>]

Good morning,

> Well, there was always the idea to allow mapping to canonical  
> models using the schema tree hierarchy we used in biocase. But  
> that's for a new version for sure!
>
Yes yes, thats a new version. I had the requests from Milko for a  
better mapping to canonical models. By the way this will also help us  
supporting other protocols-schemas.
His requests are pretty much what we had in biocase:

-Show the schema as a tree.
-Show mandatory fields in red
-Indicate if a field is repeatable and be able to set up dontRepeat
-Show documentation behind the name of the concept

And do all this with AJAX without having to refresh the page or at  
least controlling very well the scroll after a refresh (this one is  
easy!)

> Alright, lets set the max repeating number to 1000 by default, ok?
> Markus

Fine!

Javi.

Re: [PyWrapper-devel] PyWrapper and BioCASE Provider Software

[<m.d...@BG...>]

Marc,
I'd always be glad about any testing. you can write to this developer =
list if you run into trouble and there is a bug tracking site where you =
can submit tickets.=20
http://trac.pywrapper.org/pywrapper/wiki/Contribute#UserFeedback=20
we use it a lot. btw, ive updated the trunk code a lot over the weekend =
removing about 10 newly discovered bugs!
markus
=20
=20
 -----Original Message-----
From: Marc Brugman [mailto:mbr...@et...]=20
Sent: Freitag, 27. Oktober 2006 10:05
To: D=F6ring, Markus
Subject: RE: PyWrapper and BioCASE Provider Software



	Gutemorgen Markus,


  _____ =20

		From: "D=F6ring, Markus" [mailto:m.d...@BG...]=20
		Sent: donderdag 26 oktober 2006 11:47
		To: mbr...@et...
		Subject: RE: PyWrapper and BioCASE Provider Software
	=09
	=09
		Marc,
		unfortunately we are still in the progress of updating documentation =
and creating installers.
		so ive included all libraries that do not need comilation into the =
software directly, but we want to release pywrapper with an installer =
that does all for you and even includes a local version of python, so =
your system will not get dirty at all. there should be a windows binary =
installer and for linux/osx an installer script that you need to run. =
unfortunately we still need some days to finish this as we can only work =
on it in our free time on weekends and evenings.

	If you need my help to test just ask me. I have some free time myself =
at night and in the weekend  that I can spend on working with you. I =
have MacOS X and Windows XP at home. I have access to a Windows 2003 =
server (32 and 64 bits) and Maxerver OS X 10.3 and 10.4 for testing at =
ETI.

		the wrapper surely runs on any system, but right now has limited =
support for rdbms - currently only mysql and postgresql.
		we need ms sql server, access & oracle pretty quickly though.

	Unfortunately I am not a Python programmer...
	=20
	I will let you know when I am stuck with the program.
	=20
	Wiedersehn,
	=20
	Marc

Re: [PyWrapper-devel] pywrapper errors

[<m.d...@BG...>]

> > http://trac.pywrapper.org/pywrapper/ticket/124
>=20
> This is a difficult one... Actually because I was going to=20
> ask you to =20
> change your chip on the config tool and that we start considering =20
> allowing a better maping to canonical outputmodels or actually to =20
> just schemas like in the biocase world. But i think this need=20
> further =20
> discussion.

Well, there was always the idea to allow mapping to canonical models =
using the schema tree hierarchy we used in biocase. But that's for a new =
version for sure!



> > http://trac.pywrapper.org/pywrapper/ticket/120
>=20
> Cool, But it might be something to consider adding some=20
> parameters by =20
> default... we dont want every new resource to be widely open with no =20
> restrictions right?


Alright, lets set the max repeating number to 1000 by default, ok?
Markus

Re: [PyWrapper-devel] pywrapper errors

[Javier de la T. <ja...@gm...>]

Ok,

Checking...

On 29/10/2006, at 16:33, Markus D=F6ring wrote:

> hey there,
> ive fixed most of the errors you found.
> But some of them were invalid I think, please take a look at what I =20=

> did:
>
> http://trac.pywrapper.org/pywrapper/ticket/124

This is a difficult one... Actually because I was going to ask you to =20=

change your chip on the config tool and that we start considering =20
allowing a better maping to canonical outputmodels or actually to =20
just schemas like in the biocase world. But i think this need further =20=

discussion.

> http://trac.pywrapper.org/pywrapper/ticket/120

Cool, But it might be something to consider adding some parameters by =20=

default... we dont want every new resource to be widely open with no =20
restrictions right?

> http://trac.pywrapper.org/pywrapper/ticket/115

I agree with your comments on the ticket...

> http://trac.pywrapper.org/pywrapper/ticket/116

Ok, I accept your comment on this. The BioMOBY config file will be =20
created only once the user user click on the biomoby settings.
Ideally it should only be created when a new service is created, but =20
that will be much more work to change it now... and I dont think is =20
that bad to leave a biomoby_setting file there no?
Fixed!

> http://trac.pywrapper.org/pywrapper/ticket/109

Good, I think this one is solved then.

>
> the only problems left are the ones to do with cherrypy3.
> I gotta find out how to configure mod_python and how to get rid of =20
> this stupid error when shutting down the server.
>
Good luck, we are almost there :)

Javi.

Re: [PyWrapper-devel] pywrapper site

[Javier de la T. <ja...@gm...>]

Done!

On 29/10/2006, at 16:40, Markus D=F6ring wrote:

> javi,
> can you add IPGRI to the right bottom of our sponsors in Trac?
> m

Re: [PyWrapper-devel] Pywrapper libs

[Javier de la T. <ja...@gm...>]

Fine,

I would also add the soap, and biomoby libraries (they dont need to be
compiled).

I have an empty machine now and I dont have xcode installed so I can
not really install anything, aghhh, until I get to Madrid I dont think
I can do much. And unfortunately SSH is close on the network here so I
can not access any external server...

On 10/24/06, "D=F6ring, Markus" <m.d...@bg...> wrote:
> Javi, One more thing, something we wanted to do for some time already:
> I've included some pure python libraries in our lib directory so we don't=
 need to install them anywhere.
> Its not really needed if we have the installer, but it will make the inst=
allation at least faster cause they are there already! The libs are so far:
>  Cherrypy300beta
>  kid 0.9.3
>  elementtree XXX
>
> --
>  Markus D=F6ring
>  Botanic Garden and Botanical Museum Berlin Dahlem,
>  Dept. of Biodiversity Informatics
>  K=F6nigin-Luise-Str. 6-8, D-14191 Berlin
>  Phone: +49 30 83850-284
>  Email: m.d...@bg...
>  URL: http://www.bgbm.org/BioDivInf/,
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> PyWrapper-devel mailing list
> PyW...@li...
> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel
>

[PyWrapper-devel] FW: Dev server

[<m.d...@BG...>]

Ah,
Some more. Ive activated the configtool password checking!
And the server runs as production by default. If you wanna start it as a =
dev sever, supply dev as a parameter to the startup script:

python start_server.py 8079 dev
 or
python start_server.py dev 1234

--
 Markus D=F6ring

[PyWrapper-devel] Pywrapper libs

[<m.d...@BG...>]

Javi, One more thing, something we wanted to do for some time already:
I've included some pure python libraries in our lib directory so we =
don't need to install them anywhere.
Its not really needed if we have the installer, but it will make the =
installation at least faster cause they are there already! The libs are =
so far:
 Cherrypy300beta
 kid 0.9.3
 elementtree XXX

--
 Markus D=F6ring
 Botanic Garden and Botanical Museum Berlin Dahlem,
 Dept. of Biodiversity Informatics
 K=F6nigin-Luise-Str. 6-8, D-14191 Berlin
 Phone: +49 30 83850-284
 Email: m.d...@bg...
 URL: http://www.bgbm.org/BioDivInf/,

Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir: capabilities

[Javier de la T. <ja...@gm...>]

Hi Renato,

> The content of dct:modified could also be manually updated whenever
> there are significant changes in the underlying data. In the worst
> case it would always show us the provider's creation date. But then
> we should probably have dct:modifed and dct:created...
>
> I can't remember if there was any specific reason for not including
> both DublinCore fields. Anyway, it makes sense to have dct:created
> and dct:modified, doesn't matter if optional or mandatory.
>

I also dont remember, but I think it was because Markus just looked  
for the dublin core concepts that matched the previous concepts we  
had. So probably we haven't even consider it. I really dont mind  
adding it, well I mind because we are feature freeze already, but  
apart of this I dont mind... maybe I tend more for optional than  
mandatory because, again, when something was created can also be  
difficult to figure out. Let say that I update my provider software,  
if the software doesnt take care the creation date will be "recreated".

Javi.

Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir: capabilities

[Renato De G. <re...@cr...>]

Hi again,

Now about the dct:modified message...

In DiGIR/DarwinCore networks "DateLastModified" is mandatory both as 
a mapped concept and as a resource attribute inside each metadata 
response. I'm not sure how important it is to force providers to 
include this information even when they cannot get it automatically 
from individual records. It makes a difference for indexers, but they 
can live without this information (basically re-scanning everything 
periodically).

The content of dct:modified could also be manually updated whenever 
there are significant changes in the underlying data. In the worst 
case it would always show us the provider's creation date. But then 
we should probably have dct:modifed and dct:created...

I can't remember if there was any specific reason for not including 
both DublinCore fields. Anyway, it makes sense to have dct:created 
and dct:modified, doesn't matter if optional or mandatory.

Regards,
--
Renato

On 31 Jul 2006 at 15:18, Javier de la Torre wrote:

> Cool,
> 
> Then we dont have to discuss anything. Lets make it optional.
> 
> Cheers.
> 
> On 7/31/06, "D=F6ring, Markus" <m.d...@bg...> wrote:
> > good.
> > PyWrapper caches the metadata in a file and the provider can
> specify how often it should be updated. Usually once a day. Then its
> lightning fast except for the 1 query. But an empty metadata element
> is ok. The schema currently doesnt allow this I think. Should we
> make at least the dct:modified optional? Ah, the ABCDdiscussion
> again...
> >
> > -- Markus
> >
> >
> > > -----Urspr=FCngliche Nachricht-----
> > > Von: pyw...@li...
> > > [mailto:pyw...@li...] Im
> > > Auftrag von Renato De Giovanni
> > > Gesendet: Montag, 31. Juli 2006 14:28
> > > An: tdw...@li...
> > > Cc: PyWrapper Developers mailing list
> > > Betreff: Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir:
> > > capabilities
> > >
> > > OK, Markus. Agreed.
> > > But maybe we could also consider an empty metadata response,
> > > because "dct:modified" will likely require interaction with
> > > the DB. And it could take some time for the larger ones
> > > (experience from DiGIR).
> > >
> > > Regards,
> > > --
> > > Renato
> > >
> > > > I have implemented the log-only request now and would like
> > > to suggest
> > > > the
> > > > following:
> > > >
> > > > 1) add "log-only" attribute to responeOperationGroup. Ive
> chosen
> > > > "log-only" cause we already have there an attribute
> "apply-xslt"
> > > > 2) add a mandatory boolean attribute "logRequestsDenied" to
> the
> > > > operation element in a capabilities request
> > > > 3) use existing responses for the log-only request. So if you
> do a
> > > > search with log-only active, you will get an empty search
> response
> > > > back. Thats much easier to implement and doesnt require any
> > > change in
> > > > the schema. The same works with inventories. Pong, Capa &
> Meta
> > > > responses dont cost much anyway, so we could do a normal
> > > response (if
> > > > anyway uses log-only with those requests at all)
> > > >
> > > >
> > > > Does everyone agree to this?
> > > > The schema is already updated for this.
> > > >
> > > >
> > > > Markus

[PyWrapper-devel] TDWG abstract about PyWrapper

[Javier de la T. <ja...@gm...>]

Hi all,

I suppose most of the people is already in holidays, but maybe I am
lucky. I will be submitting an abstract about PyWrapper for next TDWG
meeting in Missouri.
My idea is to explain the movement from a close development to a real
open source community that I hope we are doing.
Therefore I would like to ask everybody to revise the abstract and
comment it if you have a moment. I would also appreciate editorial and
orthographical help!

Here it goes:

--------------
PyWrapper v2: from a project development to a real open source community
de la Torre, J., D=F6ring, M.

PyWrapper v2 is a major revision of the previous BioCASe Provider
Software. It has been highly redeveloped to become the first TAPIR
implementation. During the last year several projects had contributed
to its development and extension. At the same time the project has
been moved into a new development environment, outside of any
institution, to promote its development by a real open source
community.

Additionally, PyWrapper has evolved into a multiprotocol middleware
software. Different projects are demanding to make their data
providers available through different protocols, not only TDWG
related. The software has been modularized and support for BioMOBY
protocol has been already implemented. Plans include providing support
for LSID resolution and WFS in the middle term. The goal is to provide
a single interface for providers to map their databases only once and
start sharing their data in multiple different protocols.

Finally it is also envision the development of complementary tools to
bundle with PyWrapper. The first one will be the so-called ?QueryTool;
a generic client to create web interfaces for providers databases
based on AJAX technology. Hopefully the number of additionally modules
available will grow as different communities contribute to the
project.
------------------

Thanks in advance.

Javier.