From jmfernandez at cnb.uam.es  Wed Sep  1 15:00:02 2004
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Wed Sep  1 15:01:19 2004
Subject: [MOBY-dev] Problems testing a newly created MOBY Central (+ Fix)
Message-ID: <41361C32.1020405@cnb.uam.es>

Hi everybody,
	soon I'm going to give a practical seminar about MOBY, and I'm creating 
a local MOBY Central for the practices. This is not my first time 
creating a MOBY Central (I created one 9 months ago), but last version 
in CVS seems to have problems.

	First of all, intructions in

http://www.biomoby.org/InstallingMOBYCentral.html

should be updated, because last RDF changes in MOBY require RDF::Core 
Perl library as a pre-requisite before running a MOBY Central (and 
perhaps a the other libraries??).

	The problem I have found is the next: I ran the 
testMOBYClientCentral_v05.pl script in order to check if the 
installation was correct. First try failed in the first test due the 
lack of RDF::Core. The second try (after installing RDF::Core) seemed to 
run well until it failed in the 18th one, which corresponds to 
registerService. Next lines are from the Apache error log:

[Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] Useless use of 
hash element in void context at 
/usr/lib/perl5/site_perl/5.8.3/RDF/Core/Serializer.pm line 52.
[Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] DBD::mysql::db 
selectrow_array failed: Unknown column 'signatureURL' in 'field list' at 
/usr/lib/perl5/site_perl/5.8.3/MOBY/Adaptor/moby/queryapi/mysql.pm line 
172, <IN> line 34

	I have dug inside the referenced file told by the error message, and it 
is a query to the tables service_instance and authority from mobycentral 
database. It seems the signatureURL column should exist in 
service_instance table, and so moby database skeletons in CVS should be 
updated.
	
	What data type should have that column, Mark? I have created it as a 
VARCHAR(255), and now it works.

	Last, moby database skeletons (ie mysql dumps) in CVS should also be 
updated in order to reflect the last small change Mark told us about the 
datatype of maximum_value and minimum_value.

	Best Regards,
		Jos? Mar?a

-- 
Jos? Mar?a Fern?ndez Gonz?lez		e-mail: jmfernandez@cnb.uam.es
Tlfn:	(+34) 91 585 46 69		Fax:	(+34) 91 585 45 06
Grupo de Dise?o de Proteinas		Protein Design Group
Centro Nacional de Biotecnolog?a	National Center of Biotechnology
C.P.: 28049				Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From mwilkinson at mrl.ubc.ca  Wed Sep  1 15:30:30 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed Sep  1 15:31:01 2004
Subject: [MOBY-dev] Re: [MISC] [MOBY-l] Problems testing a newly created
	MOBY Central (+ Fix)
In-Reply-To: <41361C32.1020405@cnb.uam.es>
References: <41361C32.1020405@cnb.uam.es>
Message-ID: <1094067029.17672.55.camel@myhost.mydomain>

Sorry, I am hoping to get all of the documentation updated as quickly as
possible, but grant deadlines are getting in the way...

The change to the database structure was (I think) announced on the
mailing list.  You can also get it by calling the 'DUMP' method of
MOBY::Central (or via the client), or you can examine the database
directly by logging in to a mysql session with the username
moby_external (no password)

here's the table definition for service_instance:

+---------------------+----------------------------------+------+-----+---------+----------------+
| Field               | Type                             | Null | Key |
Default | Extra          |
+---------------------+----------------------------------+------+-----+---------+----------------+
| category            | enum('moby','soap','wsdl','cgi') | YES  |     |
NULL    |                |
| servicename         | varchar(255)                     |      | MUL
|         |                |
| service_type_uri    | varchar(255)                     |      |    
|         |                |
| authority_id        | int(10) unsigned                 |      |     |
0       |                |
| url                 | varchar(255)                     |      |    
|         |                |
| contact_email       | varchar(255)                     |      |    
|         |                |
| authoritative       | enum('1','0')                    |      |     |
0       |                |
| description         | text                             |      |    
|         |                |
| service_instance_id | int(10) unsigned                 |      | PRI |
NULL    | auto_increment |
| signatureURL        | varchar(255)                     | YES  |     |
NULL    |                |
+---------------------+----------------------------------+------+-----+---------+----------------+


M


On Wed, 2004-09-01 at 12:00, Jos? Mar?a Fern?ndez Gonz?lez wrote:
> Hi everybody,
> 	soon I'm going to give a practical seminar about MOBY, and I'm creating 
> a local MOBY Central for the practices. This is not my first time 
> creating a MOBY Central (I created one 9 months ago), but last version 
> in CVS seems to have problems.
> 
> 	First of all, intructions in
> 
> http://www.biomoby.org/InstallingMOBYCentral.html
> 
> should be updated, because last RDF changes in MOBY require RDF::Core 
> Perl library as a pre-requisite before running a MOBY Central (and 
> perhaps a the other libraries??).
> 
> 	The problem I have found is the next: I ran the 
> testMOBYClientCentral_v05.pl script in order to check if the 
> installation was correct. First try failed in the first test due the 
> lack of RDF::Core. The second try (after installing RDF::Core) seemed to 
> run well until it failed in the 18th one, which corresponds to 
> registerService. Next lines are from the Apache error log:
> 
> [Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] Useless use of 
> hash element in void context at 
> /usr/lib/perl5/site_perl/5.8.3/RDF/Core/Serializer.pm line 52.
> [Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] DBD::mysql::db 
> selectrow_array failed: Unknown column 'signatureURL' in 'field list' at 
> /usr/lib/perl5/site_perl/5.8.3/MOBY/Adaptor/moby/queryapi/mysql.pm line 
> 172, <IN> line 34
> 
> 	I have dug inside the referenced file told by the error message, and it 
> is a query to the tables service_instance and authority from mobycentral 
> database. It seems the signatureURL column should exist in 
> service_instance table, and so moby database skeletons in CVS should be 
> updated.
> 	
> 	What data type should have that column, Mark? I have created it as a 
> VARCHAR(255), and now it works.
> 
> 	Last, moby database skeletons (ie mysql dumps) in CVS should also be 
> updated in order to reflect the last small change Mark told us about the 
> datatype of maximum_value and minimum_value.
> 
> 	Best Regards,
> 		Jos? Mar?a
-- 
Mark Wilkinson (mwilkinson@mrl.ubc.ca)
University of British Columbia iCAPTURE Centre

From mwilkinson at mrl.ubc.ca  Wed Sep 15 11:58:07 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed Sep 15 11:58:12 2004
Subject: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
Message-ID: <1095263887.5954.78.camel@myhost.mydomain>

Hi all, 

we are getting ready to make a very significant change in MOBY-S, so I
need **all existing service providers** to do a one-time exercise.  This
is also important for those who have their own MOBY Central
installations.

As we discussed at the last MOBY meeting, it is desirable and 'good' for
MOBY Central's registry to extract its information using a mechanism
more like a web crawler (more like S-MOBY :-) ).  As a result, Nina has
written an agent that will crawl known MOBY service providers and
extract their service signatures from RDF files.  The agent runs on a
cron, and behaves as follows:

1)  It looks up the last known address of your service signature in the
database
2)  It GET's that address expecting to find an RDF file
3)  If it doesn't find a valid RDF file there, then it flags an error;
after a certain number of errors your service(s) will be deregistered. 
(I believe that it also emails the contactEmail address and tells them
that there was an error.)
4)  If it finds an RDF, it compares the signatures of each service
described in that RDF with the database, and updates or adds these
service descriptions as necessary.
5)  If it expects to find a service signature in this RDF, and can't
find it, it concludes that the service has been taken off-line, and it
will de-register that service.
6)  The agent should be (touch wood!) tolerant of additional RDF in this
signature, such that you can add your own additional annotations to this
RDF as you wish.


The behaviour of MOBY Central is as follows:

1)  When you register a service, you may include a SignatureURL field in
your XML (or as a parameter to the MOBY::Client::Central API) indicating
where your RDF will be located.
2)  Upon successful registration of your service, MOBY Central will send
you the RDF signature of your service - you will not have to generate
this yourself!  (unless you want to... and feel free to do so!).  It
appears in the <RDF> block of the MOBY Registration object (the ->RDF
method of the MOBY:Registration object)
3)  To ensure that your service is not deleted, you must place this RDF
signature in the location that you specified in the signatureURL field
when you registered your service.
4)  If you do not include a signatureURL in your service registration,
your service will be de-registered the next time the agent runs (since
it will be unable to find an RDF file matching your service).  This
might be useful for people who are doing simple test services, as they
wont clutter up the registry for long...
4)  The deregisterService method of the MOBY Central API will **NOT**
function for any service that has a signatureURL.  It will function as
expected for any service does not have a signatureURL.


So, in short, services now have a signatureURL that points to an RDF
file describing their service.  An agent will crawl around on a regular
basis looking at these RDF signatures.  If you update a service, you
change the RDF.  if you remove a service, you delete that portion of the
RDF.  If you add a service, you either add a new signature to the RDF
and let the agent register it automatically, or you use the
registerService function of MOBY Central as you have in the past, and
allow MOBY Central to generate the RDF for you.  Services without a
signatureURL WILL BE DELETED!!!!

Of course, at the moment nobody has a signatureURL :-)  I have set up a
simple CGI page for existing service providers where they can supply a
URL and get the signature RDF for all of their existing services:

http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl


We will switch the agent on in a week or so, and after that all services
without a signatureURL will be deleted, so please go to this page ASAP. 

If the script doesn't work, or if you have any problems please let me
know and I or Nina will fix them immediately.

I hope this isn't too disruptive to people.  I'm convinced that it is a
change for the better!  Contact me by phone or email if you have any
concerns.

Cheers all!

M
-- 
Mark Wilkinson, 
Assistant Professor (Bioinformatics)
Dept. of Medical Genetics, 
University of British Columbia
James Hogg iCAPTURE Centre for Cardiovascular and Pulmonary Research
166 - 1081 Burrard St.
Vancouver, BC, Canada, V6Z 1Y6

tel: (604) 682 2344 ext. 62129
fax: (604) 806 9274
 
------------------------------------------------------------------------
The death rate in Canada currently stands at one per person.  Here
at iCAPTURE, we are working hard to improve on that figure!
------------------------------------------------------------------------
From senger at ebi.ac.uk  Wed Sep 15 16:20:57 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed Sep 15 16:20:56 2004
Subject: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain>
Message-ID: <Pine.OSF.4.21.0409152119021.1471296-100000@mozart.ebi.ac.uk>

Mark,
   I wonder why the RDF part in the registration object is marked as
CDATA. Because RDF must be anyway a valid XML why to bother to surround it
by CDATA. Having CDATA there would prevent me to have CDATA in RDF. Is
there any reason you use CDATA for the RDF part?

   Thanks,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From senger at ebi.ac.uk  Thu Sep 16 10:04:35 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep 16 10:04:42 2004
Subject: [MOBY-dev] Java developers, let's talk together
In-Reply-To: <1094067029.17672.55.camel@myhost.mydomain>
Message-ID: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>

Hi, all,
    We all know that OpenSource is a wonderful idea, and we like it. But 
sometimes the end users (in our case those who are going to use our Java 
libraries) may be confused if there are too many styles involved. I am not 
talking about the coding style - that's usually hidden and as long as it 
does what it says it does, who cares - but about the style how our code is 
deployed and used. I think that our code may provide better service if we 
can follow - when and where possible - similar principles.
   Can we, therefore, have here a chat about these principles? I do not 
want to be seen as an intruder and a dictator (even though I am both), and 
the things I am going to list here (below) are just issues for comments, 
nothing more.
   Also, I am talking about things that are part of the moby-live CVS, not
about code provided by individual service provider - unless this code is
also part of this CVS. Also, I concentrate only on MOBY-S - but it would 
be nice to apply similar principles for both MOBYs - so, Gary, please your 
comments are also valuable.

   1) Package names. It does not matter where the Java code is in the CVS
module (because one can partition things either by language, or by topic,
and both approaches can be mixed) but it would be nice if the Java package
names reflected what the code deals with. I started with names (I hope 
with obvious meanings - if not I am ready to explain):
   org.biomoby.client
   org.biomoby.shared
   org.biomoby.registry
   org.biomoby.service

   Others started their own package names:
   ca.icapture.moby
      Does this mean that the code is owned by somebody else? BTW, there
is no source for this package in the current CVS (just binaries). I
strongly feel that the biomoby CVS should have source code for everything
unless it is clearly labelledf as third-party library. Is this such case? 
   org.mobycentral...
      I think that this actually belongs more to org.biomoby.client - 
because it does not implement mobycentral funtionality (in which case I 
would recommend to use org.biomoby.registry, or org.biomoby.central...) 
but it implements new ways how to access the registry. But I am not sure.

   2) Building. What about to use Ant? :-) At the moment, some subprojects
does not support much re-building by other users. Such support should be a
primary rule for an open source project. Or am I too autocrative here?

   3) Third-party libraries (the ones we have only as jar files).
   There is no single solution. We may have them as part of the CVS, or 
let Ant download them when a user is re-building.
   If we have them as part of moby-live CVS:
   - it is always sure that after 'cvs co' you have everything and in 
correct version
   - the CVS can be huge (as it is now) and many users will use just a 
small sub-part (like perl users) but they still need to check-out 
everything.
   Almost opposite arguments apply for not to have them here. Open 
question...
   But I feel that having the same third-party libraries in several places 
within the same project (Ed?) does sound good.

   4) Generated documentation. I think that Java API that is generated 
from Java code should not be part of the CVS. It is anyway a paint in the 
neck to keep it sync with the CVS. The build procedures (Ant, hopefully) 
should be able to generate it for each user when [s]he is re-building.

   4) Documentation. I hope to have one BioMoby Java starting page from
where Java users can go to all Java-based subprojects. I will update the
current jMoby pages (if you do not mind) - but could you send me the text
you would like to be added at the starting page and pointing to 
yoursub-project please?

   With kindest regards,
   Martin   

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger




From gordonp at cbr.nrc.ca  Thu Sep 16 10:37:47 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Thu Sep 16 10:37:44 2004
Subject: [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
Message-ID: <4149A53B.4050804@cbr.nrc.ca>

Hey Martin,

>   1) Package names. It does not matter where the Java code is in the CVS
>module (because one can partition things either by language, or by topic,
>and both approaches can be mixed) but it would be nice if the Java package
>names reflected what the code deals with. I started with names (I hope 
>with obvious meanings - if not I am ready to explain):
>   org.biomoby.client
>   org.biomoby.shared
>   org.biomoby.registry
>   org.biomoby.service
>  
>
I agree, we should probably fit the other classes into this hierarchy 
for core classes,
and at least into a contrib folder if it's not core.

>   2) Building. What about to use Ant? :-) At the moment, some subprojects
>does not support much re-building by other users. Such support should be a
>primary rule for an open source project. Or am I too autocrative here?
>  
>
Yeah, we use Ant here too, it's a godsend.  Are there any subprojects that
require fancy compilation, or can we just use a generic task?

>   3) Third-party libraries (the ones we have only as jar files).
>   There is no single solution. We may have them as part of the CVS, or 
>let Ant download them when a user is re-building.
>   If we have them as part of moby-live CVS:
>   - it is always sure that after 'cvs co' you have everything and in 
>correct version
>   - the CVS can be huge (as it is now) and many users will use just a 
>small sub-part (like perl users) but they still need to check-out 
>everything.
>   Almost opposite arguments apply for not to have them here. Open 
>question...
>   But I feel that having the same third-party libraries in several places 
>within the same project (Ed?) does sound good.
>  
>
I'm thinking that 95% of users checkout the whole Java archive when they 
fetch
the code.  Also, they usually won't dig deep enough to figure out 
exactly what parts
of the code they are using require what third-party libraries (and hence 
would have
to include all the jars when they wrap up their own MOBY apps).  Then 
you get the
issue of classpaths, and possible conflicts if two sub projects use 
different versions of
the  third party programs. I'm for a libs directory where all the .jars 
are stored, and
probably a README that says which parts of the code use which jars.

>   4) Generated documentation. I think that Java API that is generated 
>from Java code should not be part of the CVS. It is anyway a paint in the 
>neck to keep it sync with the CVS. The build procedures (Ant, hopefully) 
>should be able to generate it for each user when [s]he is re-building.
>  
>
I agree.

>   4) Documentation. I hope to have one BioMoby Java starting page from
>where Java users can go to all Java-based subprojects. I will update the
>current jMoby pages (if you do not mind) - but could you send me the text
>you would like to be added at the starting page and pointing to 
>yoursub-project please?
>  
>
I've got nothing so far, but would like to contrbute a page on MOBY 
object instance creation...

>   With kindest regards,
>   Martin   
>
>  
>

From gordonp at cbr.nrc.ca  Thu Sep 16 10:37:47 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Thu Sep 16 10:37:45 2004
Subject: [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
Message-ID: <4149A53B.4050804@cbr.nrc.ca>

Hey Martin,

>   1) Package names. It does not matter where the Java code is in the CVS
>module (because one can partition things either by language, or by topic,
>and both approaches can be mixed) but it would be nice if the Java package
>names reflected what the code deals with. I started with names (I hope 
>with obvious meanings - if not I am ready to explain):
>   org.biomoby.client
>   org.biomoby.shared
>   org.biomoby.registry
>   org.biomoby.service
>  
>
I agree, we should probably fit the other classes into this hierarchy 
for core classes,
and at least into a contrib folder if it's not core.

>   2) Building. What about to use Ant? :-) At the moment, some subprojects
>does not support much re-building by other users. Such support should be a
>primary rule for an open source project. Or am I too autocrative here?
>  
>
Yeah, we use Ant here too, it's a godsend.  Are there any subprojects that
require fancy compilation, or can we just use a generic task?

>   3) Third-party libraries (the ones we have only as jar files).
>   There is no single solution. We may have them as part of the CVS, or 
>let Ant download them when a user is re-building.
>   If we have them as part of moby-live CVS:
>   - it is always sure that after 'cvs co' you have everything and in 
>correct version
>   - the CVS can be huge (as it is now) and many users will use just a 
>small sub-part (like perl users) but they still need to check-out 
>everything.
>   Almost opposite arguments apply for not to have them here. Open 
>question...
>   But I feel that having the same third-party libraries in several places 
>within the same project (Ed?) does sound good.
>  
>
I'm thinking that 95% of users checkout the whole Java archive when they 
fetch
the code.  Also, they usually won't dig deep enough to figure out 
exactly what parts
of the code they are using require what third-party libraries (and hence 
would have
to include all the jars when they wrap up their own MOBY apps).  Then 
you get the
issue of classpaths, and possible conflicts if two sub projects use 
different versions of
the  third party programs. I'm for a libs directory where all the .jars 
are stored, and
probably a README that says which parts of the code use which jars.

>   4) Generated documentation. I think that Java API that is generated 
>from Java code should not be part of the CVS. It is anyway a paint in the 
>neck to keep it sync with the CVS. The build procedures (Ant, hopefully) 
>should be able to generate it for each user when [s]he is re-building.
>  
>
I agree.

>   4) Documentation. I hope to have one BioMoby Java starting page from
>where Java users can go to all Java-based subprojects. I will update the
>current jMoby pages (if you do not mind) - but could you send me the text
>you would like to be added at the starting page and pointing to 
>yoursub-project please?
>  
>
I've got nothing so far, but would like to contrbute a page on MOBY 
object instance creation...

>   With kindest regards,
>   Martin   
>
>  
>

From mwilkinson at mrl.ubc.ca  Thu Sep 16 18:02:51 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Thu Sep 16 18:03:04 2004
Subject: [MISC] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <Pine.OSF.4.21.0409152119021.1471296-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0409152119021.1471296-100000@mozart.ebi.ac.uk>
Message-ID: <1095372170.11263.37.camel@myhost.mydomain>

Hi Martin, 

you're absolutely right.  I had it in there during debugging so that I
could retrieve messages where the XML was incorrectly formatted.

I've removed that now, but it has the unfortunate consequence that
**EVERYONE** must do a cvs update on their MOBY::Client::Central, since
the old client library assumed that it was CDATA, and wont extract the
RDF-XML from the registration object.

I will also make a new release for those who are only downloading the
releases.

Ugh... sorry about that!

M



On Wed, 2004-09-15 at 13:20, Martin Senger wrote:
> Mark,
>    I wonder why the RDF part in the registration object is marked as
> CDATA. Because RDF must be anyway a valid XML why to bother to surround it
> by CDATA. Having CDATA there would prevent me to have CDATA in RDF. Is
> there any reason you use CDATA for the RDF part?
> 
>    Thanks,
>    Martin
-- 
Mark Wilkinson (mwilkinson@mrl.ubc.ca)
University of British Columbia iCAPTURE Centre
From mwilkinson at mrl.ubc.ca  Thu Sep 16 18:25:11 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Thu Sep 16 18:25:17 2004
Subject: [MOBY-dev] CVS update required & new release available
Message-ID: <1095373511.11263.42.camel@myhost.mydomain>

Hi all, 

I just had to make a change in the client code that will allow you to
extract the RDF from the Registration object (Perl users only).

Please do a CVS update if you are using CVS, or download the latest
release from the biomoby.org/releases page, otherwise the RDF will not
be available to you in the MOBY::Registration object.

Java users should be (?? Martin/Paul ??) unaffected by this change - all
I did was remove the CDATA tags around the RDF-XML in the Registration
XML message.

M


-- 
Mark Wilkinson (mwilkinson@mrl.ubc.ca)
University of British Columbia iCAPTURE Centre
From senger at ebi.ac.uk  Thu Sep 16 18:32:23 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep 16 18:32:19 2004
Subject: [MOBY-dev] CVS update required & new release available
In-Reply-To: <1095373511.11263.42.camel@myhost.mydomain>
Message-ID: <Pine.OSF.4.21.0409162330020.859783-100000@ice.ebi.ac.uk>

> Java users should be (?? Martin/Paul ??) unaffected by this change
>
   I am just coding the whole new registration stuff, so I do not need to
announce a change because I have not commited it yet :-)
   I will let Java users know soon... (I already must thank to Eddie for
his valuable suggestions and conrtibutions).

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From senger at ebi.ac.uk  Thu Sep 16 18:32:23 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep 16 18:32:20 2004
Subject: [MOBY-dev] CVS update required & new release available
In-Reply-To: <1095373511.11263.42.camel@myhost.mydomain>
Message-ID: <Pine.OSF.4.21.0409162330020.859783-100000@ice.ebi.ac.uk>

> Java users should be (?? Martin/Paul ??) unaffected by this change
>
   I am just coding the whole new registration stuff, so I do not need to
announce a change because I have not commited it yet :-)
   I will let Java users know soon... (I already must thank to Eddie for
his valuable suggestions and conrtibutions).

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From mwilkinson at mrl.ubc.ca  Thu Sep 16 18:40:00 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Thu Sep 16 18:40:03 2004
Subject: [MISC] [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
Message-ID: <1095374399.11261.58.camel@myhost.mydomain>

Hi Martin, 

Eddie's package names are my fault.  He was working on something quite
task-specific, and I didn't know if his modules were going to fit
happily with yours or not.  Just to be safe, I advised him to put his
new modules into their own folder for the time being.  I didn't think
further about the naming conventions that he should use.

You should perhaps work out with him directly where they fit best, and
we can make the changes and re-commit.

Sorry about that!

M

-- 
Mark Wilkinson (mwilkinson@mrl.ubc.ca)
University of British Columbia iCAPTURE Centre
From senger at ebi.ac.uk  Thu Sep 16 18:56:12 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep 16 18:57:09 2004
Subject: [MISC] [MOBY-dev] Java developers, let's talk together
In-Reply-To: <1095374399.11261.58.camel@myhost.mydomain>
Message-ID: <Pine.OSF.4.21.0409162353010.859783-100000@ice.ebi.ac.uk>

> Eddie's package names are my fault.
>
   Actually, there was no fault, at all. I was just trying to start
discussion :-)
   And I will continue, especially with the most important topic, pointed
out by Paul G., how to make sure that users of Java libraries always know
what put on their claspath when they use several libraries from several
authors. I have to sleep on that... (because put everything
third-party libs into one shared directory can lead to the versioning
problem).

> You should perhaps work out with him directly where they fit best, and
> we can make the changes and re-commit.
>
   Yes, we are in touch...

   Regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From adf at ncgr.org  Thu Sep 16 19:46:52 2004
From: adf at ncgr.org (Andrew D. Farmer)
Date: Thu Sep 16 19:46:44 2004
Subject: [MISC] [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.OSF.4.21.0409162353010.859783-100000@ice.ebi.ac.uk>
Message-ID: <Pine.LNX.4.44.0409161728270.12609-100000@alberich.ncgr.org>

>    And I will continue, especially with the most important topic, pointed
> out by Paul G., how to make sure that users of Java libraries always know
> what put on their claspath when they use several libraries from several
> authors. I have to sleep on that... (because put everything
> third-party libs into one shared directory can lead to the versioning
> problem).

I missed this in the original message, but it happened to catch my eye here.
FWIW, we had a similar problem in ISYS, where independent components each 
came with their own set of classes (possibly different versions of the same 
libs) and the system itself had its own set. 

The solution we used involved custom classloaders (which I have since read 
officially qualifies one as a master of black magic); if I recall correctly, 
you can actually have multiple versions of the "same" class loaded into one 
VM, provided that they are loaded by different classloaders. Each class 
(version) maintains a reference to the classloader that loaded it, and the 
latter is given the first chance at loading classes referenced by the former 
or delegating to another classloader to find it. It is a bit complicated, 
but designed for situations like this.  
It does require that some mechanism other than the system classpath be used
for specifying the location of the resources for each classloader; in our
case, each component had its own directory space and the custom classloaders
just searched the lib directory of that component for jars (or it could be
done as a config file).

Your situation may not call for measures this complicated, but let me know
if you want any more information on our experience with this approach...

Andrew

> 
> > You should perhaps work out with him directly where they fit best, and
> > we can make the changes and re-commit.
> >
>    Yes, we are in touch...
> 
>    Regards,
>    Martin
> 
> 

-- 

Andrew Farmer
adf@ncgr.org
(505) 995-4464
Database Administrator/Software Developer
National Center for Genome Resources

---
The whole problem with the world is that fools and fanatics are always
so certain of themselves, and wiser people so full of doubts. -
Bertrand Russell
---


From opushneva at yahoo.ca  Fri Sep 17 00:16:47 2004
From: opushneva at yahoo.ca (Nina Opushneva)
Date: Fri Sep 17 00:16:50 2004
Subject: [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
Message-ID: <20040917041647.91439.qmail@web60903.mail.yahoo.com>




 Hi Martin,


>    1) Package names. It does not matter where the
> Java code is in the CVS
> module (because one can partition things either by
> language, or by topic,
> and both approaches can be mixed) but it would be
> nice if the Java package
> names reflected what the code deals with. I started
> with names (I hope 
> with obvious meanings - if not I am ready to
> explain):
>    org.biomoby.client
>    org.biomoby.shared
>    org.biomoby.registry
>    org.biomoby.service
> 

You are definitely right regarding the package name
convention. I didn’t find any rules for that, so I
used my own. Sorry about that, I’ll change the package
names. From my point of view the RDF Agent logically
belongs to the registry. Will be the
org.biomoby.registry.rdfagent as a RDF Agent’s base
package name ok?


>    2) Building. What about to use Ant? :-) At the
> moment, some subprojects
> does not support much re-building by other users.
> Such support should be a
> primary rule for an open source project. Or am I too
> autocrative here?
> 

Agree. I’ll develop an ANT build file for the RDF
Agent and will commit it to the CVS with source code.

>    3) Third-party libraries (the ones we have only
> as jar files).
>    There is no single solution. We may have them as
> part of the CVS, or 
> let Ant download them when a user is re-building.

Location for the third-party libraries is real issue.
I think we should discuss that altogether with
subproject directory structure. I would suggest
following:

…
 |
 subroject name
  |
  + doc
  +config
  + lib
  + src
  |
  Manifest.mf
  readme
  build.xml
  build.sh
  build.bat
  run.sh
  run.bat

This structure provides good subproject encapsulation
and resolves libraries’ version conflict problem. Main
disadvantage –duplicate some libraries. As a result
less efficient use of  the server disk space and some
extra traffic. I think that easy subproject’s
sourcecode / libs administration is much more
valuable. To put all libraries in the same place could
become a nightmare for the project
support/administration especially if keep in mind that
a jar file name means nothing. Two jars with the same
name could have absolutely different content and/or
library versions. 



>    4) Generated documentation. I think that Java API
> that is generated 
> from Java code should not be part of the CVS. It is
> anyway a paint in the 
> neck to keep it sync with the CVS. The build
> procedures (Ant, hopefully) 
> should be able to generate it for each user when
> [s]he is re-building.
> 

Agree. An ANT build file should have task “generate
JavaDoc” or similar.


>    4) Documentation. I hope to have one BioMoby Java
> starting page from
> where Java users can go to all Java-based
> subprojects. I will update the
> current jMoby pages (if you do not mind) - but could
> you send me the text
> you would like to be added at the starting page and
> pointing to 
> yoursub-project please?
> 

It is a very good idea. I will prepare the text and
send it to you as soon as I can.

Best regards,

Nina Opushneva


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
From senger at ebi.ac.uk  Fri Sep 17 06:49:21 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep 17 06:49:15 2004
Subject: [MOBY-dev] Java developers, let's talk together
In-Reply-To: <20040917041647.91439.qmail@web60903.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0409170940490.8147-100000@bagheera.ebi.ac.uk>

[ I am sorry this is a bit longer email. I am abusing the reply to Nina to
address also answers and hints from other people's emails from yesterday.  
Thanks very much for all of them; especially those interesting suggestions
about how to address versioning conflicts of the third party libraries.
Thanks again. ]

> From my point of view the RDF Agent logically belongs to the registry.
> Will be the org.biomoby.registry.rdfagent as a RDF Agent?s base package
> name ok?
>
   I agree, perfect. 

> Agree. I?ll develop an ANT build file for the RDF
> Agent and will commit it to the CVS with source code.
>
   Sounds great. (I put some comments about Ant and third-libraries 
below).
 
> Location for the third-party libraries is real issue.
> I think we should discuss that altogether with
> subproject directory structure.
>
   I would say that if we use Ant then the directory structure is not that 
important (because Ant knows where to find things). The directory 
structure becomes more relevant if we decide to move sources together. 
Which is not so bad idea - if it is easy (e.g. I feel that moving S-MOBY 
current structure to the same directory with jMoby-MOBY-S would not be 
practical).
   My suggestion is this: I am going to write down (first here, later it
should appear also in the docs somewhere; most of it is already there,
btw) some conventions which I am using now (and which - believe me - I was
thinking about quite a lot before I started to use them). Every developer
will have then three options (any has few pros and cons):

   1) To keep her/his subproject separate, or
   2) To incorporate it into current structure in moby-live/Java, or
   3) To put in into moby-live/Java - bus as a totally separate 
subdirectory.

What are the pros and cons?

   Ad 1) is preferable (unless there are reasons against it) because it
will force us to solve problems with versioning of the third-party
libraries as soon as they appear (if they appear; perhaps we will be lucky
:-)). Simply it means to share third-party libraries (sitting in the 'lib'
subdirectory).
   This is also quite good for the end-users using our libraries/code - 
because it is clear to them what to put on their classpath (usually we 
already have 'run' scripts doing it).
   The cons are: You need to conform with the existing structure and
existing policies which may not be always the best for your subproject. If
you want to change such policy it needs more discussion and time because
there are more people involved. Simply speaking: any change in structure
is costly.
   Also this does not solve the problem how the end-users can combine more 
subproject together. I will briefly address this problem at the end.

   Ad 3) is needed if you have special build requirements - so you can 
provide your own build.xml. I have never used nested build.xml so I have 
not yet experiences with this option. But it should work fine.

   If you choose ad 2) or ad 3) the suggested principles are simple:
   a) use Ant
   b) do not put Java generated documentation in the CVS (but make Ant to 
produce it)
   c) send me a link and few words about your subproject that I can
include in the jMoby main page

   If you choose ad 1) the principles above are the same, but there are 
also others (I am not only listing them but I am trying to put some 
rationale that lead me to have them. I am also prepared to discuss how to 
change them if you wish.):
   [ Everything below can be seen in moby-live/Java/build.xml, and in 
scripts moby-live/Java/build.* ]

   d) The sources are in 'src', but most of them are actually in
'src/main'. This is how to make possible to include also sources that do
not belong to any package (such as some testing classes). Simple speaking,
if your sources are in package (most of them, if not all, are) they should
go to 'src/main').

   e) Run scripts (the scripts starting various Java programs) are now in 
the main directory. This is going to be changed because we may have more 
scripts and it should polute the main level too much. There are two 
options:
   e1) To use 'run' directory.
   e2) To use 'build/run' directory.
   Using 'run' directory is easier for users. When they look into the top
level, they see 'run' so they look there and find appropriate script. But 
the script will not work until they actually build everything, and the 
script must always be started from the top level directory (because it 
must have relative path to 'build' and 'lib' directories with classes).
   Using 'build/run' is not so obvious but has otherwise quite a lot
advantages: the scripts are generated by Ant, so they have the full paths
to classes, so they can be called from anywhere; they cannot be started
before building them - because they do not exist before that :-), and they
can be customized (using standard 'build.properties' file) for local needs
(if there are such needs, hopefully as little as possible - but for
example for scripts accessing locations out of the CVS space, like Tomcat, 
it is needed).
   Saying this I vote for 'build/run'...

   f) The probably most contentious topic is how to get third-party
libraries. The basic question is: should they be part of the CVS or be
downloaded when you first build it? After many considerations, and after
discussing with people around here, I have taken the second option
(downloading them). (The moby-live/Java/README explains how it works.) If
we continue to use this option, I will change the place where I am getting
these libraries from to somewhere where other developers can put their
libraries as well (it must be a place accessible by HTTP - at the moment I
have it in my space at EBI).
   This email is too long now - so we may discuss this topic separately if 
we wish.

   That's all regarding the policies.

   Nina also suggested:
>   + doc
>   +config
>
   * moby-live/Java uses 'docs' instead of 'doc', sorry for that;
   * I usually have 'config' under 'src' - but there are no special 
reasons for that.

> This structure provides good subproject encapsulation
> and resolves libraries? version conflict problem. Main
> disadvantage ?duplicate some libraries. As a result
> less efficient use of  the server disk space and some
> extra traffic.
>
   As I tried to explain above, the problem is not with having duplicates,
but with the versioning conflicts that can happen when a user starts using
two - until now separated - subprojects. He has to pick up a library from
one of these subproject - which may lead to failure of the other one. If
we share the libraries from the beginning we know about it during the
developing and testing phase already.

> To put all libraries in the same place could become a nightmare for the
> project support/administration
>
   It may be well true - but better have this nightmare for administrators 
and developers than for our users. Just my 2c.

   So I finish now... Again sorry for the extend of this email.
   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger







From rebecca.ernst at gsf.de  Fri Sep 17 08:30:21 2004
From: rebecca.ernst at gsf.de (Rebecca Ernst)
Date: Fri Sep 17 08:30:13 2004
Subject: [MOBY-dev] signatureURL
In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain>
References: <1095263887.5954.78.camel@myhost.mydomain>
Message-ID: <414AD8DD.7000601@gsf.de>

Hi Mark!

I don't know if you check who of the service providers has generated his 
serviceSignature - Just for the case that you don't check it: 
I wanted to inform you that mips.gsf.de is now up-to-date and prepared 
for the visit of Ninas agent ;-)

Rebecca



-- 
Rebecca Ernst
MIPS, Inst. for Bioinformatics
GSF Research Center for Environment and Health
Ingolstaedter Landstr. 1
85764 Neuherberg
fon: +49 89 3187 3583
email: Rebecca.Ernst@gsf.de

From mwilkinson at mrl.ubc.ca  Fri Sep 17 09:35:45 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Fri Sep 17 09:35:51 2004
Subject: [MOBY-dev] Re: [MISC] signatureURL
In-Reply-To: <414AD8DD.7000601@gsf.de>
References: <1095263887.5954.78.camel@myhost.mydomain>
	<414AD8DD.7000601@gsf.de>
Message-ID: <1095428145.11263.194.camel@myhost.mydomain>

Hiya, 

I will check the database by eye before we switch the agent on, and
contact anyone who is tardy :-)

M


On Fri, 2004-09-17 at 05:30, Rebecca Ernst wrote:
> Hi Mark!
> 
> I don't know if you check who of the service providers has generated his 
> serviceSignature - Just for the case that you don't check it: 
> I wanted to inform you that mips.gsf.de is now up-to-date and prepared 
> for the visit of Ninas agent ;-)
> 
> Rebecca
-- 
Mark Wilkinson (mwilkinson@mrl.ubc.ca)
University of British Columbia iCAPTURE Centre
From gordonp at cbr.nrc.ca  Fri Sep 17 10:44:55 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Fri Sep 17 10:44:48 2004
Subject: [MISC] [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.LNX.4.44.0409161728270.12609-100000@alberich.ncgr.org>
References: <Pine.LNX.4.44.0409161728270.12609-100000@alberich.ncgr.org>
Message-ID: <414AF867.7020707@cbr.nrc.ca>

People will probably disagree with me here, because it creates a little 
more work for the developers,
but can't we all at least try to use the same version of Axis for 
example?  When you want to write new code,
you can see if there's an acceptable version of the lib of interest 
already committed, and if you absolutely must
use a newer version that is not backward compatible, you can put it in a 
project specific lib directory? 

Later, you can try to convince people that they should update their 
code, or place the old lib in their project-specific
lib directory.  e.g. "Hey!  All Java developers!  Get off your asses and 
use Axis 1.1 instead of the crappy
Axis 1.0 which doesn't cache the non-existence of deserialization helper 
classes and causes thousands of
HTTP requests/disk accesses while running SOAP services!".  There are a 
lot more people contributing to
BioPerl, and they all use the same libraries, we Java programmers can't 
let them show us up :-)

>>   And I will continue, especially with the most important topic, pointed
>>out by Paul G., how to make sure that users of Java libraries always know
>>what put on their claspath when they use several libraries from several
>>authors. I have to sleep on that... (because put everything
>>third-party libs into one shared directory can lead to the versioning
>>problem).
>>    
>>
>
>I missed this in the original message, but it happened to catch my eye here.
>FWIW, we had a similar problem in ISYS, where independent components each 
>came with their own set of classes (possibly different versions of the same 
>libs) and the system itself had its own set. 
>
>  
>
>The solution we used involved custom classloaders (which I have since read 
>officially qualifies one as a master of black magic);
>
Hee hee, I wrote my own class loader too, but so that I could 
automatically create applet JARs
with only the classes I needed for the app instead of all of the classes 
in the third party packages
I was using.  When is the next Black Magic Circle clandestine meeting? :-)
From senger at ebi.ac.uk  Fri Sep 17 10:52:41 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep 17 10:52:33 2004
Subject: [MISC] [MOBY-dev] Java developers, let's talk together
In-Reply-To: <414AF867.7020707@cbr.nrc.ca>
Message-ID: <Pine.LNX.4.44.0409171550260.8340-100000@bagheera.ebi.ac.uk>

> People will probably disagree with me here, because it creates a little
> more work for the developers, but can't we all at least try to use the
> same version of Axis for example?
>
   Well, that was my preferred option :-) Put your code into
moby-live/Java, and use what is there in 'lib' (or what is downloaded
there when you first build it - but this is another story). If it does not 
suite you, shout loudly...

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From senger at ebi.ac.uk  Tue Sep 21 07:02:34 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue Sep 21 07:03:00 2004
Subject: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain>
Message-ID: <Pine.LNX.4.44.0409211156090.20316-100000@bagheera.ebi.ac.uk>

Mark,
   I found the agent's behaviour description slightly inconsistent in one 
place (perhaps agent is not inconsistent, perhaps it is only the 
description, I have not tested the agent itself):

> The agent runs on a cron, and behaves as follows:
> ...
> 3)  If it doesn't find a valid RDF file there, then it flags an error;
> after a certain number of errors your service(s) will be deregistered.
> ...
> 5)  If it expects to find a service signature in this RDF, and can't
> find it, it concludes that the service has been taken off-line, and it
> will de-register that service.
>
   So: if there is no file at all, it will try several times before
de-registering the service. But if there is any RDF file but without my
service, it will de-register it immediatelly. Why does it not behave the
same in these two cases? In reality, it would mean slightly different
behaviour when I am adding my first service (so the RDF file with all my
services does not exist yes) and when I am adding the second and more 
services (when the RDF file exists - havig my previous services - but it 
still does not have my last one).

   Regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From senger at ebi.ac.uk  Tue Sep 21 07:02:34 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue Sep 21 07:03:02 2004
Subject: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain>
Message-ID: <Pine.LNX.4.44.0409211156090.20316-100000@bagheera.ebi.ac.uk>

Mark,
   I found the agent's behaviour description slightly inconsistent in one 
place (perhaps agent is not inconsistent, perhaps it is only the 
description, I have not tested the agent itself):

> The agent runs on a cron, and behaves as follows:
> ...
> 3)  If it doesn't find a valid RDF file there, then it flags an error;
> after a certain number of errors your service(s) will be deregistered.
> ...
> 5)  If it expects to find a service signature in this RDF, and can't
> find it, it concludes that the service has been taken off-line, and it
> will de-register that service.
>
   So: if there is no file at all, it will try several times before
de-registering the service. But if there is any RDF file but without my
service, it will de-register it immediatelly. Why does it not behave the
same in these two cases? In reality, it would mean slightly different
behaviour when I am adding my first service (so the RDF file with all my
services does not exist yes) and when I am adding the second and more 
services (when the RDF file exists - havig my previous services - but it 
still does not have my last one).

   Regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From gordonp at cbr.nrc.ca  Tue Sep 21 10:20:56 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Tue Sep 21 10:20:41 2004
Subject: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <Pine.LNX.4.44.0409211156090.20316-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409211156090.20316-100000@bagheera.ebi.ac.uk>
Message-ID: <415038C8.4090105@cbr.nrc.ca>

I think the idea behind the multiple attempts in case (3) is that the 
Web server might be down, or the page temporarily unavailable due to 
resource problems (e.g. forgot to mount the Web server disk :-)).  To 
make these more consistent, maybe I'd only retry fetching the RDF if the 
server could not be contacted, or if it returned a 5XX HTTP code.  
Ortherwise treat it as case (5)?

Martin Senger wrote:

>Mark,
>   I found the agent's behaviour description slightly inconsistent in one 
>place (perhaps agent is not inconsistent, perhaps it is only the 
>description, I have not tested the agent itself):
>
>  
>
>>The agent runs on a cron, and behaves as follows:
>>...
>>3)  If it doesn't find a valid RDF file there, then it flags an error;
>>after a certain number of errors your service(s) will be deregistered.
>>...
>>5)  If it expects to find a service signature in this RDF, and can't
>>find it, it concludes that the service has been taken off-line, and it
>>will de-register that service.
>>
>>    
>>
>   So: if there is no file at all, it will try several times before
>de-registering the service. But if there is any RDF file but without my
>service, it will de-register it immediatelly. Why does it not behave the
>same in these two cases? In reality, it would mean slightly different
>behaviour when I am adding my first service (so the RDF file with all my
>services does not exist yes) and when I am adding the second and more 
>services (when the RDF file exists - havig my previous services - but it 
>still does not have my last one).
>
>   Regards,
>   Martin
>
>  
>

From opushneva at yahoo.ca  Wed Sep 22 01:33:57 2004
From: opushneva at yahoo.ca (Nina Opushneva)
Date: Wed Sep 22 01:33:38 2004
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <Pine.LNX.4.44.0409211156090.20316-100000@bagheera.ebi.ac.uk>
Message-ID: <20040922053357.44035.qmail@web60906.mail.yahoo.com>

Hi Martin,

Mark is away now. May I try to answer your question.


3) It expects to find, there, a RDF representation of
the services hosted by this service provider. If the
connection is refused three times in a row for the
same reason, the services that have been registered
with this signatureURL will be deleted from
mobycentral database.  Every time a message about a
refused connection will be sent to provider.

If the connection was successful, the RDFAgent browses
the input stream and compares it to the data in the
database. New services described will be added to
database; the services, which were expected to be at
this URL, but are missing, will be deleted from the
database.

I don’t think that RDFagent is going to be working
every day, maybe for checking could be enough once a
week (lets say on Sunday). So, providers will have
time to put their RDF into the RDF file. But we can
discuss it.

Cheers,

Nina



--- Martin Senger <senger@ebi.ac.uk> wrote:

> Mark,
>    I found the agent's behaviour description
> slightly inconsistent in one 
> place (perhaps agent is not inconsistent, perhaps it
> is only the 
> description, I have not tested the agent itself):
> 
> > The agent runs on a cron, and behaves as follows:
> > ...
> > 3)  If it doesn't find a valid RDF file there,
> then it flags an error;
> > after a certain number of errors your service(s)
> will be deregistered.
> > ...
> > 5)  If it expects to find a service signature in
> this RDF, and can't
> > find it, it concludes that the service has been
> taken off-line, and it
> > will de-register that service.
> >
>    So: if there is no file at all, it will try
> several times before
> de-registering the service. But if there is any RDF
> file but without my
> service, it will de-register it immediatelly. Why
> does it not behave the
> same in these two cases? In reality, it would mean
> slightly different
> behaviour when I am adding my first service (so the
> RDF file with all my
> services does not exist yes) and when I am adding
> the second and more 
> services (when the RDF file exists - havig my
> previous services - but it 
> still does not have my last one).
> 
>    Regards,
>    Martin
> 
> -- 
> Martin Senger
> 
> EMBL Outstation - Hinxton               
> Senger@EBI.ac.uk     
> European Bioinformatics Institute        Phone:
> (+44) 1223 494636      
> Wellcome Trust Genome Campus            
> (Switchboard:     494444)
> Hinxton                                  Fax  :
> (+44) 1223 494468
> Cambridge CB10 1SD
> United Kingdom                          
> http://industry.ebi.ac.uk/~senger
> 
> _______________________________________________
> moby-l mailing list
> moby-l@biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
> 



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 
From senger at ebi.ac.uk  Wed Sep 22 07:15:31 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed Sep 22 07:15:19 2004
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <20040922053357.44035.qmail@web60906.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0409221211580.2054-100000@bagheera.ebi.ac.uk>

> May I try to answer your question.
> 
Nina,
   Thanks for the clarification.
   Just one minor question: Assuming I do not wish to register a service
for long, therefore I do not plan to send any signatureURL. Is it safe to
include an empty signatureURL tag, or do I *have* to omit it at all?

   Regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From senger at ebi.ac.uk  Wed Sep 22 07:15:31 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed Sep 22 07:15:22 2004
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <20040922053357.44035.qmail@web60906.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0409221211580.2054-100000@bagheera.ebi.ac.uk>

> May I try to answer your question.
> 
Nina,
   Thanks for the clarification.
   Just one minor question: Assuming I do not wish to register a service
for long, therefore I do not plan to send any signatureURL. Is it safe to
include an empty signatureURL tag, or do I *have* to omit it at all?

   Regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From senger at ebi.ac.uk  Wed Sep 22 09:23:31 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed Sep 22 09:29:18 2004
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <20040922053357.44035.qmail@web60906.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>

Here are few comments and perhaps questions. But before that I would like
to stress that these issues are urgent NOW (sorry for the capital letters)
because we are changing libraries now and we need these issues to be fixed
(or explained) really soon. Thanks.

1) Testing registry seems to have still older version - it still returns 
RDF with CDATA. It would be good to have it restarted, or whatever it 
needs. The testing registry with the latest software is important 
especially now when we are testing new registration procedures.

2) The service description, as returned in the RDF, lost its CDATA 
protection. Perhaps it is correct, I do not know enough about RDF 
documents. I have just observed that the 'strange characters', 
such as '>', that I put into my service description, were returned 
escaped: the character '>' was escaped as '&amp;gt;' - which does not seem 
to be correct (but perhaps I am mistaken).

Anyway, I wonder why to play with escaping at all, why not to keep there 
CDATA. We have CDATA in service description just because we did not want 
to escape everything there - is that correct?

3) I also wonder where are all our LSIDs? There is no single LSID in the 
whole returned RDF. I thought that we expressed almost everything as LSIDs 
in biomoby (at least internally).

4) I use this list to strongly express how I agree with the last Rebecca 
email about being still able to deregister a service by calling a 
deregister method even if the service has been registered with the 
signatureURL.

5) Finally, just to make this list complete, I would like to remind the 
others that there had been a discussion about possibility to get RDF from 
the registry even for services that had been already registered. I would 
like to have this feature soon - because it may need an addition tag in 
the service object, so the sooner we know about it the better.

   With kindest regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger


From rebecca.ernst at gsf.de  Wed Sep 22 10:02:18 2004
From: rebecca.ernst at gsf.de (Rebecca Ernst)
Date: Wed Sep 22 10:02:00 2004
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <415185EA.4080005@gsf.de>

Hi Martin!

referring to your last point:

>5) Finally, just to make this list complete, I would like to remind the 
>others that there had been a discussion about possibility to get RDF from 
>the registry even for services that had been already registered. I would 
>like to have this feature soon - because it may need an addition tag in 
>the service object, so the sooner we know about it the better.
>

This is a snippet of Marks former mail:

Of course, at the moment nobody has a signatureURL   I have set up a
simple CGI page for existing service providers where they can supply a
URL and get the signature RDF for all of their existing services:

http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl



Cheers,
Rebecca



-- 
Rebecca Ernst
MIPS, Inst. for Bioinformatics
GSF Research Center for Environment and Health
Ingolstaedter Landstr. 1
85764 Neuherberg
fon: +49 89 3187 3583
email: Rebecca.Ernst@gsf.de

From rebecca.ernst at gsf.de  Wed Sep 22 10:02:18 2004
From: rebecca.ernst at gsf.de (Rebecca Ernst)
Date: Wed Sep 22 10:02:00 2004
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <415185EA.4080005@gsf.de>

Hi Martin!

referring to your last point:

>5) Finally, just to make this list complete, I would like to remind the 
>others that there had been a discussion about possibility to get RDF from 
>the registry even for services that had been already registered. I would 
>like to have this feature soon - because it may need an addition tag in 
>the service object, so the sooner we know about it the better.
>

This is a snippet of Marks former mail:

Of course, at the moment nobody has a signatureURL   I have set up a
simple CGI page for existing service providers where they can supply a
URL and get the signature RDF for all of their existing services:

http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl



Cheers,
Rebecca



-- 
Rebecca Ernst
MIPS, Inst. for Bioinformatics
GSF Research Center for Environment and Health
Ingolstaedter Landstr. 1
85764 Neuherberg
fon: +49 89 3187 3583
email: Rebecca.Ernst@gsf.de

From senger at ebi.ac.uk  Wed Sep 22 10:09:43 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed Sep 22 10:10:31 2004
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <415185EA.4080005@gsf.de>
Message-ID: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>

> This is a snippet of Marks former mail:
> 
> Of course, at the moment nobody has a signatureURL   I have set up a
> simple CGI page for existing service providers where they can supply a
> URL and get the signature RDF for all of their existing services:
> 
> http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl
>
   Yes, I know about it. But Mark said that this cgi-bin will be there 
only temporarily. I had in mind something more permanent (for example if 
you loose your RDF you should be able to get it back somehow from the 
registry, without registering it again...). We have discussed this with 
Mark already and he seems to agree with providing such functionality - I 
had put it in the list of observations just not to let it slip from my
(and his :-)) mind...
 
   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From senger at ebi.ac.uk  Wed Sep 22 10:09:43 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed Sep 22 10:10:38 2004
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <415185EA.4080005@gsf.de>
Message-ID: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>

> This is a snippet of Marks former mail:
> 
> Of course, at the moment nobody has a signatureURL   I have set up a
> simple CGI page for existing service providers where they can supply a
> URL and get the signature RDF for all of their existing services:
> 
> http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl
>
   Yes, I know about it. But Mark said that this cgi-bin will be there 
only temporarily. I had in mind something more permanent (for example if 
you loose your RDF you should be able to get it back somehow from the 
registry, without registering it again...). We have discussed this with 
Mark already and he seems to agree with providing such functionality - I 
had put it in the list of observations just not to let it slip from my
(and his :-)) mind...
 
   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From opushneva at yahoo.ca  Wed Sep 22 13:01:26 2004
From: opushneva at yahoo.ca (Nina Opushneva)
Date: Wed Sep 22 13:01:08 2004
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <Pine.LNX.4.44.0409221211580.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <20040922170126.43575.qmail@web60901.mail.yahoo.com>

Hi Martin,
 
If you put the RDF of your service into a separate
file and include an empty signatureURL tag by
registration, the RDFagent will not process it.
Otherwise, if you put your RDF into the file which URL
is “known” for the registry database, it will be
processed.
(But in the first way you need to ask Mark if it's
possible include an empty signatureURL during of a
registration).

If you wish to save your service RDF into the RDF
file, but you don't wish to put the information about
this service into registry database, you can to make
RDF of this service “not valid for MOBY”.

 A valid MOBY RDF means that it has the complete set
of descriptions:
     serviceName  
     serviceType  
     authURI      
     contactEmail 
     description 
     category  
     URL   
     input/output (may be one of them)
 
If you delete or comment one of that descriptions,
RDFagent will not process RDF of this service.

Cheers,

Nina


--- Martin Senger <senger@ebi.ac.uk> wrote:

> > May I try to answer your question.
> > 
> Nina,
>    Thanks for the clarification.
>    Just one minor question: Assuming I do not wish
> to register a service
> for long, therefore I do not plan to send any
> signatureURL. Is it safe to
> include an empty signatureURL tag, or do I *have* to
> omit it at all?
> 
>    Regards,
>    Martin
> 
> -- 
> Martin Senger
> 
> EMBL Outstation - Hinxton               
> Senger@EBI.ac.uk     
> European Bioinformatics Institute        Phone:
> (+44) 1223 494636      
> Wellcome Trust Genome Campus            
> (Switchboard:     494444)
> Hinxton                                  Fax  :
> (+44) 1223 494468
> Cambridge CB10 1SD
> United Kingdom                          
> http://industry.ebi.ac.uk/~senger
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 
From markw at illuminae.com  Wed Sep 22 19:31:00 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Sep 22 19:30:53 2004
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <41520B34.9080307@illuminae.com>

Hello from beautiful Banff!  I'm here at the SAB meeting for the grant 
under which MOBY-S is funded... wish me luck!

It turns out that the conference centre has public wireless access in 
the pub, but not in the rooms... oh dear!  ;-)

Yes, Martin and I have discussed this, and agreed that it should be a 
part of the MOBY Central API.  Martin, keep reminding me, as I have a 
ton of other things consuming my time at the moment so constant pressure 
will be required to get it done in a timely way...

Cheers all!

Mark


Martin Senger wrote:

>>This is a snippet of Marks former mail:
>>
>>Of course, at the moment nobody has a signatureURL   I have set up a
>>simple CGI page for existing service providers where they can supply a
>>URL and get the signature RDF for all of their existing services:
>>
>>http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl
>>
>>    
>>
>   Yes, I know about it. But Mark said that this cgi-bin will be there 
>only temporarily. I had in mind something more permanent (for example if 
>you loose your RDF you should be able to get it back somehow from the 
>registry, without registering it again...). We have discussed this with 
>Mark already and he seems to agree with providing such functionality - I 
>had put it in the list of observations just not to let it slip from my
>(and his :-)) mind...
> 
>   Cheers,
>   Martin
>
>  
>
From markw at illuminae.com  Wed Sep 22 19:31:00 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Sep 22 19:31:05 2004
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <41520B34.9080307@illuminae.com>

Hello from beautiful Banff!  I'm here at the SAB meeting for the grant 
under which MOBY-S is funded... wish me luck!

It turns out that the conference centre has public wireless access in 
the pub, but not in the rooms... oh dear!  ;-)

Yes, Martin and I have discussed this, and agreed that it should be a 
part of the MOBY Central API.  Martin, keep reminding me, as I have a 
ton of other things consuming my time at the moment so constant pressure 
will be required to get it done in a timely way...

Cheers all!

Mark


Martin Senger wrote:

>>This is a snippet of Marks former mail:
>>
>>Of course, at the moment nobody has a signatureURL   I have set up a
>>simple CGI page for existing service providers where they can supply a
>>URL and get the signature RDF for all of their existing services:
>>
>>http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl
>>
>>    
>>
>   Yes, I know about it. But Mark said that this cgi-bin will be there 
>only temporarily. I had in mind something more permanent (for example if 
>you loose your RDF you should be able to get it back somehow from the 
>registry, without registering it again...). We have discussed this with 
>Mark already and he seems to agree with providing such functionality - I 
>had put it in the list of observations just not to let it slip from my
>(and his :-)) mind...
> 
>   Cheers,
>   Martin
>
>  
>
From markw at illuminae.com  Wed Sep 22 20:11:55 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Sep 22 20:12:18 2004
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <415214CB.3010805@illuminae.com>

Martin Senger wrote:

>1) Testing registry seems to have still older version - it still returns 
>RDF with CDATA. It would be good to have it restarted,
>  
>
Done

>2) The service description, as returned in the RDF, lost its CDATA 
>protection. Perhaps it is correct,
>

Um... well, I removed it at your request, so... :-)

> I do not know enough about RDF 
>documents. I have just observed that the 'strange characters', 
>such as '>', that I put into my service description, were returned 
>escaped: the character '>' was escaped as '&amp;gt;' - which does not seem 
>to be correct (but perhaps I am mistaken).
>  
>
AFAIK, anything that is not contained in a CDATA section will be 
escaped.  It is done at the library-level and I have no (?) control over it.

>Anyway, I wonder why to play with escaping at all, why not to keep there 
>CDATA.
>
Because you asked me to remove it, and your reasons were valid :-)  The 
RDF is a valid XML fragment, so there was really no good reason to put 
it in a CDATA section.

> We have CDATA in service description just because we did not want 
>to escape everything there - is that correct?
>  
>
Correct.

>3) I also wonder where are all our LSIDs? There is no single LSID in the 
>whole returned RDF. I thought that we expressed almost everything as LSIDs 
>in biomoby (at least internally).
>  
>
That's a very good point!  I agree with you 110%, and I can implement 
this fairly quickly at at the RDF-production end of things.  At the 
RDF-consumption end, I'll have to talk to Nina about it.  I'm fairly 
sure that we can work it out quickly.  The problem at the moment is that 
LSID resolution in MOBY is completely broken.  The latest version of the 
Perl LSID resolver stack (or at least, the latest the last time I 
looked) is built on top of alpha code libraries, and other libraries 
that are not yet in CPAN.  I was able to get it to compile (with a bit 
of fussing) on my Linux machine, but it throws errors up the ying-yang 
on mobycentral (Solaris).  As such, LSID resolution of MOBY LSID's will 
not be possible until someone has time to write an LSID resolver in 
Java, or the LSID code developers make changes to their stack  :-/   :-(


>4) I use this list to strongly express how I agree with the last Rebecca 
>email about being still able to deregister a service by calling a 
>deregister method even if the service has been registered with the 
>signatureURL.
>
>  
>
Well, I strongly disagree with you :-)   Gosh, THAT has never happened 
before!  ;-)

You have to remember what the driving force was to create the RDF-based 
deregistration!! The problem is that any kid with the ability to read an 
API could have come in and desroyed our registry by deregistering all of 
the services in it with a 5-line Perl script!  Authentication was just a 
pain in the arse and totally impractical, so the only remaining solution 
was to remove that functionality of MOBY Central and move the problem to 
the service providers machine.  I am loathe to move away from that model 
because in the last 18 months nobody has come up with a better solution!!

If a better solution exists, then we can certainly revisit the issue...

>5) Finally, just to make this list complete, I would like to remind the 
>others that there had been a discussion about possibility to get RDF from 
>the registry even for services that had been already registered. I would 
>like to have this feature soon - because it may need an addition tag in 
>the service object, so the sooner we know about it the better.
>
>  
>
Yes, I might actually try to get that done tonight in my room, and 
upload it to mobycentral tomorrow.  I'll let you know.

Cheers!

M

>  
>
From markw at illuminae.com  Wed Sep 22 20:11:55 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Sep 22 20:12:23 2004
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <415214CB.3010805@illuminae.com>

Martin Senger wrote:

>1) Testing registry seems to have still older version - it still returns 
>RDF with CDATA. It would be good to have it restarted,
>  
>
Done

>2) The service description, as returned in the RDF, lost its CDATA 
>protection. Perhaps it is correct,
>

Um... well, I removed it at your request, so... :-)

> I do not know enough about RDF 
>documents. I have just observed that the 'strange characters', 
>such as '>', that I put into my service description, were returned 
>escaped: the character '>' was escaped as '&amp;gt;' - which does not seem 
>to be correct (but perhaps I am mistaken).
>  
>
AFAIK, anything that is not contained in a CDATA section will be 
escaped.  It is done at the library-level and I have no (?) control over it.

>Anyway, I wonder why to play with escaping at all, why not to keep there 
>CDATA.
>
Because you asked me to remove it, and your reasons were valid :-)  The 
RDF is a valid XML fragment, so there was really no good reason to put 
it in a CDATA section.

> We have CDATA in service description just because we did not want 
>to escape everything there - is that correct?
>  
>
Correct.

>3) I also wonder where are all our LSIDs? There is no single LSID in the 
>whole returned RDF. I thought that we expressed almost everything as LSIDs 
>in biomoby (at least internally).
>  
>
That's a very good point!  I agree with you 110%, and I can implement 
this fairly quickly at at the RDF-production end of things.  At the 
RDF-consumption end, I'll have to talk to Nina about it.  I'm fairly 
sure that we can work it out quickly.  The problem at the moment is that 
LSID resolution in MOBY is completely broken.  The latest version of the 
Perl LSID resolver stack (or at least, the latest the last time I 
looked) is built on top of alpha code libraries, and other libraries 
that are not yet in CPAN.  I was able to get it to compile (with a bit 
of fussing) on my Linux machine, but it throws errors up the ying-yang 
on mobycentral (Solaris).  As such, LSID resolution of MOBY LSID's will 
not be possible until someone has time to write an LSID resolver in 
Java, or the LSID code developers make changes to their stack  :-/   :-(


>4) I use this list to strongly express how I agree with the last Rebecca 
>email about being still able to deregister a service by calling a 
>deregister method even if the service has been registered with the 
>signatureURL.
>
>  
>
Well, I strongly disagree with you :-)   Gosh, THAT has never happened 
before!  ;-)

You have to remember what the driving force was to create the RDF-based 
deregistration!! The problem is that any kid with the ability to read an 
API could have come in and desroyed our registry by deregistering all of 
the services in it with a 5-line Perl script!  Authentication was just a 
pain in the arse and totally impractical, so the only remaining solution 
was to remove that functionality of MOBY Central and move the problem to 
the service providers machine.  I am loathe to move away from that model 
because in the last 18 months nobody has come up with a better solution!!

If a better solution exists, then we can certainly revisit the issue...

>5) Finally, just to make this list complete, I would like to remind the 
>others that there had been a discussion about possibility to get RDF from 
>the registry even for services that had been already registered. I would 
>like to have this feature soon - because it may need an addition tag in 
>the service object, so the sooner we know about it the better.
>
>  
>
Yes, I might actually try to get that done tonight in my room, and 
upload it to mobycentral tomorrow.  I'll let you know.

Cheers!

M

>  
>
From markw at illuminae.com  Wed Sep 22 20:15:12 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Sep 22 20:15:05 2004
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <Pine.LNX.4.44.0409221211580.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221211580.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <41521590.6000505@illuminae.com>


>Is it safe to
>include an empty signatureURL tag, or do I *have* to omit it at all?
>  
>
Yup :-)  That is EXACTLY how it was designed to behave :-)  Just leave 
it out and your service will auto-deregister the next time the agent 
runs.  Alternately, you can manually deregister a service without a 
SignatureURL by using the deregisterService call of the API.

(can you tell I am answering my emails in reverse order? )

M

>  
>
From senger at ebi.ac.uk  Wed Sep 22 20:29:40 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed Sep 22 20:29:24 2004
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <415214CB.3010805@illuminae.com>
Message-ID: <Pine.OSF.4.21.0409230122070.824651-100000@ice.ebi.ac.uk>

> >2) The service description, as returned in the RDF, lost its CDATA 
> >protection. Perhaps it is correct,
> >
> 
> Um... well, I removed it at your request, so... :-)
>
   No. I was requesting to have the *whole contents* of the RDF tag
surrounded as CDATA. And I am happy that you removed it. What I am talking
about here is to keep CDATA around service description (which is somewhere
inside the whole RDF tag). So we can keep the service description exactly
the same as it was registered without mangling with escaping.
   Sorry if I have not expressed myself clearly.

> Well, I strongly disagree with you :-)   Gosh, THAT has never happened 
> before!  ;-)
>
   Well, my last email crossed your answer here. I came to the same
conclusion: security. So I do not have now such strong desire to keep the
old deregistration in place. However, the new system is for service
instances only - we still can have kids around removing our data types,
namespaces, service types and providers. So we need anyway to think about
these, too - which may give us some way how to deregister services with
signatureIRL.

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From senger at ebi.ac.uk  Wed Sep 22 20:29:40 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed Sep 22 20:29:25 2004
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <415214CB.3010805@illuminae.com>
Message-ID: <Pine.OSF.4.21.0409230122070.824651-100000@ice.ebi.ac.uk>

> >2) The service description, as returned in the RDF, lost its CDATA 
> >protection. Perhaps it is correct,
> >
> 
> Um... well, I removed it at your request, so... :-)
>
   No. I was requesting to have the *whole contents* of the RDF tag
surrounded as CDATA. And I am happy that you removed it. What I am talking
about here is to keep CDATA around service description (which is somewhere
inside the whole RDF tag). So we can keep the service description exactly
the same as it was registered without mangling with escaping.
   Sorry if I have not expressed myself clearly.

> Well, I strongly disagree with you :-)   Gosh, THAT has never happened 
> before!  ;-)
>
   Well, my last email crossed your answer here. I came to the same
conclusion: security. So I do not have now such strong desire to keep the
old deregistration in place. However, the new system is for service
instances only - we still can have kids around removing our data types,
namespaces, service types and providers. So we need anyway to think about
these, too - which may give us some way how to deregister services with
signatureIRL.

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From senger at ebi.ac.uk  Wed Sep 22 20:31:51 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed Sep 22 20:31:32 2004
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <41521590.6000505@illuminae.com>
Message-ID: <Pine.OSF.4.21.0409230130160.824651-100000@ice.ebi.ac.uk>

> >Is it safe to
> >include an empty signatureURL tag, or do I *have* to omit it at all?
> >  
> >
> Yup :-)  That is EXACTLY how it was designed to behave :-)  Just leave 
> it out and your service will auto-deregister the next time the agent 
> runs.  Alternately, you can manually deregister a service without a 
> SignatureURL by using the deregisterService call of the API.
> 
   My question was actually different (and Nina already replied to it):

Can I use safely <signatureURL></signatureURL>? Answer is yes, I can.

Thanks, Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From gordonp at cbr.nrc.ca  Wed Sep 22 21:39:35 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Wed Sep 22 21:39:16 2004
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.OSF.4.21.0409230122070.824651-100000@ice.ebi.ac.uk>
Message-ID: <Pine.SO4.4.05.10409222228570.17489-100000@cbrmain>


>    No. I was requesting to have the *whole contents* of the RDF tag
> surrounded as CDATA. And I am happy that you removed it. What I am talking
> about here is to keep CDATA around service description (which is somewhere
> inside the whole RDF tag). So we can keep the service description exactly
> the same as it was registered without mangling with escaping.

[Caution: possible flamebait]

If your client application is making a meaningful distinction between
"<!CDATA[[P & G]]>" and "P &amp; G", you're probably either:

1. Not using a conforming XML parser, which is bad.

or 

2. Relying on distinctions between W3C DOM CDATA Section Nodes and
TextNodes, which is officially frowned upon in the W3C DOM specs. 

In either case this would seriously affect the robustness of the code...

My CDN$0.02. :-)

From gordonp at cbr.nrc.ca  Wed Sep 22 21:39:35 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Wed Sep 22 21:39:17 2004
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.OSF.4.21.0409230122070.824651-100000@ice.ebi.ac.uk>
Message-ID: <Pine.SO4.4.05.10409222228570.17489-100000@cbrmain>


>    No. I was requesting to have the *whole contents* of the RDF tag
> surrounded as CDATA. And I am happy that you removed it. What I am talking
> about here is to keep CDATA around service description (which is somewhere
> inside the whole RDF tag). So we can keep the service description exactly
> the same as it was registered without mangling with escaping.

[Caution: possible flamebait]

If your client application is making a meaningful distinction between
"<!CDATA[[P & G]]>" and "P &amp; G", you're probably either:

1. Not using a conforming XML parser, which is bad.

or 

2. Relying on distinctions between W3C DOM CDATA Section Nodes and
TextNodes, which is officially frowned upon in the W3C DOM specs. 

In either case this would seriously affect the robustness of the code...

My CDN$0.02. :-)

From senger at ebi.ac.uk  Thu Sep 23 03:37:05 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep 23 03:36:57 2004
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.SO4.4.05.10409222228570.17489-100000@cbrmain>
Message-ID: <Pine.LNX.4.44.0409230832440.3215-100000@bagheera.ebi.ac.uk>

> If your client application is making a meaningful distinction between
> "<!CDATA[[P & G]]>" and "P &amp; G"
>
   The situation I was refering to is this: I send to registry (in service
description) "<!CDATA[[P > G]]>" but I get back (in RDF) "P &amp;gt; G" 
which I think is wrong (because somewhere during the processing it was 
obviously escaped twice - first to "P &gt; G" - which is correct - and 
from here to "P &amp;gt; G" - which seems to be incorrect).

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From senger at ebi.ac.uk  Thu Sep 23 03:37:05 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep 23 03:36:59 2004
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.SO4.4.05.10409222228570.17489-100000@cbrmain>
Message-ID: <Pine.LNX.4.44.0409230832440.3215-100000@bagheera.ebi.ac.uk>

> If your client application is making a meaningful distinction between
> "<!CDATA[[P & G]]>" and "P &amp; G"
>
   The situation I was refering to is this: I send to registry (in service
description) "<!CDATA[[P > G]]>" but I get back (in RDF) "P &amp;gt; G" 
which I think is wrong (because somewhere during the processing it was 
obviously escaped twice - first to "P &gt; G" - which is correct - and 
from here to "P &amp;gt; G" - which seems to be incorrect).

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From senger at ebi.ac.uk  Thu Sep 23 05:06:49 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep 23 05:11:29 2004
Subject: [MOBY-dev] getting RDF from BioMoby
In-Reply-To: <Pine.OSF.4.21.0409230046070.824651-100000@ice.ebi.ac.uk>
Message-ID: <Pine.OSF.4.21.0409230945120.933195-100000@ice.ebi.ac.uk>

Mark,
   Finally, I started to update my graphical tool for displaying moby
objects. I am going to use now the RDF tree that I can get from the
biomoby registry. Because I plan to add this new features (getting RDF
resources) to the main jMoby library - so anyone can get it, I have few
qustions before I dive into it:

   1) I found these URLs:
http://biomoby.org/RESOURCES/MOBY-S/Objects
http://biomoby.org/RESOURCES/MOBY-S/Services
http://biomoby.org/RESOURCES/MOBY-S/Namespaces
http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances

   But I need URLs that can distinguish between various moby registries. I
noticed that the URLs above were actually redirected to URLs:

http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Objects
http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Services
http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Namespaces
http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/ServiceInstances

   These URLs look better for my purpose - because they seem to include an
address of one particular registry. But I am not sure if these
redirections are done in the same way for everybody who has his/her own
registry installed. So the real question is:

   What part of these URLs is the same for everybody (because it is
hard-coded somewhere in your code), and what part should I allow to
customize? E.g. would it be correct to say that access to any registry can
be expressed as:
   http://<your-registry>/RESOURCES/MOBY-S/Objects
   ...
where <your-registry> by default is http://biomoby.org/ (or
http://mobycentral.cbr.nrc.ca/cgi-bin)?

   2) I remember that you also mentioned a URL that gives back everything
in one go (something with 'all' somewhere). Does it exist?

   3) The Perl code mentions also 'Predicates' but when I try it cannot
find it. Is this anything interesting for me? (Btw, if I use a wrong URL,
the one without thye last part, such as
http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/, it makes your
server unhappy :-) .)

   4) And finally, how stable is this, 'undocumented', part of registry's
API? Can I rely on it and include it in the Java libraries? If it is
stable, it would be nice to have it published on the biomoby pages.

   Thanks (and again I wish you nice stay in the Rockies),
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger


From markw at illuminae.com  Thu Sep 23 06:41:34 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Thu Sep 23 06:41:18 2004
Subject: [MOBY-dev] getting RDF from BioMoby
In-Reply-To: <Pine.OSF.4.21.0409230945120.933195-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0409230945120.933195-100000@ice.ebi.ac.uk>
Message-ID: <4152A85E.7030701@illuminae.com>

Hi Martin,

This part of the system (I wouldn't call it part of the API yet :-) ) is 
not at all stable, but once people start using it I will be forced to 
make some hard decisions and make it stable, so... let's keep working 
through these issues :-)

The code is pretty tightly connected to the main public registry, though 
it could be made more generic if necessary.  At the moment it gets its 
Objects, Namespaces, and Services definitions from a very simple and 
fast CGI that outputs tab-delimited text from direct database calls.   
This would have to be changed to be useful to other registries.  
ServiceInstances come from a call to MOBY::Client::Central, so that is 
less of a problem (you can set the URL of your desired registry in the 
constructor for that object).  I could re-write it to use 
MOBY::Client::Central for all of these calls, but it significantly slows 
it down...  As I say, if it is important to make this script more 
generic I can do so quite easily.

The URL you are looking for is:  http://biomoby.org/RESOURCES/MOBY-S/FULL

I haven't written the subroutine that generates the RDF for predicates yet.

Interesting that the server is unhappy if you don't add extra path 
info... it should "die" in that case and send back an error...???

Thanks for your warm thoughts - it's a bit chilly here in the mountains 
:-)  Gorgeous, but chilly...

M


Martin Senger wrote:

>Mark,
>   Finally, I started to update my graphical tool for displaying moby
>objects. I am going to use now the RDF tree that I can get from the
>biomoby registry. Because I plan to add this new features (getting RDF
>resources) to the main jMoby library - so anyone can get it, I have few
>qustions before I dive into it:
>
>   1) I found these URLs:
>http://biomoby.org/RESOURCES/MOBY-S/Objects
>http://biomoby.org/RESOURCES/MOBY-S/Services
>http://biomoby.org/RESOURCES/MOBY-S/Namespaces
>http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances
>
>   But I need URLs that can distinguish between various moby registries. I
>noticed that the URLs above were actually redirected to URLs:
>
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Objects
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Services
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Namespaces
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/ServiceInstances
>
>   These URLs look better for my purpose - because they seem to include an
>address of one particular registry. But I am not sure if these
>redirections are done in the same way for everybody who has his/her own
>registry installed. So the real question is:
>
>   What part of these URLs is the same for everybody (because it is
>hard-coded somewhere in your code), and what part should I allow to
>customize? E.g. would it be correct to say that access to any registry can
>be expressed as:
>   http://<your-registry>/RESOURCES/MOBY-S/Objects
>   ...
>where <your-registry> by default is http://biomoby.org/ (or
>http://mobycentral.cbr.nrc.ca/cgi-bin)?
>
>   2) I remember that you also mentioned a URL that gives back everything
>in one go (something with 'all' somewhere). Does it exist?
>
>   3) The Perl code mentions also 'Predicates' but when I try it cannot
>find it. Is this anything interesting for me? (Btw, if I use a wrong URL,
>the one without thye last part, such as
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/, it makes your
>server unhappy :-) .)
>
>   4) And finally, how stable is this, 'undocumented', part of registry's
>API? Can I rely on it and include it in the Java libraries? If it is
>stable, it would be nice to have it published on the biomoby pages.
>
>   Thanks (and again I wish you nice stay in the Rockies),
>   Martin
>
>  
>
From markw at illuminae.com  Thu Sep 23 06:41:34 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Thu Sep 23 06:41:20 2004
Subject: [MOBY-dev] getting RDF from BioMoby
In-Reply-To: <Pine.OSF.4.21.0409230945120.933195-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0409230945120.933195-100000@ice.ebi.ac.uk>
Message-ID: <4152A85E.7030701@illuminae.com>

Hi Martin,

This part of the system (I wouldn't call it part of the API yet :-) ) is 
not at all stable, but once people start using it I will be forced to 
make some hard decisions and make it stable, so... let's keep working 
through these issues :-)

The code is pretty tightly connected to the main public registry, though 
it could be made more generic if necessary.  At the moment it gets its 
Objects, Namespaces, and Services definitions from a very simple and 
fast CGI that outputs tab-delimited text from direct database calls.   
This would have to be changed to be useful to other registries.  
ServiceInstances come from a call to MOBY::Client::Central, so that is 
less of a problem (you can set the URL of your desired registry in the 
constructor for that object).  I could re-write it to use 
MOBY::Client::Central for all of these calls, but it significantly slows 
it down...  As I say, if it is important to make this script more 
generic I can do so quite easily.

The URL you are looking for is:  http://biomoby.org/RESOURCES/MOBY-S/FULL

I haven't written the subroutine that generates the RDF for predicates yet.

Interesting that the server is unhappy if you don't add extra path 
info... it should "die" in that case and send back an error...???

Thanks for your warm thoughts - it's a bit chilly here in the mountains 
:-)  Gorgeous, but chilly...

M


Martin Senger wrote:

>Mark,
>   Finally, I started to update my graphical tool for displaying moby
>objects. I am going to use now the RDF tree that I can get from the
>biomoby registry. Because I plan to add this new features (getting RDF
>resources) to the main jMoby library - so anyone can get it, I have few
>qustions before I dive into it:
>
>   1) I found these URLs:
>http://biomoby.org/RESOURCES/MOBY-S/Objects
>http://biomoby.org/RESOURCES/MOBY-S/Services
>http://biomoby.org/RESOURCES/MOBY-S/Namespaces
>http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances
>
>   But I need URLs that can distinguish between various moby registries. I
>noticed that the URLs above were actually redirected to URLs:
>
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Objects
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Services
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Namespaces
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/ServiceInstances
>
>   These URLs look better for my purpose - because they seem to include an
>address of one particular registry. But I am not sure if these
>redirections are done in the same way for everybody who has his/her own
>registry installed. So the real question is:
>
>   What part of these URLs is the same for everybody (because it is
>hard-coded somewhere in your code), and what part should I allow to
>customize? E.g. would it be correct to say that access to any registry can
>be expressed as:
>   http://<your-registry>/RESOURCES/MOBY-S/Objects
>   ...
>where <your-registry> by default is http://biomoby.org/ (or
>http://mobycentral.cbr.nrc.ca/cgi-bin)?
>
>   2) I remember that you also mentioned a URL that gives back everything
>in one go (something with 'all' somewhere). Does it exist?
>
>   3) The Perl code mentions also 'Predicates' but when I try it cannot
>find it. Is this anything interesting for me? (Btw, if I use a wrong URL,
>the one without thye last part, such as
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/, it makes your
>server unhappy :-) .)
>
>   4) And finally, how stable is this, 'undocumented', part of registry's
>API? Can I rely on it and include it in the Java libraries? If it is
>stable, it would be nice to have it published on the biomoby pages.
>
>   Thanks (and again I wish you nice stay in the Rockies),
>   Martin
>
>  
>
From senger at ebi.ac.uk  Thu Sep 23 07:13:47 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep 23 07:14:46 2004
Subject: [MOBY-dev] getting RDF from BioMoby
In-Reply-To: <4152A85E.7030701@illuminae.com>
Message-ID: <Pine.LNX.4.44.0409231148070.3265-100000@bagheera.ebi.ac.uk>

Mark,
   Thanks for a fast reply.

> This part of the system (I wouldn't call it part of the API yet :-) ) is 
> not at all stable, but once people start using it I will be forced to 
> make some hard decisions and make it stable, so... let's keep working 
> through these issues :-)
>
   Well, I can start using it if I know that it will not disappear anytime 
:-) Catch-22. Anyway, I am willing to play with it (a ka 'use it') and 
later we will see...

> The code is pretty tightly connected to the main public registry, though 
> it could be made more generic if necessary.
>
   It's okay for now. Thanks for the clarification.

   But I have (two) more questions (with sub-questions): The main reason
for using these calls is that I can get "everything" in one go. So this is
useful for people creating things like 'moby browsers' because they
usually need the whole contents of the registry. Because of that I am
willing to dive into RDF if:

   a) it is the best way how to get "everything" (is it? are there better 
ways? DUMP probably is not the best way)

   b) is there really everything?
   I am new to RDF so I am probably wrong. But, for example, when I have
looked into returned RDF of Objects and found CommentedDNASequence object,
I found all its parents (not in one place, but I found them, even though I
do know why all parents are listed directly under CommentedDNASequence,
except Object that is listed separately under VirtualSequence) referred as
'subClassOf' but I could not find (it may be my mistake by reading the
RDF) that it HASA two strings (sequencestring and description) and an
integer (length). Are these HAS[A] relationship there?

   And the second question: Even though it seem quite obvious from reading 
RDF, it would be nice if you provide (even still unofficial) list how are 
the various attributes mapped into RDF predicates. For example, that 
'<contactMail>' becomes 'cd:creator', or that '<Input>' becomes 
'mobyPred:consumes'.

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From senger at ebi.ac.uk  Thu Sep 23 07:13:47 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep 23 07:14:48 2004
Subject: [MOBY-dev] getting RDF from BioMoby
In-Reply-To: <4152A85E.7030701@illuminae.com>
Message-ID: <Pine.LNX.4.44.0409231148070.3265-100000@bagheera.ebi.ac.uk>

Mark,
   Thanks for a fast reply.

> This part of the system (I wouldn't call it part of the API yet :-) ) is 
> not at all stable, but once people start using it I will be forced to 
> make some hard decisions and make it stable, so... let's keep working 
> through these issues :-)
>
   Well, I can start using it if I know that it will not disappear anytime 
:-) Catch-22. Anyway, I am willing to play with it (a ka 'use it') and 
later we will see...

> The code is pretty tightly connected to the main public registry, though 
> it could be made more generic if necessary.
>
   It's okay for now. Thanks for the clarification.

   But I have (two) more questions (with sub-questions): The main reason
for using these calls is that I can get "everything" in one go. So this is
useful for people creating things like 'moby browsers' because they
usually need the whole contents of the registry. Because of that I am
willing to dive into RDF if:

   a) it is the best way how to get "everything" (is it? are there better 
ways? DUMP probably is not the best way)

   b) is there really everything?
   I am new to RDF so I am probably wrong. But, for example, when I have
looked into returned RDF of Objects and found CommentedDNASequence object,
I found all its parents (not in one place, but I found them, even though I
do know why all parents are listed directly under CommentedDNASequence,
except Object that is listed separately under VirtualSequence) referred as
'subClassOf' but I could not find (it may be my mistake by reading the
RDF) that it HASA two strings (sequencestring and description) and an
integer (length). Are these HAS[A] relationship there?

   And the second question: Even though it seem quite obvious from reading 
RDF, it would be nice if you provide (even still unofficial) list how are 
the various attributes mapped into RDF predicates. For example, that 
'<contactMail>' becomes 'cd:creator', or that '<Input>' becomes 
'mobyPred:consumes'.

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From fgibbons at hms.harvard.edu  Thu Sep 23 09:41:35 2004
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Thu Sep 23 09:37:41 2004
Subject: [MOBY-dev] Service deregistation *must* be fast: perhaps function
 call could precipitate prompt web agent visit?
In-Reply-To: <200409230013.i8N0DbKr031813@portal.open-bio.org>
Message-ID: <5.2.1.1.2.20040923093202.019ebea8@email.med.harvard.edu>

Martin, Mark,

At 08:13 PM 9/22/2004, you wrote:
> >4) I use this list to strongly express how I agree with the last Rebecca
> >email about being still able to deregister a service by calling a
> >deregister method even if the service has been registered with the
> >signatureURL.
> >
> >
> >
>Well, I strongly disagree with you :-)   Gosh, THAT has never happened
>before!  ;-)
>
>You have to remember what the driving force was to create the RDF-based
>deregistration!! The problem is that any kid with the ability to read an
>API could have come in and desroyed our registry by deregistering all of
>the services in it with a 5-line Perl script!  Authentication was just a
>pain in the arse and totally impractical, so the only remaining solution
>was to remove that functionality of MOBY Central and move the problem to
>the service providers machine.  I am loathe to move away from that model
>because in the last 18 months nobody has come up with a better solution!!
>
>If a better solution exists, then we can certainly revisit the issue...

It seems to me that mostly people want rapid deregistration when they're 
actively developing a service. Once it's all set up, the need disappears. I 
have an idea, I don't know if it would be too much work, or too 
impractical, but here it is anyway....

What if different registries had the ability to set different 
deregistration policies. The 'real' Moby Central could allow dereg only by 
removing the RDF file, but the 'test' registry could allow this too, while 
also allowing dereg requests by API calls. I have absolutely NO idea how 
this might be implemented. But for me, I do my development work in the test 
registry, and only when I'm happy with things do I go ahead and put it up 
in the main registry.

Just a thought. I really must side with Rebecca - how can I debug a service 
if I have to wait days before the screwups I made in registering it are 
fixed by moby central's agent crawling over to my web page? Another idea 
might be that a function call causes the agent to come and look for the RDF 
within a short period of time (two minutes, say), and if it's gone the 
service is deregistered. I'm not advocating that the function call be 
blocking, of course, that would be impractical. It would always return 
quickly, and if there were anything returned, it could only indicate that 
the service had previously been registered, that the request had been 
received, and perhaps some estimate of how long before the agent could come 
by and check. There would be no indication of successful deregistration. 
That would require a separate call (to some other routine - findService?) 
after sufficient time had passed.

-Frank

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 

From markw at illuminae.com  Thu Sep 23 10:04:05 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Thu Sep 23 10:03:57 2004
Subject: [MOBY-dev] Service deregistation *must* be fast: perhaps function
	call could precipitate prompt web agent visit?
In-Reply-To: <5.2.1.1.2.20040923093202.019ebea8@email.med.harvard.edu>
References: <5.2.1.1.2.20040923093202.019ebea8@email.med.harvard.edu>
Message-ID: <4152D7D5.2000501@illuminae.com>

I have said a few times that if you register a service with no 
SignatureURL it will remain in the registry until the agent removes it.  
This is how you should put temporary test services into the registry.  
Also, if you need to modify it more quickly, no problem - Services 
without a SignatureURL can be deregistered with the API call.

This should cover the scenario you are describing.

M


Frank Gibbons wrote:

> Martin, Mark,
>
> At 08:13 PM 9/22/2004, you wrote:
>
>> >4) I use this list to strongly express how I agree with the last 
>> Rebecca
>> >email about being still able to deregister a service by calling a
>> >deregister method even if the service has been registered with the
>> >signatureURL.
>> >
>> >
>> >
>> Well, I strongly disagree with you :-)   Gosh, THAT has never happened
>> before!  ;-)
>>
>> You have to remember what the driving force was to create the RDF-based
>> deregistration!! The problem is that any kid with the ability to read an
>> API could have come in and desroyed our registry by deregistering all of
>> the services in it with a 5-line Perl script!  Authentication was just a
>> pain in the arse and totally impractical, so the only remaining solution
>> was to remove that functionality of MOBY Central and move the problem to
>> the service providers machine.  I am loathe to move away from that model
>> because in the last 18 months nobody has come up with a better 
>> solution!!
>>
>> If a better solution exists, then we can certainly revisit the issue...
>
>
> It seems to me that mostly people want rapid deregistration when 
> they're actively developing a service. Once it's all set up, the need 
> disappears. I have an idea, I don't know if it would be too much work, 
> or too impractical, but here it is anyway....
>
> What if different registries had the ability to set different 
> deregistration policies. The 'real' Moby Central could allow dereg 
> only by removing the RDF file, but the 'test' registry could allow 
> this too, while also allowing dereg requests by API calls. I have 
> absolutely NO idea how this might be implemented. But for me, I do my 
> development work in the test registry, and only when I'm happy with 
> things do I go ahead and put it up in the main registry.
>
> Just a thought. I really must side with Rebecca - how can I debug a 
> service if I have to wait days before the screwups I made in 
> registering it are fixed by moby central's agent crawling over to my 
> web page? Another idea might be that a function call causes the agent 
> to come and look for the RDF within a short period of time (two 
> minutes, say), and if it's gone the service is deregistered. I'm not 
> advocating that the function call be blocking, of course, that would 
> be impractical. It would always return quickly, and if there were 
> anything returned, it could only indicate that the service had 
> previously been registered, that the request had been received, and 
> perhaps some estimate of how long before the agent could come by and 
> check. There would be no indication of successful deregistration. That 
> would require a separate call (to some other routine - findService?) 
> after sufficient time had passed.
>
> -Frank
>
> PhD, Computational Biologist,
> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 
> 02115, USA.
> Tel: 617-432-3555       Fax: 617-432-3557       
> http://llama.med.harvard.edu/~fgibbons
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
From senger at ebi.ac.uk  Thu Sep 23 10:50:32 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep 23 10:50:15 2004
Subject: [MOBY-dev] about service deregistation once again
In-Reply-To: <4152D7D5.2000501@illuminae.com>
Message-ID: <Pine.OSF.4.21.0409231528350.1073682-100000@mozart.ebi.ac.uk>

I like summaries :-) Here is another (subjective) one:

1) There are three needs for deregistration:

   a) A service is registered intentinally temporarily. This is for time
of testing and debugging. Its deregistration is covered by an empty
signatureURL pretty well. The only missing point here is that I would like
to have evn in this phase a possibility to see the service's RDF. At the
moment it si provided by a temporary cgi-bin script. But there should be
more stable way - and Mark is planning to work on it (AFAIK).

   b) A service is registered fully and its service provider decides to
remove the service (actually not the service but a record about the
service in registry, but that we all understand). Here we have a scenario
with removing service's RDF on the service provider side, and waiting for
the agent. It sounds okay - mainly because it is quite probable that the
service itself is defunc now, so the delay with deregistration does not do
much harm.

   c) A service is registered but needs a change (let's call it a
Rebecca's scenario). Here service provider needs a rapid action - because
without a correct record in registry his/her service cannot be used -
because many general clients takes information about services only from
registry. I think here we need improvements in deregistration because it
is too late to wait for any agent. The initiative here should start from
the service provider.

   What can be done for the case ad c)?
   There are (IMO) two general solutions:

   i) Registry can give something to the registrant (a token) that can be
used for authorized deregistration. This was the intention of the ID in
the registration object. We may revive its usage for this option - but it
still have some security implication (e.g. at themoment the moby database
is open, faik, so the IDs can be found).

   ii) Or, registry takes some action going to the service provider side
to confirm the authenticity of the deregistration request (here we
had/have plan with contact-email, and here fits actually also the agent
scenario). The problem is that we still need a mechanism that can trigger
the registry to take the action. And this is missing.
   So (and here is my main suggestion) why not this: A service provider
will still use a deregisterService call, and the registry - when it sees
that the service has a signatureURL, sends agent *now* to this side. Of
course, the service provider must make sure that the RDF is either
updated, or missing (in which case he/she will register again).

   What do you think about this?

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From rebecca.ernst at gsf.de  Fri Sep 24 03:22:15 2004
From: rebecca.ernst at gsf.de (Rebecca Ernst)
Date: Fri Sep 24 03:21:54 2004
Subject: [MOBY-dev] about service deregistation once again
In-Reply-To: <Pine.OSF.4.21.0409231528350.1073682-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0409231528350.1073682-100000@mozart.ebi.ac.uk>
Message-ID: <4153CB27.6000208@gsf.de>

Hi Martin, (Mark, Frank, etc.)!

This was a useful summary! Obviously Mark had the one scenario in mind 
(a) and Frank and I had another one in mind (c).
I quite like the idea of asking the agent for a visit. This would 
completely solve my problem.
Mark, would this be possible? Easy to implement?

Cheers,
Rebecca



Martin Senger wrote:

>I like summaries :-) Here is another (subjective) one:
>
>1) There are three needs for deregistration:
>
>   a) A service is registered intentinally temporarily. This is for time
>of testing and debugging. Its deregistration is covered by an empty
>signatureURL pretty well. The only missing point here is that I would like
>to have evn in this phase a possibility to see the service's RDF. At the
>moment it si provided by a temporary cgi-bin script. But there should be
>more stable way - and Mark is planning to work on it (AFAIK).
>
>   b) A service is registered fully and its service provider decides to
>remove the service (actually not the service but a record about the
>service in registry, but that we all understand). Here we have a scenario
>with removing service's RDF on the service provider side, and waiting for
>the agent. It sounds okay - mainly because it is quite probable that the
>service itself is defunc now, so the delay with deregistration does not do
>much harm.
>
>   c) A service is registered but needs a change (let's call it a
>Rebecca's scenario). Here service provider needs a rapid action - because
>without a correct record in registry his/her service cannot be used -
>because many general clients takes information about services only from
>registry. I think here we need improvements in deregistration because it
>is too late to wait for any agent. The initiative here should start from
>the service provider.
>
>   What can be done for the case ad c)?
>   There are (IMO) two general solutions:
>
>   i) Registry can give something to the registrant (a token) that can be
>used for authorized deregistration. This was the intention of the ID in
>the registration object. We may revive its usage for this option - but it
>still have some security implication (e.g. at themoment the moby database
>is open, faik, so the IDs can be found).
>
>   ii) Or, registry takes some action going to the service provider side
>to confirm the authenticity of the deregistration request (here we
>had/have plan with contact-email, and here fits actually also the agent
>scenario). The problem is that we still need a mechanism that can trigger
>the registry to take the action. And this is missing.
>   So (and here is my main suggestion) why not this: A service provider
>will still use a deregisterService call, and the registry - when it sees
>that the service has a signatureURL, sends agent *now* to this side. Of
>course, the service provider must make sure that the RDF is either
>updated, or missing (in which case he/she will register again).
>
>   What do you think about this?
>
>   Martin
>
>  
>

-- 
Rebecca Ernst
MIPS, Inst. for Bioinformatics
GSF Research Center for Environment and Health
Ingolstaedter Landstr. 1
85764 Neuherberg
fon: +49 89 3187 3583
email: Rebecca.Ernst@gsf.de

From senger at ebi.ac.uk  Fri Sep 24 07:10:37 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep 24 07:10:21 2004
Subject: [MOBY-dev] Re: about service deregistation once again (a bug?)
In-Reply-To: <Pine.OSF.4.21.0409231528350.1073682-100000@mozart.ebi.ac.uk>
Message-ID: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>

One more observation - I suppose that there is a bug:

Nina explained that the agent would not go to a service that had been
registered without signatureURL, neither to a service that had been
registered with an empty signatureURL tag (such as
<signatureURL></signatureURL>).

However, the old-fashioned deregistration call will be rejected for
services that had been registered with an empty signatureURL, telling you
that the agent would take care about it. Which would not - see paragraph
above.

So, there are unregisterable services... (fortunately, there are many of 
them now, but only in the testing registry :-))

Cheers,
Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From markw at illuminae.com  Fri Sep 24 09:24:00 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri Sep 24 09:23:47 2004
Subject: [MOBY-dev] about service deregistation once again
In-Reply-To: <4153CB27.6000208@gsf.de>
References: <Pine.OSF.4.21.0409231528350.1073682-100000@mozart.ebi.ac.uk>
	<4153CB27.6000208@gsf.de>
Message-ID: <41541FF0.2090701@illuminae.com>

Nina and I are working on it right now :-)  Should be done by next week,

M

Rebecca Ernst wrote:

> Hi Martin, (Mark, Frank, etc.)!
>
> This was a useful summary! Obviously Mark had the one scenario in mind 
> (a) and Frank and I had another one in mind (c).
> I quite like the idea of asking the agent for a visit. This would 
> completely solve my problem.
> Mark, would this be possible? Easy to implement?
>
> Cheers,
> Rebecca
>
>
>
> Martin Senger wrote:
>
>> I like summaries :-) Here is another (subjective) one:
>>
>> 1) There are three needs for deregistration:
>>
>>   a) A service is registered intentinally temporarily. This is for time
>> of testing and debugging. Its deregistration is covered by an empty
>> signatureURL pretty well. The only missing point here is that I would 
>> like
>> to have evn in this phase a possibility to see the service's RDF. At the
>> moment it si provided by a temporary cgi-bin script. But there should be
>> more stable way - and Mark is planning to work on it (AFAIK).
>>
>>   b) A service is registered fully and its service provider decides to
>> remove the service (actually not the service but a record about the
>> service in registry, but that we all understand). Here we have a 
>> scenario
>> with removing service's RDF on the service provider side, and waiting 
>> for
>> the agent. It sounds okay - mainly because it is quite probable that the
>> service itself is defunc now, so the delay with deregistration does 
>> not do
>> much harm.
>>
>>   c) A service is registered but needs a change (let's call it a
>> Rebecca's scenario). Here service provider needs a rapid action - 
>> because
>> without a correct record in registry his/her service cannot be used -
>> because many general clients takes information about services only from
>> registry. I think here we need improvements in deregistration because it
>> is too late to wait for any agent. The initiative here should start from
>> the service provider.
>>
>>   What can be done for the case ad c)?
>>   There are (IMO) two general solutions:
>>
>>   i) Registry can give something to the registrant (a token) that can be
>> used for authorized deregistration. This was the intention of the ID in
>> the registration object. We may revive its usage for this option - 
>> but it
>> still have some security implication (e.g. at themoment the moby 
>> database
>> is open, faik, so the IDs can be found).
>>
>>   ii) Or, registry takes some action going to the service provider side
>> to confirm the authenticity of the deregistration request (here we
>> had/have plan with contact-email, and here fits actually also the agent
>> scenario). The problem is that we still need a mechanism that can 
>> trigger
>> the registry to take the action. And this is missing.
>>   So (and here is my main suggestion) why not this: A service provider
>> will still use a deregisterService call, and the registry - when it sees
>> that the service has a signatureURL, sends agent *now* to this side. Of
>> course, the service provider must make sure that the RDF is either
>> updated, or missing (in which case he/she will register again).
>>
>>   What do you think about this?
>>
>>   Martin
>>
>>  
>>
>
From markw at illuminae.com  Fri Sep 24 09:26:49 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri Sep 24 09:26:29 2004
Subject: [MOBY-dev] Re: about service deregistation once again (a bug?)
In-Reply-To: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>
Message-ID: <41542099.60700@illuminae.com>

Martin Senger wrote:

>Nina explained that the agent would not go to a service that had been
>registered without signatureURL, neither to a service that had been
>registered with an empty signatureURL tag (such as
><signatureURL></signatureURL>).
>  
>
Aren't these two statements identical?

>However, the old-fashioned deregistration call will be rejected for
>services that had been registered with an empty signatureURL, telling you
>that the agent would take care about it. Which would not - see paragraph
>above.
>  
>
Unless it is not functioning correctly, the old fashioned deregisration 
call WILL NOT be rejected for services that have been registered with an 
empty signature URL.  Is that the bug you are reporting?

M

From edward.kawas at gmail.com  Fri Sep 24 11:20:17 2004
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Fri Sep 24 11:20:09 2004
Subject: [MOBY-dev] Question about authorities
In-Reply-To: <41542099.60700@illuminae.com>
References: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>
	<41542099.60700@illuminae.com>
Message-ID: <b4bcf7b1040924082063363be6@mail.gmail.com>

I have a quick question on the authorities (URI) part of registering
objects, services, etc.

URI is a domain, e.g. www.illuminae.com
would the following work?

illuminae.com  or  mobycentral.cbr.nrc.ca ?

Thanks,

Eddie
From markw at illuminae.com  Fri Sep 24 11:22:47 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri Sep 24 11:22:30 2004
Subject: [MOBY-dev] Question about authorities
In-Reply-To: <b4bcf7b1040924082063363be6@mail.gmail.com>
References: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>	<41542099.60700@illuminae.com>
	<b4bcf7b1040924082063363be6@mail.gmail.com>
Message-ID: <41543BC7.1080202@illuminae.com>

yes


Eddie Kawas wrote:

>I have a quick question on the authorities (URI) part of registering
>objects, services, etc.
>
>URI is a domain, e.g. www.illuminae.com
>would the following work?
>
>illuminae.com  or  mobycentral.cbr.nrc.ca ?
>
>Thanks,
>
>Eddie
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev@biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>  
>
From markw at illuminae.com  Fri Sep 24 11:23:29 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri Sep 24 11:23:12 2004
Subject: [MOBY-dev] Question about authorities
In-Reply-To: <b4bcf7b1040924082063363be6@mail.gmail.com>
References: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>	<41542099.60700@illuminae.com>
	<b4bcf7b1040924082063363be6@mail.gmail.com>
Message-ID: <41543BF1.8030501@illuminae.com>

IMO it is *preferable* to have the domain without the "www" prefix, but 
that's just me.

M

Eddie Kawas wrote:

>I have a quick question on the authorities (URI) part of registering
>objects, services, etc.
>
>URI is a domain, e.g. www.illuminae.com
>would the following work?
>
>illuminae.com  or  mobycentral.cbr.nrc.ca ?
>
>Thanks,
>
>Eddie
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev@biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>  
>
From gss at ncgr.org  Fri Sep 24 11:44:35 2004
From: gss at ncgr.org (Gary Schiltz)
Date: Fri Sep 24 11:47:56 2004
Subject: [MOBY-dev] MOBY Meeting: 20-21 November in Santa Fe
Message-ID: <415440E3.2070000@ncgr.org>

Hello MOBY'ers!

The next MOBY meeting will be held at NCGR (www.ncgr.org) in Santa Fe, 
New Mexico, the weekend of 20-21 November, 2004. We'll finish by about 
3:00 MST on Sunday, so you could catch a flight as early as about 5:30. 
Also, Mark Wilkinson will be giving a talk on MOBY Services at NCGR on 
November 19 (some time in the afternoon, I believe); everyone is welcome 
to attend, so consider coming a day early. I'll soon put together a page 
of information with an agenda, links to accommodations covering a range 
of prices, and other details. There will be a small registration fee to 
cover breakfast and lunch for Saturday and Sunday.

In the interim, please post suggestions for topics to cover at the meeting.

----

Gary Schiltz
Principal Software Engineer
National Center for Genome Resources
Santa Fe, New Mexico

gss@ncgr.org
505-995-4414 (Work)
505-670-5983 (Cell)
From senger at ebi.ac.uk  Fri Sep 24 15:26:57 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep 24 15:26:37 2004
Subject: [MOBY-dev] Re: about service deregistation once again (a bug?)
In-Reply-To: <41542099.60700@illuminae.com>
Message-ID: <Pine.OSF.4.21.0409241507580.528084-100000@ice.ebi.ac.uk>

> >Nina explained that the agent would not go to a service that had been
> >registered without signatureURL, neither to a service that had been
> >registered with an empty signatureURL tag (such as
> ><signatureURL></signatureURL>).
> >  
> >
> Aren't these two statements identical?
>
   C'mon, of course, they are not.
   I can send a registration without any signatureURL tag, at all, or I
can send it with <signatureURL></signatureURL>.
   However, it does not matter anymore, see below...
 
> >However, the old-fashioned deregistration call will be rejected for
> >services that had been registered with an empty signatureURL, telling you
> >that the agent would take care about it. Which would not - see paragraph
> >above.
> >  
> >
> Unless it is not functioning correctly, the old fashioned deregisration 
> call WILL NOT be rejected for services that have been registered with an 
> empty signature URL.  Is that the bug you are reporting?
>
   Yes, it was... But not anymore... the bug was in my code that had not
properly printed signatureURL (so I thought that it was not there). Sorry
for that, it happens (at least one good output from this email exchange is
that I found that signatureURL was missing in the documentation of the
Service List Response Object - could you add it there?).

   Cheers,
   Martin

PS. I wonder if you got my email asking about RDF output...? (Perhaps it
was missed under the peaks of Rockies :-))
M.

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger


From markw at illuminae.com  Sat Sep 25 14:59:28 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Sat Sep 25 14:59:06 2004
Subject: [MOBY-dev] Re: about service deregistation once again (a bug?)
In-Reply-To: <Pine.OSF.4.21.0409241507580.528084-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0409241507580.528084-100000@ice.ebi.ac.uk>
Message-ID: <4155C010.8000100@illuminae.com>



>>Aren't these two statements identical?
>>    
>>
>   C'mon, of course, they are not.
>   I can send a registration without any signatureURL tag, at all, or I
>can send it with <signatureURL></signatureURL>.
>  
>
I think the two cases are treated identically by MOBY Central.


>   Yes, it was... But not anymore... the bug was in my code that had not
>properly printed signatureURL (so I thought that it was not there).
>

Cool!

>that I found that signatureURL was missing in the documentation of the
>Service List Response Object - could you add it there?).
>  
>
Yup.  I'll do that when I get back. (remind me if I forget...)

>PS. I wonder if you got my email asking about RDF output...? (Perhaps it
>was missed under the peaks of Rockies :-))
>  
>
I'll look back through my messages.  I am having trouble understanding 
messages this week due to the thin mountain air ;-)

M


>M.
>
>  
>
From markw at illuminae.com  Sat Sep 25 15:04:13 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Sat Sep 25 15:04:07 2004
Subject: [MOBY-dev] Re: about service deregistation once again (a bug?)
In-Reply-To: <Pine.OSF.4.21.0409241507580.528084-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0409241507580.528084-100000@ice.ebi.ac.uk>
Message-ID: <4155C12D.6020305@illuminae.com>

b.t.w. Martin, I gave a Taverna demo today at the SAB meeting.  There is 
general agreement among the bioinformatics platform members (Genome 
Canada) that we should adopt Taverna as our recommended MOBY/Emboss 
client :-)  Yay!

M


Martin Senger wrote:

>>>Nina explained that the agent would not go to a service that had been
>>>registered without signatureURL, neither to a service that had been
>>>registered with an empty signatureURL tag (such as
>>><signatureURL></signatureURL>).
>>> 
>>>
>>>      
>>>
>>Aren't these two statements identical?
>>
>>    
>>
>   C'mon, of course, they are not.
>   I can send a registration without any signatureURL tag, at all, or I
>can send it with <signatureURL></signatureURL>.
>   However, it does not matter anymore, see below...
> 
>  
>
>>>However, the old-fashioned deregistration call will be rejected for
>>>services that had been registered with an empty signatureURL, telling you
>>>that the agent would take care about it. Which would not - see paragraph
>>>above.
>>> 
>>>
>>>      
>>>
>>Unless it is not functioning correctly, the old fashioned deregisration 
>>call WILL NOT be rejected for services that have been registered with an 
>>empty signature URL.  Is that the bug you are reporting?
>>
>>    
>>
>   Yes, it was... But not anymore... the bug was in my code that had not
>properly printed signatureURL (so I thought that it was not there). Sorry
>for that, it happens (at least one good output from this email exchange is
>that I found that signatureURL was missing in the documentation of the
>Service List Response Object - could you add it there?).
>
>   Cheers,
>   Martin
>
>PS. I wonder if you got my email asking about RDF output...? (Perhaps it
>was missed under the peaks of Rockies :-))
>M.
>
>  
>
From jmfernandez at cnb.uam.es  Wed Sep  1 15:00:02 2004
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Wed, 01 Sep 2004 21:00:02 +0200
Subject: [MOBY-dev] Problems testing a newly created MOBY Central (+ Fix)
Message-ID: <41361C32.1020405@cnb.uam.es>

Hi everybody,
	soon I'm going to give a practical seminar about MOBY, and I'm creating 
a local MOBY Central for the practices. This is not my first time 
creating a MOBY Central (I created one 9 months ago), but last version 
in CVS seems to have problems.

	First of all, intructions in

http://www.biomoby.org/InstallingMOBYCentral.html

should be updated, because last RDF changes in MOBY require RDF::Core 
Perl library as a pre-requisite before running a MOBY Central (and 
perhaps a the other libraries??).

	The problem I have found is the next: I ran the 
testMOBYClientCentral_v05.pl script in order to check if the 
installation was correct. First try failed in the first test due the 
lack of RDF::Core. The second try (after installing RDF::Core) seemed to 
run well until it failed in the 18th one, which corresponds to 
registerService. Next lines are from the Apache error log:

[Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] Useless use of 
hash element in void context at 
/usr/lib/perl5/site_perl/5.8.3/RDF/Core/Serializer.pm line 52.
[Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] DBD::mysql::db 
selectrow_array failed: Unknown column 'signatureURL' in 'field list' at 
/usr/lib/perl5/site_perl/5.8.3/MOBY/Adaptor/moby/queryapi/mysql.pm line 
172, <IN> line 34

	I have dug inside the referenced file told by the error message, and it 
is a query to the tables service_instance and authority from mobycentral 
database. It seems the signatureURL column should exist in 
service_instance table, and so moby database skeletons in CVS should be 
updated.
	
	What data type should have that column, Mark? I have created it as a 
VARCHAR(255), and now it works.

	Last, moby database skeletons (ie mysql dumps) in CVS should also be 
updated in order to reflect the last small change Mark told us about the 
datatype of maximum_value and minimum_value.

	Best Regards,
		Jos? Mar?a

-- 
Jos? Mar?a Fern?ndez Gonz?lez		e-mail: jmfernandez at cnb.uam.es
Tlfn:	(+34) 91 585 46 69		Fax:	(+34) 91 585 45 06
Grupo de Dise?o de Proteinas		Protein Design Group
Centro Nacional de Biotecnolog?a	National Center of Biotechnology
C.P.: 28049				Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)


From mwilkinson at mrl.ubc.ca  Wed Sep  1 15:30:30 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 01 Sep 2004 12:30:30 -0700
Subject: [MOBY-dev] Re: [MISC] [MOBY-l] Problems testing a newly created
	MOBY Central (+ Fix)
In-Reply-To: <41361C32.1020405@cnb.uam.es>
References: <41361C32.1020405@cnb.uam.es>
Message-ID: <1094067029.17672.55.camel@myhost.mydomain>

Sorry, I am hoping to get all of the documentation updated as quickly as
possible, but grant deadlines are getting in the way...

The change to the database structure was (I think) announced on the
mailing list.  You can also get it by calling the 'DUMP' method of
MOBY::Central (or via the client), or you can examine the database
directly by logging in to a mysql session with the username
moby_external (no password)

here's the table definition for service_instance:

+---------------------+----------------------------------+------+-----+---------+----------------+
| Field               | Type                             | Null | Key |
Default | Extra          |
+---------------------+----------------------------------+------+-----+---------+----------------+
| category            | enum('moby','soap','wsdl','cgi') | YES  |     |
NULL    |                |
| servicename         | varchar(255)                     |      | MUL
|         |                |
| service_type_uri    | varchar(255)                     |      |    
|         |                |
| authority_id        | int(10) unsigned                 |      |     |
0       |                |
| url                 | varchar(255)                     |      |    
|         |                |
| contact_email       | varchar(255)                     |      |    
|         |                |
| authoritative       | enum('1','0')                    |      |     |
0       |                |
| description         | text                             |      |    
|         |                |
| service_instance_id | int(10) unsigned                 |      | PRI |
NULL    | auto_increment |
| signatureURL        | varchar(255)                     | YES  |     |
NULL    |                |
+---------------------+----------------------------------+------+-----+---------+----------------+


M


On Wed, 2004-09-01 at 12:00, Jos? Mar?a Fern?ndez Gonz?lez wrote:
> Hi everybody,
> 	soon I'm going to give a practical seminar about MOBY, and I'm creating 
> a local MOBY Central for the practices. This is not my first time 
> creating a MOBY Central (I created one 9 months ago), but last version 
> in CVS seems to have problems.
> 
> 	First of all, intructions in
> 
> http://www.biomoby.org/InstallingMOBYCentral.html
> 
> should be updated, because last RDF changes in MOBY require RDF::Core 
> Perl library as a pre-requisite before running a MOBY Central (and 
> perhaps a the other libraries??).
> 
> 	The problem I have found is the next: I ran the 
> testMOBYClientCentral_v05.pl script in order to check if the 
> installation was correct. First try failed in the first test due the 
> lack of RDF::Core. The second try (after installing RDF::Core) seemed to 
> run well until it failed in the 18th one, which corresponds to 
> registerService. Next lines are from the Apache error log:
> 
> [Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] Useless use of 
> hash element in void context at 
> /usr/lib/perl5/site_perl/5.8.3/RDF/Core/Serializer.pm line 52.
> [Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] DBD::mysql::db 
> selectrow_array failed: Unknown column 'signatureURL' in 'field list' at 
> /usr/lib/perl5/site_perl/5.8.3/MOBY/Adaptor/moby/queryapi/mysql.pm line 
> 172, <IN> line 34
> 
> 	I have dug inside the referenced file told by the error message, and it 
> is a query to the tables service_instance and authority from mobycentral 
> database. It seems the signatureURL column should exist in 
> service_instance table, and so moby database skeletons in CVS should be 
> updated.
> 	
> 	What data type should have that column, Mark? I have created it as a 
> VARCHAR(255), and now it works.
> 
> 	Last, moby database skeletons (ie mysql dumps) in CVS should also be 
> updated in order to reflect the last small change Mark told us about the 
> datatype of maximum_value and minimum_value.
> 
> 	Best Regards,
> 		Jos? Mar?a
-- 
Mark Wilkinson (mwilkinson at mrl.ubc.ca)
University of British Columbia iCAPTURE Centre



From mwilkinson at mrl.ubc.ca  Wed Sep 15 11:58:07 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 15 Sep 2004 08:58:07 -0700
Subject: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
Message-ID: <1095263887.5954.78.camel@myhost.mydomain>

Hi all, 

we are getting ready to make a very significant change in MOBY-S, so I
need **all existing service providers** to do a one-time exercise.  This
is also important for those who have their own MOBY Central
installations.

As we discussed at the last MOBY meeting, it is desirable and 'good' for
MOBY Central's registry to extract its information using a mechanism
more like a web crawler (more like S-MOBY :-) ).  As a result, Nina has
written an agent that will crawl known MOBY service providers and
extract their service signatures from RDF files.  The agent runs on a
cron, and behaves as follows:

1)  It looks up the last known address of your service signature in the
database
2)  It GET's that address expecting to find an RDF file
3)  If it doesn't find a valid RDF file there, then it flags an error;
after a certain number of errors your service(s) will be deregistered. 
(I believe that it also emails the contactEmail address and tells them
that there was an error.)
4)  If it finds an RDF, it compares the signatures of each service
described in that RDF with the database, and updates or adds these
service descriptions as necessary.
5)  If it expects to find a service signature in this RDF, and can't
find it, it concludes that the service has been taken off-line, and it
will de-register that service.
6)  The agent should be (touch wood!) tolerant of additional RDF in this
signature, such that you can add your own additional annotations to this
RDF as you wish.


The behaviour of MOBY Central is as follows:

1)  When you register a service, you may include a SignatureURL field in
your XML (or as a parameter to the MOBY::Client::Central API) indicating
where your RDF will be located.
2)  Upon successful registration of your service, MOBY Central will send
you the RDF signature of your service - you will not have to generate
this yourself!  (unless you want to... and feel free to do so!).  It
appears in the <RDF> block of the MOBY Registration object (the ->RDF
method of the MOBY:Registration object)
3)  To ensure that your service is not deleted, you must place this RDF
signature in the location that you specified in the signatureURL field
when you registered your service.
4)  If you do not include a signatureURL in your service registration,
your service will be de-registered the next time the agent runs (since
it will be unable to find an RDF file matching your service).  This
might be useful for people who are doing simple test services, as they
wont clutter up the registry for long...
4)  The deregisterService method of the MOBY Central API will **NOT**
function for any service that has a signatureURL.  It will function as
expected for any service does not have a signatureURL.


So, in short, services now have a signatureURL that points to an RDF
file describing their service.  An agent will crawl around on a regular
basis looking at these RDF signatures.  If you update a service, you
change the RDF.  if you remove a service, you delete that portion of the
RDF.  If you add a service, you either add a new signature to the RDF
and let the agent register it automatically, or you use the
registerService function of MOBY Central as you have in the past, and
allow MOBY Central to generate the RDF for you.  Services without a
signatureURL WILL BE DELETED!!!!

Of course, at the moment nobody has a signatureURL :-)  I have set up a
simple CGI page for existing service providers where they can supply a
URL and get the signature RDF for all of their existing services:

http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl


We will switch the agent on in a week or so, and after that all services
without a signatureURL will be deleted, so please go to this page ASAP. 

If the script doesn't work, or if you have any problems please let me
know and I or Nina will fix them immediately.

I hope this isn't too disruptive to people.  I'm convinced that it is a
change for the better!  Contact me by phone or email if you have any
concerns.

Cheers all!

M
-- 
Mark Wilkinson, 
Assistant Professor (Bioinformatics)
Dept. of Medical Genetics, 
University of British Columbia
James Hogg iCAPTURE Centre for Cardiovascular and Pulmonary Research
166 - 1081 Burrard St.
Vancouver, BC, Canada, V6Z 1Y6

tel: (604) 682 2344 ext. 62129
fax: (604) 806 9274
 
------------------------------------------------------------------------
The death rate in Canada currently stands at one per person.  Here
at iCAPTURE, we are working hard to improve on that figure!
------------------------------------------------------------------------


From senger at ebi.ac.uk  Wed Sep 15 16:20:57 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 15 Sep 2004 21:20:57 +0100 (BST)
Subject: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain>
Message-ID: <Pine.OSF.4.21.0409152119021.1471296-100000@mozart.ebi.ac.uk>

Mark,
   I wonder why the RDF part in the registration object is marked as
CDATA. Because RDF must be anyway a valid XML why to bother to surround it
by CDATA. Having CDATA there would prevent me to have CDATA in RDF. Is
there any reason you use CDATA for the RDF part?

   Thanks,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Thu Sep 16 10:04:35 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 16 Sep 2004 15:04:35 +0100 (BST)
Subject: [MOBY-dev] Java developers, let's talk together
In-Reply-To: <1094067029.17672.55.camel@myhost.mydomain>
Message-ID: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>

Hi, all,
    We all know that OpenSource is a wonderful idea, and we like it. But 
sometimes the end users (in our case those who are going to use our Java 
libraries) may be confused if there are too many styles involved. I am not 
talking about the coding style - that's usually hidden and as long as it 
does what it says it does, who cares - but about the style how our code is 
deployed and used. I think that our code may provide better service if we 
can follow - when and where possible - similar principles.
   Can we, therefore, have here a chat about these principles? I do not 
want to be seen as an intruder and a dictator (even though I am both), and 
the things I am going to list here (below) are just issues for comments, 
nothing more.
   Also, I am talking about things that are part of the moby-live CVS, not
about code provided by individual service provider - unless this code is
also part of this CVS. Also, I concentrate only on MOBY-S - but it would 
be nice to apply similar principles for both MOBYs - so, Gary, please your 
comments are also valuable.

   1) Package names. It does not matter where the Java code is in the CVS
module (because one can partition things either by language, or by topic,
and both approaches can be mixed) but it would be nice if the Java package
names reflected what the code deals with. I started with names (I hope 
with obvious meanings - if not I am ready to explain):
   org.biomoby.client
   org.biomoby.shared
   org.biomoby.registry
   org.biomoby.service

   Others started their own package names:
   ca.icapture.moby
      Does this mean that the code is owned by somebody else? BTW, there
is no source for this package in the current CVS (just binaries). I
strongly feel that the biomoby CVS should have source code for everything
unless it is clearly labelledf as third-party library. Is this such case? 
   org.mobycentral...
      I think that this actually belongs more to org.biomoby.client - 
because it does not implement mobycentral funtionality (in which case I 
would recommend to use org.biomoby.registry, or org.biomoby.central...) 
but it implements new ways how to access the registry. But I am not sure.

   2) Building. What about to use Ant? :-) At the moment, some subprojects
does not support much re-building by other users. Such support should be a
primary rule for an open source project. Or am I too autocrative here?

   3) Third-party libraries (the ones we have only as jar files).
   There is no single solution. We may have them as part of the CVS, or 
let Ant download them when a user is re-building.
   If we have them as part of moby-live CVS:
   - it is always sure that after 'cvs co' you have everything and in 
correct version
   - the CVS can be huge (as it is now) and many users will use just a 
small sub-part (like perl users) but they still need to check-out 
everything.
   Almost opposite arguments apply for not to have them here. Open 
question...
   But I feel that having the same third-party libraries in several places 
within the same project (Ed?) does sound good.

   4) Generated documentation. I think that Java API that is generated 
from Java code should not be part of the CVS. It is anyway a paint in the 
neck to keep it sync with the CVS. The build procedures (Ant, hopefully) 
should be able to generate it for each user when [s]he is re-building.

   4) Documentation. I hope to have one BioMoby Java starting page from
where Java users can go to all Java-based subprojects. I will update the
current jMoby pages (if you do not mind) - but could you send me the text
you would like to be added at the starting page and pointing to 
yoursub-project please?

   With kindest regards,
   Martin   

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger






From gordonp at cbr.nrc.ca  Thu Sep 16 10:37:47 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Thu, 16 Sep 2004 08:37:47 -0600
Subject: [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
Message-ID: <4149A53B.4050804@cbr.nrc.ca>

Hey Martin,

>   1) Package names. It does not matter where the Java code is in the CVS
>module (because one can partition things either by language, or by topic,
>and both approaches can be mixed) but it would be nice if the Java package
>names reflected what the code deals with. I started with names (I hope 
>with obvious meanings - if not I am ready to explain):
>   org.biomoby.client
>   org.biomoby.shared
>   org.biomoby.registry
>   org.biomoby.service
>  
>
I agree, we should probably fit the other classes into this hierarchy 
for core classes,
and at least into a contrib folder if it's not core.

>   2) Building. What about to use Ant? :-) At the moment, some subprojects
>does not support much re-building by other users. Such support should be a
>primary rule for an open source project. Or am I too autocrative here?
>  
>
Yeah, we use Ant here too, it's a godsend.  Are there any subprojects that
require fancy compilation, or can we just use a generic task?

>   3) Third-party libraries (the ones we have only as jar files).
>   There is no single solution. We may have them as part of the CVS, or 
>let Ant download them when a user is re-building.
>   If we have them as part of moby-live CVS:
>   - it is always sure that after 'cvs co' you have everything and in 
>correct version
>   - the CVS can be huge (as it is now) and many users will use just a 
>small sub-part (like perl users) but they still need to check-out 
>everything.
>   Almost opposite arguments apply for not to have them here. Open 
>question...
>   But I feel that having the same third-party libraries in several places 
>within the same project (Ed?) does sound good.
>  
>
I'm thinking that 95% of users checkout the whole Java archive when they 
fetch
the code.  Also, they usually won't dig deep enough to figure out 
exactly what parts
of the code they are using require what third-party libraries (and hence 
would have
to include all the jars when they wrap up their own MOBY apps).  Then 
you get the
issue of classpaths, and possible conflicts if two sub projects use 
different versions of
the  third party programs. I'm for a libs directory where all the .jars 
are stored, and
probably a README that says which parts of the code use which jars.

>   4) Generated documentation. I think that Java API that is generated 
>from Java code should not be part of the CVS. It is anyway a paint in the 
>neck to keep it sync with the CVS. The build procedures (Ant, hopefully) 
>should be able to generate it for each user when [s]he is re-building.
>  
>
I agree.

>   4) Documentation. I hope to have one BioMoby Java starting page from
>where Java users can go to all Java-based subprojects. I will update the
>current jMoby pages (if you do not mind) - but could you send me the text
>you would like to be added at the starting page and pointing to 
>yoursub-project please?
>  
>
I've got nothing so far, but would like to contrbute a page on MOBY 
object instance creation...

>   With kindest regards,
>   Martin   
>
>  
>



From gordonp at cbr.nrc.ca  Thu Sep 16 10:37:47 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Thu, 16 Sep 2004 08:37:47 -0600
Subject: [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
Message-ID: <4149A53B.4050804@cbr.nrc.ca>

Hey Martin,

>   1) Package names. It does not matter where the Java code is in the CVS
>module (because one can partition things either by language, or by topic,
>and both approaches can be mixed) but it would be nice if the Java package
>names reflected what the code deals with. I started with names (I hope 
>with obvious meanings - if not I am ready to explain):
>   org.biomoby.client
>   org.biomoby.shared
>   org.biomoby.registry
>   org.biomoby.service
>  
>
I agree, we should probably fit the other classes into this hierarchy 
for core classes,
and at least into a contrib folder if it's not core.

>   2) Building. What about to use Ant? :-) At the moment, some subprojects
>does not support much re-building by other users. Such support should be a
>primary rule for an open source project. Or am I too autocrative here?
>  
>
Yeah, we use Ant here too, it's a godsend.  Are there any subprojects that
require fancy compilation, or can we just use a generic task?

>   3) Third-party libraries (the ones we have only as jar files).
>   There is no single solution. We may have them as part of the CVS, or 
>let Ant download them when a user is re-building.
>   If we have them as part of moby-live CVS:
>   - it is always sure that after 'cvs co' you have everything and in 
>correct version
>   - the CVS can be huge (as it is now) and many users will use just a 
>small sub-part (like perl users) but they still need to check-out 
>everything.
>   Almost opposite arguments apply for not to have them here. Open 
>question...
>   But I feel that having the same third-party libraries in several places 
>within the same project (Ed?) does sound good.
>  
>
I'm thinking that 95% of users checkout the whole Java archive when they 
fetch
the code.  Also, they usually won't dig deep enough to figure out 
exactly what parts
of the code they are using require what third-party libraries (and hence 
would have
to include all the jars when they wrap up their own MOBY apps).  Then 
you get the
issue of classpaths, and possible conflicts if two sub projects use 
different versions of
the  third party programs. I'm for a libs directory where all the .jars 
are stored, and
probably a README that says which parts of the code use which jars.

>   4) Generated documentation. I think that Java API that is generated 
>from Java code should not be part of the CVS. It is anyway a paint in the 
>neck to keep it sync with the CVS. The build procedures (Ant, hopefully) 
>should be able to generate it for each user when [s]he is re-building.
>  
>
I agree.

>   4) Documentation. I hope to have one BioMoby Java starting page from
>where Java users can go to all Java-based subprojects. I will update the
>current jMoby pages (if you do not mind) - but could you send me the text
>you would like to be added at the starting page and pointing to 
>yoursub-project please?
>  
>
I've got nothing so far, but would like to contrbute a page on MOBY 
object instance creation...

>   With kindest regards,
>   Martin   
>
>  
>



From mwilkinson at mrl.ubc.ca  Thu Sep 16 18:02:51 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Thu, 16 Sep 2004 15:02:51 -0700
Subject: [MISC] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <Pine.OSF.4.21.0409152119021.1471296-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0409152119021.1471296-100000@mozart.ebi.ac.uk>
Message-ID: <1095372170.11263.37.camel@myhost.mydomain>

Hi Martin, 

you're absolutely right.  I had it in there during debugging so that I
could retrieve messages where the XML was incorrectly formatted.

I've removed that now, but it has the unfortunate consequence that
**EVERYONE** must do a cvs update on their MOBY::Client::Central, since
the old client library assumed that it was CDATA, and wont extract the
RDF-XML from the registration object.

I will also make a new release for those who are only downloading the
releases.

Ugh... sorry about that!

M



On Wed, 2004-09-15 at 13:20, Martin Senger wrote:
> Mark,
>    I wonder why the RDF part in the registration object is marked as
> CDATA. Because RDF must be anyway a valid XML why to bother to surround it
> by CDATA. Having CDATA there would prevent me to have CDATA in RDF. Is
> there any reason you use CDATA for the RDF part?
> 
>    Thanks,
>    Martin
-- 
Mark Wilkinson (mwilkinson at mrl.ubc.ca)
University of British Columbia iCAPTURE Centre


From mwilkinson at mrl.ubc.ca  Thu Sep 16 18:25:11 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Thu, 16 Sep 2004 15:25:11 -0700
Subject: [MOBY-dev] CVS update required & new release available
Message-ID: <1095373511.11263.42.camel@myhost.mydomain>

Hi all, 

I just had to make a change in the client code that will allow you to
extract the RDF from the Registration object (Perl users only).

Please do a CVS update if you are using CVS, or download the latest
release from the biomoby.org/releases page, otherwise the RDF will not
be available to you in the MOBY::Registration object.

Java users should be (?? Martin/Paul ??) unaffected by this change - all
I did was remove the CDATA tags around the RDF-XML in the Registration
XML message.

M


-- 
Mark Wilkinson (mwilkinson at mrl.ubc.ca)
University of British Columbia iCAPTURE Centre


From senger at ebi.ac.uk  Thu Sep 16 18:32:23 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 16 Sep 2004 23:32:23 +0100 (BST)
Subject: [MOBY-dev] CVS update required & new release available
In-Reply-To: <1095373511.11263.42.camel@myhost.mydomain>
Message-ID: <Pine.OSF.4.21.0409162330020.859783-100000@ice.ebi.ac.uk>

> Java users should be (?? Martin/Paul ??) unaffected by this change
>
   I am just coding the whole new registration stuff, so I do not need to
announce a change because I have not commited it yet :-)
   I will let Java users know soon... (I already must thank to Eddie for
his valuable suggestions and conrtibutions).

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Thu Sep 16 18:32:23 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 16 Sep 2004 23:32:23 +0100 (BST)
Subject: [MOBY-dev] CVS update required & new release available
In-Reply-To: <1095373511.11263.42.camel@myhost.mydomain>
Message-ID: <Pine.OSF.4.21.0409162330020.859783-100000@ice.ebi.ac.uk>

> Java users should be (?? Martin/Paul ??) unaffected by this change
>
   I am just coding the whole new registration stuff, so I do not need to
announce a change because I have not commited it yet :-)
   I will let Java users know soon... (I already must thank to Eddie for
his valuable suggestions and conrtibutions).

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From mwilkinson at mrl.ubc.ca  Thu Sep 16 18:40:00 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Thu, 16 Sep 2004 15:40:00 -0700
Subject: [MISC] [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
Message-ID: <1095374399.11261.58.camel@myhost.mydomain>

Hi Martin, 

Eddie's package names are my fault.  He was working on something quite
task-specific, and I didn't know if his modules were going to fit
happily with yours or not.  Just to be safe, I advised him to put his
new modules into their own folder for the time being.  I didn't think
further about the naming conventions that he should use.

You should perhaps work out with him directly where they fit best, and
we can make the changes and re-commit.

Sorry about that!

M

-- 
Mark Wilkinson (mwilkinson at mrl.ubc.ca)
University of British Columbia iCAPTURE Centre


From senger at ebi.ac.uk  Thu Sep 16 18:56:12 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 16 Sep 2004 23:56:12 +0100 (BST)
Subject: [MISC] [MOBY-dev] Java developers, let's talk together
In-Reply-To: <1095374399.11261.58.camel@myhost.mydomain>
Message-ID: <Pine.OSF.4.21.0409162353010.859783-100000@ice.ebi.ac.uk>

> Eddie's package names are my fault.
>
   Actually, there was no fault, at all. I was just trying to start
discussion :-)
   And I will continue, especially with the most important topic, pointed
out by Paul G., how to make sure that users of Java libraries always know
what put on their claspath when they use several libraries from several
authors. I have to sleep on that... (because put everything
third-party libs into one shared directory can lead to the versioning
problem).

> You should perhaps work out with him directly where they fit best, and
> we can make the changes and re-commit.
>
   Yes, we are in touch...

   Regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From adf at ncgr.org  Thu Sep 16 19:46:52 2004
From: adf at ncgr.org (Andrew D. Farmer)
Date: Thu, 16 Sep 2004 17:46:52 -0600 (MDT)
Subject: [MISC] [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.OSF.4.21.0409162353010.859783-100000@ice.ebi.ac.uk>
Message-ID: <Pine.LNX.4.44.0409161728270.12609-100000@alberich.ncgr.org>

>    And I will continue, especially with the most important topic, pointed
> out by Paul G., how to make sure that users of Java libraries always know
> what put on their claspath when they use several libraries from several
> authors. I have to sleep on that... (because put everything
> third-party libs into one shared directory can lead to the versioning
> problem).

I missed this in the original message, but it happened to catch my eye here.
FWIW, we had a similar problem in ISYS, where independent components each 
came with their own set of classes (possibly different versions of the same 
libs) and the system itself had its own set. 

The solution we used involved custom classloaders (which I have since read 
officially qualifies one as a master of black magic); if I recall correctly, 
you can actually have multiple versions of the "same" class loaded into one 
VM, provided that they are loaded by different classloaders. Each class 
(version) maintains a reference to the classloader that loaded it, and the 
latter is given the first chance at loading classes referenced by the former 
or delegating to another classloader to find it. It is a bit complicated, 
but designed for situations like this.  
It does require that some mechanism other than the system classpath be used
for specifying the location of the resources for each classloader; in our
case, each component had its own directory space and the custom classloaders
just searched the lib directory of that component for jars (or it could be
done as a config file).

Your situation may not call for measures this complicated, but let me know
if you want any more information on our experience with this approach...

Andrew

> 
> > You should perhaps work out with him directly where they fit best, and
> > we can make the changes and re-commit.
> >
>    Yes, we are in touch...
> 
>    Regards,
>    Martin
> 
> 

-- 

Andrew Farmer
adf at ncgr.org
(505) 995-4464
Database Administrator/Software Developer
National Center for Genome Resources

---
The whole problem with the world is that fools and fanatics are always
so certain of themselves, and wiser people so full of doubts. -
Bertrand Russell
---




From opushneva at yahoo.ca  Fri Sep 17 00:16:47 2004
From: opushneva at yahoo.ca (Nina Opushneva)
Date: Thu, 16 Sep 2004 21:16:47 -0700 (PDT)
Subject: [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
Message-ID: <20040917041647.91439.qmail@web60903.mail.yahoo.com>




 Hi Martin,


>    1) Package names. It does not matter where the
> Java code is in the CVS
> module (because one can partition things either by
> language, or by topic,
> and both approaches can be mixed) but it would be
> nice if the Java package
> names reflected what the code deals with. I started
> with names (I hope 
> with obvious meanings - if not I am ready to
> explain):
>    org.biomoby.client
>    org.biomoby.shared
>    org.biomoby.registry
>    org.biomoby.service
> 

You are definitely right regarding the package name
convention. I didn’t find any rules for that, so I
used my own. Sorry about that, I’ll change the package
names. From my point of view the RDF Agent logically
belongs to the registry. Will be the
org.biomoby.registry.rdfagent as a RDF Agent’s base
package name ok?


>    2) Building. What about to use Ant? :-) At the
> moment, some subprojects
> does not support much re-building by other users.
> Such support should be a
> primary rule for an open source project. Or am I too
> autocrative here?
> 

Agree. I’ll develop an ANT build file for the RDF
Agent and will commit it to the CVS with source code.

>    3) Third-party libraries (the ones we have only
> as jar files).
>    There is no single solution. We may have them as
> part of the CVS, or 
> let Ant download them when a user is re-building.

Location for the third-party libraries is real issue.
I think we should discuss that altogether with
subproject directory structure. I would suggest
following:

…
 |
 subroject name
  |
  + doc
  +config
  + lib
  + src
  |
  Manifest.mf
  readme
  build.xml
  build.sh
  build.bat
  run.sh
  run.bat

This structure provides good subproject encapsulation
and resolves libraries’ version conflict problem. Main
disadvantage –duplicate some libraries. As a result
less efficient use of  the server disk space and some
extra traffic. I think that easy subproject’s
sourcecode / libs administration is much more
valuable. To put all libraries in the same place could
become a nightmare for the project
support/administration especially if keep in mind that
a jar file name means nothing. Two jars with the same
name could have absolutely different content and/or
library versions. 



>    4) Generated documentation. I think that Java API
> that is generated 
> from Java code should not be part of the CVS. It is
> anyway a paint in the 
> neck to keep it sync with the CVS. The build
> procedures (Ant, hopefully) 
> should be able to generate it for each user when
> [s]he is re-building.
> 

Agree. An ANT build file should have task “generate
JavaDoc” or similar.


>    4) Documentation. I hope to have one BioMoby Java
> starting page from
> where Java users can go to all Java-based
> subprojects. I will update the
> current jMoby pages (if you do not mind) - but could
> you send me the text
> you would like to be added at the starting page and
> pointing to 
> yoursub-project please?
> 

It is a very good idea. I will prepare the text and
send it to you as soon as I can.

Best regards,

Nina Opushneva


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com


From senger at ebi.ac.uk  Fri Sep 17 06:49:21 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 17 Sep 2004 11:49:21 +0100 (BST)
Subject: [MOBY-dev] Java developers, let's talk together
In-Reply-To: <20040917041647.91439.qmail@web60903.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0409170940490.8147-100000@bagheera.ebi.ac.uk>

[ I am sorry this is a bit longer email. I am abusing the reply to Nina to
address also answers and hints from other people's emails from yesterday.  
Thanks very much for all of them; especially those interesting suggestions
about how to address versioning conflicts of the third party libraries.
Thanks again. ]

> From my point of view the RDF Agent logically belongs to the registry.
> Will be the org.biomoby.registry.rdfagent as a RDF Agent?s base package
> name ok?
>
   I agree, perfect. 

> Agree. I?ll develop an ANT build file for the RDF
> Agent and will commit it to the CVS with source code.
>
   Sounds great. (I put some comments about Ant and third-libraries 
below).
 
> Location for the third-party libraries is real issue.
> I think we should discuss that altogether with
> subproject directory structure.
>
   I would say that if we use Ant then the directory structure is not that 
important (because Ant knows where to find things). The directory 
structure becomes more relevant if we decide to move sources together. 
Which is not so bad idea - if it is easy (e.g. I feel that moving S-MOBY 
current structure to the same directory with jMoby-MOBY-S would not be 
practical).
   My suggestion is this: I am going to write down (first here, later it
should appear also in the docs somewhere; most of it is already there,
btw) some conventions which I am using now (and which - believe me - I was
thinking about quite a lot before I started to use them). Every developer
will have then three options (any has few pros and cons):

   1) To keep her/his subproject separate, or
   2) To incorporate it into current structure in moby-live/Java, or
   3) To put in into moby-live/Java - bus as a totally separate 
subdirectory.

What are the pros and cons?

   Ad 1) is preferable (unless there are reasons against it) because it
will force us to solve problems with versioning of the third-party
libraries as soon as they appear (if they appear; perhaps we will be lucky
:-)). Simply it means to share third-party libraries (sitting in the 'lib'
subdirectory).
   This is also quite good for the end-users using our libraries/code - 
because it is clear to them what to put on their classpath (usually we 
already have 'run' scripts doing it).
   The cons are: You need to conform with the existing structure and
existing policies which may not be always the best for your subproject. If
you want to change such policy it needs more discussion and time because
there are more people involved. Simply speaking: any change in structure
is costly.
   Also this does not solve the problem how the end-users can combine more 
subproject together. I will briefly address this problem at the end.

   Ad 3) is needed if you have special build requirements - so you can 
provide your own build.xml. I have never used nested build.xml so I have 
not yet experiences with this option. But it should work fine.

   If you choose ad 2) or ad 3) the suggested principles are simple:
   a) use Ant
   b) do not put Java generated documentation in the CVS (but make Ant to 
produce it)
   c) send me a link and few words about your subproject that I can
include in the jMoby main page

   If you choose ad 1) the principles above are the same, but there are 
also others (I am not only listing them but I am trying to put some 
rationale that lead me to have them. I am also prepared to discuss how to 
change them if you wish.):
   [ Everything below can be seen in moby-live/Java/build.xml, and in 
scripts moby-live/Java/build.* ]

   d) The sources are in 'src', but most of them are actually in
'src/main'. This is how to make possible to include also sources that do
not belong to any package (such as some testing classes). Simple speaking,
if your sources are in package (most of them, if not all, are) they should
go to 'src/main').

   e) Run scripts (the scripts starting various Java programs) are now in 
the main directory. This is going to be changed because we may have more 
scripts and it should polute the main level too much. There are two 
options:
   e1) To use 'run' directory.
   e2) To use 'build/run' directory.
   Using 'run' directory is easier for users. When they look into the top
level, they see 'run' so they look there and find appropriate script. But 
the script will not work until they actually build everything, and the 
script must always be started from the top level directory (because it 
must have relative path to 'build' and 'lib' directories with classes).
   Using 'build/run' is not so obvious but has otherwise quite a lot
advantages: the scripts are generated by Ant, so they have the full paths
to classes, so they can be called from anywhere; they cannot be started
before building them - because they do not exist before that :-), and they
can be customized (using standard 'build.properties' file) for local needs
(if there are such needs, hopefully as little as possible - but for
example for scripts accessing locations out of the CVS space, like Tomcat, 
it is needed).
   Saying this I vote for 'build/run'...

   f) The probably most contentious topic is how to get third-party
libraries. The basic question is: should they be part of the CVS or be
downloaded when you first build it? After many considerations, and after
discussing with people around here, I have taken the second option
(downloading them). (The moby-live/Java/README explains how it works.) If
we continue to use this option, I will change the place where I am getting
these libraries from to somewhere where other developers can put their
libraries as well (it must be a place accessible by HTTP - at the moment I
have it in my space at EBI).
   This email is too long now - so we may discuss this topic separately if 
we wish.

   That's all regarding the policies.

   Nina also suggested:
>   + doc
>   +config
>
   * moby-live/Java uses 'docs' instead of 'doc', sorry for that;
   * I usually have 'config' under 'src' - but there are no special 
reasons for that.

> This structure provides good subproject encapsulation
> and resolves libraries? version conflict problem. Main
> disadvantage ?duplicate some libraries. As a result
> less efficient use of  the server disk space and some
> extra traffic.
>
   As I tried to explain above, the problem is not with having duplicates,
but with the versioning conflicts that can happen when a user starts using
two - until now separated - subprojects. He has to pick up a library from
one of these subproject - which may lead to failure of the other one. If
we share the libraries from the beginning we know about it during the
developing and testing phase already.

> To put all libraries in the same place could become a nightmare for the
> project support/administration
>
   It may be well true - but better have this nightmare for administrators 
and developers than for our users. Just my 2c.

   So I finish now... Again sorry for the extend of this email.
   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger









From rebecca.ernst at gsf.de  Fri Sep 17 08:30:21 2004
From: rebecca.ernst at gsf.de (Rebecca Ernst)
Date: Fri, 17 Sep 2004 14:30:21 +0200
Subject: [MOBY-dev] signatureURL
In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain>
References: <1095263887.5954.78.camel@myhost.mydomain>
Message-ID: <414AD8DD.7000601@gsf.de>

Hi Mark!

I don't know if you check who of the service providers has generated his 
serviceSignature - Just for the case that you don't check it: 
I wanted to inform you that mips.gsf.de is now up-to-date and prepared 
for the visit of Ninas agent ;-)

Rebecca



-- 
Rebecca Ernst
MIPS, Inst. for Bioinformatics
GSF Research Center for Environment and Health
Ingolstaedter Landstr. 1
85764 Neuherberg
fon: +49 89 3187 3583
email: Rebecca.Ernst at gsf.de



From mwilkinson at mrl.ubc.ca  Fri Sep 17 09:35:45 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Fri, 17 Sep 2004 06:35:45 -0700
Subject: [MOBY-dev] Re: [MISC] signatureURL
In-Reply-To: <414AD8DD.7000601@gsf.de>
References: <1095263887.5954.78.camel@myhost.mydomain>
	<414AD8DD.7000601@gsf.de>
Message-ID: <1095428145.11263.194.camel@myhost.mydomain>

Hiya, 

I will check the database by eye before we switch the agent on, and
contact anyone who is tardy :-)

M


On Fri, 2004-09-17 at 05:30, Rebecca Ernst wrote:
> Hi Mark!
> 
> I don't know if you check who of the service providers has generated his 
> serviceSignature - Just for the case that you don't check it: 
> I wanted to inform you that mips.gsf.de is now up-to-date and prepared 
> for the visit of Ninas agent ;-)
> 
> Rebecca
-- 
Mark Wilkinson (mwilkinson at mrl.ubc.ca)
University of British Columbia iCAPTURE Centre


From gordonp at cbr.nrc.ca  Fri Sep 17 10:44:55 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Fri, 17 Sep 2004 08:44:55 -0600
Subject: [MISC] [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.LNX.4.44.0409161728270.12609-100000@alberich.ncgr.org>
References: <Pine.LNX.4.44.0409161728270.12609-100000@alberich.ncgr.org>
Message-ID: <414AF867.7020707@cbr.nrc.ca>

People will probably disagree with me here, because it creates a little 
more work for the developers,
but can't we all at least try to use the same version of Axis for 
example?  When you want to write new code,
you can see if there's an acceptable version of the lib of interest 
already committed, and if you absolutely must
use a newer version that is not backward compatible, you can put it in a 
project specific lib directory? 

Later, you can try to convince people that they should update their 
code, or place the old lib in their project-specific
lib directory.  e.g. "Hey!  All Java developers!  Get off your asses and 
use Axis 1.1 instead of the crappy
Axis 1.0 which doesn't cache the non-existence of deserialization helper 
classes and causes thousands of
HTTP requests/disk accesses while running SOAP services!".  There are a 
lot more people contributing to
BioPerl, and they all use the same libraries, we Java programmers can't 
let them show us up :-)

>>   And I will continue, especially with the most important topic, pointed
>>out by Paul G., how to make sure that users of Java libraries always know
>>what put on their claspath when they use several libraries from several
>>authors. I have to sleep on that... (because put everything
>>third-party libs into one shared directory can lead to the versioning
>>problem).
>>    
>>
>
>I missed this in the original message, but it happened to catch my eye here.
>FWIW, we had a similar problem in ISYS, where independent components each 
>came with their own set of classes (possibly different versions of the same 
>libs) and the system itself had its own set. 
>
>  
>
>The solution we used involved custom classloaders (which I have since read 
>officially qualifies one as a master of black magic);
>
Hee hee, I wrote my own class loader too, but so that I could 
automatically create applet JARs
with only the classes I needed for the app instead of all of the classes 
in the third party packages
I was using.  When is the next Black Magic Circle clandestine meeting? :-)


From senger at ebi.ac.uk  Fri Sep 17 10:52:41 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 17 Sep 2004 15:52:41 +0100 (BST)
Subject: [MISC] [MOBY-dev] Java developers, let's talk together
In-Reply-To: <414AF867.7020707@cbr.nrc.ca>
Message-ID: <Pine.LNX.4.44.0409171550260.8340-100000@bagheera.ebi.ac.uk>

> People will probably disagree with me here, because it creates a little
> more work for the developers, but can't we all at least try to use the
> same version of Axis for example?
>
   Well, that was my preferred option :-) Put your code into
moby-live/Java, and use what is there in 'lib' (or what is downloaded
there when you first build it - but this is another story). If it does not 
suite you, shout loudly...

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Tue Sep 21 07:02:34 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 21 Sep 2004 12:02:34 +0100 (BST)
Subject: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain>
Message-ID: <Pine.LNX.4.44.0409211156090.20316-100000@bagheera.ebi.ac.uk>

Mark,
   I found the agent's behaviour description slightly inconsistent in one 
place (perhaps agent is not inconsistent, perhaps it is only the 
description, I have not tested the agent itself):

> The agent runs on a cron, and behaves as follows:
> ...
> 3)  If it doesn't find a valid RDF file there, then it flags an error;
> after a certain number of errors your service(s) will be deregistered.
> ...
> 5)  If it expects to find a service signature in this RDF, and can't
> find it, it concludes that the service has been taken off-line, and it
> will de-register that service.
>
   So: if there is no file at all, it will try several times before
de-registering the service. But if there is any RDF file but without my
service, it will de-register it immediatelly. Why does it not behave the
same in these two cases? In reality, it would mean slightly different
behaviour when I am adding my first service (so the RDF file with all my
services does not exist yes) and when I am adding the second and more 
services (when the RDF file exists - havig my previous services - but it 
still does not have my last one).

   Regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Tue Sep 21 07:02:34 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 21 Sep 2004 12:02:34 +0100 (BST)
Subject: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain>
Message-ID: <Pine.LNX.4.44.0409211156090.20316-100000@bagheera.ebi.ac.uk>

Mark,
   I found the agent's behaviour description slightly inconsistent in one 
place (perhaps agent is not inconsistent, perhaps it is only the 
description, I have not tested the agent itself):

> The agent runs on a cron, and behaves as follows:
> ...
> 3)  If it doesn't find a valid RDF file there, then it flags an error;
> after a certain number of errors your service(s) will be deregistered.
> ...
> 5)  If it expects to find a service signature in this RDF, and can't
> find it, it concludes that the service has been taken off-line, and it
> will de-register that service.
>
   So: if there is no file at all, it will try several times before
de-registering the service. But if there is any RDF file but without my
service, it will de-register it immediatelly. Why does it not behave the
same in these two cases? In reality, it would mean slightly different
behaviour when I am adding my first service (so the RDF file with all my
services does not exist yes) and when I am adding the second and more 
services (when the RDF file exists - havig my previous services - but it 
still does not have my last one).

   Regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From gordonp at cbr.nrc.ca  Tue Sep 21 10:20:56 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Tue, 21 Sep 2004 08:20:56 -0600
Subject: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <Pine.LNX.4.44.0409211156090.20316-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409211156090.20316-100000@bagheera.ebi.ac.uk>
Message-ID: <415038C8.4090105@cbr.nrc.ca>

I think the idea behind the multiple attempts in case (3) is that the 
Web server might be down, or the page temporarily unavailable due to 
resource problems (e.g. forgot to mount the Web server disk :-)).  To 
make these more consistent, maybe I'd only retry fetching the RDF if the 
server could not be contacted, or if it returned a 5XX HTTP code.  
Ortherwise treat it as case (5)?

Martin Senger wrote:

>Mark,
>   I found the agent's behaviour description slightly inconsistent in one 
>place (perhaps agent is not inconsistent, perhaps it is only the 
>description, I have not tested the agent itself):
>
>  
>
>>The agent runs on a cron, and behaves as follows:
>>...
>>3)  If it doesn't find a valid RDF file there, then it flags an error;
>>after a certain number of errors your service(s) will be deregistered.
>>...
>>5)  If it expects to find a service signature in this RDF, and can't
>>find it, it concludes that the service has been taken off-line, and it
>>will de-register that service.
>>
>>    
>>
>   So: if there is no file at all, it will try several times before
>de-registering the service. But if there is any RDF file but without my
>service, it will de-register it immediatelly. Why does it not behave the
>same in these two cases? In reality, it would mean slightly different
>behaviour when I am adding my first service (so the RDF file with all my
>services does not exist yes) and when I am adding the second and more 
>services (when the RDF file exists - havig my previous services - but it 
>still does not have my last one).
>
>   Regards,
>   Martin
>
>  
>



From opushneva at yahoo.ca  Wed Sep 22 01:33:57 2004
From: opushneva at yahoo.ca (Nina Opushneva)
Date: Tue, 21 Sep 2004 22:33:57 -0700 (PDT)
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <Pine.LNX.4.44.0409211156090.20316-100000@bagheera.ebi.ac.uk>
Message-ID: <20040922053357.44035.qmail@web60906.mail.yahoo.com>

Hi Martin,

Mark is away now. May I try to answer your question.


3) It expects to find, there, a RDF representation of
the services hosted by this service provider. If the
connection is refused three times in a row for the
same reason, the services that have been registered
with this signatureURL will be deleted from
mobycentral database.  Every time a message about a
refused connection will be sent to provider.

If the connection was successful, the RDFAgent browses
the input stream and compares it to the data in the
database. New services described will be added to
database; the services, which were expected to be at
this URL, but are missing, will be deleted from the
database.

I don’t think that RDFagent is going to be working
every day, maybe for checking could be enough once a
week (lets say on Sunday). So, providers will have
time to put their RDF into the RDF file. But we can
discuss it.

Cheers,

Nina



--- Martin Senger <senger at ebi.ac.uk> wrote:

> Mark,
>    I found the agent's behaviour description
> slightly inconsistent in one 
> place (perhaps agent is not inconsistent, perhaps it
> is only the 
> description, I have not tested the agent itself):
> 
> > The agent runs on a cron, and behaves as follows:
> > ...
> > 3)  If it doesn't find a valid RDF file there,
> then it flags an error;
> > after a certain number of errors your service(s)
> will be deregistered.
> > ...
> > 5)  If it expects to find a service signature in
> this RDF, and can't
> > find it, it concludes that the service has been
> taken off-line, and it
> > will de-register that service.
> >
>    So: if there is no file at all, it will try
> several times before
> de-registering the service. But if there is any RDF
> file but without my
> service, it will de-register it immediatelly. Why
> does it not behave the
> same in these two cases? In reality, it would mean
> slightly different
> behaviour when I am adding my first service (so the
> RDF file with all my
> services does not exist yes) and when I am adding
> the second and more 
> services (when the RDF file exists - havig my
> previous services - but it 
> still does not have my last one).
> 
>    Regards,
>    Martin
> 
> -- 
> Martin Senger
> 
> EMBL Outstation - Hinxton               
> Senger at EBI.ac.uk     
> European Bioinformatics Institute        Phone:
> (+44) 1223 494636      
> Wellcome Trust Genome Campus            
> (Switchboard:     494444)
> Hinxton                                  Fax  :
> (+44) 1223 494468
> Cambridge CB10 1SD
> United Kingdom                          
> http://industry.ebi.ac.uk/~senger
> 
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
> 



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 


From senger at ebi.ac.uk  Wed Sep 22 07:15:31 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 22 Sep 2004 12:15:31 +0100 (BST)
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <20040922053357.44035.qmail@web60906.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0409221211580.2054-100000@bagheera.ebi.ac.uk>

> May I try to answer your question.
> 
Nina,
   Thanks for the clarification.
   Just one minor question: Assuming I do not wish to register a service
for long, therefore I do not plan to send any signatureURL. Is it safe to
include an empty signatureURL tag, or do I *have* to omit it at all?

   Regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Wed Sep 22 07:15:31 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 22 Sep 2004 12:15:31 +0100 (BST)
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <20040922053357.44035.qmail@web60906.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0409221211580.2054-100000@bagheera.ebi.ac.uk>

> May I try to answer your question.
> 
Nina,
   Thanks for the clarification.
   Just one minor question: Assuming I do not wish to register a service
for long, therefore I do not plan to send any signatureURL. Is it safe to
include an empty signatureURL tag, or do I *have* to omit it at all?

   Regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Wed Sep 22 09:23:31 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 22 Sep 2004 14:23:31 +0100 (BST)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <20040922053357.44035.qmail@web60906.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>

Here are few comments and perhaps questions. But before that I would like
to stress that these issues are urgent NOW (sorry for the capital letters)
because we are changing libraries now and we need these issues to be fixed
(or explained) really soon. Thanks.

1) Testing registry seems to have still older version - it still returns 
RDF with CDATA. It would be good to have it restarted, or whatever it 
needs. The testing registry with the latest software is important 
especially now when we are testing new registration procedures.

2) The service description, as returned in the RDF, lost its CDATA 
protection. Perhaps it is correct, I do not know enough about RDF 
documents. I have just observed that the 'strange characters', 
such as '>', that I put into my service description, were returned 
escaped: the character '>' was escaped as '&amp;gt;' - which does not seem 
to be correct (but perhaps I am mistaken).

Anyway, I wonder why to play with escaping at all, why not to keep there 
CDATA. We have CDATA in service description just because we did not want 
to escape everything there - is that correct?

3) I also wonder where are all our LSIDs? There is no single LSID in the 
whole returned RDF. I thought that we expressed almost everything as LSIDs 
in biomoby (at least internally).

4) I use this list to strongly express how I agree with the last Rebecca 
email about being still able to deregister a service by calling a 
deregister method even if the service has been registered with the 
signatureURL.

5) Finally, just to make this list complete, I would like to remind the 
others that there had been a discussion about possibility to get RDF from 
the registry even for services that had been already registered. I would 
like to have this feature soon - because it may need an addition tag in 
the service object, so the sooner we know about it the better.

   With kindest regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger




From rebecca.ernst at gsf.de  Wed Sep 22 10:02:18 2004
From: rebecca.ernst at gsf.de (Rebecca Ernst)
Date: Wed, 22 Sep 2004 16:02:18 +0200
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <415185EA.4080005@gsf.de>

Hi Martin!

referring to your last point:

>5) Finally, just to make this list complete, I would like to remind the 
>others that there had been a discussion about possibility to get RDF from 
>the registry even for services that had been already registered. I would 
>like to have this feature soon - because it may need an addition tag in 
>the service object, so the sooner we know about it the better.
>

This is a snippet of Marks former mail:

Of course, at the moment nobody has a signatureURL   I have set up a
simple CGI page for existing service providers where they can supply a
URL and get the signature RDF for all of their existing services:

http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl



Cheers,
Rebecca



-- 
Rebecca Ernst
MIPS, Inst. for Bioinformatics
GSF Research Center for Environment and Health
Ingolstaedter Landstr. 1
85764 Neuherberg
fon: +49 89 3187 3583
email: Rebecca.Ernst at gsf.de



From rebecca.ernst at gsf.de  Wed Sep 22 10:02:18 2004
From: rebecca.ernst at gsf.de (Rebecca Ernst)
Date: Wed, 22 Sep 2004 16:02:18 +0200
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <415185EA.4080005@gsf.de>

Hi Martin!

referring to your last point:

>5) Finally, just to make this list complete, I would like to remind the 
>others that there had been a discussion about possibility to get RDF from 
>the registry even for services that had been already registered. I would 
>like to have this feature soon - because it may need an addition tag in 
>the service object, so the sooner we know about it the better.
>

This is a snippet of Marks former mail:

Of course, at the moment nobody has a signatureURL   I have set up a
simple CGI page for existing service providers where they can supply a
URL and get the signature RDF for all of their existing services:

http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl



Cheers,
Rebecca



-- 
Rebecca Ernst
MIPS, Inst. for Bioinformatics
GSF Research Center for Environment and Health
Ingolstaedter Landstr. 1
85764 Neuherberg
fon: +49 89 3187 3583
email: Rebecca.Ernst at gsf.de



From senger at ebi.ac.uk  Wed Sep 22 10:09:43 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 22 Sep 2004 15:09:43 +0100 (BST)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <415185EA.4080005@gsf.de>
Message-ID: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>

> This is a snippet of Marks former mail:
> 
> Of course, at the moment nobody has a signatureURL   I have set up a
> simple CGI page for existing service providers where they can supply a
> URL and get the signature RDF for all of their existing services:
> 
> http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl
>
   Yes, I know about it. But Mark said that this cgi-bin will be there 
only temporarily. I had in mind something more permanent (for example if 
you loose your RDF you should be able to get it back somehow from the 
registry, without registering it again...). We have discussed this with 
Mark already and he seems to agree with providing such functionality - I 
had put it in the list of observations just not to let it slip from my
(and his :-)) mind...
 
   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Wed Sep 22 10:09:43 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 22 Sep 2004 15:09:43 +0100 (BST)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <415185EA.4080005@gsf.de>
Message-ID: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>

> This is a snippet of Marks former mail:
> 
> Of course, at the moment nobody has a signatureURL   I have set up a
> simple CGI page for existing service providers where they can supply a
> URL and get the signature RDF for all of their existing services:
> 
> http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl
>
   Yes, I know about it. But Mark said that this cgi-bin will be there 
only temporarily. I had in mind something more permanent (for example if 
you loose your RDF you should be able to get it back somehow from the 
registry, without registering it again...). We have discussed this with 
Mark already and he seems to agree with providing such functionality - I 
had put it in the list of observations just not to let it slip from my
(and his :-)) mind...
 
   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From opushneva at yahoo.ca  Wed Sep 22 13:01:26 2004
From: opushneva at yahoo.ca (Nina Opushneva)
Date: Wed, 22 Sep 2004 10:01:26 -0700 (PDT)
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <Pine.LNX.4.44.0409221211580.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <20040922170126.43575.qmail@web60901.mail.yahoo.com>

Hi Martin,
 
If you put the RDF of your service into a separate
file and include an empty signatureURL tag by
registration, the RDFagent will not process it.
Otherwise, if you put your RDF into the file which URL
is “known” for the registry database, it will be
processed.
(But in the first way you need to ask Mark if it's
possible include an empty signatureURL during of a
registration).

If you wish to save your service RDF into the RDF
file, but you don't wish to put the information about
this service into registry database, you can to make
RDF of this service “not valid for MOBY”.

 A valid MOBY RDF means that it has the complete set
of descriptions:
     serviceName  
     serviceType  
     authURI      
     contactEmail 
     description 
     category  
     URL   
     input/output (may be one of them)
 
If you delete or comment one of that descriptions,
RDFagent will not process RDF of this service.

Cheers,

Nina


--- Martin Senger <senger at ebi.ac.uk> wrote:

> > May I try to answer your question.
> > 
> Nina,
>    Thanks for the clarification.
>    Just one minor question: Assuming I do not wish
> to register a service
> for long, therefore I do not plan to send any
> signatureURL. Is it safe to
> include an empty signatureURL tag, or do I *have* to
> omit it at all?
> 
>    Regards,
>    Martin
> 
> -- 
> Martin Senger
> 
> EMBL Outstation - Hinxton               
> Senger at EBI.ac.uk     
> European Bioinformatics Institute        Phone:
> (+44) 1223 494636      
> Wellcome Trust Genome Campus            
> (Switchboard:     494444)
> Hinxton                                  Fax  :
> (+44) 1223 494468
> Cambridge CB10 1SD
> United Kingdom                          
> http://industry.ebi.ac.uk/~senger
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 


From markw at illuminae.com  Wed Sep 22 19:31:00 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 22 Sep 2004 16:31:00 -0700
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <41520B34.9080307@illuminae.com>

Hello from beautiful Banff!  I'm here at the SAB meeting for the grant 
under which MOBY-S is funded... wish me luck!

It turns out that the conference centre has public wireless access in 
the pub, but not in the rooms... oh dear!  ;-)

Yes, Martin and I have discussed this, and agreed that it should be a 
part of the MOBY Central API.  Martin, keep reminding me, as I have a 
ton of other things consuming my time at the moment so constant pressure 
will be required to get it done in a timely way...

Cheers all!

Mark


Martin Senger wrote:

>>This is a snippet of Marks former mail:
>>
>>Of course, at the moment nobody has a signatureURL   I have set up a
>>simple CGI page for existing service providers where they can supply a
>>URL and get the signature RDF for all of their existing services:
>>
>>http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl
>>
>>    
>>
>   Yes, I know about it. But Mark said that this cgi-bin will be there 
>only temporarily. I had in mind something more permanent (for example if 
>you loose your RDF you should be able to get it back somehow from the 
>registry, without registering it again...). We have discussed this with 
>Mark already and he seems to agree with providing such functionality - I 
>had put it in the list of observations just not to let it slip from my
>(and his :-)) mind...
> 
>   Cheers,
>   Martin
>
>  
>


From markw at illuminae.com  Wed Sep 22 19:31:00 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 22 Sep 2004 16:31:00 -0700
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <41520B34.9080307@illuminae.com>

Hello from beautiful Banff!  I'm here at the SAB meeting for the grant 
under which MOBY-S is funded... wish me luck!

It turns out that the conference centre has public wireless access in 
the pub, but not in the rooms... oh dear!  ;-)

Yes, Martin and I have discussed this, and agreed that it should be a 
part of the MOBY Central API.  Martin, keep reminding me, as I have a 
ton of other things consuming my time at the moment so constant pressure 
will be required to get it done in a timely way...

Cheers all!

Mark


Martin Senger wrote:

>>This is a snippet of Marks former mail:
>>
>>Of course, at the moment nobody has a signatureURL   I have set up a
>>simple CGI page for existing service providers where they can supply a
>>URL and get the signature RDF for all of their existing services:
>>
>>http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl
>>
>>    
>>
>   Yes, I know about it. But Mark said that this cgi-bin will be there 
>only temporarily. I had in mind something more permanent (for example if 
>you loose your RDF you should be able to get it back somehow from the 
>registry, without registering it again...). We have discussed this with 
>Mark already and he seems to agree with providing such functionality - I 
>had put it in the list of observations just not to let it slip from my
>(and his :-)) mind...
> 
>   Cheers,
>   Martin
>
>  
>


From markw at illuminae.com  Wed Sep 22 20:11:55 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 22 Sep 2004 17:11:55 -0700
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <415214CB.3010805@illuminae.com>

Martin Senger wrote:

>1) Testing registry seems to have still older version - it still returns 
>RDF with CDATA. It would be good to have it restarted,
>  
>
Done

>2) The service description, as returned in the RDF, lost its CDATA 
>protection. Perhaps it is correct,
>

Um... well, I removed it at your request, so... :-)

> I do not know enough about RDF 
>documents. I have just observed that the 'strange characters', 
>such as '>', that I put into my service description, were returned 
>escaped: the character '>' was escaped as '&amp;gt;' - which does not seem 
>to be correct (but perhaps I am mistaken).
>  
>
AFAIK, anything that is not contained in a CDATA section will be 
escaped.  It is done at the library-level and I have no (?) control over it.

>Anyway, I wonder why to play with escaping at all, why not to keep there 
>CDATA.
>
Because you asked me to remove it, and your reasons were valid :-)  The 
RDF is a valid XML fragment, so there was really no good reason to put 
it in a CDATA section.

> We have CDATA in service description just because we did not want 
>to escape everything there - is that correct?
>  
>
Correct.

>3) I also wonder where are all our LSIDs? There is no single LSID in the 
>whole returned RDF. I thought that we expressed almost everything as LSIDs 
>in biomoby (at least internally).
>  
>
That's a very good point!  I agree with you 110%, and I can implement 
this fairly quickly at at the RDF-production end of things.  At the 
RDF-consumption end, I'll have to talk to Nina about it.  I'm fairly 
sure that we can work it out quickly.  The problem at the moment is that 
LSID resolution in MOBY is completely broken.  The latest version of the 
Perl LSID resolver stack (or at least, the latest the last time I 
looked) is built on top of alpha code libraries, and other libraries 
that are not yet in CPAN.  I was able to get it to compile (with a bit 
of fussing) on my Linux machine, but it throws errors up the ying-yang 
on mobycentral (Solaris).  As such, LSID resolution of MOBY LSID's will 
not be possible until someone has time to write an LSID resolver in 
Java, or the LSID code developers make changes to their stack  :-/   :-(


>4) I use this list to strongly express how I agree with the last Rebecca 
>email about being still able to deregister a service by calling a 
>deregister method even if the service has been registered with the 
>signatureURL.
>
>  
>
Well, I strongly disagree with you :-)   Gosh, THAT has never happened 
before!  ;-)

You have to remember what the driving force was to create the RDF-based 
deregistration!! The problem is that any kid with the ability to read an 
API could have come in and desroyed our registry by deregistering all of 
the services in it with a 5-line Perl script!  Authentication was just a 
pain in the arse and totally impractical, so the only remaining solution 
was to remove that functionality of MOBY Central and move the problem to 
the service providers machine.  I am loathe to move away from that model 
because in the last 18 months nobody has come up with a better solution!!

If a better solution exists, then we can certainly revisit the issue...

>5) Finally, just to make this list complete, I would like to remind the 
>others that there had been a discussion about possibility to get RDF from 
>the registry even for services that had been already registered. I would 
>like to have this feature soon - because it may need an addition tag in 
>the service object, so the sooner we know about it the better.
>
>  
>
Yes, I might actually try to get that done tonight in my room, and 
upload it to mobycentral tomorrow.  I'll let you know.

Cheers!

M

>  
>


From markw at illuminae.com  Wed Sep 22 20:11:55 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 22 Sep 2004 17:11:55 -0700
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <415214CB.3010805@illuminae.com>

Martin Senger wrote:

>1) Testing registry seems to have still older version - it still returns 
>RDF with CDATA. It would be good to have it restarted,
>  
>
Done

>2) The service description, as returned in the RDF, lost its CDATA 
>protection. Perhaps it is correct,
>

Um... well, I removed it at your request, so... :-)

> I do not know enough about RDF 
>documents. I have just observed that the 'strange characters', 
>such as '>', that I put into my service description, were returned 
>escaped: the character '>' was escaped as '&amp;gt;' - which does not seem 
>to be correct (but perhaps I am mistaken).
>  
>
AFAIK, anything that is not contained in a CDATA section will be 
escaped.  It is done at the library-level and I have no (?) control over it.

>Anyway, I wonder why to play with escaping at all, why not to keep there 
>CDATA.
>
Because you asked me to remove it, and your reasons were valid :-)  The 
RDF is a valid XML fragment, so there was really no good reason to put 
it in a CDATA section.

> We have CDATA in service description just because we did not want 
>to escape everything there - is that correct?
>  
>
Correct.

>3) I also wonder where are all our LSIDs? There is no single LSID in the 
>whole returned RDF. I thought that we expressed almost everything as LSIDs 
>in biomoby (at least internally).
>  
>
That's a very good point!  I agree with you 110%, and I can implement 
this fairly quickly at at the RDF-production end of things.  At the 
RDF-consumption end, I'll have to talk to Nina about it.  I'm fairly 
sure that we can work it out quickly.  The problem at the moment is that 
LSID resolution in MOBY is completely broken.  The latest version of the 
Perl LSID resolver stack (or at least, the latest the last time I 
looked) is built on top of alpha code libraries, and other libraries 
that are not yet in CPAN.  I was able to get it to compile (with a bit 
of fussing) on my Linux machine, but it throws errors up the ying-yang 
on mobycentral (Solaris).  As such, LSID resolution of MOBY LSID's will 
not be possible until someone has time to write an LSID resolver in 
Java, or the LSID code developers make changes to their stack  :-/   :-(


>4) I use this list to strongly express how I agree with the last Rebecca 
>email about being still able to deregister a service by calling a 
>deregister method even if the service has been registered with the 
>signatureURL.
>
>  
>
Well, I strongly disagree with you :-)   Gosh, THAT has never happened 
before!  ;-)

You have to remember what the driving force was to create the RDF-based 
deregistration!! The problem is that any kid with the ability to read an 
API could have come in and desroyed our registry by deregistering all of 
the services in it with a 5-line Perl script!  Authentication was just a 
pain in the arse and totally impractical, so the only remaining solution 
was to remove that functionality of MOBY Central and move the problem to 
the service providers machine.  I am loathe to move away from that model 
because in the last 18 months nobody has come up with a better solution!!

If a better solution exists, then we can certainly revisit the issue...

>5) Finally, just to make this list complete, I would like to remind the 
>others that there had been a discussion about possibility to get RDF from 
>the registry even for services that had been already registered. I would 
>like to have this feature soon - because it may need an addition tag in 
>the service object, so the sooner we know about it the better.
>
>  
>
Yes, I might actually try to get that done tonight in my room, and 
upload it to mobycentral tomorrow.  I'll let you know.

Cheers!

M

>  
>


From markw at illuminae.com  Wed Sep 22 20:15:12 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 22 Sep 2004 17:15:12 -0700
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <Pine.LNX.4.44.0409221211580.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221211580.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <41521590.6000505@illuminae.com>


>Is it safe to
>include an empty signatureURL tag, or do I *have* to omit it at all?
>  
>
Yup :-)  That is EXACTLY how it was designed to behave :-)  Just leave 
it out and your service will auto-deregister the next time the agent 
runs.  Alternately, you can manually deregister a service without a 
SignatureURL by using the deregisterService call of the API.

(can you tell I am answering my emails in reverse order? )

M

>  
>


From senger at ebi.ac.uk  Wed Sep 22 20:29:40 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 01:29:40 +0100 (BST)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <415214CB.3010805@illuminae.com>
Message-ID: <Pine.OSF.4.21.0409230122070.824651-100000@ice.ebi.ac.uk>

> >2) The service description, as returned in the RDF, lost its CDATA 
> >protection. Perhaps it is correct,
> >
> 
> Um... well, I removed it at your request, so... :-)
>
   No. I was requesting to have the *whole contents* of the RDF tag
surrounded as CDATA. And I am happy that you removed it. What I am talking
about here is to keep CDATA around service description (which is somewhere
inside the whole RDF tag). So we can keep the service description exactly
the same as it was registered without mangling with escaping.
   Sorry if I have not expressed myself clearly.

> Well, I strongly disagree with you :-)   Gosh, THAT has never happened 
> before!  ;-)
>
   Well, my last email crossed your answer here. I came to the same
conclusion: security. So I do not have now such strong desire to keep the
old deregistration in place. However, the new system is for service
instances only - we still can have kids around removing our data types,
namespaces, service types and providers. So we need anyway to think about
these, too - which may give us some way how to deregister services with
signatureIRL.

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Wed Sep 22 20:29:40 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 01:29:40 +0100 (BST)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <415214CB.3010805@illuminae.com>
Message-ID: <Pine.OSF.4.21.0409230122070.824651-100000@ice.ebi.ac.uk>

> >2) The service description, as returned in the RDF, lost its CDATA 
> >protection. Perhaps it is correct,
> >
> 
> Um... well, I removed it at your request, so... :-)
>
   No. I was requesting to have the *whole contents* of the RDF tag
surrounded as CDATA. And I am happy that you removed it. What I am talking
about here is to keep CDATA around service description (which is somewhere
inside the whole RDF tag). So we can keep the service description exactly
the same as it was registered without mangling with escaping.
   Sorry if I have not expressed myself clearly.

> Well, I strongly disagree with you :-)   Gosh, THAT has never happened 
> before!  ;-)
>
   Well, my last email crossed your answer here. I came to the same
conclusion: security. So I do not have now such strong desire to keep the
old deregistration in place. However, the new system is for service
instances only - we still can have kids around removing our data types,
namespaces, service types and providers. So we need anyway to think about
these, too - which may give us some way how to deregister services with
signatureIRL.

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Wed Sep 22 20:31:51 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 01:31:51 +0100 (BST)
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <41521590.6000505@illuminae.com>
Message-ID: <Pine.OSF.4.21.0409230130160.824651-100000@ice.ebi.ac.uk>

> >Is it safe to
> >include an empty signatureURL tag, or do I *have* to omit it at all?
> >  
> >
> Yup :-)  That is EXACTLY how it was designed to behave :-)  Just leave 
> it out and your service will auto-deregister the next time the agent 
> runs.  Alternately, you can manually deregister a service without a 
> SignatureURL by using the deregisterService call of the API.
> 
   My question was actually different (and Nina already replied to it):

Can I use safely <signatureURL></signatureURL>? Answer is yes, I can.

Thanks, Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From gordonp at cbr.nrc.ca  Wed Sep 22 21:39:35 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Wed, 22 Sep 2004 22:39:35 -0300 (ADT)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.OSF.4.21.0409230122070.824651-100000@ice.ebi.ac.uk>
Message-ID: <Pine.SO4.4.05.10409222228570.17489-100000@cbrmain>


>    No. I was requesting to have the *whole contents* of the RDF tag
> surrounded as CDATA. And I am happy that you removed it. What I am talking
> about here is to keep CDATA around service description (which is somewhere
> inside the whole RDF tag). So we can keep the service description exactly
> the same as it was registered without mangling with escaping.

[Caution: possible flamebait]

If your client application is making a meaningful distinction between
"<!CDATA[[P & G]]>" and "P &amp; G", you're probably either:

1. Not using a conforming XML parser, which is bad.

or 

2. Relying on distinctions between W3C DOM CDATA Section Nodes and
TextNodes, which is officially frowned upon in the W3C DOM specs. 

In either case this would seriously affect the robustness of the code...

My CDN$0.02. :-)



From gordonp at cbr.nrc.ca  Wed Sep 22 21:39:35 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Wed, 22 Sep 2004 22:39:35 -0300 (ADT)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.OSF.4.21.0409230122070.824651-100000@ice.ebi.ac.uk>
Message-ID: <Pine.SO4.4.05.10409222228570.17489-100000@cbrmain>


>    No. I was requesting to have the *whole contents* of the RDF tag
> surrounded as CDATA. And I am happy that you removed it. What I am talking
> about here is to keep CDATA around service description (which is somewhere
> inside the whole RDF tag). So we can keep the service description exactly
> the same as it was registered without mangling with escaping.

[Caution: possible flamebait]

If your client application is making a meaningful distinction between
"<!CDATA[[P & G]]>" and "P &amp; G", you're probably either:

1. Not using a conforming XML parser, which is bad.

or 

2. Relying on distinctions between W3C DOM CDATA Section Nodes and
TextNodes, which is officially frowned upon in the W3C DOM specs. 

In either case this would seriously affect the robustness of the code...

My CDN$0.02. :-)



From senger at ebi.ac.uk  Thu Sep 23 03:37:05 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 08:37:05 +0100 (BST)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.SO4.4.05.10409222228570.17489-100000@cbrmain>
Message-ID: <Pine.LNX.4.44.0409230832440.3215-100000@bagheera.ebi.ac.uk>

> If your client application is making a meaningful distinction between
> "<!CDATA[[P & G]]>" and "P &amp; G"
>
   The situation I was refering to is this: I send to registry (in service
description) "<!CDATA[[P > G]]>" but I get back (in RDF) "P &amp;gt; G" 
which I think is wrong (because somewhere during the processing it was 
obviously escaped twice - first to "P &gt; G" - which is correct - and 
from here to "P &amp;gt; G" - which seems to be incorrect).

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Thu Sep 23 03:37:05 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 08:37:05 +0100 (BST)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.SO4.4.05.10409222228570.17489-100000@cbrmain>
Message-ID: <Pine.LNX.4.44.0409230832440.3215-100000@bagheera.ebi.ac.uk>

> If your client application is making a meaningful distinction between
> "<!CDATA[[P & G]]>" and "P &amp; G"
>
   The situation I was refering to is this: I send to registry (in service
description) "<!CDATA[[P > G]]>" but I get back (in RDF) "P &amp;gt; G" 
which I think is wrong (because somewhere during the processing it was 
obviously escaped twice - first to "P &gt; G" - which is correct - and 
from here to "P &amp;gt; G" - which seems to be incorrect).

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Thu Sep 23 05:06:49 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 10:06:49 +0100 (BST)
Subject: [MOBY-dev] getting RDF from BioMoby
In-Reply-To: <Pine.OSF.4.21.0409230046070.824651-100000@ice.ebi.ac.uk>
Message-ID: <Pine.OSF.4.21.0409230945120.933195-100000@ice.ebi.ac.uk>

Mark,
   Finally, I started to update my graphical tool for displaying moby
objects. I am going to use now the RDF tree that I can get from the
biomoby registry. Because I plan to add this new features (getting RDF
resources) to the main jMoby library - so anyone can get it, I have few
qustions before I dive into it:

   1) I found these URLs:
http://biomoby.org/RESOURCES/MOBY-S/Objects
http://biomoby.org/RESOURCES/MOBY-S/Services
http://biomoby.org/RESOURCES/MOBY-S/Namespaces
http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances

   But I need URLs that can distinguish between various moby registries. I
noticed that the URLs above were actually redirected to URLs:

http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Objects
http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Services
http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Namespaces
http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/ServiceInstances

   These URLs look better for my purpose - because they seem to include an
address of one particular registry. But I am not sure if these
redirections are done in the same way for everybody who has his/her own
registry installed. So the real question is:

   What part of these URLs is the same for everybody (because it is
hard-coded somewhere in your code), and what part should I allow to
customize? E.g. would it be correct to say that access to any registry can
be expressed as:
   http://<your-registry>/RESOURCES/MOBY-S/Objects
   ...
where <your-registry> by default is http://biomoby.org/ (or
http://mobycentral.cbr.nrc.ca/cgi-bin)?

   2) I remember that you also mentioned a URL that gives back everything
in one go (something with 'all' somewhere). Does it exist?

   3) The Perl code mentions also 'Predicates' but when I try it cannot
find it. Is this anything interesting for me? (Btw, if I use a wrong URL,
the one without thye last part, such as
http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/, it makes your
server unhappy :-) .)

   4) And finally, how stable is this, 'undocumented', part of registry's
API? Can I rely on it and include it in the Java libraries? If it is
stable, it would be nice to have it published on the biomoby pages.

   Thanks (and again I wish you nice stay in the Rockies),
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger




From markw at illuminae.com  Thu Sep 23 06:41:34 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Thu, 23 Sep 2004 03:41:34 -0700
Subject: [MOBY-dev] getting RDF from BioMoby
In-Reply-To: <Pine.OSF.4.21.0409230945120.933195-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0409230945120.933195-100000@ice.ebi.ac.uk>
Message-ID: <4152A85E.7030701@illuminae.com>

Hi Martin,

This part of the system (I wouldn't call it part of the API yet :-) ) is 
not at all stable, but once people start using it I will be forced to 
make some hard decisions and make it stable, so... let's keep working 
through these issues :-)

The code is pretty tightly connected to the main public registry, though 
it could be made more generic if necessary.  At the moment it gets its 
Objects, Namespaces, and Services definitions from a very simple and 
fast CGI that outputs tab-delimited text from direct database calls.   
This would have to be changed to be useful to other registries.  
ServiceInstances come from a call to MOBY::Client::Central, so that is 
less of a problem (you can set the URL of your desired registry in the 
constructor for that object).  I could re-write it to use 
MOBY::Client::Central for all of these calls, but it significantly slows 
it down...  As I say, if it is important to make this script more 
generic I can do so quite easily.

The URL you are looking for is:  http://biomoby.org/RESOURCES/MOBY-S/FULL

I haven't written the subroutine that generates the RDF for predicates yet.

Interesting that the server is unhappy if you don't add extra path 
info... it should "die" in that case and send back an error...???

Thanks for your warm thoughts - it's a bit chilly here in the mountains 
:-)  Gorgeous, but chilly...

M


Martin Senger wrote:

>Mark,
>   Finally, I started to update my graphical tool for displaying moby
>objects. I am going to use now the RDF tree that I can get from the
>biomoby registry. Because I plan to add this new features (getting RDF
>resources) to the main jMoby library - so anyone can get it, I have few
>qustions before I dive into it:
>
>   1) I found these URLs:
>http://biomoby.org/RESOURCES/MOBY-S/Objects
>http://biomoby.org/RESOURCES/MOBY-S/Services
>http://biomoby.org/RESOURCES/MOBY-S/Namespaces
>http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances
>
>   But I need URLs that can distinguish between various moby registries. I
>noticed that the URLs above were actually redirected to URLs:
>
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Objects
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Services
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Namespaces
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/ServiceInstances
>
>   These URLs look better for my purpose - because they seem to include an
>address of one particular registry. But I am not sure if these
>redirections are done in the same way for everybody who has his/her own
>registry installed. So the real question is:
>
>   What part of these URLs is the same for everybody (because it is
>hard-coded somewhere in your code), and what part should I allow to
>customize? E.g. would it be correct to say that access to any registry can
>be expressed as:
>   http://<your-registry>/RESOURCES/MOBY-S/Objects
>   ...
>where <your-registry> by default is http://biomoby.org/ (or
>http://mobycentral.cbr.nrc.ca/cgi-bin)?
>
>   2) I remember that you also mentioned a URL that gives back everything
>in one go (something with 'all' somewhere). Does it exist?
>
>   3) The Perl code mentions also 'Predicates' but when I try it cannot
>find it. Is this anything interesting for me? (Btw, if I use a wrong URL,
>the one without thye last part, such as
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/, it makes your
>server unhappy :-) .)
>
>   4) And finally, how stable is this, 'undocumented', part of registry's
>API? Can I rely on it and include it in the Java libraries? If it is
>stable, it would be nice to have it published on the biomoby pages.
>
>   Thanks (and again I wish you nice stay in the Rockies),
>   Martin
>
>  
>


From markw at illuminae.com  Thu Sep 23 06:41:34 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Thu, 23 Sep 2004 03:41:34 -0700
Subject: [MOBY-dev] getting RDF from BioMoby
In-Reply-To: <Pine.OSF.4.21.0409230945120.933195-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0409230945120.933195-100000@ice.ebi.ac.uk>
Message-ID: <4152A85E.7030701@illuminae.com>

Hi Martin,

This part of the system (I wouldn't call it part of the API yet :-) ) is 
not at all stable, but once people start using it I will be forced to 
make some hard decisions and make it stable, so... let's keep working 
through these issues :-)

The code is pretty tightly connected to the main public registry, though 
it could be made more generic if necessary.  At the moment it gets its 
Objects, Namespaces, and Services definitions from a very simple and 
fast CGI that outputs tab-delimited text from direct database calls.   
This would have to be changed to be useful to other registries.  
ServiceInstances come from a call to MOBY::Client::Central, so that is 
less of a problem (you can set the URL of your desired registry in the 
constructor for that object).  I could re-write it to use 
MOBY::Client::Central for all of these calls, but it significantly slows 
it down...  As I say, if it is important to make this script more 
generic I can do so quite easily.

The URL you are looking for is:  http://biomoby.org/RESOURCES/MOBY-S/FULL

I haven't written the subroutine that generates the RDF for predicates yet.

Interesting that the server is unhappy if you don't add extra path 
info... it should "die" in that case and send back an error...???

Thanks for your warm thoughts - it's a bit chilly here in the mountains 
:-)  Gorgeous, but chilly...

M


Martin Senger wrote:

>Mark,
>   Finally, I started to update my graphical tool for displaying moby
>objects. I am going to use now the RDF tree that I can get from the
>biomoby registry. Because I plan to add this new features (getting RDF
>resources) to the main jMoby library - so anyone can get it, I have few
>qustions before I dive into it:
>
>   1) I found these URLs:
>http://biomoby.org/RESOURCES/MOBY-S/Objects
>http://biomoby.org/RESOURCES/MOBY-S/Services
>http://biomoby.org/RESOURCES/MOBY-S/Namespaces
>http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances
>
>   But I need URLs that can distinguish between various moby registries. I
>noticed that the URLs above were actually redirected to URLs:
>
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Objects
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Services
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Namespaces
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/ServiceInstances
>
>   These URLs look better for my purpose - because they seem to include an
>address of one particular registry. But I am not sure if these
>redirections are done in the same way for everybody who has his/her own
>registry installed. So the real question is:
>
>   What part of these URLs is the same for everybody (because it is
>hard-coded somewhere in your code), and what part should I allow to
>customize? E.g. would it be correct to say that access to any registry can
>be expressed as:
>   http://<your-registry>/RESOURCES/MOBY-S/Objects
>   ...
>where <your-registry> by default is http://biomoby.org/ (or
>http://mobycentral.cbr.nrc.ca/cgi-bin)?
>
>   2) I remember that you also mentioned a URL that gives back everything
>in one go (something with 'all' somewhere). Does it exist?
>
>   3) The Perl code mentions also 'Predicates' but when I try it cannot
>find it. Is this anything interesting for me? (Btw, if I use a wrong URL,
>the one without thye last part, such as
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/, it makes your
>server unhappy :-) .)
>
>   4) And finally, how stable is this, 'undocumented', part of registry's
>API? Can I rely on it and include it in the Java libraries? If it is
>stable, it would be nice to have it published on the biomoby pages.
>
>   Thanks (and again I wish you nice stay in the Rockies),
>   Martin
>
>  
>


From senger at ebi.ac.uk  Thu Sep 23 07:13:47 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 12:13:47 +0100 (BST)
Subject: [MOBY-dev] getting RDF from BioMoby
In-Reply-To: <4152A85E.7030701@illuminae.com>
Message-ID: <Pine.LNX.4.44.0409231148070.3265-100000@bagheera.ebi.ac.uk>

Mark,
   Thanks for a fast reply.

> This part of the system (I wouldn't call it part of the API yet :-) ) is 
> not at all stable, but once people start using it I will be forced to 
> make some hard decisions and make it stable, so... let's keep working 
> through these issues :-)
>
   Well, I can start using it if I know that it will not disappear anytime 
:-) Catch-22. Anyway, I am willing to play with it (a ka 'use it') and 
later we will see...

> The code is pretty tightly connected to the main public registry, though 
> it could be made more generic if necessary.
>
   It's okay for now. Thanks for the clarification.

   But I have (two) more questions (with sub-questions): The main reason
for using these calls is that I can get "everything" in one go. So this is
useful for people creating things like 'moby browsers' because they
usually need the whole contents of the registry. Because of that I am
willing to dive into RDF if:

   a) it is the best way how to get "everything" (is it? are there better 
ways? DUMP probably is not the best way)

   b) is there really everything?
   I am new to RDF so I am probably wrong. But, for example, when I have
looked into returned RDF of Objects and found CommentedDNASequence object,
I found all its parents (not in one place, but I found them, even though I
do know why all parents are listed directly under CommentedDNASequence,
except Object that is listed separately under VirtualSequence) referred as
'subClassOf' but I could not find (it may be my mistake by reading the
RDF) that it HASA two strings (sequencestring and description) and an
integer (length). Are these HAS[A] relationship there?

   And the second question: Even though it seem quite obvious from reading 
RDF, it would be nice if you provide (even still unofficial) list how are 
the various attributes mapped into RDF predicates. For example, that 
'<contactMail>' becomes 'cd:creator', or that '<Input>' becomes 
'mobyPred:consumes'.

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Thu Sep 23 07:13:47 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 12:13:47 +0100 (BST)
Subject: [MOBY-dev] getting RDF from BioMoby
In-Reply-To: <4152A85E.7030701@illuminae.com>
Message-ID: <Pine.LNX.4.44.0409231148070.3265-100000@bagheera.ebi.ac.uk>

Mark,
   Thanks for a fast reply.

> This part of the system (I wouldn't call it part of the API yet :-) ) is 
> not at all stable, but once people start using it I will be forced to 
> make some hard decisions and make it stable, so... let's keep working 
> through these issues :-)
>
   Well, I can start using it if I know that it will not disappear anytime 
:-) Catch-22. Anyway, I am willing to play with it (a ka 'use it') and 
later we will see...

> The code is pretty tightly connected to the main public registry, though 
> it could be made more generic if necessary.
>
   It's okay for now. Thanks for the clarification.

   But I have (two) more questions (with sub-questions): The main reason
for using these calls is that I can get "everything" in one go. So this is
useful for people creating things like 'moby browsers' because they
usually need the whole contents of the registry. Because of that I am
willing to dive into RDF if:

   a) it is the best way how to get "everything" (is it? are there better 
ways? DUMP probably is not the best way)

   b) is there really everything?
   I am new to RDF so I am probably wrong. But, for example, when I have
looked into returned RDF of Objects and found CommentedDNASequence object,
I found all its parents (not in one place, but I found them, even though I
do know why all parents are listed directly under CommentedDNASequence,
except Object that is listed separately under VirtualSequence) referred as
'subClassOf' but I could not find (it may be my mistake by reading the
RDF) that it HASA two strings (sequencestring and description) and an
integer (length). Are these HAS[A] relationship there?

   And the second question: Even though it seem quite obvious from reading 
RDF, it would be nice if you provide (even still unofficial) list how are 
the various attributes mapped into RDF predicates. For example, that 
'<contactMail>' becomes 'cd:creator', or that '<Input>' becomes 
'mobyPred:consumes'.

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From fgibbons at hms.harvard.edu  Thu Sep 23 09:41:35 2004
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Thu, 23 Sep 2004 09:41:35 -0400
Subject: [MOBY-dev] Service deregistation *must* be fast: perhaps function
 call could precipitate prompt web agent visit?
In-Reply-To: <200409230013.i8N0DbKr031813@portal.open-bio.org>
Message-ID: <5.2.1.1.2.20040923093202.019ebea8@email.med.harvard.edu>

Martin, Mark,

At 08:13 PM 9/22/2004, you wrote:
> >4) I use this list to strongly express how I agree with the last Rebecca
> >email about being still able to deregister a service by calling a
> >deregister method even if the service has been registered with the
> >signatureURL.
> >
> >
> >
>Well, I strongly disagree with you :-)   Gosh, THAT has never happened
>before!  ;-)
>
>You have to remember what the driving force was to create the RDF-based
>deregistration!! The problem is that any kid with the ability to read an
>API could have come in and desroyed our registry by deregistering all of
>the services in it with a 5-line Perl script!  Authentication was just a
>pain in the arse and totally impractical, so the only remaining solution
>was to remove that functionality of MOBY Central and move the problem to
>the service providers machine.  I am loathe to move away from that model
>because in the last 18 months nobody has come up with a better solution!!
>
>If a better solution exists, then we can certainly revisit the issue...

It seems to me that mostly people want rapid deregistration when they're 
actively developing a service. Once it's all set up, the need disappears. I 
have an idea, I don't know if it would be too much work, or too 
impractical, but here it is anyway....

What if different registries had the ability to set different 
deregistration policies. The 'real' Moby Central could allow dereg only by 
removing the RDF file, but the 'test' registry could allow this too, while 
also allowing dereg requests by API calls. I have absolutely NO idea how 
this might be implemented. But for me, I do my development work in the test 
registry, and only when I'm happy with things do I go ahead and put it up 
in the main registry.

Just a thought. I really must side with Rebecca - how can I debug a service 
if I have to wait days before the screwups I made in registering it are 
fixed by moby central's agent crawling over to my web page? Another idea 
might be that a function call causes the agent to come and look for the RDF 
within a short period of time (two minutes, say), and if it's gone the 
service is deregistered. I'm not advocating that the function call be 
blocking, of course, that would be impractical. It would always return 
quickly, and if there were anything returned, it could only indicate that 
the service had previously been registered, that the request had been 
received, and perhaps some estimate of how long before the agent could come 
by and check. There would be no indication of successful deregistration. 
That would require a separate call (to some other routine - findService?) 
after sufficient time had passed.

-Frank

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From markw at illuminae.com  Thu Sep 23 10:04:05 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Thu, 23 Sep 2004 07:04:05 -0700
Subject: [MOBY-dev] Service deregistation *must* be fast: perhaps function
	call could precipitate prompt web agent visit?
In-Reply-To: <5.2.1.1.2.20040923093202.019ebea8@email.med.harvard.edu>
References: <5.2.1.1.2.20040923093202.019ebea8@email.med.harvard.edu>
Message-ID: <4152D7D5.2000501@illuminae.com>

I have said a few times that if you register a service with no 
SignatureURL it will remain in the registry until the agent removes it.  
This is how you should put temporary test services into the registry.  
Also, if you need to modify it more quickly, no problem - Services 
without a SignatureURL can be deregistered with the API call.

This should cover the scenario you are describing.

M


Frank Gibbons wrote:

> Martin, Mark,
>
> At 08:13 PM 9/22/2004, you wrote:
>
>> >4) I use this list to strongly express how I agree with the last 
>> Rebecca
>> >email about being still able to deregister a service by calling a
>> >deregister method even if the service has been registered with the
>> >signatureURL.
>> >
>> >
>> >
>> Well, I strongly disagree with you :-)   Gosh, THAT has never happened
>> before!  ;-)
>>
>> You have to remember what the driving force was to create the RDF-based
>> deregistration!! The problem is that any kid with the ability to read an
>> API could have come in and desroyed our registry by deregistering all of
>> the services in it with a 5-line Perl script!  Authentication was just a
>> pain in the arse and totally impractical, so the only remaining solution
>> was to remove that functionality of MOBY Central and move the problem to
>> the service providers machine.  I am loathe to move away from that model
>> because in the last 18 months nobody has come up with a better 
>> solution!!
>>
>> If a better solution exists, then we can certainly revisit the issue...
>
>
> It seems to me that mostly people want rapid deregistration when 
> they're actively developing a service. Once it's all set up, the need 
> disappears. I have an idea, I don't know if it would be too much work, 
> or too impractical, but here it is anyway....
>
> What if different registries had the ability to set different 
> deregistration policies. The 'real' Moby Central could allow dereg 
> only by removing the RDF file, but the 'test' registry could allow 
> this too, while also allowing dereg requests by API calls. I have 
> absolutely NO idea how this might be implemented. But for me, I do my 
> development work in the test registry, and only when I'm happy with 
> things do I go ahead and put it up in the main registry.
>
> Just a thought. I really must side with Rebecca - how can I debug a 
> service if I have to wait days before the screwups I made in 
> registering it are fixed by moby central's agent crawling over to my 
> web page? Another idea might be that a function call causes the agent 
> to come and look for the RDF within a short period of time (two 
> minutes, say), and if it's gone the service is deregistered. I'm not 
> advocating that the function call be blocking, of course, that would 
> be impractical. It would always return quickly, and if there were 
> anything returned, it could only indicate that the service had 
> previously been registered, that the request had been received, and 
> perhaps some estimate of how long before the agent could come by and 
> check. There would be no indication of successful deregistration. That 
> would require a separate call (to some other routine - findService?) 
> after sufficient time had passed.
>
> -Frank
>
> PhD, Computational Biologist,
> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 
> 02115, USA.
> Tel: 617-432-3555       Fax: 617-432-3557       
> http://llama.med.harvard.edu/~fgibbons
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


From senger at ebi.ac.uk  Thu Sep 23 10:50:32 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 15:50:32 +0100 (BST)
Subject: [MOBY-dev] about service deregistation once again
In-Reply-To: <4152D7D5.2000501@illuminae.com>
Message-ID: <Pine.OSF.4.21.0409231528350.1073682-100000@mozart.ebi.ac.uk>

I like summaries :-) Here is another (subjective) one:

1) There are three needs for deregistration:

   a) A service is registered intentinally temporarily. This is for time
of testing and debugging. Its deregistration is covered by an empty
signatureURL pretty well. The only missing point here is that I would like
to have evn in this phase a possibility to see the service's RDF. At the
moment it si provided by a temporary cgi-bin script. But there should be
more stable way - and Mark is planning to work on it (AFAIK).

   b) A service is registered fully and its service provider decides to
remove the service (actually not the service but a record about the
service in registry, but that we all understand). Here we have a scenario
with removing service's RDF on the service provider side, and waiting for
the agent. It sounds okay - mainly because it is quite probable that the
service itself is defunc now, so the delay with deregistration does not do
much harm.

   c) A service is registered but needs a change (let's call it a
Rebecca's scenario). Here service provider needs a rapid action - because
without a correct record in registry his/her service cannot be used -
because many general clients takes information about services only from
registry. I think here we need improvements in deregistration because it
is too late to wait for any agent. The initiative here should start from
the service provider.

   What can be done for the case ad c)?
   There are (IMO) two general solutions:

   i) Registry can give something to the registrant (a token) that can be
used for authorized deregistration. This was the intention of the ID in
the registration object. We may revive its usage for this option - but it
still have some security implication (e.g. at themoment the moby database
is open, faik, so the IDs can be found).

   ii) Or, registry takes some action going to the service provider side
to confirm the authenticity of the deregistration request (here we
had/have plan with contact-email, and here fits actually also the agent
scenario). The problem is that we still need a mechanism that can trigger
the registry to take the action. And this is missing.
   So (and here is my main suggestion) why not this: A service provider
will still use a deregisterService call, and the registry - when it sees
that the service has a signatureURL, sends agent *now* to this side. Of
course, the service provider must make sure that the RDF is either
updated, or missing (in which case he/she will register again).

   What do you think about this?

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From rebecca.ernst at gsf.de  Fri Sep 24 03:22:15 2004
From: rebecca.ernst at gsf.de (Rebecca Ernst)
Date: Fri, 24 Sep 2004 09:22:15 +0200
Subject: [MOBY-dev] about service deregistation once again
In-Reply-To: <Pine.OSF.4.21.0409231528350.1073682-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0409231528350.1073682-100000@mozart.ebi.ac.uk>
Message-ID: <4153CB27.6000208@gsf.de>

Hi Martin, (Mark, Frank, etc.)!

This was a useful summary! Obviously Mark had the one scenario in mind 
(a) and Frank and I had another one in mind (c).
I quite like the idea of asking the agent for a visit. This would 
completely solve my problem.
Mark, would this be possible? Easy to implement?

Cheers,
Rebecca



Martin Senger wrote:

>I like summaries :-) Here is another (subjective) one:
>
>1) There are three needs for deregistration:
>
>   a) A service is registered intentinally temporarily. This is for time
>of testing and debugging. Its deregistration is covered by an empty
>signatureURL pretty well. The only missing point here is that I would like
>to have evn in this phase a possibility to see the service's RDF. At the
>moment it si provided by a temporary cgi-bin script. But there should be
>more stable way - and Mark is planning to work on it (AFAIK).
>
>   b) A service is registered fully and its service provider decides to
>remove the service (actually not the service but a record about the
>service in registry, but that we all understand). Here we have a scenario
>with removing service's RDF on the service provider side, and waiting for
>the agent. It sounds okay - mainly because it is quite probable that the
>service itself is defunc now, so the delay with deregistration does not do
>much harm.
>
>   c) A service is registered but needs a change (let's call it a
>Rebecca's scenario). Here service provider needs a rapid action - because
>without a correct record in registry his/her service cannot be used -
>because many general clients takes information about services only from
>registry. I think here we need improvements in deregistration because it
>is too late to wait for any agent. The initiative here should start from
>the service provider.
>
>   What can be done for the case ad c)?
>   There are (IMO) two general solutions:
>
>   i) Registry can give something to the registrant (a token) that can be
>used for authorized deregistration. This was the intention of the ID in
>the registration object. We may revive its usage for this option - but it
>still have some security implication (e.g. at themoment the moby database
>is open, faik, so the IDs can be found).
>
>   ii) Or, registry takes some action going to the service provider side
>to confirm the authenticity of the deregistration request (here we
>had/have plan with contact-email, and here fits actually also the agent
>scenario). The problem is that we still need a mechanism that can trigger
>the registry to take the action. And this is missing.
>   So (and here is my main suggestion) why not this: A service provider
>will still use a deregisterService call, and the registry - when it sees
>that the service has a signatureURL, sends agent *now* to this side. Of
>course, the service provider must make sure that the RDF is either
>updated, or missing (in which case he/she will register again).
>
>   What do you think about this?
>
>   Martin
>
>  
>

-- 
Rebecca Ernst
MIPS, Inst. for Bioinformatics
GSF Research Center for Environment and Health
Ingolstaedter Landstr. 1
85764 Neuherberg
fon: +49 89 3187 3583
email: Rebecca.Ernst at gsf.de



From senger at ebi.ac.uk  Fri Sep 24 07:10:37 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 24 Sep 2004 12:10:37 +0100 (BST)
Subject: [MOBY-dev] Re: about service deregistation once again (a bug?)
In-Reply-To: <Pine.OSF.4.21.0409231528350.1073682-100000@mozart.ebi.ac.uk>
Message-ID: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>

One more observation - I suppose that there is a bug:

Nina explained that the agent would not go to a service that had been
registered without signatureURL, neither to a service that had been
registered with an empty signatureURL tag (such as
<signatureURL></signatureURL>).

However, the old-fashioned deregistration call will be rejected for
services that had been registered with an empty signatureURL, telling you
that the agent would take care about it. Which would not - see paragraph
above.

So, there are unregisterable services... (fortunately, there are many of 
them now, but only in the testing registry :-))

Cheers,
Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From markw at illuminae.com  Fri Sep 24 09:24:00 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 24 Sep 2004 06:24:00 -0700
Subject: [MOBY-dev] about service deregistation once again
In-Reply-To: <4153CB27.6000208@gsf.de>
References: <Pine.OSF.4.21.0409231528350.1073682-100000@mozart.ebi.ac.uk>
	<4153CB27.6000208@gsf.de>
Message-ID: <41541FF0.2090701@illuminae.com>

Nina and I are working on it right now :-)  Should be done by next week,

M

Rebecca Ernst wrote:

> Hi Martin, (Mark, Frank, etc.)!
>
> This was a useful summary! Obviously Mark had the one scenario in mind 
> (a) and Frank and I had another one in mind (c).
> I quite like the idea of asking the agent for a visit. This would 
> completely solve my problem.
> Mark, would this be possible? Easy to implement?
>
> Cheers,
> Rebecca
>
>
>
> Martin Senger wrote:
>
>> I like summaries :-) Here is another (subjective) one:
>>
>> 1) There are three needs for deregistration:
>>
>>   a) A service is registered intentinally temporarily. This is for time
>> of testing and debugging. Its deregistration is covered by an empty
>> signatureURL pretty well. The only missing point here is that I would 
>> like
>> to have evn in this phase a possibility to see the service's RDF. At the
>> moment it si provided by a temporary cgi-bin script. But there should be
>> more stable way - and Mark is planning to work on it (AFAIK).
>>
>>   b) A service is registered fully and its service provider decides to
>> remove the service (actually not the service but a record about the
>> service in registry, but that we all understand). Here we have a 
>> scenario
>> with removing service's RDF on the service provider side, and waiting 
>> for
>> the agent. It sounds okay - mainly because it is quite probable that the
>> service itself is defunc now, so the delay with deregistration does 
>> not do
>> much harm.
>>
>>   c) A service is registered but needs a change (let's call it a
>> Rebecca's scenario). Here service provider needs a rapid action - 
>> because
>> without a correct record in registry his/her service cannot be used -
>> because many general clients takes information about services only from
>> registry. I think here we need improvements in deregistration because it
>> is too late to wait for any agent. The initiative here should start from
>> the service provider.
>>
>>   What can be done for the case ad c)?
>>   There are (IMO) two general solutions:
>>
>>   i) Registry can give something to the registrant (a token) that can be
>> used for authorized deregistration. This was the intention of the ID in
>> the registration object. We may revive its usage for this option - 
>> but it
>> still have some security implication (e.g. at themoment the moby 
>> database
>> is open, faik, so the IDs can be found).
>>
>>   ii) Or, registry takes some action going to the service provider side
>> to confirm the authenticity of the deregistration request (here we
>> had/have plan with contact-email, and here fits actually also the agent
>> scenario). The problem is that we still need a mechanism that can 
>> trigger
>> the registry to take the action. And this is missing.
>>   So (and here is my main suggestion) why not this: A service provider
>> will still use a deregisterService call, and the registry - when it sees
>> that the service has a signatureURL, sends agent *now* to this side. Of
>> course, the service provider must make sure that the RDF is either
>> updated, or missing (in which case he/she will register again).
>>
>>   What do you think about this?
>>
>>   Martin
>>
>>  
>>
>


From markw at illuminae.com  Fri Sep 24 09:26:49 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 24 Sep 2004 06:26:49 -0700
Subject: [MOBY-dev] Re: about service deregistation once again (a bug?)
In-Reply-To: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>
Message-ID: <41542099.60700@illuminae.com>

Martin Senger wrote:

>Nina explained that the agent would not go to a service that had been
>registered without signatureURL, neither to a service that had been
>registered with an empty signatureURL tag (such as
><signatureURL></signatureURL>).
>  
>
Aren't these two statements identical?

>However, the old-fashioned deregistration call will be rejected for
>services that had been registered with an empty signatureURL, telling you
>that the agent would take care about it. Which would not - see paragraph
>above.
>  
>
Unless it is not functioning correctly, the old fashioned deregisration 
call WILL NOT be rejected for services that have been registered with an 
empty signature URL.  Is that the bug you are reporting?

M



From edward.kawas at gmail.com  Fri Sep 24 11:20:17 2004
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Fri, 24 Sep 2004 08:20:17 -0700
Subject: [MOBY-dev] Question about authorities
In-Reply-To: <41542099.60700@illuminae.com>
References: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>
	<41542099.60700@illuminae.com>
Message-ID: <b4bcf7b1040924082063363be6@mail.gmail.com>

I have a quick question on the authorities (URI) part of registering
objects, services, etc.

URI is a domain, e.g. www.illuminae.com
would the following work?

illuminae.com  or  mobycentral.cbr.nrc.ca ?

Thanks,

Eddie


From markw at illuminae.com  Fri Sep 24 11:22:47 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 24 Sep 2004 08:22:47 -0700
Subject: [MOBY-dev] Question about authorities
In-Reply-To: <b4bcf7b1040924082063363be6@mail.gmail.com>
References: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>	<41542099.60700@illuminae.com>
	<b4bcf7b1040924082063363be6@mail.gmail.com>
Message-ID: <41543BC7.1080202@illuminae.com>

yes


Eddie Kawas wrote:

>I have a quick question on the authorities (URI) part of registering
>objects, services, etc.
>
>URI is a domain, e.g. www.illuminae.com
>would the following work?
>
>illuminae.com  or  mobycentral.cbr.nrc.ca ?
>
>Thanks,
>
>Eddie
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>  
>


From markw at illuminae.com  Fri Sep 24 11:23:29 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 24 Sep 2004 08:23:29 -0700
Subject: [MOBY-dev] Question about authorities
In-Reply-To: <b4bcf7b1040924082063363be6@mail.gmail.com>
References: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>	<41542099.60700@illuminae.com>
	<b4bcf7b1040924082063363be6@mail.gmail.com>
Message-ID: <41543BF1.8030501@illuminae.com>

IMO it is *preferable* to have the domain without the "www" prefix, but 
that's just me.

M

Eddie Kawas wrote:

>I have a quick question on the authorities (URI) part of registering
>objects, services, etc.
>
>URI is a domain, e.g. www.illuminae.com
>would the following work?
>
>illuminae.com  or  mobycentral.cbr.nrc.ca ?
>
>Thanks,
>
>Eddie
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>  
>


From gss at ncgr.org  Fri Sep 24 11:44:35 2004
From: gss at ncgr.org (Gary Schiltz)
Date: Fri, 24 Sep 2004 09:44:35 -0600
Subject: [MOBY-dev] MOBY Meeting: 20-21 November in Santa Fe
Message-ID: <415440E3.2070000@ncgr.org>

Hello MOBY'ers!

The next MOBY meeting will be held at NCGR (www.ncgr.org) in Santa Fe, 
New Mexico, the weekend of 20-21 November, 2004. We'll finish by about 
3:00 MST on Sunday, so you could catch a flight as early as about 5:30. 
Also, Mark Wilkinson will be giving a talk on MOBY Services at NCGR on 
November 19 (some time in the afternoon, I believe); everyone is welcome 
to attend, so consider coming a day early. I'll soon put together a page 
of information with an agenda, links to accommodations covering a range 
of prices, and other details. There will be a small registration fee to 
cover breakfast and lunch for Saturday and Sunday.

In the interim, please post suggestions for topics to cover at the meeting.

----

Gary Schiltz
Principal Software Engineer
National Center for Genome Resources
Santa Fe, New Mexico

gss at ncgr.org
505-995-4414 (Work)
505-670-5983 (Cell)


From senger at ebi.ac.uk  Fri Sep 24 15:26:57 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 24 Sep 2004 20:26:57 +0100 (BST)
Subject: [MOBY-dev] Re: about service deregistation once again (a bug?)
In-Reply-To: <41542099.60700@illuminae.com>
Message-ID: <Pine.OSF.4.21.0409241507580.528084-100000@ice.ebi.ac.uk>

> >Nina explained that the agent would not go to a service that had been
> >registered without signatureURL, neither to a service that had been
> >registered with an empty signatureURL tag (such as
> ><signatureURL></signatureURL>).
> >  
> >
> Aren't these two statements identical?
>
   C'mon, of course, they are not.
   I can send a registration without any signatureURL tag, at all, or I
can send it with <signatureURL></signatureURL>.
   However, it does not matter anymore, see below...
 
> >However, the old-fashioned deregistration call will be rejected for
> >services that had been registered with an empty signatureURL, telling you
> >that the agent would take care about it. Which would not - see paragraph
> >above.
> >  
> >
> Unless it is not functioning correctly, the old fashioned deregisration 
> call WILL NOT be rejected for services that have been registered with an 
> empty signature URL.  Is that the bug you are reporting?
>
   Yes, it was... But not anymore... the bug was in my code that had not
properly printed signatureURL (so I thought that it was not there). Sorry
for that, it happens (at least one good output from this email exchange is
that I found that signatureURL was missing in the documentation of the
Service List Response Object - could you add it there?).

   Cheers,
   Martin

PS. I wonder if you got my email asking about RDF output...? (Perhaps it
was missed under the peaks of Rockies :-))
M.

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger




From markw at illuminae.com  Sat Sep 25 14:59:28 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Sat, 25 Sep 2004 11:59:28 -0700
Subject: [MOBY-dev] Re: about service deregistation once again (a bug?)
In-Reply-To: <Pine.OSF.4.21.0409241507580.528084-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0409241507580.528084-100000@ice.ebi.ac.uk>
Message-ID: <4155C010.8000100@illuminae.com>



>>Aren't these two statements identical?
>>    
>>
>   C'mon, of course, they are not.
>   I can send a registration without any signatureURL tag, at all, or I
>can send it with <signatureURL></signatureURL>.
>  
>
I think the two cases are treated identically by MOBY Central.


>   Yes, it was... But not anymore... the bug was in my code that had not
>properly printed signatureURL (so I thought that it was not there).
>

Cool!

>that I found that signatureURL was missing in the documentation of the
>Service List Response Object - could you add it there?).
>  
>
Yup.  I'll do that when I get back. (remind me if I forget...)

>PS. I wonder if you got my email asking about RDF output...? (Perhaps it
>was missed under the peaks of Rockies :-))
>  
>
I'll look back through my messages.  I am having trouble understanding 
messages this week due to the thin mountain air ;-)

M


>M.
>
>  
>


From markw at illuminae.com  Sat Sep 25 15:04:13 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Sat, 25 Sep 2004 12:04:13 -0700
Subject: [MOBY-dev] Re: about service deregistation once again (a bug?)
In-Reply-To: <Pine.OSF.4.21.0409241507580.528084-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0409241507580.528084-100000@ice.ebi.ac.uk>
Message-ID: <4155C12D.6020305@illuminae.com>

b.t.w. Martin, I gave a Taverna demo today at the SAB meeting.  There is 
general agreement among the bioinformatics platform members (Genome 
Canada) that we should adopt Taverna as our recommended MOBY/Emboss 
client :-)  Yay!

M


Martin Senger wrote:

>>>Nina explained that the agent would not go to a service that had been
>>>registered without signatureURL, neither to a service that had been
>>>registered with an empty signatureURL tag (such as
>>><signatureURL></signatureURL>).
>>> 
>>>
>>>      
>>>
>>Aren't these two statements identical?
>>
>>    
>>
>   C'mon, of course, they are not.
>   I can send a registration without any signatureURL tag, at all, or I
>can send it with <signatureURL></signatureURL>.
>   However, it does not matter anymore, see below...
> 
>  
>
>>>However, the old-fashioned deregistration call will be rejected for
>>>services that had been registered with an empty signatureURL, telling you
>>>that the agent would take care about it. Which would not - see paragraph
>>>above.
>>> 
>>>
>>>      
>>>
>>Unless it is not functioning correctly, the old fashioned deregisration 
>>call WILL NOT be rejected for services that have been registered with an 
>>empty signature URL.  Is that the bug you are reporting?
>>
>>    
>>
>   Yes, it was... But not anymore... the bug was in my code that had not
>properly printed signatureURL (so I thought that it was not there). Sorry
>for that, it happens (at least one good output from this email exchange is
>that I found that signatureURL was missing in the documentation of the
>Service List Response Object - could you add it there?).
>
>   Cheers,
>   Martin
>
>PS. I wonder if you got my email asking about RDF output...? (Perhaps it
>was missed under the peaks of Rockies :-))
>M.
>
>  
>


From jmfernandez at cnb.uam.es  Wed Sep  1 19:00:02 2004
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Wed, 01 Sep 2004 21:00:02 +0200
Subject: [MOBY-dev] Problems testing a newly created MOBY Central (+ Fix)
Message-ID: <41361C32.1020405@cnb.uam.es>

Hi everybody,
	soon I'm going to give a practical seminar about MOBY, and I'm creating 
a local MOBY Central for the practices. This is not my first time 
creating a MOBY Central (I created one 9 months ago), but last version 
in CVS seems to have problems.

	First of all, intructions in

http://www.biomoby.org/InstallingMOBYCentral.html

should be updated, because last RDF changes in MOBY require RDF::Core 
Perl library as a pre-requisite before running a MOBY Central (and 
perhaps a the other libraries??).

	The problem I have found is the next: I ran the 
testMOBYClientCentral_v05.pl script in order to check if the 
installation was correct. First try failed in the first test due the 
lack of RDF::Core. The second try (after installing RDF::Core) seemed to 
run well until it failed in the 18th one, which corresponds to 
registerService. Next lines are from the Apache error log:

[Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] Useless use of 
hash element in void context at 
/usr/lib/perl5/site_perl/5.8.3/RDF/Core/Serializer.pm line 52.
[Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] DBD::mysql::db 
selectrow_array failed: Unknown column 'signatureURL' in 'field list' at 
/usr/lib/perl5/site_perl/5.8.3/MOBY/Adaptor/moby/queryapi/mysql.pm line 
172, <IN> line 34

	I have dug inside the referenced file told by the error message, and it 
is a query to the tables service_instance and authority from mobycentral 
database. It seems the signatureURL column should exist in 
service_instance table, and so moby database skeletons in CVS should be 
updated.
	
	What data type should have that column, Mark? I have created it as a 
VARCHAR(255), and now it works.

	Last, moby database skeletons (ie mysql dumps) in CVS should also be 
updated in order to reflect the last small change Mark told us about the 
datatype of maximum_value and minimum_value.

	Best Regards,
		Jos? Mar?a

-- 
Jos? Mar?a Fern?ndez Gonz?lez		e-mail: jmfernandez at cnb.uam.es
Tlfn:	(+34) 91 585 46 69		Fax:	(+34) 91 585 45 06
Grupo de Dise?o de Proteinas		Protein Design Group
Centro Nacional de Biotecnolog?a	National Center of Biotechnology
C.P.: 28049				Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)


From mwilkinson at mrl.ubc.ca  Wed Sep  1 19:30:30 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 01 Sep 2004 12:30:30 -0700
Subject: [MOBY-dev] Re: [MISC] [MOBY-l] Problems testing a newly created
	MOBY Central (+ Fix)
In-Reply-To: <41361C32.1020405@cnb.uam.es>
References: <41361C32.1020405@cnb.uam.es>
Message-ID: <1094067029.17672.55.camel@myhost.mydomain>

Sorry, I am hoping to get all of the documentation updated as quickly as
possible, but grant deadlines are getting in the way...

The change to the database structure was (I think) announced on the
mailing list.  You can also get it by calling the 'DUMP' method of
MOBY::Central (or via the client), or you can examine the database
directly by logging in to a mysql session with the username
moby_external (no password)

here's the table definition for service_instance:

+---------------------+----------------------------------+------+-----+---------+----------------+
| Field               | Type                             | Null | Key |
Default | Extra          |
+---------------------+----------------------------------+------+-----+---------+----------------+
| category            | enum('moby','soap','wsdl','cgi') | YES  |     |
NULL    |                |
| servicename         | varchar(255)                     |      | MUL
|         |                |
| service_type_uri    | varchar(255)                     |      |    
|         |                |
| authority_id        | int(10) unsigned                 |      |     |
0       |                |
| url                 | varchar(255)                     |      |    
|         |                |
| contact_email       | varchar(255)                     |      |    
|         |                |
| authoritative       | enum('1','0')                    |      |     |
0       |                |
| description         | text                             |      |    
|         |                |
| service_instance_id | int(10) unsigned                 |      | PRI |
NULL    | auto_increment |
| signatureURL        | varchar(255)                     | YES  |     |
NULL    |                |
+---------------------+----------------------------------+------+-----+---------+----------------+


M


On Wed, 2004-09-01 at 12:00, Jos? Mar?a Fern?ndez Gonz?lez wrote:
> Hi everybody,
> 	soon I'm going to give a practical seminar about MOBY, and I'm creating 
> a local MOBY Central for the practices. This is not my first time 
> creating a MOBY Central (I created one 9 months ago), but last version 
> in CVS seems to have problems.
> 
> 	First of all, intructions in
> 
> http://www.biomoby.org/InstallingMOBYCentral.html
> 
> should be updated, because last RDF changes in MOBY require RDF::Core 
> Perl library as a pre-requisite before running a MOBY Central (and 
> perhaps a the other libraries??).
> 
> 	The problem I have found is the next: I ran the 
> testMOBYClientCentral_v05.pl script in order to check if the 
> installation was correct. First try failed in the first test due the 
> lack of RDF::Core. The second try (after installing RDF::Core) seemed to 
> run well until it failed in the 18th one, which corresponds to 
> registerService. Next lines are from the Apache error log:
> 
> [Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] Useless use of 
> hash element in void context at 
> /usr/lib/perl5/site_perl/5.8.3/RDF/Core/Serializer.pm line 52.
> [Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] DBD::mysql::db 
> selectrow_array failed: Unknown column 'signatureURL' in 'field list' at 
> /usr/lib/perl5/site_perl/5.8.3/MOBY/Adaptor/moby/queryapi/mysql.pm line 
> 172, <IN> line 34
> 
> 	I have dug inside the referenced file told by the error message, and it 
> is a query to the tables service_instance and authority from mobycentral 
> database. It seems the signatureURL column should exist in 
> service_instance table, and so moby database skeletons in CVS should be 
> updated.
> 	
> 	What data type should have that column, Mark? I have created it as a 
> VARCHAR(255), and now it works.
> 
> 	Last, moby database skeletons (ie mysql dumps) in CVS should also be 
> updated in order to reflect the last small change Mark told us about the 
> datatype of maximum_value and minimum_value.
> 
> 	Best Regards,
> 		Jos? Mar?a
-- 
Mark Wilkinson (mwilkinson at mrl.ubc.ca)
University of British Columbia iCAPTURE Centre



From mwilkinson at mrl.ubc.ca  Wed Sep 15 15:58:07 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 15 Sep 2004 08:58:07 -0700
Subject: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
Message-ID: <1095263887.5954.78.camel@myhost.mydomain>

Hi all, 

we are getting ready to make a very significant change in MOBY-S, so I
need **all existing service providers** to do a one-time exercise.  This
is also important for those who have their own MOBY Central
installations.

As we discussed at the last MOBY meeting, it is desirable and 'good' for
MOBY Central's registry to extract its information using a mechanism
more like a web crawler (more like S-MOBY :-) ).  As a result, Nina has
written an agent that will crawl known MOBY service providers and
extract their service signatures from RDF files.  The agent runs on a
cron, and behaves as follows:

1)  It looks up the last known address of your service signature in the
database
2)  It GET's that address expecting to find an RDF file
3)  If it doesn't find a valid RDF file there, then it flags an error;
after a certain number of errors your service(s) will be deregistered. 
(I believe that it also emails the contactEmail address and tells them
that there was an error.)
4)  If it finds an RDF, it compares the signatures of each service
described in that RDF with the database, and updates or adds these
service descriptions as necessary.
5)  If it expects to find a service signature in this RDF, and can't
find it, it concludes that the service has been taken off-line, and it
will de-register that service.
6)  The agent should be (touch wood!) tolerant of additional RDF in this
signature, such that you can add your own additional annotations to this
RDF as you wish.


The behaviour of MOBY Central is as follows:

1)  When you register a service, you may include a SignatureURL field in
your XML (or as a parameter to the MOBY::Client::Central API) indicating
where your RDF will be located.
2)  Upon successful registration of your service, MOBY Central will send
you the RDF signature of your service - you will not have to generate
this yourself!  (unless you want to... and feel free to do so!).  It
appears in the <RDF> block of the MOBY Registration object (the ->RDF
method of the MOBY:Registration object)
3)  To ensure that your service is not deleted, you must place this RDF
signature in the location that you specified in the signatureURL field
when you registered your service.
4)  If you do not include a signatureURL in your service registration,
your service will be de-registered the next time the agent runs (since
it will be unable to find an RDF file matching your service).  This
might be useful for people who are doing simple test services, as they
wont clutter up the registry for long...
4)  The deregisterService method of the MOBY Central API will **NOT**
function for any service that has a signatureURL.  It will function as
expected for any service does not have a signatureURL.


So, in short, services now have a signatureURL that points to an RDF
file describing their service.  An agent will crawl around on a regular
basis looking at these RDF signatures.  If you update a service, you
change the RDF.  if you remove a service, you delete that portion of the
RDF.  If you add a service, you either add a new signature to the RDF
and let the agent register it automatically, or you use the
registerService function of MOBY Central as you have in the past, and
allow MOBY Central to generate the RDF for you.  Services without a
signatureURL WILL BE DELETED!!!!

Of course, at the moment nobody has a signatureURL :-)  I have set up a
simple CGI page for existing service providers where they can supply a
URL and get the signature RDF for all of their existing services:

http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl


We will switch the agent on in a week or so, and after that all services
without a signatureURL will be deleted, so please go to this page ASAP. 

If the script doesn't work, or if you have any problems please let me
know and I or Nina will fix them immediately.

I hope this isn't too disruptive to people.  I'm convinced that it is a
change for the better!  Contact me by phone or email if you have any
concerns.

Cheers all!

M
-- 
Mark Wilkinson, 
Assistant Professor (Bioinformatics)
Dept. of Medical Genetics, 
University of British Columbia
James Hogg iCAPTURE Centre for Cardiovascular and Pulmonary Research
166 - 1081 Burrard St.
Vancouver, BC, Canada, V6Z 1Y6

tel: (604) 682 2344 ext. 62129
fax: (604) 806 9274
 
------------------------------------------------------------------------
The death rate in Canada currently stands at one per person.  Here
at iCAPTURE, we are working hard to improve on that figure!
------------------------------------------------------------------------


From senger at ebi.ac.uk  Wed Sep 15 20:20:57 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 15 Sep 2004 21:20:57 +0100 (BST)
Subject: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain>
Message-ID: <Pine.OSF.4.21.0409152119021.1471296-100000@mozart.ebi.ac.uk>

Mark,
   I wonder why the RDF part in the registration object is marked as
CDATA. Because RDF must be anyway a valid XML why to bother to surround it
by CDATA. Having CDATA there would prevent me to have CDATA in RDF. Is
there any reason you use CDATA for the RDF part?

   Thanks,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Thu Sep 16 14:04:35 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 16 Sep 2004 15:04:35 +0100 (BST)
Subject: [MOBY-dev] Java developers, let's talk together
In-Reply-To: <1094067029.17672.55.camel@myhost.mydomain>
Message-ID: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>

Hi, all,
    We all know that OpenSource is a wonderful idea, and we like it. But 
sometimes the end users (in our case those who are going to use our Java 
libraries) may be confused if there are too many styles involved. I am not 
talking about the coding style - that's usually hidden and as long as it 
does what it says it does, who cares - but about the style how our code is 
deployed and used. I think that our code may provide better service if we 
can follow - when and where possible - similar principles.
   Can we, therefore, have here a chat about these principles? I do not 
want to be seen as an intruder and a dictator (even though I am both), and 
the things I am going to list here (below) are just issues for comments, 
nothing more.
   Also, I am talking about things that are part of the moby-live CVS, not
about code provided by individual service provider - unless this code is
also part of this CVS. Also, I concentrate only on MOBY-S - but it would 
be nice to apply similar principles for both MOBYs - so, Gary, please your 
comments are also valuable.

   1) Package names. It does not matter where the Java code is in the CVS
module (because one can partition things either by language, or by topic,
and both approaches can be mixed) but it would be nice if the Java package
names reflected what the code deals with. I started with names (I hope 
with obvious meanings - if not I am ready to explain):
   org.biomoby.client
   org.biomoby.shared
   org.biomoby.registry
   org.biomoby.service

   Others started their own package names:
   ca.icapture.moby
      Does this mean that the code is owned by somebody else? BTW, there
is no source for this package in the current CVS (just binaries). I
strongly feel that the biomoby CVS should have source code for everything
unless it is clearly labelledf as third-party library. Is this such case? 
   org.mobycentral...
      I think that this actually belongs more to org.biomoby.client - 
because it does not implement mobycentral funtionality (in which case I 
would recommend to use org.biomoby.registry, or org.biomoby.central...) 
but it implements new ways how to access the registry. But I am not sure.

   2) Building. What about to use Ant? :-) At the moment, some subprojects
does not support much re-building by other users. Such support should be a
primary rule for an open source project. Or am I too autocrative here?

   3) Third-party libraries (the ones we have only as jar files).
   There is no single solution. We may have them as part of the CVS, or 
let Ant download them when a user is re-building.
   If we have them as part of moby-live CVS:
   - it is always sure that after 'cvs co' you have everything and in 
correct version
   - the CVS can be huge (as it is now) and many users will use just a 
small sub-part (like perl users) but they still need to check-out 
everything.
   Almost opposite arguments apply for not to have them here. Open 
question...
   But I feel that having the same third-party libraries in several places 
within the same project (Ed?) does sound good.

   4) Generated documentation. I think that Java API that is generated 
from Java code should not be part of the CVS. It is anyway a paint in the 
neck to keep it sync with the CVS. The build procedures (Ant, hopefully) 
should be able to generate it for each user when [s]he is re-building.

   4) Documentation. I hope to have one BioMoby Java starting page from
where Java users can go to all Java-based subprojects. I will update the
current jMoby pages (if you do not mind) - but could you send me the text
you would like to be added at the starting page and pointing to 
yoursub-project please?

   With kindest regards,
   Martin   

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger






From gordonp at cbr.nrc.ca  Thu Sep 16 14:37:47 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Thu, 16 Sep 2004 08:37:47 -0600
Subject: [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
Message-ID: <4149A53B.4050804@cbr.nrc.ca>

Hey Martin,

>   1) Package names. It does not matter where the Java code is in the CVS
>module (because one can partition things either by language, or by topic,
>and both approaches can be mixed) but it would be nice if the Java package
>names reflected what the code deals with. I started with names (I hope 
>with obvious meanings - if not I am ready to explain):
>   org.biomoby.client
>   org.biomoby.shared
>   org.biomoby.registry
>   org.biomoby.service
>  
>
I agree, we should probably fit the other classes into this hierarchy 
for core classes,
and at least into a contrib folder if it's not core.

>   2) Building. What about to use Ant? :-) At the moment, some subprojects
>does not support much re-building by other users. Such support should be a
>primary rule for an open source project. Or am I too autocrative here?
>  
>
Yeah, we use Ant here too, it's a godsend.  Are there any subprojects that
require fancy compilation, or can we just use a generic task?

>   3) Third-party libraries (the ones we have only as jar files).
>   There is no single solution. We may have them as part of the CVS, or 
>let Ant download them when a user is re-building.
>   If we have them as part of moby-live CVS:
>   - it is always sure that after 'cvs co' you have everything and in 
>correct version
>   - the CVS can be huge (as it is now) and many users will use just a 
>small sub-part (like perl users) but they still need to check-out 
>everything.
>   Almost opposite arguments apply for not to have them here. Open 
>question...
>   But I feel that having the same third-party libraries in several places 
>within the same project (Ed?) does sound good.
>  
>
I'm thinking that 95% of users checkout the whole Java archive when they 
fetch
the code.  Also, they usually won't dig deep enough to figure out 
exactly what parts
of the code they are using require what third-party libraries (and hence 
would have
to include all the jars when they wrap up their own MOBY apps).  Then 
you get the
issue of classpaths, and possible conflicts if two sub projects use 
different versions of
the  third party programs. I'm for a libs directory where all the .jars 
are stored, and
probably a README that says which parts of the code use which jars.

>   4) Generated documentation. I think that Java API that is generated 
>from Java code should not be part of the CVS. It is anyway a paint in the 
>neck to keep it sync with the CVS. The build procedures (Ant, hopefully) 
>should be able to generate it for each user when [s]he is re-building.
>  
>
I agree.

>   4) Documentation. I hope to have one BioMoby Java starting page from
>where Java users can go to all Java-based subprojects. I will update the
>current jMoby pages (if you do not mind) - but could you send me the text
>you would like to be added at the starting page and pointing to 
>yoursub-project please?
>  
>
I've got nothing so far, but would like to contrbute a page on MOBY 
object instance creation...

>   With kindest regards,
>   Martin   
>
>  
>



From gordonp at cbr.nrc.ca  Thu Sep 16 14:37:47 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Thu, 16 Sep 2004 08:37:47 -0600
Subject: [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
Message-ID: <4149A53B.4050804@cbr.nrc.ca>

Hey Martin,

>   1) Package names. It does not matter where the Java code is in the CVS
>module (because one can partition things either by language, or by topic,
>and both approaches can be mixed) but it would be nice if the Java package
>names reflected what the code deals with. I started with names (I hope 
>with obvious meanings - if not I am ready to explain):
>   org.biomoby.client
>   org.biomoby.shared
>   org.biomoby.registry
>   org.biomoby.service
>  
>
I agree, we should probably fit the other classes into this hierarchy 
for core classes,
and at least into a contrib folder if it's not core.

>   2) Building. What about to use Ant? :-) At the moment, some subprojects
>does not support much re-building by other users. Such support should be a
>primary rule for an open source project. Or am I too autocrative here?
>  
>
Yeah, we use Ant here too, it's a godsend.  Are there any subprojects that
require fancy compilation, or can we just use a generic task?

>   3) Third-party libraries (the ones we have only as jar files).
>   There is no single solution. We may have them as part of the CVS, or 
>let Ant download them when a user is re-building.
>   If we have them as part of moby-live CVS:
>   - it is always sure that after 'cvs co' you have everything and in 
>correct version
>   - the CVS can be huge (as it is now) and many users will use just a 
>small sub-part (like perl users) but they still need to check-out 
>everything.
>   Almost opposite arguments apply for not to have them here. Open 
>question...
>   But I feel that having the same third-party libraries in several places 
>within the same project (Ed?) does sound good.
>  
>
I'm thinking that 95% of users checkout the whole Java archive when they 
fetch
the code.  Also, they usually won't dig deep enough to figure out 
exactly what parts
of the code they are using require what third-party libraries (and hence 
would have
to include all the jars when they wrap up their own MOBY apps).  Then 
you get the
issue of classpaths, and possible conflicts if two sub projects use 
different versions of
the  third party programs. I'm for a libs directory where all the .jars 
are stored, and
probably a README that says which parts of the code use which jars.

>   4) Generated documentation. I think that Java API that is generated 
>from Java code should not be part of the CVS. It is anyway a paint in the 
>neck to keep it sync with the CVS. The build procedures (Ant, hopefully) 
>should be able to generate it for each user when [s]he is re-building.
>  
>
I agree.

>   4) Documentation. I hope to have one BioMoby Java starting page from
>where Java users can go to all Java-based subprojects. I will update the
>current jMoby pages (if you do not mind) - but could you send me the text
>you would like to be added at the starting page and pointing to 
>yoursub-project please?
>  
>
I've got nothing so far, but would like to contrbute a page on MOBY 
object instance creation...

>   With kindest regards,
>   Martin   
>
>  
>



From mwilkinson at mrl.ubc.ca  Thu Sep 16 22:02:51 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Thu, 16 Sep 2004 15:02:51 -0700
Subject: [MISC] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <Pine.OSF.4.21.0409152119021.1471296-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0409152119021.1471296-100000@mozart.ebi.ac.uk>
Message-ID: <1095372170.11263.37.camel@myhost.mydomain>

Hi Martin, 

you're absolutely right.  I had it in there during debugging so that I
could retrieve messages where the XML was incorrectly formatted.

I've removed that now, but it has the unfortunate consequence that
**EVERYONE** must do a cvs update on their MOBY::Client::Central, since
the old client library assumed that it was CDATA, and wont extract the
RDF-XML from the registration object.

I will also make a new release for those who are only downloading the
releases.

Ugh... sorry about that!

M



On Wed, 2004-09-15 at 13:20, Martin Senger wrote:
> Mark,
>    I wonder why the RDF part in the registration object is marked as
> CDATA. Because RDF must be anyway a valid XML why to bother to surround it
> by CDATA. Having CDATA there would prevent me to have CDATA in RDF. Is
> there any reason you use CDATA for the RDF part?
> 
>    Thanks,
>    Martin
-- 
Mark Wilkinson (mwilkinson at mrl.ubc.ca)
University of British Columbia iCAPTURE Centre


From mwilkinson at mrl.ubc.ca  Thu Sep 16 22:25:11 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Thu, 16 Sep 2004 15:25:11 -0700
Subject: [MOBY-dev] CVS update required & new release available
Message-ID: <1095373511.11263.42.camel@myhost.mydomain>

Hi all, 

I just had to make a change in the client code that will allow you to
extract the RDF from the Registration object (Perl users only).

Please do a CVS update if you are using CVS, or download the latest
release from the biomoby.org/releases page, otherwise the RDF will not
be available to you in the MOBY::Registration object.

Java users should be (?? Martin/Paul ??) unaffected by this change - all
I did was remove the CDATA tags around the RDF-XML in the Registration
XML message.

M


-- 
Mark Wilkinson (mwilkinson at mrl.ubc.ca)
University of British Columbia iCAPTURE Centre


From senger at ebi.ac.uk  Thu Sep 16 22:32:23 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 16 Sep 2004 23:32:23 +0100 (BST)
Subject: [MOBY-dev] CVS update required & new release available
In-Reply-To: <1095373511.11263.42.camel@myhost.mydomain>
Message-ID: <Pine.OSF.4.21.0409162330020.859783-100000@ice.ebi.ac.uk>

> Java users should be (?? Martin/Paul ??) unaffected by this change
>
   I am just coding the whole new registration stuff, so I do not need to
announce a change because I have not commited it yet :-)
   I will let Java users know soon... (I already must thank to Eddie for
his valuable suggestions and conrtibutions).

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Thu Sep 16 22:32:23 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 16 Sep 2004 23:32:23 +0100 (BST)
Subject: [MOBY-dev] CVS update required & new release available
In-Reply-To: <1095373511.11263.42.camel@myhost.mydomain>
Message-ID: <Pine.OSF.4.21.0409162330020.859783-100000@ice.ebi.ac.uk>

> Java users should be (?? Martin/Paul ??) unaffected by this change
>
   I am just coding the whole new registration stuff, so I do not need to
announce a change because I have not commited it yet :-)
   I will let Java users know soon... (I already must thank to Eddie for
his valuable suggestions and conrtibutions).

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From mwilkinson at mrl.ubc.ca  Thu Sep 16 22:40:00 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Thu, 16 Sep 2004 15:40:00 -0700
Subject: [MISC] [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
Message-ID: <1095374399.11261.58.camel@myhost.mydomain>

Hi Martin, 

Eddie's package names are my fault.  He was working on something quite
task-specific, and I didn't know if his modules were going to fit
happily with yours or not.  Just to be safe, I advised him to put his
new modules into their own folder for the time being.  I didn't think
further about the naming conventions that he should use.

You should perhaps work out with him directly where they fit best, and
we can make the changes and re-commit.

Sorry about that!

M

-- 
Mark Wilkinson (mwilkinson at mrl.ubc.ca)
University of British Columbia iCAPTURE Centre


From senger at ebi.ac.uk  Thu Sep 16 22:56:12 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 16 Sep 2004 23:56:12 +0100 (BST)
Subject: [MISC] [MOBY-dev] Java developers, let's talk together
In-Reply-To: <1095374399.11261.58.camel@myhost.mydomain>
Message-ID: <Pine.OSF.4.21.0409162353010.859783-100000@ice.ebi.ac.uk>

> Eddie's package names are my fault.
>
   Actually, there was no fault, at all. I was just trying to start
discussion :-)
   And I will continue, especially with the most important topic, pointed
out by Paul G., how to make sure that users of Java libraries always know
what put on their claspath when they use several libraries from several
authors. I have to sleep on that... (because put everything
third-party libs into one shared directory can lead to the versioning
problem).

> You should perhaps work out with him directly where they fit best, and
> we can make the changes and re-commit.
>
   Yes, we are in touch...

   Regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From adf at ncgr.org  Thu Sep 16 23:46:52 2004
From: adf at ncgr.org (Andrew D. Farmer)
Date: Thu, 16 Sep 2004 17:46:52 -0600 (MDT)
Subject: [MISC] [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.OSF.4.21.0409162353010.859783-100000@ice.ebi.ac.uk>
Message-ID: <Pine.LNX.4.44.0409161728270.12609-100000@alberich.ncgr.org>

>    And I will continue, especially with the most important topic, pointed
> out by Paul G., how to make sure that users of Java libraries always know
> what put on their claspath when they use several libraries from several
> authors. I have to sleep on that... (because put everything
> third-party libs into one shared directory can lead to the versioning
> problem).

I missed this in the original message, but it happened to catch my eye here.
FWIW, we had a similar problem in ISYS, where independent components each 
came with their own set of classes (possibly different versions of the same 
libs) and the system itself had its own set. 

The solution we used involved custom classloaders (which I have since read 
officially qualifies one as a master of black magic); if I recall correctly, 
you can actually have multiple versions of the "same" class loaded into one 
VM, provided that they are loaded by different classloaders. Each class 
(version) maintains a reference to the classloader that loaded it, and the 
latter is given the first chance at loading classes referenced by the former 
or delegating to another classloader to find it. It is a bit complicated, 
but designed for situations like this.  
It does require that some mechanism other than the system classpath be used
for specifying the location of the resources for each classloader; in our
case, each component had its own directory space and the custom classloaders
just searched the lib directory of that component for jars (or it could be
done as a config file).

Your situation may not call for measures this complicated, but let me know
if you want any more information on our experience with this approach...

Andrew

> 
> > You should perhaps work out with him directly where they fit best, and
> > we can make the changes and re-commit.
> >
>    Yes, we are in touch...
> 
>    Regards,
>    Martin
> 
> 

-- 

Andrew Farmer
adf at ncgr.org
(505) 995-4464
Database Administrator/Software Developer
National Center for Genome Resources

---
The whole problem with the world is that fools and fanatics are always
so certain of themselves, and wiser people so full of doubts. -
Bertrand Russell
---




From opushneva at yahoo.ca  Fri Sep 17 04:16:47 2004
From: opushneva at yahoo.ca (Nina Opushneva)
Date: Thu, 16 Sep 2004 21:16:47 -0700 (PDT)
Subject: [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.LNX.4.44.0409161430540.7221-100000@bagheera.ebi.ac.uk>
Message-ID: <20040917041647.91439.qmail@web60903.mail.yahoo.com>




 Hi Martin,


>    1) Package names. It does not matter where the
> Java code is in the CVS
> module (because one can partition things either by
> language, or by topic,
> and both approaches can be mixed) but it would be
> nice if the Java package
> names reflected what the code deals with. I started
> with names (I hope 
> with obvious meanings - if not I am ready to
> explain):
>    org.biomoby.client
>    org.biomoby.shared
>    org.biomoby.registry
>    org.biomoby.service
> 

You are definitely right regarding the package name
convention. I didn?t find any rules for that, so I
used my own. Sorry about that, I?ll change the package
names. From my point of view the RDF Agent logically
belongs to the registry. Will be the
org.biomoby.registry.rdfagent as a RDF Agent?s base
package name ok?


>    2) Building. What about to use Ant? :-) At the
> moment, some subprojects
> does not support much re-building by other users.
> Such support should be a
> primary rule for an open source project. Or am I too
> autocrative here?
> 

Agree. I?ll develop an ANT build file for the RDF
Agent and will commit it to the CVS with source code.

>    3) Third-party libraries (the ones we have only
> as jar files).
>    There is no single solution. We may have them as
> part of the CVS, or 
> let Ant download them when a user is re-building.

Location for the third-party libraries is real issue.
I think we should discuss that altogether with
subproject directory structure. I would suggest
following:

?
 |
 subroject name
  |
  + doc
  +config
  + lib
  + src
  |
  Manifest.mf
  readme
  build.xml
  build.sh
  build.bat
  run.sh
  run.bat

This structure provides good subproject encapsulation
and resolves libraries? version conflict problem. Main
disadvantage ?duplicate some libraries. As a result
less efficient use of  the server disk space and some
extra traffic. I think that easy subproject?s
sourcecode / libs administration is much more
valuable. To put all libraries in the same place could
become a nightmare for the project
support/administration especially if keep in mind that
a jar file name means nothing. Two jars with the same
name could have absolutely different content and/or
library versions. 



>    4) Generated documentation. I think that Java API
> that is generated 
> from Java code should not be part of the CVS. It is
> anyway a paint in the 
> neck to keep it sync with the CVS. The build
> procedures (Ant, hopefully) 
> should be able to generate it for each user when
> [s]he is re-building.
> 

Agree. An ANT build file should have task ?generate
JavaDoc? or similar.


>    4) Documentation. I hope to have one BioMoby Java
> starting page from
> where Java users can go to all Java-based
> subprojects. I will update the
> current jMoby pages (if you do not mind) - but could
> you send me the text
> you would like to be added at the starting page and
> pointing to 
> yoursub-project please?
> 

It is a very good idea. I will prepare the text and
send it to you as soon as I can.

Best regards,

Nina Opushneva


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com


From senger at ebi.ac.uk  Fri Sep 17 10:49:21 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 17 Sep 2004 11:49:21 +0100 (BST)
Subject: [MOBY-dev] Java developers, let's talk together
In-Reply-To: <20040917041647.91439.qmail@web60903.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0409170940490.8147-100000@bagheera.ebi.ac.uk>

[ I am sorry this is a bit longer email. I am abusing the reply to Nina to
address also answers and hints from other people's emails from yesterday.  
Thanks very much for all of them; especially those interesting suggestions
about how to address versioning conflicts of the third party libraries.
Thanks again. ]

> From my point of view the RDF Agent logically belongs to the registry.
> Will be the org.biomoby.registry.rdfagent as a RDF Agent?s base package
> name ok?
>
   I agree, perfect. 

> Agree. I?ll develop an ANT build file for the RDF
> Agent and will commit it to the CVS with source code.
>
   Sounds great. (I put some comments about Ant and third-libraries 
below).
 
> Location for the third-party libraries is real issue.
> I think we should discuss that altogether with
> subproject directory structure.
>
   I would say that if we use Ant then the directory structure is not that 
important (because Ant knows where to find things). The directory 
structure becomes more relevant if we decide to move sources together. 
Which is not so bad idea - if it is easy (e.g. I feel that moving S-MOBY 
current structure to the same directory with jMoby-MOBY-S would not be 
practical).
   My suggestion is this: I am going to write down (first here, later it
should appear also in the docs somewhere; most of it is already there,
btw) some conventions which I am using now (and which - believe me - I was
thinking about quite a lot before I started to use them). Every developer
will have then three options (any has few pros and cons):

   1) To keep her/his subproject separate, or
   2) To incorporate it into current structure in moby-live/Java, or
   3) To put in into moby-live/Java - bus as a totally separate 
subdirectory.

What are the pros and cons?

   Ad 1) is preferable (unless there are reasons against it) because it
will force us to solve problems with versioning of the third-party
libraries as soon as they appear (if they appear; perhaps we will be lucky
:-)). Simply it means to share third-party libraries (sitting in the 'lib'
subdirectory).
   This is also quite good for the end-users using our libraries/code - 
because it is clear to them what to put on their classpath (usually we 
already have 'run' scripts doing it).
   The cons are: You need to conform with the existing structure and
existing policies which may not be always the best for your subproject. If
you want to change such policy it needs more discussion and time because
there are more people involved. Simply speaking: any change in structure
is costly.
   Also this does not solve the problem how the end-users can combine more 
subproject together. I will briefly address this problem at the end.

   Ad 3) is needed if you have special build requirements - so you can 
provide your own build.xml. I have never used nested build.xml so I have 
not yet experiences with this option. But it should work fine.

   If you choose ad 2) or ad 3) the suggested principles are simple:
   a) use Ant
   b) do not put Java generated documentation in the CVS (but make Ant to 
produce it)
   c) send me a link and few words about your subproject that I can
include in the jMoby main page

   If you choose ad 1) the principles above are the same, but there are 
also others (I am not only listing them but I am trying to put some 
rationale that lead me to have them. I am also prepared to discuss how to 
change them if you wish.):
   [ Everything below can be seen in moby-live/Java/build.xml, and in 
scripts moby-live/Java/build.* ]

   d) The sources are in 'src', but most of them are actually in
'src/main'. This is how to make possible to include also sources that do
not belong to any package (such as some testing classes). Simple speaking,
if your sources are in package (most of them, if not all, are) they should
go to 'src/main').

   e) Run scripts (the scripts starting various Java programs) are now in 
the main directory. This is going to be changed because we may have more 
scripts and it should polute the main level too much. There are two 
options:
   e1) To use 'run' directory.
   e2) To use 'build/run' directory.
   Using 'run' directory is easier for users. When they look into the top
level, they see 'run' so they look there and find appropriate script. But 
the script will not work until they actually build everything, and the 
script must always be started from the top level directory (because it 
must have relative path to 'build' and 'lib' directories with classes).
   Using 'build/run' is not so obvious but has otherwise quite a lot
advantages: the scripts are generated by Ant, so they have the full paths
to classes, so they can be called from anywhere; they cannot be started
before building them - because they do not exist before that :-), and they
can be customized (using standard 'build.properties' file) for local needs
(if there are such needs, hopefully as little as possible - but for
example for scripts accessing locations out of the CVS space, like Tomcat, 
it is needed).
   Saying this I vote for 'build/run'...

   f) The probably most contentious topic is how to get third-party
libraries. The basic question is: should they be part of the CVS or be
downloaded when you first build it? After many considerations, and after
discussing with people around here, I have taken the second option
(downloading them). (The moby-live/Java/README explains how it works.) If
we continue to use this option, I will change the place where I am getting
these libraries from to somewhere where other developers can put their
libraries as well (it must be a place accessible by HTTP - at the moment I
have it in my space at EBI).
   This email is too long now - so we may discuss this topic separately if 
we wish.

   That's all regarding the policies.

   Nina also suggested:
>   + doc
>   +config
>
   * moby-live/Java uses 'docs' instead of 'doc', sorry for that;
   * I usually have 'config' under 'src' - but there are no special 
reasons for that.

> This structure provides good subproject encapsulation
> and resolves libraries? version conflict problem. Main
> disadvantage ?duplicate some libraries. As a result
> less efficient use of  the server disk space and some
> extra traffic.
>
   As I tried to explain above, the problem is not with having duplicates,
but with the versioning conflicts that can happen when a user starts using
two - until now separated - subprojects. He has to pick up a library from
one of these subproject - which may lead to failure of the other one. If
we share the libraries from the beginning we know about it during the
developing and testing phase already.

> To put all libraries in the same place could become a nightmare for the
> project support/administration
>
   It may be well true - but better have this nightmare for administrators 
and developers than for our users. Just my 2c.

   So I finish now... Again sorry for the extend of this email.
   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger









From rebecca.ernst at gsf.de  Fri Sep 17 12:30:21 2004
From: rebecca.ernst at gsf.de (Rebecca Ernst)
Date: Fri, 17 Sep 2004 14:30:21 +0200
Subject: [MOBY-dev] signatureURL
In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain>
References: <1095263887.5954.78.camel@myhost.mydomain>
Message-ID: <414AD8DD.7000601@gsf.de>

Hi Mark!

I don't know if you check who of the service providers has generated his 
serviceSignature - Just for the case that you don't check it: 
I wanted to inform you that mips.gsf.de is now up-to-date and prepared 
for the visit of Ninas agent ;-)

Rebecca



-- 
Rebecca Ernst
MIPS, Inst. for Bioinformatics
GSF Research Center for Environment and Health
Ingolstaedter Landstr. 1
85764 Neuherberg
fon: +49 89 3187 3583
email: Rebecca.Ernst at gsf.de



From mwilkinson at mrl.ubc.ca  Fri Sep 17 13:35:45 2004
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Fri, 17 Sep 2004 06:35:45 -0700
Subject: [MOBY-dev] Re: [MISC] signatureURL
In-Reply-To: <414AD8DD.7000601@gsf.de>
References: <1095263887.5954.78.camel@myhost.mydomain>
	<414AD8DD.7000601@gsf.de>
Message-ID: <1095428145.11263.194.camel@myhost.mydomain>

Hiya, 

I will check the database by eye before we switch the agent on, and
contact anyone who is tardy :-)

M


On Fri, 2004-09-17 at 05:30, Rebecca Ernst wrote:
> Hi Mark!
> 
> I don't know if you check who of the service providers has generated his 
> serviceSignature - Just for the case that you don't check it: 
> I wanted to inform you that mips.gsf.de is now up-to-date and prepared 
> for the visit of Ninas agent ;-)
> 
> Rebecca
-- 
Mark Wilkinson (mwilkinson at mrl.ubc.ca)
University of British Columbia iCAPTURE Centre


From gordonp at cbr.nrc.ca  Fri Sep 17 14:44:55 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Fri, 17 Sep 2004 08:44:55 -0600
Subject: [MISC] [MOBY-dev] Java developers, let's talk together
In-Reply-To: <Pine.LNX.4.44.0409161728270.12609-100000@alberich.ncgr.org>
References: <Pine.LNX.4.44.0409161728270.12609-100000@alberich.ncgr.org>
Message-ID: <414AF867.7020707@cbr.nrc.ca>

People will probably disagree with me here, because it creates a little 
more work for the developers,
but can't we all at least try to use the same version of Axis for 
example?  When you want to write new code,
you can see if there's an acceptable version of the lib of interest 
already committed, and if you absolutely must
use a newer version that is not backward compatible, you can put it in a 
project specific lib directory? 

Later, you can try to convince people that they should update their 
code, or place the old lib in their project-specific
lib directory.  e.g. "Hey!  All Java developers!  Get off your asses and 
use Axis 1.1 instead of the crappy
Axis 1.0 which doesn't cache the non-existence of deserialization helper 
classes and causes thousands of
HTTP requests/disk accesses while running SOAP services!".  There are a 
lot more people contributing to
BioPerl, and they all use the same libraries, we Java programmers can't 
let them show us up :-)

>>   And I will continue, especially with the most important topic, pointed
>>out by Paul G., how to make sure that users of Java libraries always know
>>what put on their claspath when they use several libraries from several
>>authors. I have to sleep on that... (because put everything
>>third-party libs into one shared directory can lead to the versioning
>>problem).
>>    
>>
>
>I missed this in the original message, but it happened to catch my eye here.
>FWIW, we had a similar problem in ISYS, where independent components each 
>came with their own set of classes (possibly different versions of the same 
>libs) and the system itself had its own set. 
>
>  
>
>The solution we used involved custom classloaders (which I have since read 
>officially qualifies one as a master of black magic);
>
Hee hee, I wrote my own class loader too, but so that I could 
automatically create applet JARs
with only the classes I needed for the app instead of all of the classes 
in the third party packages
I was using.  When is the next Black Magic Circle clandestine meeting? :-)


From senger at ebi.ac.uk  Fri Sep 17 14:52:41 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 17 Sep 2004 15:52:41 +0100 (BST)
Subject: [MISC] [MOBY-dev] Java developers, let's talk together
In-Reply-To: <414AF867.7020707@cbr.nrc.ca>
Message-ID: <Pine.LNX.4.44.0409171550260.8340-100000@bagheera.ebi.ac.uk>

> People will probably disagree with me here, because it creates a little
> more work for the developers, but can't we all at least try to use the
> same version of Axis for example?
>
   Well, that was my preferred option :-) Put your code into
moby-live/Java, and use what is there in 'lib' (or what is downloaded
there when you first build it - but this is another story). If it does not 
suite you, shout loudly...

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Tue Sep 21 11:02:34 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 21 Sep 2004 12:02:34 +0100 (BST)
Subject: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain>
Message-ID: <Pine.LNX.4.44.0409211156090.20316-100000@bagheera.ebi.ac.uk>

Mark,
   I found the agent's behaviour description slightly inconsistent in one 
place (perhaps agent is not inconsistent, perhaps it is only the 
description, I have not tested the agent itself):

> The agent runs on a cron, and behaves as follows:
> ...
> 3)  If it doesn't find a valid RDF file there, then it flags an error;
> after a certain number of errors your service(s) will be deregistered.
> ...
> 5)  If it expects to find a service signature in this RDF, and can't
> find it, it concludes that the service has been taken off-line, and it
> will de-register that service.
>
   So: if there is no file at all, it will try several times before
de-registering the service. But if there is any RDF file but without my
service, it will de-register it immediatelly. Why does it not behave the
same in these two cases? In reality, it would mean slightly different
behaviour when I am adding my first service (so the RDF file with all my
services does not exist yes) and when I am adding the second and more 
services (when the RDF file exists - havig my previous services - but it 
still does not have my last one).

   Regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Tue Sep 21 11:02:34 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 21 Sep 2004 12:02:34 +0100 (BST)
Subject: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain>
Message-ID: <Pine.LNX.4.44.0409211156090.20316-100000@bagheera.ebi.ac.uk>

Mark,
   I found the agent's behaviour description slightly inconsistent in one 
place (perhaps agent is not inconsistent, perhaps it is only the 
description, I have not tested the agent itself):

> The agent runs on a cron, and behaves as follows:
> ...
> 3)  If it doesn't find a valid RDF file there, then it flags an error;
> after a certain number of errors your service(s) will be deregistered.
> ...
> 5)  If it expects to find a service signature in this RDF, and can't
> find it, it concludes that the service has been taken off-line, and it
> will de-register that service.
>
   So: if there is no file at all, it will try several times before
de-registering the service. But if there is any RDF file but without my
service, it will de-register it immediatelly. Why does it not behave the
same in these two cases? In reality, it would mean slightly different
behaviour when I am adding my first service (so the RDF file with all my
services does not exist yes) and when I am adding the second and more 
services (when the RDF file exists - havig my previous services - but it 
still does not have my last one).

   Regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From gordonp at cbr.nrc.ca  Tue Sep 21 14:20:56 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Tue, 21 Sep 2004 08:20:56 -0600
Subject: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <Pine.LNX.4.44.0409211156090.20316-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409211156090.20316-100000@bagheera.ebi.ac.uk>
Message-ID: <415038C8.4090105@cbr.nrc.ca>

I think the idea behind the multiple attempts in case (3) is that the 
Web server might be down, or the page temporarily unavailable due to 
resource problems (e.g. forgot to mount the Web server disk :-)).  To 
make these more consistent, maybe I'd only retry fetching the RDF if the 
server could not be contacted, or if it returned a 5XX HTTP code.  
Ortherwise treat it as case (5)?

Martin Senger wrote:

>Mark,
>   I found the agent's behaviour description slightly inconsistent in one 
>place (perhaps agent is not inconsistent, perhaps it is only the 
>description, I have not tested the agent itself):
>
>  
>
>>The agent runs on a cron, and behaves as follows:
>>...
>>3)  If it doesn't find a valid RDF file there, then it flags an error;
>>after a certain number of errors your service(s) will be deregistered.
>>...
>>5)  If it expects to find a service signature in this RDF, and can't
>>find it, it concludes that the service has been taken off-line, and it
>>will de-register that service.
>>
>>    
>>
>   So: if there is no file at all, it will try several times before
>de-registering the service. But if there is any RDF file but without my
>service, it will de-register it immediatelly. Why does it not behave the
>same in these two cases? In reality, it would mean slightly different
>behaviour when I am adding my first service (so the RDF file with all my
>services does not exist yes) and when I am adding the second and more 
>services (when the RDF file exists - havig my previous services - but it 
>still does not have my last one).
>
>   Regards,
>   Martin
>
>  
>



From opushneva at yahoo.ca  Wed Sep 22 05:33:57 2004
From: opushneva at yahoo.ca (Nina Opushneva)
Date: Tue, 21 Sep 2004 22:33:57 -0700 (PDT)
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <Pine.LNX.4.44.0409211156090.20316-100000@bagheera.ebi.ac.uk>
Message-ID: <20040922053357.44035.qmail@web60906.mail.yahoo.com>

Hi Martin,

Mark is away now. May I try to answer your question.


3) It expects to find, there, a RDF representation of
the services hosted by this service provider. If the
connection is refused three times in a row for the
same reason, the services that have been registered
with this signatureURL will be deleted from
mobycentral database.  Every time a message about a
refused connection will be sent to provider.

If the connection was successful, the RDFAgent browses
the input stream and compares it to the data in the
database. New services described will be added to
database; the services, which were expected to be at
this URL, but are missing, will be deleted from the
database.

I don?t think that RDFagent is going to be working
every day, maybe for checking could be enough once a
week (lets say on Sunday). So, providers will have
time to put their RDF into the RDF file. But we can
discuss it.

Cheers,

Nina



--- Martin Senger <senger at ebi.ac.uk> wrote:

> Mark,
>    I found the agent's behaviour description
> slightly inconsistent in one 
> place (perhaps agent is not inconsistent, perhaps it
> is only the 
> description, I have not tested the agent itself):
> 
> > The agent runs on a cron, and behaves as follows:
> > ...
> > 3)  If it doesn't find a valid RDF file there,
> then it flags an error;
> > after a certain number of errors your service(s)
> will be deregistered.
> > ...
> > 5)  If it expects to find a service signature in
> this RDF, and can't
> > find it, it concludes that the service has been
> taken off-line, and it
> > will de-register that service.
> >
>    So: if there is no file at all, it will try
> several times before
> de-registering the service. But if there is any RDF
> file but without my
> service, it will de-register it immediatelly. Why
> does it not behave the
> same in these two cases? In reality, it would mean
> slightly different
> behaviour when I am adding my first service (so the
> RDF file with all my
> services does not exist yes) and when I am adding
> the second and more 
> services (when the RDF file exists - havig my
> previous services - but it 
> still does not have my last one).
> 
>    Regards,
>    Martin
> 
> -- 
> Martin Senger
> 
> EMBL Outstation - Hinxton               
> Senger at EBI.ac.uk     
> European Bioinformatics Institute        Phone:
> (+44) 1223 494636      
> Wellcome Trust Genome Campus            
> (Switchboard:     494444)
> Hinxton                                  Fax  :
> (+44) 1223 494468
> Cambridge CB10 1SD
> United Kingdom                          
> http://industry.ebi.ac.uk/~senger
> 
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
> 



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 


From senger at ebi.ac.uk  Wed Sep 22 11:15:31 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 22 Sep 2004 12:15:31 +0100 (BST)
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <20040922053357.44035.qmail@web60906.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0409221211580.2054-100000@bagheera.ebi.ac.uk>

> May I try to answer your question.
> 
Nina,
   Thanks for the clarification.
   Just one minor question: Assuming I do not wish to register a service
for long, therefore I do not plan to send any signatureURL. Is it safe to
include an empty signatureURL tag, or do I *have* to omit it at all?

   Regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Wed Sep 22 11:15:31 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 22 Sep 2004 12:15:31 +0100 (BST)
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <20040922053357.44035.qmail@web60906.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0409221211580.2054-100000@bagheera.ebi.ac.uk>

> May I try to answer your question.
> 
Nina,
   Thanks for the clarification.
   Just one minor question: Assuming I do not wish to register a service
for long, therefore I do not plan to send any signatureURL. Is it safe to
include an empty signatureURL tag, or do I *have* to omit it at all?

   Regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Wed Sep 22 13:23:31 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 22 Sep 2004 14:23:31 +0100 (BST)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <20040922053357.44035.qmail@web60906.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>

Here are few comments and perhaps questions. But before that I would like
to stress that these issues are urgent NOW (sorry for the capital letters)
because we are changing libraries now and we need these issues to be fixed
(or explained) really soon. Thanks.

1) Testing registry seems to have still older version - it still returns 
RDF with CDATA. It would be good to have it restarted, or whatever it 
needs. The testing registry with the latest software is important 
especially now when we are testing new registration procedures.

2) The service description, as returned in the RDF, lost its CDATA 
protection. Perhaps it is correct, I do not know enough about RDF 
documents. I have just observed that the 'strange characters', 
such as '>', that I put into my service description, were returned 
escaped: the character '>' was escaped as '&amp;gt;' - which does not seem 
to be correct (but perhaps I am mistaken).

Anyway, I wonder why to play with escaping at all, why not to keep there 
CDATA. We have CDATA in service description just because we did not want 
to escape everything there - is that correct?

3) I also wonder where are all our LSIDs? There is no single LSID in the 
whole returned RDF. I thought that we expressed almost everything as LSIDs 
in biomoby (at least internally).

4) I use this list to strongly express how I agree with the last Rebecca 
email about being still able to deregister a service by calling a 
deregister method even if the service has been registered with the 
signatureURL.

5) Finally, just to make this list complete, I would like to remind the 
others that there had been a discussion about possibility to get RDF from 
the registry even for services that had been already registered. I would 
like to have this feature soon - because it may need an addition tag in 
the service object, so the sooner we know about it the better.

   With kindest regards,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger




From rebecca.ernst at gsf.de  Wed Sep 22 14:02:18 2004
From: rebecca.ernst at gsf.de (Rebecca Ernst)
Date: Wed, 22 Sep 2004 16:02:18 +0200
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <415185EA.4080005@gsf.de>

Hi Martin!

referring to your last point:

>5) Finally, just to make this list complete, I would like to remind the 
>others that there had been a discussion about possibility to get RDF from 
>the registry even for services that had been already registered. I would 
>like to have this feature soon - because it may need an addition tag in 
>the service object, so the sooner we know about it the better.
>

This is a snippet of Marks former mail:

Of course, at the moment nobody has a signatureURL   I have set up a
simple CGI page for existing service providers where they can supply a
URL and get the signature RDF for all of their existing services:

http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl



Cheers,
Rebecca



-- 
Rebecca Ernst
MIPS, Inst. for Bioinformatics
GSF Research Center for Environment and Health
Ingolstaedter Landstr. 1
85764 Neuherberg
fon: +49 89 3187 3583
email: Rebecca.Ernst at gsf.de



From rebecca.ernst at gsf.de  Wed Sep 22 14:02:18 2004
From: rebecca.ernst at gsf.de (Rebecca Ernst)
Date: Wed, 22 Sep 2004 16:02:18 +0200
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <415185EA.4080005@gsf.de>

Hi Martin!

referring to your last point:

>5) Finally, just to make this list complete, I would like to remind the 
>others that there had been a discussion about possibility to get RDF from 
>the registry even for services that had been already registered. I would 
>like to have this feature soon - because it may need an addition tag in 
>the service object, so the sooner we know about it the better.
>

This is a snippet of Marks former mail:

Of course, at the moment nobody has a signatureURL   I have set up a
simple CGI page for existing service providers where they can supply a
URL and get the signature RDF for all of their existing services:

http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl



Cheers,
Rebecca



-- 
Rebecca Ernst
MIPS, Inst. for Bioinformatics
GSF Research Center for Environment and Health
Ingolstaedter Landstr. 1
85764 Neuherberg
fon: +49 89 3187 3583
email: Rebecca.Ernst at gsf.de



From senger at ebi.ac.uk  Wed Sep 22 14:09:43 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 22 Sep 2004 15:09:43 +0100 (BST)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <415185EA.4080005@gsf.de>
Message-ID: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>

> This is a snippet of Marks former mail:
> 
> Of course, at the moment nobody has a signatureURL   I have set up a
> simple CGI page for existing service providers where they can supply a
> URL and get the signature RDF for all of their existing services:
> 
> http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl
>
   Yes, I know about it. But Mark said that this cgi-bin will be there 
only temporarily. I had in mind something more permanent (for example if 
you loose your RDF you should be able to get it back somehow from the 
registry, without registering it again...). We have discussed this with 
Mark already and he seems to agree with providing such functionality - I 
had put it in the list of observations just not to let it slip from my
(and his :-)) mind...
 
   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Wed Sep 22 14:09:43 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 22 Sep 2004 15:09:43 +0100 (BST)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <415185EA.4080005@gsf.de>
Message-ID: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>

> This is a snippet of Marks former mail:
> 
> Of course, at the moment nobody has a signatureURL   I have set up a
> simple CGI page for existing service providers where they can supply a
> URL and get the signature RDF for all of their existing services:
> 
> http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl
>
   Yes, I know about it. But Mark said that this cgi-bin will be there 
only temporarily. I had in mind something more permanent (for example if 
you loose your RDF you should be able to get it back somehow from the 
registry, without registering it again...). We have discussed this with 
Mark already and he seems to agree with providing such functionality - I 
had put it in the list of observations just not to let it slip from my
(and his :-)) mind...
 
   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From opushneva at yahoo.ca  Wed Sep 22 17:01:26 2004
From: opushneva at yahoo.ca (Nina Opushneva)
Date: Wed, 22 Sep 2004 10:01:26 -0700 (PDT)
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <Pine.LNX.4.44.0409221211580.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <20040922170126.43575.qmail@web60901.mail.yahoo.com>

Hi Martin,
 
If you put the RDF of your service into a separate
file and include an empty signatureURL tag by
registration, the RDFagent will not process it.
Otherwise, if you put your RDF into the file which URL
is ?known? for the registry database, it will be
processed.
(But in the first way you need to ask Mark if it's
possible include an empty signatureURL during of a
registration).

If you wish to save your service RDF into the RDF
file, but you don't wish to put the information about
this service into registry database, you can to make
RDF of this service ?not valid for MOBY?.

 A valid MOBY RDF means that it has the complete set
of descriptions:
     serviceName  
     serviceType  
     authURI      
     contactEmail 
     description 
     category  
     URL   
     input/output (may be one of them)
 
If you delete or comment one of that descriptions,
RDFagent will not process RDF of this service.

Cheers,

Nina


--- Martin Senger <senger at ebi.ac.uk> wrote:

> > May I try to answer your question.
> > 
> Nina,
>    Thanks for the clarification.
>    Just one minor question: Assuming I do not wish
> to register a service
> for long, therefore I do not plan to send any
> signatureURL. Is it safe to
> include an empty signatureURL tag, or do I *have* to
> omit it at all?
> 
>    Regards,
>    Martin
> 
> -- 
> Martin Senger
> 
> EMBL Outstation - Hinxton               
> Senger at EBI.ac.uk     
> European Bioinformatics Institute        Phone:
> (+44) 1223 494636      
> Wellcome Trust Genome Campus            
> (Switchboard:     494444)
> Hinxton                                  Fax  :
> (+44) 1223 494468
> Cambridge CB10 1SD
> United Kingdom                          
> http://industry.ebi.ac.uk/~senger
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 


From markw at illuminae.com  Wed Sep 22 23:31:00 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 22 Sep 2004 16:31:00 -0700
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <41520B34.9080307@illuminae.com>

Hello from beautiful Banff!  I'm here at the SAB meeting for the grant 
under which MOBY-S is funded... wish me luck!

It turns out that the conference centre has public wireless access in 
the pub, but not in the rooms... oh dear!  ;-)

Yes, Martin and I have discussed this, and agreed that it should be a 
part of the MOBY Central API.  Martin, keep reminding me, as I have a 
ton of other things consuming my time at the moment so constant pressure 
will be required to get it done in a timely way...

Cheers all!

Mark


Martin Senger wrote:

>>This is a snippet of Marks former mail:
>>
>>Of course, at the moment nobody has a signatureURL   I have set up a
>>simple CGI page for existing service providers where they can supply a
>>URL and get the signature RDF for all of their existing services:
>>
>>http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl
>>
>>    
>>
>   Yes, I know about it. But Mark said that this cgi-bin will be there 
>only temporarily. I had in mind something more permanent (for example if 
>you loose your RDF you should be able to get it back somehow from the 
>registry, without registering it again...). We have discussed this with 
>Mark already and he seems to agree with providing such functionality - I 
>had put it in the list of observations just not to let it slip from my
>(and his :-)) mind...
> 
>   Cheers,
>   Martin
>
>  
>


From markw at illuminae.com  Wed Sep 22 23:31:00 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 22 Sep 2004 16:31:00 -0700
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221506130.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <41520B34.9080307@illuminae.com>

Hello from beautiful Banff!  I'm here at the SAB meeting for the grant 
under which MOBY-S is funded... wish me luck!

It turns out that the conference centre has public wireless access in 
the pub, but not in the rooms... oh dear!  ;-)

Yes, Martin and I have discussed this, and agreed that it should be a 
part of the MOBY Central API.  Martin, keep reminding me, as I have a 
ton of other things consuming my time at the moment so constant pressure 
will be required to get it done in a timely way...

Cheers all!

Mark


Martin Senger wrote:

>>This is a snippet of Marks former mail:
>>
>>Of course, at the moment nobody has a signatureURL   I have set up a
>>simple CGI page for existing service providers where they can supply a
>>URL and get the signature RDF for all of their existing services:
>>
>>http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl
>>
>>    
>>
>   Yes, I know about it. But Mark said that this cgi-bin will be there 
>only temporarily. I had in mind something more permanent (for example if 
>you loose your RDF you should be able to get it back somehow from the 
>registry, without registering it again...). We have discussed this with 
>Mark already and he seems to agree with providing such functionality - I 
>had put it in the list of observations just not to let it slip from my
>(and his :-)) mind...
> 
>   Cheers,
>   Martin
>
>  
>


From markw at illuminae.com  Thu Sep 23 00:11:55 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 22 Sep 2004 17:11:55 -0700
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <415214CB.3010805@illuminae.com>

Martin Senger wrote:

>1) Testing registry seems to have still older version - it still returns 
>RDF with CDATA. It would be good to have it restarted,
>  
>
Done

>2) The service description, as returned in the RDF, lost its CDATA 
>protection. Perhaps it is correct,
>

Um... well, I removed it at your request, so... :-)

> I do not know enough about RDF 
>documents. I have just observed that the 'strange characters', 
>such as '>', that I put into my service description, were returned 
>escaped: the character '>' was escaped as '&amp;gt;' - which does not seem 
>to be correct (but perhaps I am mistaken).
>  
>
AFAIK, anything that is not contained in a CDATA section will be 
escaped.  It is done at the library-level and I have no (?) control over it.

>Anyway, I wonder why to play with escaping at all, why not to keep there 
>CDATA.
>
Because you asked me to remove it, and your reasons were valid :-)  The 
RDF is a valid XML fragment, so there was really no good reason to put 
it in a CDATA section.

> We have CDATA in service description just because we did not want 
>to escape everything there - is that correct?
>  
>
Correct.

>3) I also wonder where are all our LSIDs? There is no single LSID in the 
>whole returned RDF. I thought that we expressed almost everything as LSIDs 
>in biomoby (at least internally).
>  
>
That's a very good point!  I agree with you 110%, and I can implement 
this fairly quickly at at the RDF-production end of things.  At the 
RDF-consumption end, I'll have to talk to Nina about it.  I'm fairly 
sure that we can work it out quickly.  The problem at the moment is that 
LSID resolution in MOBY is completely broken.  The latest version of the 
Perl LSID resolver stack (or at least, the latest the last time I 
looked) is built on top of alpha code libraries, and other libraries 
that are not yet in CPAN.  I was able to get it to compile (with a bit 
of fussing) on my Linux machine, but it throws errors up the ying-yang 
on mobycentral (Solaris).  As such, LSID resolution of MOBY LSID's will 
not be possible until someone has time to write an LSID resolver in 
Java, or the LSID code developers make changes to their stack  :-/   :-(


>4) I use this list to strongly express how I agree with the last Rebecca 
>email about being still able to deregister a service by calling a 
>deregister method even if the service has been registered with the 
>signatureURL.
>
>  
>
Well, I strongly disagree with you :-)   Gosh, THAT has never happened 
before!  ;-)

You have to remember what the driving force was to create the RDF-based 
deregistration!! The problem is that any kid with the ability to read an 
API could have come in and desroyed our registry by deregistering all of 
the services in it with a 5-line Perl script!  Authentication was just a 
pain in the arse and totally impractical, so the only remaining solution 
was to remove that functionality of MOBY Central and move the problem to 
the service providers machine.  I am loathe to move away from that model 
because in the last 18 months nobody has come up with a better solution!!

If a better solution exists, then we can certainly revisit the issue...

>5) Finally, just to make this list complete, I would like to remind the 
>others that there had been a discussion about possibility to get RDF from 
>the registry even for services that had been already registered. I would 
>like to have this feature soon - because it may need an addition tag in 
>the service object, so the sooner we know about it the better.
>
>  
>
Yes, I might actually try to get that done tonight in my room, and 
upload it to mobycentral tomorrow.  I'll let you know.

Cheers!

M

>  
>


From markw at illuminae.com  Thu Sep 23 00:11:55 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 22 Sep 2004 17:11:55 -0700
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221345080.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <415214CB.3010805@illuminae.com>

Martin Senger wrote:

>1) Testing registry seems to have still older version - it still returns 
>RDF with CDATA. It would be good to have it restarted,
>  
>
Done

>2) The service description, as returned in the RDF, lost its CDATA 
>protection. Perhaps it is correct,
>

Um... well, I removed it at your request, so... :-)

> I do not know enough about RDF 
>documents. I have just observed that the 'strange characters', 
>such as '>', that I put into my service description, were returned 
>escaped: the character '>' was escaped as '&amp;gt;' - which does not seem 
>to be correct (but perhaps I am mistaken).
>  
>
AFAIK, anything that is not contained in a CDATA section will be 
escaped.  It is done at the library-level and I have no (?) control over it.

>Anyway, I wonder why to play with escaping at all, why not to keep there 
>CDATA.
>
Because you asked me to remove it, and your reasons were valid :-)  The 
RDF is a valid XML fragment, so there was really no good reason to put 
it in a CDATA section.

> We have CDATA in service description just because we did not want 
>to escape everything there - is that correct?
>  
>
Correct.

>3) I also wonder where are all our LSIDs? There is no single LSID in the 
>whole returned RDF. I thought that we expressed almost everything as LSIDs 
>in biomoby (at least internally).
>  
>
That's a very good point!  I agree with you 110%, and I can implement 
this fairly quickly at at the RDF-production end of things.  At the 
RDF-consumption end, I'll have to talk to Nina about it.  I'm fairly 
sure that we can work it out quickly.  The problem at the moment is that 
LSID resolution in MOBY is completely broken.  The latest version of the 
Perl LSID resolver stack (or at least, the latest the last time I 
looked) is built on top of alpha code libraries, and other libraries 
that are not yet in CPAN.  I was able to get it to compile (with a bit 
of fussing) on my Linux machine, but it throws errors up the ying-yang 
on mobycentral (Solaris).  As such, LSID resolution of MOBY LSID's will 
not be possible until someone has time to write an LSID resolver in 
Java, or the LSID code developers make changes to their stack  :-/   :-(


>4) I use this list to strongly express how I agree with the last Rebecca 
>email about being still able to deregister a service by calling a 
>deregister method even if the service has been registered with the 
>signatureURL.
>
>  
>
Well, I strongly disagree with you :-)   Gosh, THAT has never happened 
before!  ;-)

You have to remember what the driving force was to create the RDF-based 
deregistration!! The problem is that any kid with the ability to read an 
API could have come in and desroyed our registry by deregistering all of 
the services in it with a 5-line Perl script!  Authentication was just a 
pain in the arse and totally impractical, so the only remaining solution 
was to remove that functionality of MOBY Central and move the problem to 
the service providers machine.  I am loathe to move away from that model 
because in the last 18 months nobody has come up with a better solution!!

If a better solution exists, then we can certainly revisit the issue...

>5) Finally, just to make this list complete, I would like to remind the 
>others that there had been a discussion about possibility to get RDF from 
>the registry even for services that had been already registered. I would 
>like to have this feature soon - because it may need an addition tag in 
>the service object, so the sooner we know about it the better.
>
>  
>
Yes, I might actually try to get that done tonight in my room, and 
upload it to mobycentral tomorrow.  I'll let you know.

Cheers!

M

>  
>


From markw at illuminae.com  Thu Sep 23 00:15:12 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 22 Sep 2004 17:15:12 -0700
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <Pine.LNX.4.44.0409221211580.2054-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409221211580.2054-100000@bagheera.ebi.ac.uk>
Message-ID: <41521590.6000505@illuminae.com>


>Is it safe to
>include an empty signatureURL tag, or do I *have* to omit it at all?
>  
>
Yup :-)  That is EXACTLY how it was designed to behave :-)  Just leave 
it out and your service will auto-deregister the next time the agent 
runs.  Alternately, you can manually deregister a service without a 
SignatureURL by using the deregisterService call of the API.

(can you tell I am answering my emails in reverse order? )

M

>  
>


From senger at ebi.ac.uk  Thu Sep 23 00:29:40 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 01:29:40 +0100 (BST)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <415214CB.3010805@illuminae.com>
Message-ID: <Pine.OSF.4.21.0409230122070.824651-100000@ice.ebi.ac.uk>

> >2) The service description, as returned in the RDF, lost its CDATA 
> >protection. Perhaps it is correct,
> >
> 
> Um... well, I removed it at your request, so... :-)
>
   No. I was requesting to have the *whole contents* of the RDF tag
surrounded as CDATA. And I am happy that you removed it. What I am talking
about here is to keep CDATA around service description (which is somewhere
inside the whole RDF tag). So we can keep the service description exactly
the same as it was registered without mangling with escaping.
   Sorry if I have not expressed myself clearly.

> Well, I strongly disagree with you :-)   Gosh, THAT has never happened 
> before!  ;-)
>
   Well, my last email crossed your answer here. I came to the same
conclusion: security. So I do not have now such strong desire to keep the
old deregistration in place. However, the new system is for service
instances only - we still can have kids around removing our data types,
namespaces, service types and providers. So we need anyway to think about
these, too - which may give us some way how to deregister services with
signatureIRL.

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Thu Sep 23 00:29:40 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 01:29:40 +0100 (BST)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <415214CB.3010805@illuminae.com>
Message-ID: <Pine.OSF.4.21.0409230122070.824651-100000@ice.ebi.ac.uk>

> >2) The service description, as returned in the RDF, lost its CDATA 
> >protection. Perhaps it is correct,
> >
> 
> Um... well, I removed it at your request, so... :-)
>
   No. I was requesting to have the *whole contents* of the RDF tag
surrounded as CDATA. And I am happy that you removed it. What I am talking
about here is to keep CDATA around service description (which is somewhere
inside the whole RDF tag). So we can keep the service description exactly
the same as it was registered without mangling with escaping.
   Sorry if I have not expressed myself clearly.

> Well, I strongly disagree with you :-)   Gosh, THAT has never happened 
> before!  ;-)
>
   Well, my last email crossed your answer here. I came to the same
conclusion: security. So I do not have now such strong desire to keep the
old deregistration in place. However, the new system is for service
instances only - we still can have kids around removing our data types,
namespaces, service types and providers. So we need anyway to think about
these, too - which may give us some way how to deregister services with
signatureIRL.

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Thu Sep 23 00:31:51 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 01:31:51 +0100 (BST)
Subject: [MOBY-l] Re: [MOBY-dev] URGENT:  Attention ALL SERVICE PROVIDERS
In-Reply-To: <41521590.6000505@illuminae.com>
Message-ID: <Pine.OSF.4.21.0409230130160.824651-100000@ice.ebi.ac.uk>

> >Is it safe to
> >include an empty signatureURL tag, or do I *have* to omit it at all?
> >  
> >
> Yup :-)  That is EXACTLY how it was designed to behave :-)  Just leave 
> it out and your service will auto-deregister the next time the agent 
> runs.  Alternately, you can manually deregister a service without a 
> SignatureURL by using the deregisterService call of the API.
> 
   My question was actually different (and Nina already replied to it):

Can I use safely <signatureURL></signatureURL>? Answer is yes, I can.

Thanks, Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From gordonp at cbr.nrc.ca  Thu Sep 23 01:39:35 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Wed, 22 Sep 2004 22:39:35 -0300 (ADT)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.OSF.4.21.0409230122070.824651-100000@ice.ebi.ac.uk>
Message-ID: <Pine.SO4.4.05.10409222228570.17489-100000@cbrmain>


>    No. I was requesting to have the *whole contents* of the RDF tag
> surrounded as CDATA. And I am happy that you removed it. What I am talking
> about here is to keep CDATA around service description (which is somewhere
> inside the whole RDF tag). So we can keep the service description exactly
> the same as it was registered without mangling with escaping.

[Caution: possible flamebait]

If your client application is making a meaningful distinction between
"<!CDATA[[P & G]]>" and "P &amp; G", you're probably either:

1. Not using a conforming XML parser, which is bad.

or 

2. Relying on distinctions between W3C DOM CDATA Section Nodes and
TextNodes, which is officially frowned upon in the W3C DOM specs. 

In either case this would seriously affect the robustness of the code...

My CDN$0.02. :-)



From gordonp at cbr.nrc.ca  Thu Sep 23 01:39:35 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Wed, 22 Sep 2004 22:39:35 -0300 (ADT)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.OSF.4.21.0409230122070.824651-100000@ice.ebi.ac.uk>
Message-ID: <Pine.SO4.4.05.10409222228570.17489-100000@cbrmain>


>    No. I was requesting to have the *whole contents* of the RDF tag
> surrounded as CDATA. And I am happy that you removed it. What I am talking
> about here is to keep CDATA around service description (which is somewhere
> inside the whole RDF tag). So we can keep the service description exactly
> the same as it was registered without mangling with escaping.

[Caution: possible flamebait]

If your client application is making a meaningful distinction between
"<!CDATA[[P & G]]>" and "P &amp; G", you're probably either:

1. Not using a conforming XML parser, which is bad.

or 

2. Relying on distinctions between W3C DOM CDATA Section Nodes and
TextNodes, which is officially frowned upon in the W3C DOM specs. 

In either case this would seriously affect the robustness of the code...

My CDN$0.02. :-)



From senger at ebi.ac.uk  Thu Sep 23 07:37:05 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 08:37:05 +0100 (BST)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.SO4.4.05.10409222228570.17489-100000@cbrmain>
Message-ID: <Pine.LNX.4.44.0409230832440.3215-100000@bagheera.ebi.ac.uk>

> If your client application is making a meaningful distinction between
> "<!CDATA[[P & G]]>" and "P &amp; G"
>
   The situation I was refering to is this: I send to registry (in service
description) "<!CDATA[[P > G]]>" but I get back (in RDF) "P &amp;gt; G" 
which I think is wrong (because somewhere during the processing it was 
obviously escaped twice - first to "P &gt; G" - which is correct - and 
from here to "P &amp;gt; G" - which seems to be incorrect).

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Thu Sep 23 07:37:05 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 08:37:05 +0100 (BST)
Subject: [MOBY-dev] observations about registrations with RDF
In-Reply-To: <Pine.SO4.4.05.10409222228570.17489-100000@cbrmain>
Message-ID: <Pine.LNX.4.44.0409230832440.3215-100000@bagheera.ebi.ac.uk>

> If your client application is making a meaningful distinction between
> "<!CDATA[[P & G]]>" and "P &amp; G"
>
   The situation I was refering to is this: I send to registry (in service
description) "<!CDATA[[P > G]]>" but I get back (in RDF) "P &amp;gt; G" 
which I think is wrong (because somewhere during the processing it was 
obviously escaped twice - first to "P &gt; G" - which is correct - and 
from here to "P &amp;gt; G" - which seems to be incorrect).

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Thu Sep 23 09:06:49 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 10:06:49 +0100 (BST)
Subject: [MOBY-dev] getting RDF from BioMoby
In-Reply-To: <Pine.OSF.4.21.0409230046070.824651-100000@ice.ebi.ac.uk>
Message-ID: <Pine.OSF.4.21.0409230945120.933195-100000@ice.ebi.ac.uk>

Mark,
   Finally, I started to update my graphical tool for displaying moby
objects. I am going to use now the RDF tree that I can get from the
biomoby registry. Because I plan to add this new features (getting RDF
resources) to the main jMoby library - so anyone can get it, I have few
qustions before I dive into it:

   1) I found these URLs:
http://biomoby.org/RESOURCES/MOBY-S/Objects
http://biomoby.org/RESOURCES/MOBY-S/Services
http://biomoby.org/RESOURCES/MOBY-S/Namespaces
http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances

   But I need URLs that can distinguish between various moby registries. I
noticed that the URLs above were actually redirected to URLs:

http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Objects
http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Services
http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Namespaces
http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/ServiceInstances

   These URLs look better for my purpose - because they seem to include an
address of one particular registry. But I am not sure if these
redirections are done in the same way for everybody who has his/her own
registry installed. So the real question is:

   What part of these URLs is the same for everybody (because it is
hard-coded somewhere in your code), and what part should I allow to
customize? E.g. would it be correct to say that access to any registry can
be expressed as:
   http://<your-registry>/RESOURCES/MOBY-S/Objects
   ...
where <your-registry> by default is http://biomoby.org/ (or
http://mobycentral.cbr.nrc.ca/cgi-bin)?

   2) I remember that you also mentioned a URL that gives back everything
in one go (something with 'all' somewhere). Does it exist?

   3) The Perl code mentions also 'Predicates' but when I try it cannot
find it. Is this anything interesting for me? (Btw, if I use a wrong URL,
the one without thye last part, such as
http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/, it makes your
server unhappy :-) .)

   4) And finally, how stable is this, 'undocumented', part of registry's
API? Can I rely on it and include it in the Java libraries? If it is
stable, it would be nice to have it published on the biomoby pages.

   Thanks (and again I wish you nice stay in the Rockies),
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger




From markw at illuminae.com  Thu Sep 23 10:41:34 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Thu, 23 Sep 2004 03:41:34 -0700
Subject: [MOBY-dev] getting RDF from BioMoby
In-Reply-To: <Pine.OSF.4.21.0409230945120.933195-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0409230945120.933195-100000@ice.ebi.ac.uk>
Message-ID: <4152A85E.7030701@illuminae.com>

Hi Martin,

This part of the system (I wouldn't call it part of the API yet :-) ) is 
not at all stable, but once people start using it I will be forced to 
make some hard decisions and make it stable, so... let's keep working 
through these issues :-)

The code is pretty tightly connected to the main public registry, though 
it could be made more generic if necessary.  At the moment it gets its 
Objects, Namespaces, and Services definitions from a very simple and 
fast CGI that outputs tab-delimited text from direct database calls.   
This would have to be changed to be useful to other registries.  
ServiceInstances come from a call to MOBY::Client::Central, so that is 
less of a problem (you can set the URL of your desired registry in the 
constructor for that object).  I could re-write it to use 
MOBY::Client::Central for all of these calls, but it significantly slows 
it down...  As I say, if it is important to make this script more 
generic I can do so quite easily.

The URL you are looking for is:  http://biomoby.org/RESOURCES/MOBY-S/FULL

I haven't written the subroutine that generates the RDF for predicates yet.

Interesting that the server is unhappy if you don't add extra path 
info... it should "die" in that case and send back an error...???

Thanks for your warm thoughts - it's a bit chilly here in the mountains 
:-)  Gorgeous, but chilly...

M


Martin Senger wrote:

>Mark,
>   Finally, I started to update my graphical tool for displaying moby
>objects. I am going to use now the RDF tree that I can get from the
>biomoby registry. Because I plan to add this new features (getting RDF
>resources) to the main jMoby library - so anyone can get it, I have few
>qustions before I dive into it:
>
>   1) I found these URLs:
>http://biomoby.org/RESOURCES/MOBY-S/Objects
>http://biomoby.org/RESOURCES/MOBY-S/Services
>http://biomoby.org/RESOURCES/MOBY-S/Namespaces
>http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances
>
>   But I need URLs that can distinguish between various moby registries. I
>noticed that the URLs above were actually redirected to URLs:
>
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Objects
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Services
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Namespaces
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/ServiceInstances
>
>   These URLs look better for my purpose - because they seem to include an
>address of one particular registry. But I am not sure if these
>redirections are done in the same way for everybody who has his/her own
>registry installed. So the real question is:
>
>   What part of these URLs is the same for everybody (because it is
>hard-coded somewhere in your code), and what part should I allow to
>customize? E.g. would it be correct to say that access to any registry can
>be expressed as:
>   http://<your-registry>/RESOURCES/MOBY-S/Objects
>   ...
>where <your-registry> by default is http://biomoby.org/ (or
>http://mobycentral.cbr.nrc.ca/cgi-bin)?
>
>   2) I remember that you also mentioned a URL that gives back everything
>in one go (something with 'all' somewhere). Does it exist?
>
>   3) The Perl code mentions also 'Predicates' but when I try it cannot
>find it. Is this anything interesting for me? (Btw, if I use a wrong URL,
>the one without thye last part, such as
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/, it makes your
>server unhappy :-) .)
>
>   4) And finally, how stable is this, 'undocumented', part of registry's
>API? Can I rely on it and include it in the Java libraries? If it is
>stable, it would be nice to have it published on the biomoby pages.
>
>   Thanks (and again I wish you nice stay in the Rockies),
>   Martin
>
>  
>


From markw at illuminae.com  Thu Sep 23 10:41:34 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Thu, 23 Sep 2004 03:41:34 -0700
Subject: [MOBY-dev] getting RDF from BioMoby
In-Reply-To: <Pine.OSF.4.21.0409230945120.933195-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0409230945120.933195-100000@ice.ebi.ac.uk>
Message-ID: <4152A85E.7030701@illuminae.com>

Hi Martin,

This part of the system (I wouldn't call it part of the API yet :-) ) is 
not at all stable, but once people start using it I will be forced to 
make some hard decisions and make it stable, so... let's keep working 
through these issues :-)

The code is pretty tightly connected to the main public registry, though 
it could be made more generic if necessary.  At the moment it gets its 
Objects, Namespaces, and Services definitions from a very simple and 
fast CGI that outputs tab-delimited text from direct database calls.   
This would have to be changed to be useful to other registries.  
ServiceInstances come from a call to MOBY::Client::Central, so that is 
less of a problem (you can set the URL of your desired registry in the 
constructor for that object).  I could re-write it to use 
MOBY::Client::Central for all of these calls, but it significantly slows 
it down...  As I say, if it is important to make this script more 
generic I can do so quite easily.

The URL you are looking for is:  http://biomoby.org/RESOURCES/MOBY-S/FULL

I haven't written the subroutine that generates the RDF for predicates yet.

Interesting that the server is unhappy if you don't add extra path 
info... it should "die" in that case and send back an error...???

Thanks for your warm thoughts - it's a bit chilly here in the mountains 
:-)  Gorgeous, but chilly...

M


Martin Senger wrote:

>Mark,
>   Finally, I started to update my graphical tool for displaying moby
>objects. I am going to use now the RDF tree that I can get from the
>biomoby registry. Because I plan to add this new features (getting RDF
>resources) to the main jMoby library - so anyone can get it, I have few
>qustions before I dive into it:
>
>   1) I found these URLs:
>http://biomoby.org/RESOURCES/MOBY-S/Objects
>http://biomoby.org/RESOURCES/MOBY-S/Services
>http://biomoby.org/RESOURCES/MOBY-S/Namespaces
>http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances
>
>   But I need URLs that can distinguish between various moby registries. I
>noticed that the URLs above were actually redirected to URLs:
>
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Objects
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Services
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/Namespaces
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/ServiceInstances
>
>   These URLs look better for my purpose - because they seem to include an
>address of one particular registry. But I am not sure if these
>redirections are done in the same way for everybody who has his/her own
>registry installed. So the real question is:
>
>   What part of these URLs is the same for everybody (because it is
>hard-coded somewhere in your code), and what part should I allow to
>customize? E.g. would it be correct to say that access to any registry can
>be expressed as:
>   http://<your-registry>/RESOURCES/MOBY-S/Objects
>   ...
>where <your-registry> by default is http://biomoby.org/ (or
>http://mobycentral.cbr.nrc.ca/cgi-bin)?
>
>   2) I remember that you also mentioned a URL that gives back everything
>in one go (something with 'all' somewhere). Does it exist?
>
>   3) The Perl code mentions also 'Predicates' but when I try it cannot
>find it. Is this anything interesting for me? (Btw, if I use a wrong URL,
>the one without thye last part, such as
>http://mobycentral.cbr.nrc.ca/cgi-bin/RESOURCES/MOBY-S/, it makes your
>server unhappy :-) .)
>
>   4) And finally, how stable is this, 'undocumented', part of registry's
>API? Can I rely on it and include it in the Java libraries? If it is
>stable, it would be nice to have it published on the biomoby pages.
>
>   Thanks (and again I wish you nice stay in the Rockies),
>   Martin
>
>  
>


From senger at ebi.ac.uk  Thu Sep 23 11:13:47 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 12:13:47 +0100 (BST)
Subject: [MOBY-dev] getting RDF from BioMoby
In-Reply-To: <4152A85E.7030701@illuminae.com>
Message-ID: <Pine.LNX.4.44.0409231148070.3265-100000@bagheera.ebi.ac.uk>

Mark,
   Thanks for a fast reply.

> This part of the system (I wouldn't call it part of the API yet :-) ) is 
> not at all stable, but once people start using it I will be forced to 
> make some hard decisions and make it stable, so... let's keep working 
> through these issues :-)
>
   Well, I can start using it if I know that it will not disappear anytime 
:-) Catch-22. Anyway, I am willing to play with it (a ka 'use it') and 
later we will see...

> The code is pretty tightly connected to the main public registry, though 
> it could be made more generic if necessary.
>
   It's okay for now. Thanks for the clarification.

   But I have (two) more questions (with sub-questions): The main reason
for using these calls is that I can get "everything" in one go. So this is
useful for people creating things like 'moby browsers' because they
usually need the whole contents of the registry. Because of that I am
willing to dive into RDF if:

   a) it is the best way how to get "everything" (is it? are there better 
ways? DUMP probably is not the best way)

   b) is there really everything?
   I am new to RDF so I am probably wrong. But, for example, when I have
looked into returned RDF of Objects and found CommentedDNASequence object,
I found all its parents (not in one place, but I found them, even though I
do know why all parents are listed directly under CommentedDNASequence,
except Object that is listed separately under VirtualSequence) referred as
'subClassOf' but I could not find (it may be my mistake by reading the
RDF) that it HASA two strings (sequencestring and description) and an
integer (length). Are these HAS[A] relationship there?

   And the second question: Even though it seem quite obvious from reading 
RDF, it would be nice if you provide (even still unofficial) list how are 
the various attributes mapped into RDF predicates. For example, that 
'<contactMail>' becomes 'cd:creator', or that '<Input>' becomes 
'mobyPred:consumes'.

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From senger at ebi.ac.uk  Thu Sep 23 11:13:47 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 12:13:47 +0100 (BST)
Subject: [MOBY-dev] getting RDF from BioMoby
In-Reply-To: <4152A85E.7030701@illuminae.com>
Message-ID: <Pine.LNX.4.44.0409231148070.3265-100000@bagheera.ebi.ac.uk>

Mark,
   Thanks for a fast reply.

> This part of the system (I wouldn't call it part of the API yet :-) ) is 
> not at all stable, but once people start using it I will be forced to 
> make some hard decisions and make it stable, so... let's keep working 
> through these issues :-)
>
   Well, I can start using it if I know that it will not disappear anytime 
:-) Catch-22. Anyway, I am willing to play with it (a ka 'use it') and 
later we will see...

> The code is pretty tightly connected to the main public registry, though 
> it could be made more generic if necessary.
>
   It's okay for now. Thanks for the clarification.

   But I have (two) more questions (with sub-questions): The main reason
for using these calls is that I can get "everything" in one go. So this is
useful for people creating things like 'moby browsers' because they
usually need the whole contents of the registry. Because of that I am
willing to dive into RDF if:

   a) it is the best way how to get "everything" (is it? are there better 
ways? DUMP probably is not the best way)

   b) is there really everything?
   I am new to RDF so I am probably wrong. But, for example, when I have
looked into returned RDF of Objects and found CommentedDNASequence object,
I found all its parents (not in one place, but I found them, even though I
do know why all parents are listed directly under CommentedDNASequence,
except Object that is listed separately under VirtualSequence) referred as
'subClassOf' but I could not find (it may be my mistake by reading the
RDF) that it HASA two strings (sequencestring and description) and an
integer (length). Are these HAS[A] relationship there?

   And the second question: Even though it seem quite obvious from reading 
RDF, it would be nice if you provide (even still unofficial) list how are 
the various attributes mapped into RDF predicates. For example, that 
'<contactMail>' becomes 'cd:creator', or that '<Input>' becomes 
'mobyPred:consumes'.

   Cheers,
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From fgibbons at hms.harvard.edu  Thu Sep 23 13:41:35 2004
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Thu, 23 Sep 2004 09:41:35 -0400
Subject: [MOBY-dev] Service deregistation *must* be fast: perhaps function
 call could precipitate prompt web agent visit?
In-Reply-To: <200409230013.i8N0DbKr031813@portal.open-bio.org>
Message-ID: <5.2.1.1.2.20040923093202.019ebea8@email.med.harvard.edu>

Martin, Mark,

At 08:13 PM 9/22/2004, you wrote:
> >4) I use this list to strongly express how I agree with the last Rebecca
> >email about being still able to deregister a service by calling a
> >deregister method even if the service has been registered with the
> >signatureURL.
> >
> >
> >
>Well, I strongly disagree with you :-)   Gosh, THAT has never happened
>before!  ;-)
>
>You have to remember what the driving force was to create the RDF-based
>deregistration!! The problem is that any kid with the ability to read an
>API could have come in and desroyed our registry by deregistering all of
>the services in it with a 5-line Perl script!  Authentication was just a
>pain in the arse and totally impractical, so the only remaining solution
>was to remove that functionality of MOBY Central and move the problem to
>the service providers machine.  I am loathe to move away from that model
>because in the last 18 months nobody has come up with a better solution!!
>
>If a better solution exists, then we can certainly revisit the issue...

It seems to me that mostly people want rapid deregistration when they're 
actively developing a service. Once it's all set up, the need disappears. I 
have an idea, I don't know if it would be too much work, or too 
impractical, but here it is anyway....

What if different registries had the ability to set different 
deregistration policies. The 'real' Moby Central could allow dereg only by 
removing the RDF file, but the 'test' registry could allow this too, while 
also allowing dereg requests by API calls. I have absolutely NO idea how 
this might be implemented. But for me, I do my development work in the test 
registry, and only when I'm happy with things do I go ahead and put it up 
in the main registry.

Just a thought. I really must side with Rebecca - how can I debug a service 
if I have to wait days before the screwups I made in registering it are 
fixed by moby central's agent crawling over to my web page? Another idea 
might be that a function call causes the agent to come and look for the RDF 
within a short period of time (two minutes, say), and if it's gone the 
service is deregistered. I'm not advocating that the function call be 
blocking, of course, that would be impractical. It would always return 
quickly, and if there were anything returned, it could only indicate that 
the service had previously been registered, that the request had been 
received, and perhaps some estimate of how long before the agent could come 
by and check. There would be no indication of successful deregistration. 
That would require a separate call (to some other routine - findService?) 
after sufficient time had passed.

-Frank

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From markw at illuminae.com  Thu Sep 23 14:04:05 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Thu, 23 Sep 2004 07:04:05 -0700
Subject: [MOBY-dev] Service deregistation *must* be fast: perhaps function
	call could precipitate prompt web agent visit?
In-Reply-To: <5.2.1.1.2.20040923093202.019ebea8@email.med.harvard.edu>
References: <5.2.1.1.2.20040923093202.019ebea8@email.med.harvard.edu>
Message-ID: <4152D7D5.2000501@illuminae.com>

I have said a few times that if you register a service with no 
SignatureURL it will remain in the registry until the agent removes it.  
This is how you should put temporary test services into the registry.  
Also, if you need to modify it more quickly, no problem - Services 
without a SignatureURL can be deregistered with the API call.

This should cover the scenario you are describing.

M


Frank Gibbons wrote:

> Martin, Mark,
>
> At 08:13 PM 9/22/2004, you wrote:
>
>> >4) I use this list to strongly express how I agree with the last 
>> Rebecca
>> >email about being still able to deregister a service by calling a
>> >deregister method even if the service has been registered with the
>> >signatureURL.
>> >
>> >
>> >
>> Well, I strongly disagree with you :-)   Gosh, THAT has never happened
>> before!  ;-)
>>
>> You have to remember what the driving force was to create the RDF-based
>> deregistration!! The problem is that any kid with the ability to read an
>> API could have come in and desroyed our registry by deregistering all of
>> the services in it with a 5-line Perl script!  Authentication was just a
>> pain in the arse and totally impractical, so the only remaining solution
>> was to remove that functionality of MOBY Central and move the problem to
>> the service providers machine.  I am loathe to move away from that model
>> because in the last 18 months nobody has come up with a better 
>> solution!!
>>
>> If a better solution exists, then we can certainly revisit the issue...
>
>
> It seems to me that mostly people want rapid deregistration when 
> they're actively developing a service. Once it's all set up, the need 
> disappears. I have an idea, I don't know if it would be too much work, 
> or too impractical, but here it is anyway....
>
> What if different registries had the ability to set different 
> deregistration policies. The 'real' Moby Central could allow dereg 
> only by removing the RDF file, but the 'test' registry could allow 
> this too, while also allowing dereg requests by API calls. I have 
> absolutely NO idea how this might be implemented. But for me, I do my 
> development work in the test registry, and only when I'm happy with 
> things do I go ahead and put it up in the main registry.
>
> Just a thought. I really must side with Rebecca - how can I debug a 
> service if I have to wait days before the screwups I made in 
> registering it are fixed by moby central's agent crawling over to my 
> web page? Another idea might be that a function call causes the agent 
> to come and look for the RDF within a short period of time (two 
> minutes, say), and if it's gone the service is deregistered. I'm not 
> advocating that the function call be blocking, of course, that would 
> be impractical. It would always return quickly, and if there were 
> anything returned, it could only indicate that the service had 
> previously been registered, that the request had been received, and 
> perhaps some estimate of how long before the agent could come by and 
> check. There would be no indication of successful deregistration. That 
> would require a separate call (to some other routine - findService?) 
> after sufficient time had passed.
>
> -Frank
>
> PhD, Computational Biologist,
> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 
> 02115, USA.
> Tel: 617-432-3555       Fax: 617-432-3557       
> http://llama.med.harvard.edu/~fgibbons
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


From senger at ebi.ac.uk  Thu Sep 23 14:50:32 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 23 Sep 2004 15:50:32 +0100 (BST)
Subject: [MOBY-dev] about service deregistation once again
In-Reply-To: <4152D7D5.2000501@illuminae.com>
Message-ID: <Pine.OSF.4.21.0409231528350.1073682-100000@mozart.ebi.ac.uk>

I like summaries :-) Here is another (subjective) one:

1) There are three needs for deregistration:

   a) A service is registered intentinally temporarily. This is for time
of testing and debugging. Its deregistration is covered by an empty
signatureURL pretty well. The only missing point here is that I would like
to have evn in this phase a possibility to see the service's RDF. At the
moment it si provided by a temporary cgi-bin script. But there should be
more stable way - and Mark is planning to work on it (AFAIK).

   b) A service is registered fully and its service provider decides to
remove the service (actually not the service but a record about the
service in registry, but that we all understand). Here we have a scenario
with removing service's RDF on the service provider side, and waiting for
the agent. It sounds okay - mainly because it is quite probable that the
service itself is defunc now, so the delay with deregistration does not do
much harm.

   c) A service is registered but needs a change (let's call it a
Rebecca's scenario). Here service provider needs a rapid action - because
without a correct record in registry his/her service cannot be used -
because many general clients takes information about services only from
registry. I think here we need improvements in deregistration because it
is too late to wait for any agent. The initiative here should start from
the service provider.

   What can be done for the case ad c)?
   There are (IMO) two general solutions:

   i) Registry can give something to the registrant (a token) that can be
used for authorized deregistration. This was the intention of the ID in
the registration object. We may revive its usage for this option - but it
still have some security implication (e.g. at themoment the moby database
is open, faik, so the IDs can be found).

   ii) Or, registry takes some action going to the service provider side
to confirm the authenticity of the deregistration request (here we
had/have plan with contact-email, and here fits actually also the agent
scenario). The problem is that we still need a mechanism that can trigger
the registry to take the action. And this is missing.
   So (and here is my main suggestion) why not this: A service provider
will still use a deregisterService call, and the registry - when it sees
that the service has a signatureURL, sends agent *now* to this side. Of
course, the service provider must make sure that the RDF is either
updated, or missing (in which case he/she will register again).

   What do you think about this?

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From rebecca.ernst at gsf.de  Fri Sep 24 07:22:15 2004
From: rebecca.ernst at gsf.de (Rebecca Ernst)
Date: Fri, 24 Sep 2004 09:22:15 +0200
Subject: [MOBY-dev] about service deregistation once again
In-Reply-To: <Pine.OSF.4.21.0409231528350.1073682-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0409231528350.1073682-100000@mozart.ebi.ac.uk>
Message-ID: <4153CB27.6000208@gsf.de>

Hi Martin, (Mark, Frank, etc.)!

This was a useful summary! Obviously Mark had the one scenario in mind 
(a) and Frank and I had another one in mind (c).
I quite like the idea of asking the agent for a visit. This would 
completely solve my problem.
Mark, would this be possible? Easy to implement?

Cheers,
Rebecca



Martin Senger wrote:

>I like summaries :-) Here is another (subjective) one:
>
>1) There are three needs for deregistration:
>
>   a) A service is registered intentinally temporarily. This is for time
>of testing and debugging. Its deregistration is covered by an empty
>signatureURL pretty well. The only missing point here is that I would like
>to have evn in this phase a possibility to see the service's RDF. At the
>moment it si provided by a temporary cgi-bin script. But there should be
>more stable way - and Mark is planning to work on it (AFAIK).
>
>   b) A service is registered fully and its service provider decides to
>remove the service (actually not the service but a record about the
>service in registry, but that we all understand). Here we have a scenario
>with removing service's RDF on the service provider side, and waiting for
>the agent. It sounds okay - mainly because it is quite probable that the
>service itself is defunc now, so the delay with deregistration does not do
>much harm.
>
>   c) A service is registered but needs a change (let's call it a
>Rebecca's scenario). Here service provider needs a rapid action - because
>without a correct record in registry his/her service cannot be used -
>because many general clients takes information about services only from
>registry. I think here we need improvements in deregistration because it
>is too late to wait for any agent. The initiative here should start from
>the service provider.
>
>   What can be done for the case ad c)?
>   There are (IMO) two general solutions:
>
>   i) Registry can give something to the registrant (a token) that can be
>used for authorized deregistration. This was the intention of the ID in
>the registration object. We may revive its usage for this option - but it
>still have some security implication (e.g. at themoment the moby database
>is open, faik, so the IDs can be found).
>
>   ii) Or, registry takes some action going to the service provider side
>to confirm the authenticity of the deregistration request (here we
>had/have plan with contact-email, and here fits actually also the agent
>scenario). The problem is that we still need a mechanism that can trigger
>the registry to take the action. And this is missing.
>   So (and here is my main suggestion) why not this: A service provider
>will still use a deregisterService call, and the registry - when it sees
>that the service has a signatureURL, sends agent *now* to this side. Of
>course, the service provider must make sure that the RDF is either
>updated, or missing (in which case he/she will register again).
>
>   What do you think about this?
>
>   Martin
>
>  
>

-- 
Rebecca Ernst
MIPS, Inst. for Bioinformatics
GSF Research Center for Environment and Health
Ingolstaedter Landstr. 1
85764 Neuherberg
fon: +49 89 3187 3583
email: Rebecca.Ernst at gsf.de



From senger at ebi.ac.uk  Fri Sep 24 11:10:37 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 24 Sep 2004 12:10:37 +0100 (BST)
Subject: [MOBY-dev] Re: about service deregistation once again (a bug?)
In-Reply-To: <Pine.OSF.4.21.0409231528350.1073682-100000@mozart.ebi.ac.uk>
Message-ID: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>

One more observation - I suppose that there is a bug:

Nina explained that the agent would not go to a service that had been
registered without signatureURL, neither to a service that had been
registered with an empty signatureURL tag (such as
<signatureURL></signatureURL>).

However, the old-fashioned deregistration call will be rejected for
services that had been registered with an empty signatureURL, telling you
that the agent would take care about it. Which would not - see paragraph
above.

So, there are unregisterable services... (fortunately, there are many of 
them now, but only in the testing registry :-))

Cheers,
Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From markw at illuminae.com  Fri Sep 24 13:24:00 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 24 Sep 2004 06:24:00 -0700
Subject: [MOBY-dev] about service deregistation once again
In-Reply-To: <4153CB27.6000208@gsf.de>
References: <Pine.OSF.4.21.0409231528350.1073682-100000@mozart.ebi.ac.uk>
	<4153CB27.6000208@gsf.de>
Message-ID: <41541FF0.2090701@illuminae.com>

Nina and I are working on it right now :-)  Should be done by next week,

M

Rebecca Ernst wrote:

> Hi Martin, (Mark, Frank, etc.)!
>
> This was a useful summary! Obviously Mark had the one scenario in mind 
> (a) and Frank and I had another one in mind (c).
> I quite like the idea of asking the agent for a visit. This would 
> completely solve my problem.
> Mark, would this be possible? Easy to implement?
>
> Cheers,
> Rebecca
>
>
>
> Martin Senger wrote:
>
>> I like summaries :-) Here is another (subjective) one:
>>
>> 1) There are three needs for deregistration:
>>
>>   a) A service is registered intentinally temporarily. This is for time
>> of testing and debugging. Its deregistration is covered by an empty
>> signatureURL pretty well. The only missing point here is that I would 
>> like
>> to have evn in this phase a possibility to see the service's RDF. At the
>> moment it si provided by a temporary cgi-bin script. But there should be
>> more stable way - and Mark is planning to work on it (AFAIK).
>>
>>   b) A service is registered fully and its service provider decides to
>> remove the service (actually not the service but a record about the
>> service in registry, but that we all understand). Here we have a 
>> scenario
>> with removing service's RDF on the service provider side, and waiting 
>> for
>> the agent. It sounds okay - mainly because it is quite probable that the
>> service itself is defunc now, so the delay with deregistration does 
>> not do
>> much harm.
>>
>>   c) A service is registered but needs a change (let's call it a
>> Rebecca's scenario). Here service provider needs a rapid action - 
>> because
>> without a correct record in registry his/her service cannot be used -
>> because many general clients takes information about services only from
>> registry. I think here we need improvements in deregistration because it
>> is too late to wait for any agent. The initiative here should start from
>> the service provider.
>>
>>   What can be done for the case ad c)?
>>   There are (IMO) two general solutions:
>>
>>   i) Registry can give something to the registrant (a token) that can be
>> used for authorized deregistration. This was the intention of the ID in
>> the registration object. We may revive its usage for this option - 
>> but it
>> still have some security implication (e.g. at themoment the moby 
>> database
>> is open, faik, so the IDs can be found).
>>
>>   ii) Or, registry takes some action going to the service provider side
>> to confirm the authenticity of the deregistration request (here we
>> had/have plan with contact-email, and here fits actually also the agent
>> scenario). The problem is that we still need a mechanism that can 
>> trigger
>> the registry to take the action. And this is missing.
>>   So (and here is my main suggestion) why not this: A service provider
>> will still use a deregisterService call, and the registry - when it sees
>> that the service has a signatureURL, sends agent *now* to this side. Of
>> course, the service provider must make sure that the RDF is either
>> updated, or missing (in which case he/she will register again).
>>
>>   What do you think about this?
>>
>>   Martin
>>
>>  
>>
>


From markw at illuminae.com  Fri Sep 24 13:26:49 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 24 Sep 2004 06:26:49 -0700
Subject: [MOBY-dev] Re: about service deregistation once again (a bug?)
In-Reply-To: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>
Message-ID: <41542099.60700@illuminae.com>

Martin Senger wrote:

>Nina explained that the agent would not go to a service that had been
>registered without signatureURL, neither to a service that had been
>registered with an empty signatureURL tag (such as
><signatureURL></signatureURL>).
>  
>
Aren't these two statements identical?

>However, the old-fashioned deregistration call will be rejected for
>services that had been registered with an empty signatureURL, telling you
>that the agent would take care about it. Which would not - see paragraph
>above.
>  
>
Unless it is not functioning correctly, the old fashioned deregisration 
call WILL NOT be rejected for services that have been registered with an 
empty signature URL.  Is that the bug you are reporting?

M



From edward.kawas at gmail.com  Fri Sep 24 15:20:17 2004
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Fri, 24 Sep 2004 08:20:17 -0700
Subject: [MOBY-dev] Question about authorities
In-Reply-To: <41542099.60700@illuminae.com>
References: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>
	<41542099.60700@illuminae.com>
Message-ID: <b4bcf7b1040924082063363be6@mail.gmail.com>

I have a quick question on the authorities (URI) part of registering
objects, services, etc.

URI is a domain, e.g. www.illuminae.com
would the following work?

illuminae.com  or  mobycentral.cbr.nrc.ca ?

Thanks,

Eddie


From markw at illuminae.com  Fri Sep 24 15:22:47 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 24 Sep 2004 08:22:47 -0700
Subject: [MOBY-dev] Question about authorities
In-Reply-To: <b4bcf7b1040924082063363be6@mail.gmail.com>
References: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>	<41542099.60700@illuminae.com>
	<b4bcf7b1040924082063363be6@mail.gmail.com>
Message-ID: <41543BC7.1080202@illuminae.com>

yes


Eddie Kawas wrote:

>I have a quick question on the authorities (URI) part of registering
>objects, services, etc.
>
>URI is a domain, e.g. www.illuminae.com
>would the following work?
>
>illuminae.com  or  mobycentral.cbr.nrc.ca ?
>
>Thanks,
>
>Eddie
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>  
>


From markw at illuminae.com  Fri Sep 24 15:23:29 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 24 Sep 2004 08:23:29 -0700
Subject: [MOBY-dev] Question about authorities
In-Reply-To: <b4bcf7b1040924082063363be6@mail.gmail.com>
References: <Pine.LNX.4.44.0409241204020.4225-100000@bagheera.ebi.ac.uk>	<41542099.60700@illuminae.com>
	<b4bcf7b1040924082063363be6@mail.gmail.com>
Message-ID: <41543BF1.8030501@illuminae.com>

IMO it is *preferable* to have the domain without the "www" prefix, but 
that's just me.

M

Eddie Kawas wrote:

>I have a quick question on the authorities (URI) part of registering
>objects, services, etc.
>
>URI is a domain, e.g. www.illuminae.com
>would the following work?
>
>illuminae.com  or  mobycentral.cbr.nrc.ca ?
>
>Thanks,
>
>Eddie
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>  
>


From gss at ncgr.org  Fri Sep 24 15:44:35 2004
From: gss at ncgr.org (Gary Schiltz)
Date: Fri, 24 Sep 2004 09:44:35 -0600
Subject: [MOBY-dev] MOBY Meeting: 20-21 November in Santa Fe
Message-ID: <415440E3.2070000@ncgr.org>

Hello MOBY'ers!

The next MOBY meeting will be held at NCGR (www.ncgr.org) in Santa Fe, 
New Mexico, the weekend of 20-21 November, 2004. We'll finish by about 
3:00 MST on Sunday, so you could catch a flight as early as about 5:30. 
Also, Mark Wilkinson will be giving a talk on MOBY Services at NCGR on 
November 19 (some time in the afternoon, I believe); everyone is welcome 
to attend, so consider coming a day early. I'll soon put together a page 
of information with an agenda, links to accommodations covering a range 
of prices, and other details. There will be a small registration fee to 
cover breakfast and lunch for Saturday and Sunday.

In the interim, please post suggestions for topics to cover at the meeting.

----

Gary Schiltz
Principal Software Engineer
National Center for Genome Resources
Santa Fe, New Mexico

gss at ncgr.org
505-995-4414 (Work)
505-670-5983 (Cell)


From senger at ebi.ac.uk  Fri Sep 24 19:26:57 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 24 Sep 2004 20:26:57 +0100 (BST)
Subject: [MOBY-dev] Re: about service deregistation once again (a bug?)
In-Reply-To: <41542099.60700@illuminae.com>
Message-ID: <Pine.OSF.4.21.0409241507580.528084-100000@ice.ebi.ac.uk>

> >Nina explained that the agent would not go to a service that had been
> >registered without signatureURL, neither to a service that had been
> >registered with an empty signatureURL tag (such as
> ><signatureURL></signatureURL>).
> >  
> >
> Aren't these two statements identical?
>
   C'mon, of course, they are not.
   I can send a registration without any signatureURL tag, at all, or I
can send it with <signatureURL></signatureURL>.
   However, it does not matter anymore, see below...
 
> >However, the old-fashioned deregistration call will be rejected for
> >services that had been registered with an empty signatureURL, telling you
> >that the agent would take care about it. Which would not - see paragraph
> >above.
> >  
> >
> Unless it is not functioning correctly, the old fashioned deregisration 
> call WILL NOT be rejected for services that have been registered with an 
> empty signature URL.  Is that the bug you are reporting?
>
   Yes, it was... But not anymore... the bug was in my code that had not
properly printed signatureURL (so I thought that it was not there). Sorry
for that, it happens (at least one good output from this email exchange is
that I found that signatureURL was missing in the documentation of the
Service List Response Object - could you add it there?).

   Cheers,
   Martin

PS. I wonder if you got my email asking about RDF output...? (Perhaps it
was missed under the peaks of Rockies :-))
M.

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger




From markw at illuminae.com  Sat Sep 25 18:59:28 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Sat, 25 Sep 2004 11:59:28 -0700
Subject: [MOBY-dev] Re: about service deregistation once again (a bug?)
In-Reply-To: <Pine.OSF.4.21.0409241507580.528084-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0409241507580.528084-100000@ice.ebi.ac.uk>
Message-ID: <4155C010.8000100@illuminae.com>



>>Aren't these two statements identical?
>>    
>>
>   C'mon, of course, they are not.
>   I can send a registration without any signatureURL tag, at all, or I
>can send it with <signatureURL></signatureURL>.
>  
>
I think the two cases are treated identically by MOBY Central.


>   Yes, it was... But not anymore... the bug was in my code that had not
>properly printed signatureURL (so I thought that it was not there).
>

Cool!

>that I found that signatureURL was missing in the documentation of the
>Service List Response Object - could you add it there?).
>  
>
Yup.  I'll do that when I get back. (remind me if I forget...)

>PS. I wonder if you got my email asking about RDF output...? (Perhaps it
>was missed under the peaks of Rockies :-))
>  
>
I'll look back through my messages.  I am having trouble understanding 
messages this week due to the thin mountain air ;-)

M


>M.
>
>  
>


From markw at illuminae.com  Sat Sep 25 19:04:13 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Sat, 25 Sep 2004 12:04:13 -0700
Subject: [MOBY-dev] Re: about service deregistation once again (a bug?)
In-Reply-To: <Pine.OSF.4.21.0409241507580.528084-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0409241507580.528084-100000@ice.ebi.ac.uk>
Message-ID: <4155C12D.6020305@illuminae.com>

b.t.w. Martin, I gave a Taverna demo today at the SAB meeting.  There is 
general agreement among the bioinformatics platform members (Genome 
Canada) that we should adopt Taverna as our recommended MOBY/Emboss 
client :-)  Yay!

M


Martin Senger wrote:

>>>Nina explained that the agent would not go to a service that had been
>>>registered without signatureURL, neither to a service that had been
>>>registered with an empty signatureURL tag (such as
>>><signatureURL></signatureURL>).
>>> 
>>>
>>>      
>>>
>>Aren't these two statements identical?
>>
>>    
>>
>   C'mon, of course, they are not.
>   I can send a registration without any signatureURL tag, at all, or I
>can send it with <signatureURL></signatureURL>.
>   However, it does not matter anymore, see below...
> 
>  
>
>>>However, the old-fashioned deregistration call will be rejected for
>>>services that had been registered with an empty signatureURL, telling you
>>>that the agent would take care about it. Which would not - see paragraph
>>>above.
>>> 
>>>
>>>      
>>>
>>Unless it is not functioning correctly, the old fashioned deregisration 
>>call WILL NOT be rejected for services that have been registered with an 
>>empty signature URL.  Is that the bug you are reporting?
>>
>>    
>>
>   Yes, it was... But not anymore... the bug was in my code that had not
>properly printed signatureURL (so I thought that it was not there). Sorry
>for that, it happens (at least one good output from this email exchange is
>that I found that signatureURL was missing in the documentation of the
>Service List Response Object - could you add it there?).
>
>   Cheers,
>   Martin
>
>PS. I wonder if you got my email asking about RDF output...? (Perhaps it
>was missed under the peaks of Rockies :-))
>M.
>
>  
>