From lstein at cshl.edu  Mon Feb  2 07:45:11 2004
From: lstein at cshl.edu (Lincoln Stein)
Date: Mon Feb  2 07:51:55 2004
Subject: [MOBY-l] Re: namespace
In-Reply-To: <Pine.GSO.4.30.0401280901010.24283-100000@groucho.sdsc.edu>
References: <Pine.GSO.4.30.0401280901010.24283-100000@groucho.sdsc.edu>
Message-ID: <200402021445.11518.lstein@cshl.edu>

When you search MOBY central, can you tell it that you're just 
interested in objects from a particular namesspace?  This would 
really help for sharpening the search.

Lincoln

On Wednesday 28 January 2004 07:07 pm, Ken Steube wrote:
> I'm not sure I understand the question...I'll try to answer and you
> can reply for more info.
>
> An object belongs to a particular namespace
> <Object namespace=AGI_LocusCode id=At3g19100/>
> belongs to AGI_LocusCode. Sometimes you might see the namespace
> might being left blank if it's not important (such as for the
> Integer object inside a GenericSequence).
>
> I wouldn't really say a service belongs to a namespace, rather we
> say it accepts objects from particular namespaces. Or a service
> might accept objects of a certain type from any namespace if the
> namespace isn't important (such as BLAST: can accept a DNA seq from
> any namespace so the namespace isn't generally critical info for
> BLAST).
>
> Ken
>
> On Wed, 28 Jan 2004, Ardavan Kanani wrote:
> > Ken,
> >
> > Thanks for responding to my question.  My question is more about
> > an object belonging to a namespace or services belonging to a
> > namespace and not accepting or outputting objects from a
> > particular namespace. Do objects belong to particular namespaces?
> >  If that's the case where in the object registration should I
> > declare its namespace?  Since services are, sort of, objects too,
> > where do I specify what namespace they belong to.  I am trying to
> > create all my objects and services under a namespace called
> > "haplotyping_study"  I might be totally confused as how the
> > namespaces work on MOBY.  I am coming from an object oriented
> > world.  So when I see the disjoint between objects and services
> > in MOBY I get confused.
> >
> > Thanks, Ardavan Kanani
> >
> > On Jan 28, 2004, at 11:36 AM, Ken Steube wrote:
> > > On Wed, 28 Jan 2004, Ardavan Kanani wrote:
> > >> Mark,
> > >> How would I register an object or a service under a particular
> > >> namespace?  I looked at the API doc and the signature for
> > >> registerObjectClass and registerServiceName/Type does not
> > >> include a namespace parameter.
> > >
> > > Here is the script that registers my plantspGetProtein service
> > > to accept an Object from any of the namespaces
> > > ['AGI_LocusCode', 'NCBI_gi', 'SDSC_fg'].
> > >
> > > Ken
> > >
> > >
> > >
> > >
> > >
> > > #!/usr/local/bin/perl5.6.1
> > > use warnings 'all';	# Issue warnings about suspicious
> > > programming use strict;		# Must declare and initialize all
> > > variables
> > >
> > > ###############################################################
> > >######## ##
> > > # This script will register the plantspGetProtein MOBY service
> > > ###############################################################
> > >######## ##
> > >
> > > use MOBY::Client::Central;
> > > use MOBY::Client::Service;
> > >
> > > my $Central = MOBY::Client::Central->new();
> > >
> > > my $reg = $Central->registerService(
> > >   serviceName  => 'plantspGetProtein',
> > >   authURI      => 'www.sdsc.edu',
> > >   contactEmail => 'steube@sdsc.edu',
> > >   description  => "Retrieves a protein sequence from the
> > > PlantsP database (proteins related to phosphorylation,
> > > transporters and ubiquitin)",
> > >   URL          =>
> > > 'http://plantsp.sdsc.edu/cgi-bin/MOBY/PlantsP_dispatcher.cgi',
> > >   input        => [ ['', ["Object" => ['AGI_LocusCode',
> > > 'NCBI_gi', 'SDSC_fg']]], ],
> > >   output       => [ ['', ["AminoAcidSequence" => []]], ],
> > >   category     => "moby",
> > >   serviceType  => "Retrieval",
> > > );
> > > die "Bad return value from registerService" unless $reg;
> > > if ($reg->success == 1){
> > >   print "Registration successful\n\n";
> > > }
> > > else {
> > >   print "Registration failed: ", $reg->message, "\n";
> > > }
> > >
> > >
> > > --
> > > --
> > > --
> > > Ken Steube
> > > San Diego Supercomputer Center
> > > University of California, San Diego
> > > Mail code 0537, CRB room 207
> > > 9500 Gilman Drive
> > > San Diego, California, 92093-0537  USA
> > > FAX (858) 822-3610

-- 
Lincoln D. Stein
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724
From mwilkinson at mobile.rogers.com  Mon Feb  2 09:50:33 2004
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Mon Feb  2 10:04:28 2004
Subject: [MOBY-l] Re: namespace
Message-ID: <200402021504.i12F4OEs025278@portal.open-bio.org>

Yes, you can.

M

(hi from sunny Vancouver!)


!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!
From VNarayan at mail.brc.mcw.edu  Mon Feb  2 15:08:35 2004
From: VNarayan at mail.brc.mcw.edu (Vijay Narayanasamy)
Date: Mon Feb  2 15:19:15 2004
Subject: [MOBY-l] moby-l@biomoby.org
Message-ID: <295CC5EB4257D411B34D00D0B7748F4432DE8C@baldar.brc.mcw.edu>

Hi Mark,

I am currently developing a PubFetch Service for Agricola literature
database similar to PubFetch service for PubMed.

I have two services. Both use namespace "Global_Keyword" for inputs and
outputs and the object is "Object" (I'll change the namespace and object
type once I get it working)

One service takes the query and retrieves the Agricola accession numbers.
This works OK!


The second service takes the Agricola accession numbers as input and gets
the document in Medline Like format as shown in the following MOBY response

<?xml version='1.0' encoding='UTF-8'?>
      <moby:MOBY xmlns:moby='http://www.biomoby.org/moby'>
        <moby:Response moby:authority='http://www.illuminae.com'>
        
        <moby:queryResponse>
            <Simple><moby:Object namespace='Global_Keyword'
id='IND23321742'><![CDATA[
AN -   IND23321742   
XX -   3321-74260
OWN -   AGL
XX -   F600
XX -   F200
AU -   Lee, G.I.
TI -   1H, 13C and 15N resonance assignments of the kinase-interacting FHA
domain of Arabidopsis thaliana kinase-associated protein phosphatase.
PG -   p. 253-254.
GN -   Letter to the editor.
XX -   Includes references
OT -   spectral analysis
OT -   nuclear magnetic resonance spectroscopy
OT -   amino acid sequences  Internet-resource.
AU -   Li, J.
AU -   Walker, J.C.
AU -   Van Doren, S.R.
SO -   Journal of biomolecular NMR.  J. biomol. NMR  Mar 2003. v. 25 (3)
0925-2738  JBNME9  nnas  jnl52412
XX -   0667-68060
CA -     QP519.9.N83 J68
http://www.kluweronline.com/issn/0925-2738/contents
XX -   20030508  20030509  00000000  IND  GK1
Non-US]]></moby:Object></Simple>
        </moby:queryResponse>
        
    </moby:Response>
      </moby:MOBY>


But the MOBY client (Old Client) reports "service unavailable" for this
service. I don't see any error message in the apache log files. What could
be a possible reason? 

Thank you,

Vijay



Vijay Narayanasamy
Project Programmer / Analyst
Bioinformatics Program, Human and Molecular Genetics Center
Medical College of Wisconsin
8701, W. Watertown Plank Road
Milwaukee, WI 53226
414-456-8026
vnarayan@mcw.edu 
http://brc.mcw.edu/ 


From VNarayan at mail.brc.mcw.edu  Mon Feb  2 18:39:05 2004
From: VNarayan at mail.brc.mcw.edu (Vijay Narayanasamy)
Date: Mon Feb  2 18:49:46 2004
Subject: [MOBY-l] moby-l@biomoby.org
Message-ID: <295CC5EB4257D411B34D00D0B7748F4432DE92@baldar.brc.mcw.edu>

Thank you Ken, The problem was caused by printing from the Java code
(System.out.println()). I use Perl Inline Java module to wrap the Java
Pubfetch program for Agricola.

The PubFetch service for Agricola works OK now at my local BioMOBY. I will
register the service with public BioMOBY soon.

Thank you,

Vijay

-----Original Message-----
From: Ken Steube [mailto:steube@sdsc.edu] 
Sent: Monday, February 02, 2004 3:22 PM
To: Vijay Narayanasamy
Cc: 'Mark Wilkinson'; Twigger, Simon; 'moby-l@biomoby.org'
Subject: Re: [MOBY-l] moby-l@biomoby.org

Mark may still be preoccupied with moving so I'll take a crack at this.

> But the MOBY client (Old Client) reports "service unavailable"

You can't always debug a service thru the client...you don't get any error
messages. Here's a summary of what I usually do when in your situation:

There are several reasons services fail and you have to do some
experiments to figure it out:

1) Maybe the CGI is not being called.  Go to the top of your dispatcher
CGI (the one you give when you register the service) and before the
dispatch_with() call add this:

  die "testing xxxxxx";

If you see xxxxxx in your http error log you know it's getting to this
CGI.

2) Maybe it's not dispatching. Go to the top of the method for your
service (sub has the same name as the service) and add a line at the top

  return("testing yyyyyy");

Run the service from a script at the command line and see if you get this
yyyyyy line returned from the service. Once you get it you know the
service is being called.

3) Maybe your service has a compile-time error and the error message
doesn't wind up in the http error log for some reason. Run a script like
the attached to execute your service at the command line. The attached
script runs the method of a service by calling it as a subroutine with no
SOAP involvement. Look for compiler errors.

Ken




On Mon, 2 Feb 2004, Vijay Narayanasamy wrote:

> Hi Mark,
>
> I am currently developing a PubFetch Service for Agricola literature
> database similar to PubFetch service for PubMed.
>
> I have two services. Both use namespace "Global_Keyword" for inputs and
> outputs and the object is "Object" (I'll change the namespace and object
> type once I get it working)
>
> One service takes the query and retrieves the Agricola accession numbers.
> This works OK!
>
>
> The second service takes the Agricola accession numbers as input and gets
> the document in Medline Like format as shown in the following MOBY
response
>
> <?xml version='1.0' encoding='UTF-8'?>
>       <moby:MOBY xmlns:moby='http://www.biomoby.org/moby'>
>         <moby:Response moby:authority='http://www.illuminae.com'>
>
>         <moby:queryResponse>
>             <Simple><moby:Object namespace='Global_Keyword'
> id='IND23321742'><![CDATA[
> AN -   IND23321742
> XX -   3321-74260
> OWN -   AGL
> XX -   F600
> XX -   F200
> AU -   Lee, G.I.
> TI -   1H, 13C and 15N resonance assignments of the kinase-interacting FHA
> domain of Arabidopsis thaliana kinase-associated protein phosphatase.
> PG -   p. 253-254.
> GN -   Letter to the editor.
> XX -   Includes references
> OT -   spectral analysis
> OT -   nuclear magnetic resonance spectroscopy
> OT -   amino acid sequences  Internet-resource.
> AU -   Li, J.
> AU -   Walker, J.C.
> AU -   Van Doren, S.R.
> SO -   Journal of biomolecular NMR.  J. biomol. NMR  Mar 2003. v. 25 (3)
> 0925-2738  JBNME9  nnas  jnl52412
> XX -   0667-68060
> CA -     QP519.9.N83 J68
> http://www.kluweronline.com/issn/0925-2738/contents
> XX -   20030508  20030509  00000000  IND  GK1
> Non-US]]></moby:Object></Simple>
>         </moby:queryResponse>
>
>     </moby:Response>
>       </moby:MOBY>
>
>
> But the MOBY client (Old Client) reports "service unavailable" for this
> service. I don't see any error message in the apache log files. What could
> be a possible reason?
>
> Thank you,
>
> Vijay
>
>
>
> Vijay Narayanasamy
> Project Programmer / Analyst
> Bioinformatics Program, Human and Molecular Genetics Center
> Medical College of Wisconsin
> 8701, W. Watertown Plank Road
> Milwaukee, WI 53226
> 414-456-8026
> vnarayan@mcw.edu
> http://brc.mcw.edu/
>
>
> _______________________________________________
> moby-l mailing list
> moby-l@biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
>

-- 
--
--
Ken Steube
San Diego Supercomputer Center
University of California, San Diego, MC 0505
9500 Gilman Drive
San Diego, California, 92093-0505  USA
FAX (858) 822-3610
From mwilkinson at mobile.rogers.com  Mon Feb  2 22:17:15 2004
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Mon Feb  2 22:28:48 2004
Subject: [MOBY-l] moby-l@biomoby.org
Message-ID: <200402030328.i133SkHH031642@portal.open-bio.org>

Is it still the case that nobody has been able to access a moby service using Java without needing inline perl?  If so, then we really need to figure out why ASAP!

I am pretty sure that Martin and I figured out how to do it at the last I3C meeting, but we might not have disseminated the information to others.

Can someone please say "aye" if they have working code in Java?  Thanks!

Mark


!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!
From steube at sdsc.edu  Mon Feb  2 16:21:31 2004
From: steube at sdsc.edu (Ken Steube)
Date: Wed Feb  4 00:32:58 2004
Subject: [MOBY-l] moby-l@biomoby.org
In-Reply-To: <295CC5EB4257D411B34D00D0B7748F4432DE8C@baldar.brc.mcw.edu>
Message-ID: <Pine.GSO.4.30.0402021312160.5579-200000@groucho.sdsc.edu>

Mark may still be preoccupied with moving so I'll take a crack at this.

> But the MOBY client (Old Client) reports "service unavailable"

You can't always debug a service thru the client...you don't get any error
messages. Here's a summary of what I usually do when in your situation:

There are several reasons services fail and you have to do some
experiments to figure it out:

1) Maybe the CGI is not being called.  Go to the top of your dispatcher
CGI (the one you give when you register the service) and before the
dispatch_with() call add this:

  die "testing xxxxxx";

If you see xxxxxx in your http error log you know it's getting to this
CGI.

2) Maybe it's not dispatching. Go to the top of the method for your
service (sub has the same name as the service) and add a line at the top

  return("testing yyyyyy");

Run the service from a script at the command line and see if you get this
yyyyyy line returned from the service. Once you get it you know the
service is being called.

3) Maybe your service has a compile-time error and the error message
doesn't wind up in the http error log for some reason. Run a script like
the attached to execute your service at the command line. The attached
script runs the method of a service by calling it as a subroutine with no
SOAP involvement. Look for compiler errors.

Ken




On Mon, 2 Feb 2004, Vijay Narayanasamy wrote:

> Hi Mark,
>
> I am currently developing a PubFetch Service for Agricola literature
> database similar to PubFetch service for PubMed.
>
> I have two services. Both use namespace "Global_Keyword" for inputs and
> outputs and the object is "Object" (I'll change the namespace and object
> type once I get it working)
>
> One service takes the query and retrieves the Agricola accession numbers.
> This works OK!
>
>
> The second service takes the Agricola accession numbers as input and gets
> the document in Medline Like format as shown in the following MOBY response
>
> <?xml version='1.0' encoding='UTF-8'?>
>       <moby:MOBY xmlns:moby='http://www.biomoby.org/moby'>
>         <moby:Response moby:authority='http://www.illuminae.com'>
>
>         <moby:queryResponse>
>             <Simple><moby:Object namespace='Global_Keyword'
> id='IND23321742'><![CDATA[
> AN -   IND23321742
> XX -   3321-74260
> OWN -   AGL
> XX -   F600
> XX -   F200
> AU -   Lee, G.I.
> TI -   1H, 13C and 15N resonance assignments of the kinase-interacting FHA
> domain of Arabidopsis thaliana kinase-associated protein phosphatase.
> PG -   p. 253-254.
> GN -   Letter to the editor.
> XX -   Includes references
> OT -   spectral analysis
> OT -   nuclear magnetic resonance spectroscopy
> OT -   amino acid sequences  Internet-resource.
> AU -   Li, J.
> AU -   Walker, J.C.
> AU -   Van Doren, S.R.
> SO -   Journal of biomolecular NMR.  J. biomol. NMR  Mar 2003. v. 25 (3)
> 0925-2738  JBNME9  nnas  jnl52412
> XX -   0667-68060
> CA -     QP519.9.N83 J68
> http://www.kluweronline.com/issn/0925-2738/contents
> XX -   20030508  20030509  00000000  IND  GK1
> Non-US]]></moby:Object></Simple>
>         </moby:queryResponse>
>
>     </moby:Response>
>       </moby:MOBY>
>
>
> But the MOBY client (Old Client) reports "service unavailable" for this
> service. I don't see any error message in the apache log files. What could
> be a possible reason?
>
> Thank you,
>
> Vijay
>
>
>
> Vijay Narayanasamy
> Project Programmer / Analyst
> Bioinformatics Program, Human and Molecular Genetics Center
> Medical College of Wisconsin
> 8701, W. Watertown Plank Road
> Milwaukee, WI 53226
> 414-456-8026
> vnarayan@mcw.edu
> http://brc.mcw.edu/
>
>
> _______________________________________________
> moby-l mailing list
> moby-l@biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
>

-- 
--
--
Ken Steube
San Diego Supercomputer Center
University of California, San Diego, MC 0505
9500 Gilman Drive
San Diego, California, 92093-0505  USA
FAX (858) 822-3610
-------------- next part --------------
#!/usr/local/bin/perl5.6.1

# Name of .pm file containing service method "test_SequenceToFASTA"
use MobyEd_services;

# This is a sample input to a service
my $query = qq{<?xml version='1.0' encoding='UTF-8'?>
<moby:MOBY xmlns:moby='http://www.biomoby.org/moby-s'>
<moby:Query>
<moby:queryInput moby:articleName=''>
<moby:Simple>
<moby:GenericSequence namespace='AGI_LocusCode' id='At3g19100'>
<moby:Integer namespace='' id='' articleName='Length'>599</moby:Integer>
<moby:String namespace='' id='' articleName='SequenceString'>MGGCTSKPSSSVKPNPYAPKDAVLQNDDSTPAHPGKSPVRSSPAVKASPFFPFYTPSPARHRRNKSRDGGGGESKSVTSTPLRQLARAFHPPSPARHIRDVLRRRKEKKEAALPAARQQKEEEEREEVGLDKRFGFSKELQSRIELGEEIGRGHFGYTCSAKFKKGELKDQEVAVKVIPKSKMTSAISIEDVRREVKILRALSGHQNLVQFYDAFEDNANVYIVMELCGGGELLDRILARGGKYSEDDAKAVLIQILNVVAFCHLQGVVHRDLKPENFLYTSKEENSMLKVIDFGLSDFVRPDERLNDIVGSAYYVAPEVLHRSYTTEADVWSIGVIAYILLCGSRPFWARTESGIFRAVLKADPSFDEPPWPSLSFEAKDFVKRLLYKDPRKRMTASQALMHPWIAGYKKIDIPFDILIFKQIKAYLRSSSLRKAALMALSKTLTTDELLYLKAQFAHLAPNKNGLITLDSIRLALATNATEAMKESRIPDFLALLNGLQYKGMDFEEFCAASISVHQHESLDCWEQSIRHAYELFEMNGNRVIVIEELASELGVGSSIPVHTILNDWIRHTDGKLSFLGFVKLLHGVSTRQSLAKTR</moby:String>
</moby:GenericSequence>
</moby:Simple>
</moby:queryInput>
</moby:Query>
</moby:MOBY>
};

# Run the service without SOAP
my $result = MobyEd_services->test_SequenceToFASTA($query);

print "Result of debugging run:\n\n", $result;

From viji at gsf.de  Wed Feb  4 08:16:05 2004
From: viji at gsf.de (Viji)
Date: Wed Feb  4 08:24:09 2004
Subject: [MOBY-l] To access moby service using Java
Message-ID: <4020F095.9050200@gsf.de>

Hi,

I could successfully write and access a moby (test)service in Java. This 
service has an object input and String output.

I would like to know how an output moby object of type "text-xml" should 
look like.

I tried as below.

<moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
    <moby:Response moby:authority="http://mips.gsf.de">
        <moby:queryResponse queryID="">
            <Simple>
                <moby:text-xml namespace="Global_Keyword" id="431260" 
articleName="odata1">
<?xml version="1.0 encoding="UTF-8"?><element 
id="10"><desc>431260</desc></element>
                </moby:text-xml>
            </Simple>
        </moby:queryResponse>
    </moby:Response>
</moby:MOBY>

If you have worked with "text-xml" object(moby specific) types , kindly 
correct me.

Thanks
Viji

From steube at sdsc.edu  Wed Feb  4 10:53:41 2004
From: steube at sdsc.edu (Ken Steube)
Date: Wed Feb  4 10:59:54 2004
Subject: [MOBY-l] To access moby service using Java
In-Reply-To: <4020F095.9050200@gsf.de>
Message-ID: <Pine.GSO.4.30.0402040750530.12749-100000@groucho.sdsc.edu>

A text-xml is really just a String, but with a different name. What you
have is correct.

You can find out what an object looks like by going to a URL like this
one:

http://plantsp.sdsc.edu/cgi-bin/MOBY/MOBY_display_object_xml.cgi?obj=text-xml

Ken

On Wed, 4 Feb 2004, Viji wrote:

> Hi,
>
> I could successfully write and access a moby (test)service in Java. This
> service has an object input and String output.
>
> I would like to know how an output moby object of type "text-xml" should
> look like.
>
> I tried as below.
>
> <moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
>     <moby:Response moby:authority="http://mips.gsf.de">
>         <moby:queryResponse queryID="">
>             <Simple>
>                 <moby:text-xml namespace="Global_Keyword" id="431260"
> articleName="odata1">
> <?xml version="1.0 encoding="UTF-8"?><element
> id="10"><desc>431260</desc></element>
>                 </moby:text-xml>
>             </Simple>
>         </moby:queryResponse>
>     </moby:Response>
> </moby:MOBY>
>
> If you have worked with "text-xml" object(moby specific) types , kindly
> correct me.
>
> Thanks
> Viji
>
> _______________________________________________
> moby-l mailing list
> moby-l@biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
>

-- 
--
--
Ken Steube
San Diego Supercomputer Center
University of California, San Diego, MC 0505
9500 Gilman Drive
San Diego, California, 92093-0505  USA
FAX (858) 822-3610

From gordonp at cbr.nrc.ca  Wed Feb  4 11:46:47 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Wed Feb  4 11:52:56 2004
Subject: [MOBY-l] To access moby service using Java
In-Reply-To: <Pine.GSO.4.30.0402040750530.12749-100000@groucho.sdsc.edu>
References: <Pine.GSO.4.30.0402040750530.12749-100000@groucho.sdsc.edu>
Message-ID: <402121F7.30704@cbr.nrc.ca>

We should be careful.  The example below includes a complete xml 
document (albeit with no xml namespace for the data).  What would 
normally be an XML declaration on the first line of a file turns out to 
be an XML processing instruction (<?xml...) in the middle.  This 
document will not be well-formed, because the BNF definition of a 
well-formed XML document's processing instructions in the XML 1.0 
standard excludes "xml" as a PI target:


	|PI| 	   ::=    	|'<?' PITarget 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-PITarget> (S 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-S> (Char 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* - (Char 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* '?>' Char 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>*)))? '?>'|

	|PITarget| 	   ::=    	|Name 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Name> - (('X' | 'x') 
('M' | 'm') ('L' | 'l'))|


So I guess my point is that there are basically two options:

1. Wrap the moby:text-xml contents in a CDATA section so no payload 
syntax will mess up the well-formed nature of the moby document
2. Make sure we don't send xml declarations and other potentially 
dangerous data down the pipe.

The advantage to the 1st method is a guaranteed clean MOBY document 
every time.  But this also requires everyone to agree that when they see 
a moby:text-xml element, they will consider that the contents needs to 
be unescaped (i.e. the structure of the payload is not accessible from 
the MOBY document DOM, it will have to be parsed separately).  The 
second option allows the payload data and its logical partitions to be 
accessible from the MOBY DOM, but if the contents are not valid, the 
MOBY message as a whole is invalid.

The second option is convenient, but I'm leaning towards a clean 
separation of the whole thing into three layers:  SOAP network 
transport, MOBY transaction envelope, application XML contents.

My CDN$0.02.  Anyone agree, disagree, not care?

Ken Steube wrote:

>><moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
>>    <moby:Response moby:authority="http://mips.gsf.de">
>>        <moby:queryResponse queryID="">
>>            <Simple>
>>                <moby:text-xml namespace="Global_Keyword" id="431260"
>>articleName="odata1">
>><?xml version="1.0 encoding="UTF-8"?><element
>>id="10"><desc>431260</desc></element>
>>                </moby:text-xml>
>>            </Simple>
>>        </moby:queryResponse>
>>    </moby:Response>
>></moby:MOBY>
>>
>>If you have worked with "text-xml" object(moby specific) types , kindly
>>correct me.
>>
>>Thanks
>>Viji
>>
>>_______________________________________________
>>moby-l mailing list
>>moby-l@biomoby.org
>>http://biomoby.org/mailman/listinfo/moby-l
>>
>>    
>>
>
>  
>


From mwilkinson at mobile.rogers.com  Wed Feb  4 12:23:07 2004
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Wed Feb  4 12:34:57 2004
Subject: [MOBY-l] To access moby service using Java
Message-ID: <200402041734.i14HYtHH024177@portal.open-bio.org>

Yeah, I said the same thing, but I forgot to answer to the whole list.

It should be contained in a CDATA element.

Thanks Paul!

M


-----Original Message-----
From: Paul Gordon <gordonp@cbr.nrc.ca>
Date: Wed, 04 Feb 2004 09:46:47 
To:moby-l@biomoby.org
Subject: Re: [MOBY-l] To access moby service using Java

We should be careful.  The example below includes a complete xml 
document (albeit with no xml namespace for the data).  What would 
normally be an XML declaration on the first line of a file turns out to 
be an XML processing instruction (<?xml...) in the middle.  This 
document will not be well-formed, because the BNF definition of a 
well-formed XML document's processing instructions in the XML 1.0 
standard excludes "xml" as a PI target:


	|PI| 	   ::=    	|'<?' PITarget 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-PITarget> (S 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-S> (Char 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* - (Char 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* '?>' Char 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>*)))? '?>'|

	|PITarget| 	   ::=    	|Name 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Name> - (('X' | 'x') 
('M' | 'm') ('L' | 'l'))|


So I guess my point is that there are basically two options:

1. Wrap the moby:text-xml contents in a CDATA section so no payload 
syntax will mess up the well-formed nature of the moby document
2. Make sure we don't send xml declarations and other potentially 
dangerous data down the pipe.

The advantage to the 1st method is a guaranteed clean MOBY document 
every time.  But this also requires everyone to agree that when they see 
a moby:text-xml element, they will consider that the contents needs to 
be unescaped (i.e. the structure of the payload is not accessible from 
the MOBY document DOM, it will have to be parsed separately).  The 
second option allows the payload data and its logical partitions to be 
accessible from the MOBY DOM, but if the contents are not valid, the 
MOBY message as a whole is invalid.

The second option is convenient, but I'm leaning towards a clean 
separation of the whole thing into three layers:  SOAP network 
transport, MOBY transaction envelope, application XML contents.

My CDN$0.02.  Anyone agree, disagree, not care?

Ken Steube wrote:

>><moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
>>    <moby:Response moby:authority="http://mips.gsf.de">
>>        <moby:queryResponse queryID="">
>>            <Simple>
>>                <moby:text-xml namespace="Global_Keyword" id="431260"
>>articleName="odata1">
>><?xml version="1.0 encoding="UTF-8"?><element
>>id="10"><desc>431260</desc></element>
>>                </moby:text-xml>
>>            </Simple>
>>        </moby:queryResponse>
>>    </moby:Response>
>></moby:MOBY>
>>
>>If you have worked with "text-xml" object(moby specific) types , kindly
>>correct me.
>>
>>Thanks
>>Viji
>>
>>_______________________________________________
>>moby-l mailing list
>>moby-l@biomoby.org
>>http://biomoby.org/mailman/listinfo/moby-l
>>
>>    
>>
>
>  
>


_______________________________________________
moby-l mailing list
moby-l@biomoby.org
http://biomoby.org/mailman/listinfo/moby-l

!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!
From gordonp at cbr.nrc.ca  Wed Feb  4 12:56:27 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Wed Feb  4 13:02:36 2004
Subject: [MOBY-l] To access moby service using Java
In-Reply-To: <200402041728.i14HSh0r026819@furry.cbr.nrc.ca>
References: <200402041728.i14HSh0r026819@furry.cbr.nrc.ca>
Message-ID: <4021324B.4010809@cbr.nrc.ca>

Pedantic Paul on the prowl, sorry :-)

It's a common error, but technically "element" in XML refers the 
<start-tag>...</endtag> or <inline-tag/> parts of the document.  Things 
like processing instructions, comments, are "tags" or "nodes".  It's a 
CDATA Section.  Pedantic people read further.

An XML document has one or more elements, so a document that's just a 
comment is not an XML document.  In fact, the XML prolog <?xml...?> tag 
and any comments/whitespace/processing instructions after or before the 
root element close tag are not considered part of the XML document.  
Most DOM implementations will not let you access anything from the 
prolog except the document type declaration(<!DOCTYPE>), so be careful!

>It should be contained in a CDATA element.
>
>Thanks Paul!
>
>M
>
>
>-----Original Message-----
>From: Paul Gordon <gordonp@cbr.nrc.ca>
>Date: Wed, 04 Feb 2004 09:46:47 
>To:moby-l@biomoby.org
>Subject: Re: [MOBY-l] To access moby service using Java
>
>We should be careful.  The example below includes a complete xml 
>document (albeit with no xml namespace for the data).  What would 
>normally be an XML declaration on the first line of a file turns out to 
>be an XML processing instruction (<?xml...) in the middle.  This 
>document will not be well-formed, because the BNF definition of a 
>well-formed XML document's processing instructions in the XML 1.0 
>standard excludes "xml" as a PI target:
>
>
>	|PI| 	   ::=    	|'<?' PITarget 
><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-PITarget> (S 
><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-S> (Char 
><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* - (Char 
><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* '?>' Char 
><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>*)))? '?>'|
>
>	|PITarget| 	   ::=    	|Name 
><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Name> - (('X' | 'x') 
>('M' | 'm') ('L' | 'l'))|
>
>
>So I guess my point is that there are basically two options:
>
>1. Wrap the moby:text-xml contents in a CDATA section so no payload 
>syntax will mess up the well-formed nature of the moby document
>2. Make sure we don't send xml declarations and other potentially 
>dangerous data down the pipe.
>
>The advantage to the 1st method is a guaranteed clean MOBY document 
>every time.  But this also requires everyone to agree that when they see 
>a moby:text-xml element, they will consider that the contents needs to 
>be unescaped (i.e. the structure of the payload is not accessible from 
>the MOBY document DOM, it will have to be parsed separately).  The 
>second option allows the payload data and its logical partitions to be 
>accessible from the MOBY DOM, but if the contents are not valid, the 
>MOBY message as a whole is invalid.
>
>The second option is convenient, but I'm leaning towards a clean 
>separation of the whole thing into three layers:  SOAP network 
>transport, MOBY transaction envelope, application XML contents.
>
>My CDN$0.02.  Anyone agree, disagree, not care?
>
>Ken Steube wrote:
>
>  
>
>>><moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
>>>   <moby:Response moby:authority="http://mips.gsf.de">
>>>       <moby:queryResponse queryID="">
>>>           <Simple>
>>>               <moby:text-xml namespace="Global_Keyword" id="431260"
>>>articleName="odata1">
>>><?xml version="1.0 encoding="UTF-8"?><element
>>>id="10"><desc>431260</desc></element>
>>>               </moby:text-xml>
>>>           </Simple>
>>>       </moby:queryResponse>
>>>   </moby:Response>
>>></moby:MOBY>
>>>
>>>If you have worked with "text-xml" object(moby specific) types , kindly
>>>correct me.
>>>
>>>Thanks
>>>Viji
>>>
>>>_______________________________________________
>>>moby-l mailing list
>>>moby-l@biomoby.org
>>>http://biomoby.org/mailman/listinfo/moby-l
>>>
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>
>
>_______________________________________________
>moby-l mailing list
>moby-l@biomoby.org
>http://biomoby.org/mailman/listinfo/moby-l
>
>!!!!!!!!!!!!!!!!
>To respond to this message you MUST send your response to (note new address!)
>
>markw_mobile2 at illuminae dot com
>
>Responses to the reply-to address go directly to trash!
>!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
>  
>


From markw at illuminae.com  Wed Feb  4 15:49:09 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Feb  4 15:55:20 2004
Subject: [MOBY] Re: [MOBY-l] To access moby service using Java
In-Reply-To: <4021324B.4010809@cbr.nrc.ca>
References: <200402041728.i14HSh0r026819@furry.cbr.nrc.ca>
	<4021324B.4010809@cbr.nrc.ca>
Message-ID: <1075927749.2138.22.camel@localilluminae.com>

If more people were as pedantic as you we would have more successful
first-tries at MOBY service building ;-)

M

On Wed, 2004-02-04 at 11:56, Paul Gordon wrote:
> Pedantic Paul on the prowl, sorry :-)
> 
> It's a common error, but technically "element" in XML refers the 
> <start-tag>...</endtag> or <inline-tag/> parts of the document.  Things 
> like processing instructions, comments, are "tags" or "nodes".  It's a 
> CDATA Section.  Pedantic people read further.
> 
> An XML document has one or more elements, so a document that's just a 
> comment is not an XML document.  In fact, the XML prolog <?xml...?> tag 
> and any comments/whitespace/processing instructions after or before the 
> root element close tag are not considered part of the XML document.  
> Most DOM implementations will not let you access anything from the 
> prolog except the document type declaration(<!DOCTYPE>), so be careful!
> 
> >It should be contained in a CDATA element.
> >
> >Thanks Paul!
> >
> >M
> >
> >
> >-----Original Message-----
> >From: Paul Gordon <gordonp@cbr.nrc.ca>
> >Date: Wed, 04 Feb 2004 09:46:47 
> >To:moby-l@biomoby.org
> >Subject: Re: [MOBY-l] To access moby service using Java
> >
> >We should be careful.  The example below includes a complete xml 
> >document (albeit with no xml namespace for the data).  What would 
> >normally be an XML declaration on the first line of a file turns out to 
> >be an XML processing instruction (<?xml...) in the middle.  This 
> >document will not be well-formed, because the BNF definition of a 
> >well-formed XML document's processing instructions in the XML 1.0 
> >standard excludes "xml" as a PI target:
> >
> >
> >	|PI| 	   ::=    	|'<?' PITarget 
> ><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-PITarget> (S 
> ><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-S> (Char 
> ><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* - (Char 
> ><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* '?>' Char 
> ><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>*)))? '?>'|
> >
> >	|PITarget| 	   ::=    	|Name 
> ><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Name> - (('X' | 'x') 
> >('M' | 'm') ('L' | 'l'))|
> >
> >
> >So I guess my point is that there are basically two options:
> >
> >1. Wrap the moby:text-xml contents in a CDATA section so no payload 
> >syntax will mess up the well-formed nature of the moby document
> >2. Make sure we don't send xml declarations and other potentially 
> >dangerous data down the pipe.
> >
> >The advantage to the 1st method is a guaranteed clean MOBY document 
> >every time.  But this also requires everyone to agree that when they see 
> >a moby:text-xml element, they will consider that the contents needs to 
> >be unescaped (i.e. the structure of the payload is not accessible from 
> >the MOBY document DOM, it will have to be parsed separately).  The 
> >second option allows the payload data and its logical partitions to be 
> >accessible from the MOBY DOM, but if the contents are not valid, the 
> >MOBY message as a whole is invalid.
> >
> >The second option is convenient, but I'm leaning towards a clean 
> >separation of the whole thing into three layers:  SOAP network 
> >transport, MOBY transaction envelope, application XML contents.
> >
> >My CDN$0.02.  Anyone agree, disagree, not care?
> >
> >Ken Steube wrote:
> >
> >  
> >
> >>><moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
> >>>   <moby:Response moby:authority="http://mips.gsf.de">
> >>>       <moby:queryResponse queryID="">
> >>>           <Simple>
> >>>               <moby:text-xml namespace="Global_Keyword" id="431260"
> >>>articleName="odata1">
> >>><?xml version="1.0 encoding="UTF-8"?><element
> >>>id="10"><desc>431260</desc></element>
> >>>               </moby:text-xml>
> >>>           </Simple>
> >>>       </moby:queryResponse>
> >>>   </moby:Response>
> >>></moby:MOBY>
> >>>
> >>>If you have worked with "text-xml" object(moby specific) types , kindly
> >>>correct me.
> >>>
> >>>Thanks
> >>>Viji
> >>>
> >>>_______________________________________________
> >>>moby-l mailing list
> >>>moby-l@biomoby.org
> >>>http://biomoby.org/mailman/listinfo/moby-l
> >>>
> >>>   
> >>>
> >>>      
> >>>
> >> 
> >>
> >>    
> >>
> >
> >
> >_______________________________________________
> >moby-l mailing list
> >moby-l@biomoby.org
> >http://biomoby.org/mailman/listinfo/moby-l
> >
> >!!!!!!!!!!!!!!!!
> >To respond to this message you MUST send your response to (note new address!)
> >
> >markw_mobile2 at illuminae dot com
> >
> >Responses to the reply-to address go directly to trash!
> >!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> >
> >  
> >
> 
> 
> _______________________________________________
> moby-l mailing list
> moby-l@biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
-- 
Mark Wilkinson <markw@illuminae.com>
Illuminae
From steube at sdsc.edu  Wed Feb  4 16:17:22 2004
From: steube at sdsc.edu (Ken Steube)
Date: Wed Feb  4 16:23:35 2004
Subject: [MOBY] Re: [MOBY-l] To access moby service using Java
In-Reply-To: <1075927749.2138.22.camel@localilluminae.com>
Message-ID: <Pine.GSO.4.30.0402041314550.13023-100000@groucho.sdsc.edu>

I just updated my section on CDATA in my workshop material at

  http://plantgenome.sdsc.edu/mobyed2/Talks/introduction.html

I had glossed over it before, but now I have it right.

Thx for the info.

Ken

From gordonp at cbr.nrc.ca  Wed Feb  4 17:22:11 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Wed Feb  4 17:28:20 2004
Subject: [MOBY] Re: [MOBY-l] To access moby service using Java
In-Reply-To: <Pine.GSO.4.30.0402041314550.13023-100000@groucho.sdsc.edu>
References: <Pine.GSO.4.30.0402041314550.13023-100000@groucho.sdsc.edu>
Message-ID: <40217093.8090900@cbr.nrc.ca>

Almost.  Your CDATA section starts "\n<?xml...".  According to spec, 
"<?xml" must be the start of the parsed data (with the rare exception of 
a platform specific character marking the file as to be read in Text 
Mode or not, like in DOS).  That is, if the XML declaration exists at 
all (it's optional, but very strongly recommended). 

So take out the leading carriage run and you're set!

Cool runnings,

Paul

Ken Steube wrote:

>I just updated my section on CDATA in my workshop material at
>
>  http://plantgenome.sdsc.edu/mobyed2/Talks/introduction.html
>
>I had glossed over it before, but now I have it right.
>
>Thx for the info.
>
>Ken
>
>_______________________________________________
>moby-l mailing list
>moby-l@biomoby.org
>http://biomoby.org/mailman/listinfo/moby-l
>
>  
>


From rebecca.ernst at gsf.de  Thu Feb  5 10:15:19 2004
From: rebecca.ernst at gsf.de (Rebecca Ernst)
Date: Thu Feb  5 10:21:35 2004
Subject: [MOBY-l] collection articles
In-Reply-To: <200402021504.i12F4OEs025278@portal.open-bio.org>
References: <200402021504.i12F4OEs025278@portal.open-bio.org>
Message-ID: <40225E07.1040300@gsf.de>

Hi Mark (and others)!

Heiko and I had some discussions on the primary articles Simple and 
Collection today.

We couldn't imagine a scenario that made a collection article necessary. 
As far as I saw in your (Mark's) services (which give collections back) 
you could have also taken simples instead.

Could you please bring light into the mystery of the collection article? ;-)

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 markw at illuminae.com  Thu Feb  5 15:53:11 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Thu Feb  5 15:59:25 2004
Subject: [MOBY] [MOBY-l] collection articles
In-Reply-To: <40225E07.1040300@gsf.de>
References: <200402021504.i12F4OEs025278@portal.open-bio.org>
	<40225E07.1040300@gsf.de>
Message-ID: <1076014391.2033.22.camel@localilluminae.com>

On Thu, 2004-02-05 at 09:15, Rebecca Ernst wrote:

> We couldn't imagine a scenario that made a collection article necessary. 
> As far as I saw in your (Mark's) services (which give collections back) 
> you could have also taken simples instead.

Well... not really.  If I knew at registration-time exactly how many
simples I was going to pass back in response, then I could register my
service as returning that many simples.  However, in the case of all of
my services that return Collections, I do not know a priori how many
individual responses there will be to the query, so I have to use a
collection.

The service signature is very strict in that regard.  If I say that I
return 'Simple', then I return EXACTLY ONE 'Simple'.  If I return a
defined number of simples, for example 3, then I can register my service
as returning <Simple/><Simple/><Simple/> if the meaning of each Simple
is implicit, or <Simple articleName1/><Simple articleName2/><Simple
articleName3/> if the meaning of each Simple component of the response
has to be clarified.  However, if I am returning an undefined number of
Simples, then I must register it as a Collection.  Moreover, you use
Collections when part of your response is to be considered as a single
unit.  For example, in the following (C = Collection, S = Simple):

<C articleName=alignments>
	<S>
		<align1/>
	</S>
	<S>
		<align2/>
	<S>
		<align3/>
	</S>
</Collection>
<S>
	<align4>
</S>
<S>
	<Annotated GIF>
</S>
<S>
	<Consensus>
</S>

In this case, your input results in a [set of alignments], a [GIF
image], and a [Consensus] - three parts, not six :-)  Moreover, the
number of alignments in the Collection probably wasn't predictable,
since it would depend on the number of sequences passed into the service
(probably also as a Collection input).
 
Hi from my new office!!

Mark

-- 
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

------------------------------------------------------------------------
It just goes to show you that SOAP::Lite is more intuitive than you might 
think, if you know enough Perl and have the patience to dive into the 
source code.
		-Byrne Reese
		-http://builder.com.com/5100-6389_14-1045078-2.html
------------------------------------------------------------------------
From Martin.Leucker at it.uu.se  Mon Feb  9 03:41:02 2004
From: Martin.Leucker at it.uu.se (Martin Leucker)
Date: Mon Feb  9 03:47:08 2004
Subject: [MOBY-l] PDMC'04 - 1st CfP
Message-ID: <20040209084102.GA6004@hamberg.it.uu.se>


        [[ -- Apologies for multiple copies of this message -- ]]

=============================================================================

                              Call for Papers

                      3rd International Workshop on 
              PARALLEL AND DISTRIBUTED METHODS IN VERIFICATION
                              (PDMC 2004)

                   September 4, 2004, London, U.K.
      Workshop affiliated to CONCUR'04, 31 August - 3 September 2004.
             
                  http://www.fi.muni.cz/~brim/PDMC04
 
=============================================================================

OBJECTIVES: The growing importance of automated formal verification in
industry is driving a growing interest in those aspects which have a
direct impact on its applicability to real world problems. One of the
main technical challenges is in devising tools that allow to handle
large state spaces. Over the last years numerous approaches have been
developed. Recently, an increasing interest is in parallelizing and
distributing of verification techniques.

The aim of the PDMC workshop series is to cover all aspects of
parallel and distributed methods and techniques for formal
verification. Theoretical results, algorithms and case studies are
equally welcome. After two successful meetings in 2002 and 2003 with
primary focus on parallelization of model checking, the scope of the
workshop have been extended to cover all approaches where parallel and
distributed techniques can make the automated verification more
effective and/or extend its applicability. This extension is also
reflected in the new name of the workshop.

The PDMC workshop aims to provide a working forum for presenting,
sharing, and discussing recent achievements in the field of parallel
and distributed verification. The workshop will consist of invited
talks and a selection from submitted papers.

SCOPE AND TOPICS: Papers describing recent work on all aspects of
parallel and distributed verification are solicited as contributions
to PDMC. Topics of interest include, but are not limited to:

* parallel and distributed model checking 
* parallel and distributed equivalence checking 
* parallel and distributed satisfiability checking
* slicing and distributing the state space
* distributed theorem proving
* distributed constraints solving
* parallel methods in probabilistic model checking
* file systems for distributed transitions systems
* parallel methods in performance evaluation
* tools and case studies
* industrial applications  
 
SUBMISSION GUIDELINES: There are two categories of submissions:
regular papers and presentations.

    * Manuscripts of regular papers are limited to a maximum of 10
      pages (excluding bibliography and technical appendices) in
      postscript or PDF format (ENTCS style strongly recommended).

    * Presentations report on relevant results submitted to other
      forums or already published or on not yet finished work in
      progress. Presentations will appear in the workshop preliminary
      proceedings, but will not be considered for the final workshop
      proceedings. The space limit for presentations is 10 pages
      (excluding bibliography and technical appendices) in postscript
      or PDF format (ENTCS style strongly recommended).

Submissions should be made electronically using PDMC'04 Submission Page.

PROCEEDINGS: The preliminary workshop proceedings will be available as
a Research Report of Imperial College London. The final proceedings
appear as a volume of Electronic Notes in Theoretical Computer
Science. After the workshop, selected authors will be invited to
submit full versions of their papers (regular papers or presentation
results not submitted for journal publication) to a special section
of a journal (under negotiation).


IMPORTANT DATES:
    *  May 29, 2004: Submission deadline for regular papers.
    * July  5, 2004: Notification of acceptance.
    * July 10, 2004: Deadline for presentations.
    * July 31, 2004: Camera ready copy for proceedings.

 
INVITED SPEAKER:   
Boi B. Faltings (Swiss Federal Institute of Technology, Lausanne)

PROGRAM COMMITTEE:
    * Howard Barringer (Manchester Univ., UK)
    * Lubos Brim (Masaryk Univ., CZ) - Co-chair
    * Gianpiero Cabodi (Torino, IT)
    * Wan Fokkink (CWI Amsterdam, NL)
    * Hubert Garavel (INRIA, FR)
    * Hanne Gottliebsen (Queen Mary Univ. of London, UK)
    * Orna Grumberg (Haifa, Israel) 
    * Boudewijn R. Haverkort (Univ. of Twente, NL)
    * Michael Jones (Brigham Young Univ., USA)
    * Marta Kwiatkowska (Univ. of Birmingham, UK)
    * Martin Lange (LMU Muenchen, DE)
    * Martin Leucker (Uppsala Univ., SE) - Co-chair
    * Sharad Malik (Princeton Univ., USA)
    * Eric Mercer (Brigham Young Univ., USA)
    * Michel Rueher (Universite Nice Sophia Antipolis, FR)
    * Pascal Van Hentenryck (Brown University, USA)
    * Willem Visser (NASA Ames Research Center, USA) 


Lubos Brim & Martin Leucker
workshop organizers









From viji at gsf.de  Wed Feb  4 07:07:34 2004
From: viji at gsf.de (Viji)
Date: Wed Feb 11 11:07:10 2004
Subject: [MOBY-l] A moby service in Java
Message-ID: <4020E086.4030409@gsf.de>

Hi Mark,

I could successfully write and access a moby (test)service in Java. This 
service has an object input and String output.

I would like to know how an output moby object of type "text-xml" should 
look like.

I tried as below.

<moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
    <moby:Response moby:authority="http://mips.gsf.de">
        <moby:queryResponse queryID="">
            <Simple>
                <moby:text-xml namespace="Global_Keyword" id="431260" 
articleName="odata1">
<?xml version="1.0 encoding="UTF-8"?><element 
id="10"><desc>431260</desc></element>
                </moby:text-xml>
            </Simple>
        </moby:queryResponse>
    </moby:Response>
</moby:MOBY>

If you have worked with "text-xml" object(moby specific) types , kindly 
correct me.

Thanks
Viji
From viji at gsf.de  Tue Feb 10 09:28:46 2004
From: viji at gsf.de (Viji)
Date: Wed Feb 11 11:07:10 2004
Subject: [MOBY-l] Source code in Java for registering and accessing moby
 compliant services
Message-ID: <4028EA9E.4010500@gsf.de>

Hi,

Herewith I have enclosed a jar file containing 3 java files within.

1. ServiceRegistrationHelper.java   -   Helper class to register a moby 
compliant service.
2. MobyWrapper.java                    -   Again a helper class that 
unwraps and wraps the input and output MOBY objects resp.
3. TestAxis.java                             -   Main class for which I 
want to establish a moby service for the methods present in it (like 
getTestMessage or getTestXMLOutput).

Note that the authURL for the moby services, getTestMessage or 
getTestXMLOutput is the endpoint of Apache Axis web service.
To be more clear, I have already implemented a web service for the above 
class (TestAxis.java) using Apache axis(deployed in my application 
server). Then, used the endpoint as authURL for registering moby service.

Axis don't need as many services as the number of methods in the class. 
Just a single endpoint can point to all the methods present in it.

Revert back for any clarifications. I'll try to explain to the best of 
my knowledge.

Thanks
Viji
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SampleMobyServiceInJava.jar
Type: application/octet-stream
Size: 3713 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-l/attachments/20040210/6bafb632/SampleMobyServiceInJava-0001.obj
From viji at gsf.de  Tue Feb 10 09:31:38 2004
From: viji at gsf.de (Viji)
Date: Wed Feb 11 11:07:11 2004
Subject: [MOBY-l] Java code for registering and accessing
Message-ID: <4028EB4A.9000407@gsf.de>

Hi,

Herewith I have enclosed a jar file containing 3 java files within.

1. ServiceRegistrationHelper.java   -   Helper class to register a moby 
compliant service.
2. MobyWrapper.java                    -   Again a helper class that 
unwraps and wraps the input and output MOBY objects resp.
3. TestAxis.java                             -   Main class for which I 
want to establish a moby service for the methods present in it (like 
getTestMessage or getTestXMLOutput).

Note that the authURL for the moby services, getTestMessage or 
getTestXMLOutput is the endpoint of Apache Axis web service.
To be more clear, I have already implemented a web service for the above 
class (TestAxis.java) using Apache axis(deployed in my application 
server). Then, used the endpoint as authURL for registering moby service.

Axis don't need as many services as the number of methods in the class. 
Just a single endpoint can point to all the methods present in it.

Revert back for any clarifications. I'll try to explain to the best of 
my knowledge.

Thanks
Viji
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SampleMobyServiceInJava.jar
Type: application/octet-stream
Size: 3713 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-l/attachments/20040210/9b988874/SampleMobyServiceInJava-0001.obj
From viji at gsf.de  Tue Feb 10 09:41:45 2004
From: viji at gsf.de (Viji)
Date: Wed Feb 11 11:07:11 2004
Subject: [MOBY-l] Moby Compliant service in Java
Message-ID: <4028EDA9.6030607@gsf.de>

Hi,

Herewith I have enclosed a jar file containing 3 java files within.

1. ServiceRegistrationHelper.java   -   Helper class to register a moby 
compliant service.
2. MobyWrapper.java                    -   Again a helper class that 
unwraps and wraps the input and output MOBY objects resp.
3. TestAxis.java                             -   Main class for which I 
want to establish a moby service for the methods present in it (like 
getTestMessage or getTestXMLOutput).

Note that the authURL for the moby services, getTestMessage or 
getTestXMLOutput is the endpoint of Apache Axis web service.
To be more clear, I have already implemented a web service for the above 
class (TestAxis.java) using Apache axis(deployed in my application 
server). Then, used the endpoint as authURL for registering moby service.

Axis don't need as many services as the number of methods in the class. 
Just a single endpoint can point to all the methods present in it.

Revert back for any clarifications. I'll try to explain to the best of 
my knowledge.

Thanks
Viji
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SampleMobyServiceInJava.jar
Type: application/octet-stream
Size: 3713 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-l/attachments/20040210/d4ca566a/SampleMobyServiceInJava.obj
From VNarayan at mail.brc.mcw.edu  Wed Feb 11 16:18:03 2004
From: VNarayan at mail.brc.mcw.edu (Vijay Narayanasamy)
Date: Wed Feb 11 16:28:28 2004
Subject: [MOBY-l] Name Space
Message-ID: <295CC5EB4257D411B34D00D0B7748F4432DEBF@baldar.brc.mcw.edu>

Hi Mark,
?
I want a NameSpace for Agricola. 
?
In the GO http://www.geneontology.org/doc/GO.xrf_abbs there are three
entries for Agricola. 
?
'NAL', 'bib' and 'IND' 
?
With release of new Agricola website http://agricola.nal.usda.gov the
services I developed based on 'bib' became irrelevant.
?
I have developed new BioMOBY PubFetch services for Agricola using accession
number (e.g. IND84014403)
?
I want to use the namespace IND for my services. 
?
The following is the entry in GO
?
abbreviation: IND
database: AGRICOLA
object: call number
example: IND84014403
generic_url: http://agricola.cos.com/
?
The way I will use IND
?
abbreviation: IND
database: AGRICOLA
object: accession number
example: IND84014403
generic_url: http://agricola.nal.usda.gov 
example_url:
http://agricola.nal.usda.gov/cgi-bin/Pwebrecon.cgi?DB=local&CNT=1&Search_Arg
=IND84014403&Search_Code=GKEY&STARTDB=AGRIDB 
?
?
I want your consent on this namespace before I register it in MOBY.
?
Thank you,
?
Vijay
?
?
Vijay Narayanasamy
Project Programmer / Analyst
Bioinformatics Program, Human and Molecular Genetics Center
Medical College of Wisconsin
8701, W. Watertown Plank Road
Milwaukee, WI 53226
414-456-8026
vnarayan@mcw.edu 
http://brc.mcw.edu/ 
?



From markw at illuminae.com  Wed Feb 11 15:00:19 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Feb 11 17:07:31 2004
Subject: [MOBY-l] Re: [MOBY] Name Space
In-Reply-To: <295CC5EB4257D411B34D00D0B7748F4432DEBE@baldar.brc.mcw.edu>
References: <295CC5EB4257D411B34D00D0B7748F4432DEBE@baldar.brc.mcw.edu>
Message-ID: <1076529619.1675.92.camel@localilluminae.com>

On Wed, 2004-02-11 at 15:15, Vijay Narayanasamy wrote:

> 'NAL', 'bib' and 'IND' 

I see them.
>  

> I have developed new BioMOBY PubFetch services for Agricola using
> accession number (e.g. IND84014403)
> I want to use the namespace IND for my services. 

Great!

> The following is the entry in GO
> abbreviation: IND
> database: AGRICOLA
> object: call number
> example: IND84014403
> 
> generic_url: http://agricola.cos.com/

> The way I will use IND
> abbreviation: IND
> database: AGRICOLA
> object: accession number
> example: IND84014403
> 
> generic_url: http://agricola.nal.usda.gov
> example_url:
> http://agricola.nal.usda.gov/cgi-bin/Pwebrecon.cgi?DB=local&CNT=1&Search_Arg=IND84014403&Search_Code=GKEY&STARTDB=AGRIDB

I don't see any difference in the namespace portion of these two
records.  Just to be sure I am understanding you - you want to use the
IND namespace with *exactly* the same semantic meaning as it currently
has in GO, correct?  If so, then please go ahead.  I was planning to
re-parse the GO xref abbs document into MOBY sometime soon anyway, but
it you need that one right away feel free to register it... so long as
you are not trying to change its intended meaning v.v. what IND means in
the GO xref_abbs - otherwise you will get clobbered next time I parse
the file!

We have been given permission by the GO consortium to take over the
curation of this list in any case.  I just need to find time to build
the tools that will output our database in the GO_xref_abbs file format
so that we don't bugger up the GO people when we do so!  hopefully in a
week or two I'll have done that... hopefully...

Cheers!

M

From suzi at fruitfly.org  Wed Feb 11 17:14:43 2004
From: suzi at fruitfly.org (Suzanna Lewis)
Date: Wed Feb 11 17:21:10 2004
Subject: [MOBY-l] Re: [MOBY] Name Space
In-Reply-To: <1076529619.1675.92.camel@localilluminae.com>
References: <295CC5EB4257D411B34D00D0B7748F4432DEBE@baldar.brc.mcw.edu>
	<1076529619.1675.92.camel@localilluminae.com>
Message-ID: <402AA953.3030508@fruitfly.org>

That will be lovely Mark

>We have been given permission by the GO consortium to take over the
>curation of this list in any case.  I just need to find time to build
>the tools that will output our database in the GO_xref_abbs file format
>so that we don't bugger up the GO people when we do so!  hopefully in a
>week or two I'll have done that... hopefully...
>
>Cheers!
>
>M
>
>_______________________________________________
>moby-l mailing list
>moby-l@biomoby.org
>http://biomoby.org/mailman/listinfo/moby-l
>  
>

From VNarayan at mail.brc.mcw.edu  Wed Feb 11 17:48:09 2004
From: VNarayan at mail.brc.mcw.edu (Vijay Narayanasamy)
Date: Wed Feb 11 17:58:35 2004
Subject: [MOBY-l] RE: [MOBY] Name Space
Message-ID: <295CC5EB4257D411B34D00D0B7748F4432DEC0@baldar.brc.mcw.edu>

Thanks Mark. 

I have published the following services

FetchFull
Authority      prometheus.brc.mcw.edu
Description    Get FullText for given PMID
Input          Object (namespaces: PMID) 
Output         PubMed-MEDLINE (namespaces: PMID)


fetchAgID
Authority      prometheus.brc.mcw.edu
Description    Search Agricola for given query and get Agricola accession
numbers
Input          Object (namespaces: Global_Keyword) 
Output         Object (namespaces: IND) 


fetchAgDoc
Authority      prometheus.brc.mcw.edu
Description    Get Agricola document in MEDLINE like format for given
Agricola accession number
Input          Object (namespaces: IND) 
Output         text-formatted (namespaces: IND) 

-Vijay

-----Original Message-----
From: Mark Wilkinson [mailto:markw@illuminae.com] 
Sent: Wednesday, February 11, 2004 2:00 PM
To: Vijay Narayanasamy
Cc: 'moby-l@biomoby.org'; 'Midori Harris'; 'Suparna Mundodi';
'gmod-pubsearch-dv@lists.sourceforge.net'; Simon Twigger; 'Sue Rhee'
Subject: Re: [MOBY] Name Space

On Wed, 2004-02-11 at 15:15, Vijay Narayanasamy wrote:

> 'NAL', 'bib' and 'IND' 

I see them.
>  

> I have developed new BioMOBY PubFetch services for Agricola using
> accession number (e.g. IND84014403)
> I want to use the namespace IND for my services. 

Great!

> The following is the entry in GO
> abbreviation: IND
> database: AGRICOLA
> object: call number
> example: IND84014403
> 
> generic_url: http://agricola.cos.com/

> The way I will use IND
> abbreviation: IND
> database: AGRICOLA
> object: accession number
> example: IND84014403
> 
> generic_url: http://agricola.nal.usda.gov
> example_url:
>
http://agricola.nal.usda.gov/cgi-bin/Pwebrecon.cgi?DB=local&CNT=1&Search_Arg
=IND84014403&Search_Code=GKEY&STARTDB=AGRIDB

I don't see any difference in the namespace portion of these two
records.  Just to be sure I am understanding you - you want to use the
IND namespace with *exactly* the same semantic meaning as it currently
has in GO, correct?  If so, then please go ahead.  I was planning to
re-parse the GO xref abbs document into MOBY sometime soon anyway, but
it you need that one right away feel free to register it... so long as
you are not trying to change its intended meaning v.v. what IND means in
the GO xref_abbs - otherwise you will get clobbered next time I parse
the file!

We have been given permission by the GO consortium to take over the
curation of this list in any case.  I just need to find time to build
the tools that will output our database in the GO_xref_abbs file format
so that we don't bugger up the GO people when we do so!  hopefully in a
week or two I'll have done that... hopefully...

Cheers!

M
From boris.steipe at utoronto.ca  Wed Feb 11 18:37:04 2004
From: boris.steipe at utoronto.ca (Boris Steipe)
Date: Wed Feb 11 18:43:50 2004
Subject: [MOBY-l] Name Space
In-Reply-To: <295CC5EB4257D411B34D00D0B7748F4432DEBF@baldar.brc.mcw.edu>
Message-ID: <32A2C60C-5CEB-11D8-A483-000A9577512E@utoronto.ca>


On Wednesday, Feb 11, 2004, at 16:18 Canada/Eastern, Vijay Narayanasamy 
wrote:

> Hi Mark,
> ?
> I want a NameSpace for Agricola.
> ?
> In the GO http://www.geneontology.org/doc/GO.xrf_abbs there are three
> entries for Agricola.
> ?
> 'NAL', 'bib' and 'IND'
> ?

What happened to the idea of namespacing like in LSIDs i.e. making a 
namespace valid only in the context of its issuing authority and thus 
effectively using the (working, sort of) ICANN resolution mechanism to 
ensure that namespaces remain unique ?

The LSID of the object that Vijay describes apparently would be:
urn:lsid:agricola.cos.com:IND:84014403

The huge advantage is that this distributes the task of maintaining 
namespaces to the data providers - no need to register with a central 
authority.

Sure, LSIDs are meant to be permanent and not every provider supports 
them yet, but that does not prevent anyone from using the principle on 
accession numbers from elsewhere, even if the other authority has no 
mechanism to ensure uniqueness and permanence in place - it just 
wouldn't be a proper LSID yet, even if it would be structured like one. 
But it would still serve the purpose at least as well as what's 
available already.

I can't remember what the plan was, regarding that concept.

Best regards,


Boris

---
Boris Steipe
University of Toronto
Program in Proteomics & Bioinformatics
Departments of Biochemistry & Molecular and Medical Genetics
http://biochemistry.utoronto.ca/steipe/

From markw at illuminae.com  Wed Feb 11 17:16:45 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Feb 11 19:27:06 2004
Subject: [MOBY] Re: [MOBY-l] Name Space
In-Reply-To: <32A2C60C-5CEB-11D8-A483-000A9577512E@utoronto.ca>
References: <32A2C60C-5CEB-11D8-A483-000A9577512E@utoronto.ca>
Message-ID: <1076537805.1723.130.camel@localilluminae.com>

yes, that was the plan... and in effect it still *is* the plan. 
However, I cannot assign LSID's arbitrarily to another authority (this
is something they must do on their own), so for the moment all namespace
identifiers are in the "biomoby.org" LSID authority, and thus we have to
be careful of collisions.

Once LSID's become more widespread we will certainly stop using our own
LSID authority prefix and use the "genuine" one, as assigned by the true
naming authority, but until then... we're stuck.

M


On Wed, 2004-02-11 at 17:37, Boris Steipe wrote:
> On Wednesday, Feb 11, 2004, at 16:18 Canada/Eastern, Vijay Narayanasamy 
> wrote:
> 
> > Hi Mark,
> >  
> > I want a NameSpace for Agricola.
> >  
> > In the GO http://www.geneontology.org/doc/GO.xrf_abbs there are three
> > entries for Agricola.
> >  
> > 'NAL', 'bib' and 'IND'
> >  
> 
> What happened to the idea of namespacing like in LSIDs i.e. making a 
> namespace valid only in the context of its issuing authority and thus 
> effectively using the (working, sort of) ICANN resolution mechanism to 
> ensure that namespaces remain unique ?
> 
> The LSID of the object that Vijay describes apparently would be:
> urn:lsid:agricola.cos.com:IND:84014403
> 
> The huge advantage is that this distributes the task of maintaining 
> namespaces to the data providers - no need to register with a central 
> authority.
> 
> Sure, LSIDs are meant to be permanent and not every provider supports 
> them yet, but that does not prevent anyone from using the principle on 
> accession numbers from elsewhere, even if the other authority has no 
> mechanism to ensure uniqueness and permanence in place - it just 
> wouldn't be a proper LSID yet, even if it would be structured like one. 
> But it would still serve the purpose at least as well as what's 
> available already.
> 
> I can't remember what the plan was, regarding that concept.
> 
> Best regards,
> 
> 
> Boris
> 
> ---
> Boris Steipe
> University of Toronto
> Program in Proteomics & Bioinformatics
> Departments of Biochemistry & Molecular and Medical Genetics
> http://biochemistry.utoronto.ca/steipe/
> 
> _______________________________________________
> moby-l mailing list
> moby-l@biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
-- 
Mark Wilkinson <markw@illuminae.com>
Illuminae
From boris.steipe at utoronto.ca  Wed Feb 11 20:24:03 2004
From: boris.steipe at utoronto.ca (Boris Steipe)
Date: Wed Feb 11 20:30:11 2004
Subject: [MOBY] Re: [MOBY-l] Name Space
In-Reply-To: <1076537805.1723.130.camel@localilluminae.com>
Message-ID: <24A79638-5CFA-11D8-A483-000A9577512E@utoronto.ca>


On Wednesday, Feb 11, 2004, at 17:16 Canada/Eastern, Mark Wilkinson 
wrote:

Again: what would prevent you from constructing and using them "as if"? 
I don't think the potential amount of migration would be larger 
(probably smaller) than migrating say, all the moby LSIDs to whatever 
their proper authority is once that authority starts using proper 
LSIDS. Remember, you are supposed to commit to keeping LSIDs 
permanently, for hundreds of years. Do you really want to do that ? On 
the other hand I could not imagine that you would even *allow* e.g. a 
biomoby.org:pubmed to diverge in its semantics from the NCBI one.

I would suggest not assigning biomoby.org LSIDs but simply and 
pragmatically requiring an object to disambiguate its namespace by 
providing an authority. Then everyone could create/maintain their own 
namespaces - either semantically linking them to another provider's 
definition through the domain name, or rolling their own. The nice 
thing is that this would be forward compatible. Whether this tuple is 
prefixed by nothing or by urn:lsid doesn't really make a difference, 
does it ? And even if it did, it would make more sense to use 
urn:biomoby_id:authority:ns    ...

To my mind, the neatest thing about the LSIDs is not their resolve to 
maintain universal and permanent identifiers, but the elegant way of 
piggybacking on the ICANN solution to creating unique namespaces.

Sense ?


B.

(Or maybe I should start registering a batch of biomoby.org namespaces 
as a potential source of future income... Hm.   ;-)


> yes, that was the plan... and in effect it still *is* the plan.
> However, I cannot assign LSID's arbitrarily to another authority (this
> is something they must do on their own), so for the moment all 
> namespace
> identifiers are in the "biomoby.org" LSID authority, and thus we have 
> to
> be careful of collisions.
>
> Once LSID's become more widespread we will certainly stop using our own
> LSID authority prefix and use the "genuine" one, as assigned by the 
> true
> naming authority, but until then... we're stuck.
>
> M
>
>
> On Wed, 2004-02-11 at 17:37, Boris Steipe wrote:
>> On Wednesday, Feb 11, 2004, at 16:18 Canada/Eastern, Vijay 
>> Narayanasamy
>> wrote:
>>
>>> Hi Mark,
>>>
>>> I want a NameSpace for Agricola.
>>>
>>> In the GO http://www.geneontology.org/doc/GO.xrf_abbs there are three
>>> entries for Agricola.
>>>
>>> 'NAL', 'bib' and 'IND'
>>>
>>
>> What happened to the idea of namespacing like in LSIDs i.e. making a
>> namespace valid only in the context of its issuing authority and thus
>> effectively using the (working, sort of) ICANN resolution mechanism to
>> ensure that namespaces remain unique ?
>>
>> The LSID of the object that Vijay describes apparently would be:
>> urn:lsid:agricola.cos.com:IND:84014403
>>
>> The huge advantage is that this distributes the task of maintaining
>> namespaces to the data providers - no need to register with a central
>> authority.
>>
>> Sure, LSIDs are meant to be permanent and not every provider supports
>> them yet, but that does not prevent anyone from using the principle on
>> accession numbers from elsewhere, even if the other authority has no
>> mechanism to ensure uniqueness and permanence in place - it just
>> wouldn't be a proper LSID yet, even if it would be structured like 
>> one.
>> But it would still serve the purpose at least as well as what's
>> available already.
>>
>> I can't remember what the plan was, regarding that concept.
>>
>> Best regards,
>>
>>
>> Boris
>>
>> ---
>> Boris Steipe
>> University of Toronto
>> Program in Proteomics & Bioinformatics
>> Departments of Biochemistry & Molecular and Medical Genetics
>> http://biochemistry.utoronto.ca/steipe/
>>
>> _______________________________________________
>> moby-l mailing list
>> moby-l@biomoby.org
>> http://biomoby.org/mailman/listinfo/moby-l
> -- 
> Mark Wilkinson <markw@illuminae.com>
> Illuminae
> _______________________________________________
> moby-l mailing list
> moby-l@biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
>

Best regards,


Boris

---
Boris Steipe
University of Toronto
Program in Proteomics & Bioinformatics
Departments of Biochemistry & Molecular and Medical Genetics
http://biochemistry.utoronto.ca/steipe/

From senger at ebi.ac.uk  Wed Feb 11 20:39:12 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed Feb 11 20:45:21 2004
Subject: [MOBY] Re: [MOBY-l] Name Space
In-Reply-To: <24A79638-5CFA-11D8-A483-000A9577512E@utoronto.ca>
Message-ID: <Pine.OSF.4.10.10402120132310.1047662-100000@ice.ebi.ac.uk>

Just my 2c:
   The authority field is not important only as a way how to identify
things world-wide uniquely (if it was only for that, all your arguments
are completely valid) - but it *may* (the LSID spec does not mandate that 
but suggests it) be used also for finding an appropriate resolution
service that can return data identified by this LSID. Therefore, if you
put there pubmed.org, it may never find biomoby.org where it can be
resolve.
   I think the solution may be (Sean, are you listening here? Am I right?)
to have *both* in the authority - biomoby.org *and* pubmed.org - so the
resolution software will find first biomoby.org and it knows that the rest
of the authority can be ignored.

   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 markw at illuminae.com  Wed Feb 11 18:49:13 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Feb 11 20:56:20 2004
Subject: [MISC] Re: [MOBY] Re: [MOBY-l] Name Space
In-Reply-To: <24A79638-5CFA-11D8-A483-000A9577512E@utoronto.ca>
References: <24A79638-5CFA-11D8-A483-000A9577512E@utoronto.ca>
Message-ID: <1076543352.1723.157.camel@localilluminae.com>

Yes... and no... the problem is that an LSID kinda sorta inferrs that
there is a resolver out there who can resolve it to data or metadata. 
Since I cannot force e.g. NCBI to set up a resolver, and neither can I
force LSID's with the ncbi.nlm.nih.gov authority to come to biomoby.org
for their resolution (since the resolver address is embedded in the
LSID), I cannot make valid LSID's in any namespace that I do not
control.  

This is irrelevant, of course, if we don't plan to resolve them... but
we already have various tools that DO resolve them, so we need to have
them resolvable... so we have to put them in our own namespace.

By using an LSID, I only promise that I will never change its meaning -
I neither promise that it will always be valid, nor that there will
never be another LSID with an identical meaning... so what we are doing
does not break the rules (though I agree it is unfortunate in the way it
is playing out)

M

On Wed, 2004-02-11 at 19:24, Boris Steipe wrote:

> Again: what would prevent you from constructing and using them "as if"? 
> I don't think the potential amount of migration would be larger 
> (probably smaller) than migrating say, all the moby LSIDs to whatever 
> their proper authority is once that authority starts using proper 
> LSIDS. Remember, you are supposed to commit to keeping LSIDs 
> permanently, for hundreds of years. Do you really want to do that ? On 
> the other hand I could not imagine that you would even *allow* e.g. a 
> biomoby.org:pubmed to diverge in its semantics from the NCBI one.
> 
> I would suggest not assigning biomoby.org LSIDs but simply and 
> pragmatically requiring an object to disambiguate its namespace by 
> providing an authority. Then everyone could create/maintain their own 
> namespaces - either semantically linking them to another provider's 
> definition through the domain name, or rolling their own. The nice 
> thing is that this would be forward compatible. Whether this tuple is 
> prefixed by nothing or by urn:lsid doesn't really make a difference, 
> does it ? And even if it did, it would make more sense to use 
> urn:biomoby_id:authority:ns    ...
> 
> To my mind, the neatest thing about the LSIDs is not their resolve to 
> maintain universal and permanent identifiers, but the elegant way of 
> piggybacking on the ICANN solution to creating unique namespaces.
> 
> Sense ?
> 
> 
> B.
> 
> (Or maybe I should start registering a batch of biomoby.org namespaces 
> as a potential source of future income... Hm.   ;-)
> 
> 
> > yes, that was the plan... and in effect it still *is* the plan.
> > However, I cannot assign LSID's arbitrarily to another authority (this
> > is something they must do on their own), so for the moment all 
> > namespace
> > identifiers are in the "biomoby.org" LSID authority, and thus we have 
> > to
> > be careful of collisions.
> >
> > Once LSID's become more widespread we will certainly stop using our own
> > LSID authority prefix and use the "genuine" one, as assigned by the 
> > true
> > naming authority, but until then... we're stuck.
> >
> > M
> >
> >
> > On Wed, 2004-02-11 at 17:37, Boris Steipe wrote:
> >> On Wednesday, Feb 11, 2004, at 16:18 Canada/Eastern, Vijay 
> >> Narayanasamy
> >> wrote:
> >>
> >>> Hi Mark,
> >>>
> >>> I want a NameSpace for Agricola.
> >>>
> >>> In the GO http://www.geneontology.org/doc/GO.xrf_abbs there are three
> >>> entries for Agricola.
> >>>
> >>> 'NAL', 'bib' and 'IND'
> >>>
> >>
> >> What happened to the idea of namespacing like in LSIDs i.e. making a
> >> namespace valid only in the context of its issuing authority and thus
> >> effectively using the (working, sort of) ICANN resolution mechanism to
> >> ensure that namespaces remain unique ?
> >>
> >> The LSID of the object that Vijay describes apparently would be:
> >> urn:lsid:agricola.cos.com:IND:84014403
> >>
> >> The huge advantage is that this distributes the task of maintaining
> >> namespaces to the data providers - no need to register with a central
> >> authority.
> >>
> >> Sure, LSIDs are meant to be permanent and not every provider supports
> >> them yet, but that does not prevent anyone from using the principle on
> >> accession numbers from elsewhere, even if the other authority has no
> >> mechanism to ensure uniqueness and permanence in place - it just
> >> wouldn't be a proper LSID yet, even if it would be structured like 
> >> one.
> >> But it would still serve the purpose at least as well as what's
> >> available already.
> >>
> >> I can't remember what the plan was, regarding that concept.
> >>
> >> Best regards,
> >>
> >>
> >> Boris
> >>
> >> ---
> >> Boris Steipe
> >> University of Toronto
> >> Program in Proteomics & Bioinformatics
> >> Departments of Biochemistry & Molecular and Medical Genetics
> >> http://biochemistry.utoronto.ca/steipe/
> >>
> >> _______________________________________________
> >> moby-l mailing list
> >> moby-l@biomoby.org
> >> http://biomoby.org/mailman/listinfo/moby-l
> > -- 
> > Mark Wilkinson <markw@illuminae.com>
> > Illuminae
> > _______________________________________________
> > moby-l mailing list
> > moby-l@biomoby.org
> > http://biomoby.org/mailman/listinfo/moby-l
> >
> 
> Best regards,
> 
> 
> Boris
> 
> ---
> Boris Steipe
> University of Toronto
> Program in Proteomics & Bioinformatics
> Departments of Biochemistry & Molecular and Medical Genetics
> http://biochemistry.utoronto.ca/steipe/
-- 
Mark Wilkinson <markw@illuminae.com>
Illuminae
From mwilkinson at mobile.rogers.com  Wed Feb 11 21:18:39 2004
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Wed Feb 11 21:24:59 2004
Subject: [MOBY] Re: [MOBY-l] Name Space
Message-ID: <200402120224.i1C2Ov6I032729@portal.open-bio.org>

Cool - that's a trick I hadn't known about.  What is the separator character between the two authority identifiers?

I'm not sure that Sean is on this list...

M

!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!
From boris.steipe at utoronto.ca  Thu Feb 12 02:11:19 2004
From: boris.steipe at utoronto.ca (Boris Steipe)
Date: Thu Feb 12 02:17:15 2004
Subject: [MOBY] Re: [MOBY-l] Name Space
In-Reply-To: <Pine.OSF.4.10.10402120132310.1047662-100000@ice.ebi.ac.uk>
Message-ID: <A7BF558C-5D2A-11D8-A483-000A9577512E@utoronto.ca>


On Wednesday, Feb 11, 2004, at 20:39 Canada/Eastern, Martin Senger 
wrote:

Point taken- but:

To my understanding, the LSID memo does not talk about the resolution 
*mechanism* at all - in the sense of specifying *how* a conforming 
query would need to be structured to be understood by the resolver.

So in practice the client will need to figure this out anyway. Since no 
mechanism is defined you can't use it in practice to resolve anything 
since you don't know how to structure a query. Human clients will go to 
the website, use the namespace to access the proper service and paste 
the acc to retrieve the data. Silicon clients will ... format it as a 
Moby query and send it to Moby  to have Moby resolve it for them? I 
guess thats the whole point here. The only thing that needs to be 
avoided is that the client is tricked into believing this is a real 
LSID, when it isn't. "urn:lsid" could either be optional (if present, 
assume there is a resolver, but you may want to use Moby anyway). Or 
one could use urn:biomoby_id:... to specify that Moby is the resolver 
but the namespace semantics are defined elsewhere. I guess it is not a 
Good Thing to use the same string to define both namespace and 
resolution protocol.

Bottom line: I suggest that Moby use LSIDs when available, create LSIDs 
only for objects that are truly Moby objects, require that all 
namespace be prefixed with an authority that defines that namespace's 
semantics and not define LSIDs for objects not under its semantic 
authority.

My concern would be that there might be a profusion of incompatible 
namespaces otherwise. After all, how would a client know that 
biomoby.org:pubmed has the same semantics as ncbi.nlm.nih.gov:pubmed . 
That strikes me as the larger Problem.

Not ?


Boris

> Just my 2c:
>    The authority field is not important only as a way how to identify
> things world-wide uniquely (if it was only for that, all your arguments
> are completely valid) - but it *may* (the LSID spec does not mandate 
> that
> but suggests it) be used also for finding an appropriate resolution
> service that can return data identified by this LSID. Therefore, if you
> put there pubmed.org, it may never find biomoby.org where it can be
> resolve.
>    I think the solution may be (Sean, are you listening here? Am I 
> right?)
> to have *both* in the authority - biomoby.org *and* pubmed.org - so the
> resolution software will find first biomoby.org and it knows that the 
> rest
> of the authority can be ignored.
>
>    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
>
>



Best regards,


Boris

---
Boris Steipe
University of Toronto
Program in Proteomics & Bioinformatics
Departments of Biochemistry & Molecular and Medical Genetics
http://biochemistry.utoronto.ca/steipe/



Best regards,


Boris

---
Boris Steipe
University of Toronto
Program in Proteomics & Bioinformatics
Departments of Biochemistry & Molecular and Medical Genetics
http://biochemistry.utoronto.ca/steipe/

From jmfernandez at cnb.uam.es  Thu Feb 12 09:40:23 2004
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Thu Feb 12 09:46:29 2004
Subject: [MOBY-l] How to debug multi-parameter services
Message-ID: <402B9057.9050002@cnb.uam.es>

Hi everybody,
	I have developed a couple of services which take two arguments as 
input, and now, how do I debug them? The 'debugYourService' script (very 
useful) only works with single Simple input services.

	I have read the MOBY Client API (Service and ServiceInstance), and as I 
have understood you can invoke a service with a Simple parameter, a 
service with a Collection parameter but I'm unable to see the way to 
invoke a service with two Simple parameters.

	Thanks in advance,
		Jos? Mar?a Fern?ndez
-- 
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
Campus Universidad Aut?noma. Cantoblanco, Madrid (Spain).
From boris.steipe at utoronto.ca  Thu Feb 12 11:39:03 2004
From: boris.steipe at utoronto.ca (Boris Steipe)
Date: Thu Feb 12 11:49:02 2004
Subject: [MOBY-l] Re: MOBY LSID's
In-Reply-To: <1076597695.1735.13.camel@localilluminae.com>
Message-ID: <F7D6CBE6-5D79-11D8-A483-000A9577512E@utoronto.ca>


On Thursday, Feb 12, 2004, at 09:54 Canada/Eastern, Mark Wilkinson 
wrote:
[...]
>
> The important point that I think is being misunderstood here is that we
> are talking about LSID's that *represent namespaces*, NOT LSID's that
> represent data within that namespace!!  As such, biomoby.org is
> *absolutely* the correct authority for namespace LSID's, since
> biomoby.org controls the namespace ontology (as of last week!).

Ok. Thanks! This clarifies my misunderstanding. And I won't harp on the 
aspect of resolution because it's beside this point. Even though I 
believe implicit behavior is never a Good Thing, like LSID sort of 
implying a resolution mechanism. Brrr.

But back to Vijay's original namespace request for IND, bib ... : 
registering not the namespace but the namespacetype doesn't solve the 
problem but moves it to a metalevel.

I understand you would register

    urn:lsid:biomoby.org:namespacetype:IND

But this inherits the problem, it would require something like the 
following to be unique.

urn:lsid:biomoby.org:namespacetype:agricola.cos.com<some separator 
here>IND

... or do I still not get it ?


Boris

>
>
> I discuss this point in various places, but in particular it is
> discussed in my latest paper (get it from the biomoby.org website).  In
> there I have a paragraph clarifying the problem that MOBY has with 
> using
> LSID's "verbatim" (the crux being that LSID's are opaque and DO NOT
> represent underlying data-types without resolution - where the 
> knowledge
> of the underlying data-type is critical to service discovery).  I think
> we are confusing the issue by conflating an identifier WITHIN a
> namespace - for which Boris' argument is absolutely correct and I don't
> think anyone could argue with him - with an identifier that REPRESENTS 
> a
> namespace, for which MOBY is the only authority that exists.
>
> urn:lsid:biomoby.org:namespacetype:DragonDB_Allele
>
> vs.
>
> urn:lsid:antirrhinum.org:allele_id:AG113328
>
> I believe that this is the misunderstanding that is leading to this
> argument, and that once this is clear, the argument goes away.  If not,
> then please read my paragraph about it in the manuscript as I deal with
> it more comprehensively there.
>
> If you all could give me the OK I will forward this message back to the
> public list and we can finish the conversation there.
>
> Thanks!
>
> Mark
>
> -- 
> Mark Wilkinson <markw@illuminae.com>
> Illuminae
>



Best regards,


Boris

---
Boris Steipe
University of Toronto
Program in Proteomics & Bioinformatics
Departments of Biochemistry & Molecular and Medical Genetics
http://biochemistry.utoronto.ca/steipe/

From senger at ebi.ac.uk  Fri Feb 13 05:47:45 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Feb 13 05:53:39 2004
Subject: [MOBY-l] Re: bioMoby - name space (fwd)
Message-ID: <Pine.LNX.4.44.0402131046180.28463-100000@bagheera.ebi.ac.uk>

These are some opinions on the name space problem we had discussed in this 
list from the main LSID promoter/author, Sean Martin from IBM. I am 
expecting other email from him regarding "faking" the authority field - I 
will post it when I have it...

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

---------- Forwarded message ----------
Date: Thu, 12 Feb 2004 09:27:17 -0500
From: Sean Martin <sjmm@us.ibm.com>
To: Martin Senger <senger@ebi.ac.uk>
Cc: Boris Steipe <boris.steipe@utoronto.ca>, markw_mobile2@illuminae.com,
     Benjamin H Szekely <bhszekel@us.ibm.com>, Alyssa Wolf <alyssaw@us.ibm.com>,
     Jordi A Albornoz <jordi@us.ibm.com>
Subject: Re: bioMoby - name space

Hi Martin,
The way we have being thinking about it here is as follows (this is not to 
say it could not be extended as things move forward of course):

Take a lsid  ->  urn:lsid:pdb.org:1aft-qwertyfoo:1 

In this case, when I resolve it, I get pointers to the data named by the 
LSID as well as any meta-data that may be associated with it from the PDB. 
The rule we have followed is that the only authoritative place to get data 
(actual bytes named) for that LSID would be the owning authority - in this 
case the PDB. However *any* resolver (including the PDB) may have also 
have pointers to meta-data related to that LSID.  Each organization that 
has meta-data is authoritative for the meta-data that it supplies. It is 
up to the client that retrieves meta-data to decide what weight (i.e. just 
how good is this meta-data?) to give a piece of meta-data depending on 
which authorities (the source of that bit of meta-data) provided it to 
them.  Naturally the weight for meta-data from the authority that actually 
is authoritative for the data would be high - although perhaps not as high 
as my own local database which gives me the information that in my own 
testing I (for instance) found an error in the official/original 
authorities data/meta-data. The client is free to ask any number of 
authorities (there is no mechanism yet for the discover of these third 
party resolvers - you just have to know them) if they have meta-data for 
any particular LSID. Meta-data from third part authorities is usually not 
the same meta-data that the "original naming" authority (in this case the 
PDB) lists for that LSID. So biomoby.org is quite at liberty to hold its 
own meta-data records for pdb.org or any other authority issued ID's. 
Biomoby clients would be programmed to know to query both the actual 
authority listed in the LSID and the biomoby resolver any time LSID 
resolution is performed. 

This mechanism allows third parties to attach meta-data/or otherwise 
assert facts about data stored in another authority e.g annotation.  In 
fact in our LSID resolver proxy implementations, I believe you can supply 
a list of 3rd party resolvers that you want queried any time an LSID is 
resolved. This allows things like checking a bunch of internal databases, 
or the databases of "friends & colleagues" or other source important to 
your research, for data related to any LSID you happen to be resolving.

I hope this is reasonably clear. Please ask questions if not.

Kindest regards, Sean
:








Martin Senger <senger@ebi.ac.uk> 
02/12/2004 04:18 AM

To
Sean Martin/Cambridge/IBM@IBMUS
cc
Boris Steipe <boris.steipe@utoronto.ca>, <markw_mobile2@illuminae.com>
Subject
bioMoby - name space






Sean,
Yesterday there was a discussion on the BioMoby list about authority
field of the LSID - just in case you are not on that list, here is a very
brief summary - because I have asked there for your expertise:

1) Boris asked:

"What happened to the idea of namespacing like in LSIDs i.e. making a
namespace valid only in the context of its issuing authority and thus
effectively using the (working, sort of) ICANN resolution mechanism to
ensure that namespaces remain unique ?"

2) Mark replied:

"yes, that was the plan... and in effect it still *is* the plan. However,
I cannot assign LSID's arbitrarily to another authority (this is something
they must do on their own), so for the moment all namespace identifiers
are in the "biomoby.org" LSID authority, and thus we have to be careful of
collisions.
Once LSID's become more widespread we will certainly stop using our own
LSID authority prefix and use the "genuine" one, as assigned by the true
naming authority, but until then... we're stuck."

3) I have said:

"Just my 2c:
The authority field is not important only as a way how to identify
things world-wide uniquely (if it was only for that, all your arguments
are completely valid) - but it *may* (the LSID spec does not mandate that
but suggests it) be used also for finding an appropriate resolution
service that can return data identified by this LSID. Therefore, if you
put there pubmed.org, it may never find biomoby.org where it can be
resolve.
I think the solution may be (Sean, are you listening here? Am I right?)
to have *both* in the authority - biomoby.org *and* pubmed.org - so the
resolution software will find first biomoby.org and it knows that the rest
of the authority can be ignored.
"

4) Finally Mark concluded:

"Cool - that's a trick I hadn't known about.  What is the separator
character between the two authority identifiers?"

Now, Sean, your opinion? Many 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 lstein at cshl.edu  Fri Feb 13 10:33:08 2004
From: lstein at cshl.edu (Lincoln Stein)
Date: Fri Feb 13 10:39:12 2004
Subject: [MOBY-l] Proposed dates for MOBY meeting
Message-ID: <200402131733.08070.lstein@cshl.edu>

Hi,

How about the weekends of April 3-4 or April 10-11 for the next MOBY 
meeting?  I would be happy to host it at CSHL.  Before that I'm 
pretty busy with various meetings, and after that Gary is traveling.

Lincoln

-- 
Lincoln D. Stein
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724
From lstein at cshl.edu  Fri Feb 13 10:58:26 2004
From: lstein at cshl.edu (Lincoln Stein)
Date: Fri Feb 13 11:04:28 2004
Subject: [MOBY-l] Proposed dates for MOBY meeting
In-Reply-To: <200402131733.08070.lstein@cshl.edu>
References: <200402131733.08070.lstein@cshl.edu>
Message-ID: <200402131758.26132.lstein@cshl.edu>

Sorry folks, I'm afraid the previous letter was intended for the MOBY 
developers' list.

Lincoln

-- 
Lincoln D. Stein
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724
From senger at ebi.ac.uk  Fri Feb 13 11:21:11 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Feb 13 11:27:13 2004
Subject: [MOBY-l] Proposed dates for MOBY meeting
In-Reply-To: <200402131733.08070.lstein@cshl.edu>
Message-ID: <Pine.LNX.4.44.0402131620270.28463-100000@bagheera.ebi.ac.uk>

> How about the weekends of April 3-4 or April 10-11 for the next MOBY 
> meeting?
>
   3-4 April much better, because April 9-12 are Easter Holidays
   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 kanani at cshl.org  Fri Feb 13 11:37:12 2004
From: kanani at cshl.org (Ardavan Kanani)
Date: Fri Feb 13 11:43:04 2004
Subject: [MOBY-l] object deregister and find service
Message-ID: <DFD21772-5E42-11D8-ACB3-000A9591E2C8@cshl.org>

Hello all,

Lincoln wanted me to find out what would happen if an object that 
already has children was to be de-registered.  I tried this and a 
parent object, including its children, were de-registered without any 
complains from MOBY.  Is this normal or this is a bug?

I have more questions that I will bring up after more testing to make 
sure I am not doing anything wrong.


Ardavan

From markw at illuminae.com  Fri Feb 13 11:50:27 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri Feb 13 11:56:25 2004
Subject: [MOBY] [MOBY-l] object deregister and find service
In-Reply-To: <DFD21772-5E42-11D8-ACB3-000A9591E2C8@cshl.org>
References: <DFD21772-5E42-11D8-ACB3-000A9591E2C8@cshl.org>
Message-ID: <1076691026.2026.10.camel@localilluminae.com>

I can't duplicate this behaviour when I do it (in fact, it is part of my
own test-suite, so I run that test often!).   If it is really happening,
then it is definitely BAD BAD BAD!

There are, in fact, two levels of checking - the first is within MOBY
Central where it checks the service registry to see if any services are
registered that use the object.  If so, then deregistration fails.  It
then hands the request off to the OntologyServer which checks the
ontology for child nodes, and fails if they exist...

Please send me the code you are using that reveals this bug.  I wont get
to it until late next week as I am flying out to Madrid to present MOBY
to the PlaNet meeting tomorrow, but if you can show me how do duplicate
the error I will fix it ASAP, as it really is a serious bug!

Thanks!

Mark


On Fri, 2004-02-13 at 10:37, Ardavan Kanani wrote:
> Hello all,
> 
> Lincoln wanted me to find out what would happen if an object that 
> already has children was to be de-registered.  I tried this and a 
> parent object, including its children, were de-registered without any 
> complains from MOBY.  Is this normal or this is a bug?
> 
> I have more questions that I will bring up after more testing to make 
> sure I am not doing anything wrong.
> 
> 
> Ardavan
> 
> _______________________________________________
> moby-l mailing list
> moby-l@biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
-- 
Mark Wilkinson <markw@illuminae.com>
Illuminae
From markw at illuminae.com  Fri Feb 13 11:52:19 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri Feb 13 11:58:17 2004
Subject: [MOBY] Re: [MOBY-l] Proposed dates for MOBY meeting
In-Reply-To: <Pine.LNX.4.44.0402131620270.28463-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0402131620270.28463-100000@bagheera.ebi.ac.uk>
Message-ID: <1076691139.2024.13.camel@localilluminae.com>

Hi Lincoln!

Thanks for the invitation!

I could probably swing it for April as well.  The earlier dates are much
better for me also.

Mark


On Fri, 2004-02-13 at 10:21, Martin Senger wrote:
> > How about the weekends of April 3-4 or April 10-11 for the next MOBY 
> > meeting?
> >
>    3-4 April much better, because April 9-12 are Easter Holidays
>    Martin
-- 
Mark Wilkinson <markw@illuminae.com>
Illuminae
From sjmm at us.ibm.com  Fri Feb 13 13:45:03 2004
From: sjmm at us.ibm.com (Sean Martin)
Date: Fri Feb 13 19:06:41 2004
Subject: [MOBY-l] Re: bioMoby - name space (fwd)
In-Reply-To: <Pine.LNX.4.44.0402131046180.28463-100000@bagheera.ebi.ac.uk>
Message-ID: <OF21ACD00A.2AE94C25-ON85256E39.0061EEAE-85256E39.0067008F@us.ibm.com>

Now that I have the context after speaking to Martin, I only have a couple 
of things to add. Firstly, Marks comments to Martin and Boris, as pasted 
below are exactly right.

--------------start Mark's comments -------------------------

My comments after sleeping on the problem overnight are as follows:

The important point that I think is being misunderstood here is that we
are talking about LSID's that *represent namespaces*, NOT LSID's that
represent data within that namespace!!  As such, biomoby.org is
*absolutely* the correct authority for namespace LSID's, since
biomoby.org controls the namespace ontology (as of last week!).

I discuss this point in various places, but in particular it is
discussed in my latest paper (get it from the biomoby.org website).  In
there I have a paragraph clarifying the problem that MOBY has with using
LSID's "verbatim" (the crux being that LSID's are opaque and DO NOT
represent underlying data-types without resolution - where the knowledge
of the underlying data-type is critical to service discovery).  I think
we are confusing the issue by conflating an identifier WITHIN a
namespace - for which Boris' argument is absolutely correct and I don't
think anyone could argue with him - with an identifier that REPRESENTS a
namespace, for which MOBY is the only authority that exists.

urn:lsid:biomoby.org:namespacetype:DragonDB_Allele

vs.

urn:lsid:antirrhinum.org:allele_id:AG113328

I believe that this is the misunderstanding that is leading to this
argument, and that once this is clear, the argument goes away.  If not,
then please read my paragraph about it in the manuscript as I deal with
it more comprehensively there.

If you all could give me the OK I will forward this message back to the
public list and we can finish the conversation there.

Thanks!

Mark

--
Mark Wilkinson <markw@illuminae.com>
---------------------------------- end of Mark's comments 
----------------------------------

Secondly, I can shed light the (I believe unrelated) LSID authority naming 
"convention" that Martin was trying to get out of me in his first note. In 
the case where one party needs LSID's for a particular data source that 
they do not own, but which is available through some non-LSID based means 
- perhaps via the web in real-time or perhaps as a download of the latest 
database from that data source, they may if they choose, assign LSID's 
under their own authority for that 3rd party data. The authority string 
naming convention we chose to do this at an I3C hackathon was really 
simple. All one needs to do is take the authority name that one thinks 
would be a logical authority name for the data source you are interested 
in, and concatenated it with your own authority name (in this case it was 
lsid.i3c.org). Here follow some (working and resolvable) example LSID's 
assigned by the I3C during that hackathon:

urn:lsid:ensembl.org.lsid.i3c.org:homosapiens_ref:234325  -  uses the 
ensemble library to contact ensemble.orgt
urn:lsid:ncbi.nlm.gov.lsid.i3c.org:pubmed:11385576 - proxies the request 
to the NCBI machines using the XML interface
urn:lsid:ncbi.nlm.nih.gov.lsid.i3c.org:genbank:bm872070 - proxies the 
request to the NCBI machines using the XML interface

We made entries in the I3C DNS for  ncbi.nlm.gov.lsid.i3c.org, 
ebi.ack.uk.lsid.i3c.org, ncbi.nlm.nih.gov.lsid.i3c.org and attached the 
appropriate SRV records to them, as described  in section 8.3 in the OMG's 
LSID proposed specification document ( 
http://www.omg.org/docs/lifesci/03-12-02.pdf ). The resolution process 
followed is to resolve these in exactly the same was as for any other 
LSID. There is no magic attempt to break up the authority string into two 
authorities. Consumers of these LSID's can simply look at them to see 
where the data is actually coming from - in this case clearly the I3C is 
the authority and is in the end responsible for the delivery of the 
associated data using whatever means it like (proxy to the original 
source, local copy of the original source etc). It is likely folks will 
see more of these "third party" LSID's in the next months as they provide 
LSID access & intergration features to information ahead of the 'OEM' data 
provider being ready to supply their own "native" LSID's under their own 
authority string.

I hope this is clearer, but if there are further questions, please post or 
email me.

Thanks, Sean

--
Sean Martin
IBM Corp.





Martin Senger <senger@ebi.ac.uk> 
Sent by: moby-l-bounces@portal.open-bio.org
02/13/2004 05:47 AM

To
moby-l@biomoby.org
cc

Subject
[MOBY-l] Re: bioMoby - name space (fwd)






These are some opinions on the name space problem we had discussed in this
list from the main LSID promoter/author, Sean Martin from IBM. I am
expecting other email from him regarding "faking" the authority field - I
will post it when I have it...

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

---------- Forwarded message ----------
Date: Thu, 12 Feb 2004 09:27:17 -0500
From: Sean Martin <sjmm@us.ibm.com>
To: Martin Senger <senger@ebi.ac.uk>
Cc: Boris Steipe <boris.steipe@utoronto.ca>, markw_mobile2@illuminae.com,
Benjamin H Szekely <bhszekel@us.ibm.com>, Alyssa Wolf 
<alyssaw@us.ibm.com>,
Jordi A Albornoz <jordi@us.ibm.com>
Subject: Re: bioMoby - name space

Hi Martin,
The way we have being thinking about it here is as follows (this is not to
say it could not be extended as things move forward of course):

Take a lsid  ->  urn:lsid:pdb.org:1aft-qwertyfoo:1

In this case, when I resolve it, I get pointers to the data named by the
LSID as well as any meta-data that may be associated with it from the PDB.
The rule we have followed is that the only authoritative place to get data
(actual bytes named) for that LSID would be the owning authority - in this
case the PDB. However *any* resolver (including the PDB) may have also
have pointers to meta-data related to that LSID.  Each organization that
has meta-data is authoritative for the meta-data that it supplies. It is
up to the client that retrieves meta-data to decide what weight (i.e. just
how good is this meta-data?) to give a piece of meta-data depending on
which authorities (the source of that bit of meta-data) provided it to
them.  Naturally the weight for meta-data from the authority that actually
is authoritative for the data would be high - although perhaps not as high
as my own local database which gives me the information that in my own
testing I (for instance) found an error in the official/original
authorities data/meta-data. The client is free to ask any number of
authorities (there is no mechanism yet for the discover of these third
party resolvers - you just have to know them) if they have meta-data for
any particular LSID. Meta-data from third part authorities is usually not
the same meta-data that the "original naming" authority (in this case the
PDB) lists for that LSID. So biomoby.org is quite at liberty to hold its
own meta-data records for pdb.org or any other authority issued ID's.
Biomoby clients would be programmed to know to query both the actual
authority listed in the LSID and the biomoby resolver any time LSID
resolution is performed.

This mechanism allows third parties to attach meta-data/or otherwise
assert facts about data stored in another authority e.g annotation.  In
fact in our LSID resolver proxy implementations, I believe you can supply
a list of 3rd party resolvers that you want queried any time an LSID is
resolved. This allows things like checking a bunch of internal databases,
or the databases of "friends & colleagues" or other source important to
your research, for data related to any LSID you happen to be resolving.

I hope this is reasonably clear. Please ask questions if not.

Kindest regards, Sean
:








Martin Senger <senger@ebi.ac.uk>
02/12/2004 04:18 AM

To
Sean Martin/Cambridge/IBM@IBMUS
cc
Boris Steipe <boris.steipe@utoronto.ca>, <markw_mobile2@illuminae.com>
Subject
bioMoby - name space






Sean,
Yesterday there was a discussion on the BioMoby list about authority
field of the LSID - just in case you are not on that list, here is a very
brief summary - because I have asked there for your expertise:

1) Boris asked:

"What happened to the idea of namespacing like in LSIDs i.e. making a
namespace valid only in the context of its issuing authority and thus
effectively using the (working, sort of) ICANN resolution mechanism to
ensure that namespaces remain unique ?"

2) Mark replied:

"yes, that was the plan... and in effect it still *is* the plan. However,
I cannot assign LSID's arbitrarily to another authority (this is something
they must do on their own), so for the moment all namespace identifiers
are in the "biomoby.org" LSID authority, and thus we have to be careful of
collisions.
Once LSID's become more widespread we will certainly stop using our own
LSID authority prefix and use the "genuine" one, as assigned by the true
naming authority, but until then... we're stuck."

3) I have said:

"Just my 2c:
The authority field is not important only as a way how to identify
things world-wide uniquely (if it was only for that, all your arguments
are completely valid) - but it *may* (the LSID spec does not mandate that
but suggests it) be used also for finding an appropriate resolution
service that can return data identified by this LSID. Therefore, if you
put there pubmed.org, it may never find biomoby.org where it can be
resolve.
I think the solution may be (Sean, are you listening here? Am I right?)
to have *both* in the authority - biomoby.org *and* pubmed.org - so the
resolution software will find first biomoby.org and it knows that the rest
of the authority can be ignored.
"

4) Finally Mark concluded:

"Cool - that's a trick I hadn't known about.  What is the separator
character between the two authority identifiers?"

Now, Sean, your opinion? Many 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






_______________________________________________
moby-l mailing list
moby-l@biomoby.org
http://biomoby.org/mailman/listinfo/moby-l
From steube at sdsc.edu  Sat Feb 14 16:35:31 2004
From: steube at sdsc.edu (steube@sdsc.edu)
Date: Sat Feb 14 16:41:28 2004
Subject: [MOBY-l] Proposed dates for MOBY meeting
In-Reply-To: <200402131733.08070.lstein@cshl.edu>
References: <200402131733.08070.lstein@cshl.edu>
Message-ID: <1509.200.71.12.137.1076794531.squirrel@uhura.sdsc.edu>

Hi all from Montevideo, Uruguay. I gave a MOBY presentation earlier
this week and next  another next week.

Apr 3, 4  sounds good to me and Gribskov can probably attend, too.

Ken


> Hi,
>
> How about the weekends of April 3-4 or April 10-11 for the next MOBY
> meeting?  I would be happy to host it at CSHL.  Before that I'm
> pretty busy with various meetings, and after that Gary is traveling.
>
> Lincoln
>
> --
> Lincoln D. Stein
> Cold Spring Harbor Laboratory
> 1 Bungtown Road
> Cold Spring Harbor, NY 11724
> _______________________________________________
> moby-l mailing list
> moby-l@biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
>

From mwilkinson at mobile.rogers.com  Sat Feb 14 16:42:16 2004
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Sat Feb 14 16:52:08 2004
Subject: [MOBY-l] Proposed dates for MOBY meeting
Message-ID: <200402142152.i1ELq66I022821@portal.open-bio.org>

Hello from Montreal Dorval airport!  

I'm giving a Moby presentation in Madrid, Spain, tomorrow... Uruguay, Spain... We will soon take over the world! >-)

Ken, you ROCK dude!  Thanks for all your leg-work!

Cheers from the airport lounge - I'm priming myself for a week of Rebecca's bad influence ;-)

M



!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!
From lstein at cshl.edu  Mon Feb 16 04:03:07 2004
From: lstein at cshl.edu (Lincoln Stein)
Date: Mon Feb 16 04:09:09 2004
Subject: [MOBY-l] Re: bioMoby - name space (fwd)
In-Reply-To: <OF21ACD00A.2AE94C25-ON85256E39.0061EEAE-85256E39.0067008F@us.ibm.com>
References: <OF21ACD00A.2AE94C25-ON85256E39.0061EEAE-85256E39.0067008F@us.ibm.com>
Message-ID: <200402161103.07740.lstein@cshl.edu>

Thank you.  The issue is much clearer now.

Lincoln

On Friday 13 February 2004 08:45 pm, Sean Martin wrote:
> Now that I have the context after speaking to Martin, I only have a
> couple of things to add. Firstly, Marks comments to Martin and
> Boris, as pasted below are exactly right.
>
> --------------start Mark's comments -------------------------
>
> My comments after sleeping on the problem overnight are as follows:
>
> The important point that I think is being misunderstood here is
> that we are talking about LSID's that *represent namespaces*, NOT
> LSID's that represent data within that namespace!!  As such,
> biomoby.org is *absolutely* the correct authority for namespace
> LSID's, since biomoby.org controls the namespace ontology (as of
> last week!).
>
> I discuss this point in various places, but in particular it is
> discussed in my latest paper (get it from the biomoby.org website).
>  In there I have a paragraph clarifying the problem that MOBY has
> with using LSID's "verbatim" (the crux being that LSID's are opaque
> and DO NOT represent underlying data-types without resolution -
> where the knowledge of the underlying data-type is critical to
> service discovery).  I think we are confusing the issue by
> conflating an identifier WITHIN a namespace - for which Boris'
> argument is absolutely correct and I don't think anyone could argue
> with him - with an identifier that REPRESENTS a namespace, for
> which MOBY is the only authority that exists.
>
> urn:lsid:biomoby.org:namespacetype:DragonDB_Allele
>
> vs.
>
> urn:lsid:antirrhinum.org:allele_id:AG113328
>
> I believe that this is the misunderstanding that is leading to this
> argument, and that once this is clear, the argument goes away.  If
> not, then please read my paragraph about it in the manuscript as I
> deal with it more comprehensively there.
>
> If you all could give me the OK I will forward this message back to
> the public list and we can finish the conversation there.
>
> Thanks!
>
> Mark
>
> --
> Mark Wilkinson <markw@illuminae.com>
> ---------------------------------- end of Mark's comments
> ----------------------------------
>
> Secondly, I can shed light the (I believe unrelated) LSID authority
> naming "convention" that Martin was trying to get out of me in his
> first note. In the case where one party needs LSID's for a
> particular data source that they do not own, but which is available
> through some non-LSID based means - perhaps via the web in
> real-time or perhaps as a download of the latest database from that
> data source, they may if they choose, assign LSID's under their own
> authority for that 3rd party data. The authority string naming
> convention we chose to do this at an I3C hackathon was really
> simple. All one needs to do is take the authority name that one
> thinks would be a logical authority name for the data source you
> are interested in, and concatenated it with your own authority name
> (in this case it was lsid.i3c.org). Here follow some (working and
> resolvable) example LSID's assigned by the I3C during that
> hackathon:
>
> urn:lsid:ensembl.org.lsid.i3c.org:homosapiens_ref:234325  -  uses
> the ensemble library to contact ensemble.orgt
> urn:lsid:ncbi.nlm.gov.lsid.i3c.org:pubmed:11385576 - proxies the
> request to the NCBI machines using the XML interface
> urn:lsid:ncbi.nlm.nih.gov.lsid.i3c.org:genbank:bm872070 - proxies
> the request to the NCBI machines using the XML interface
>
> We made entries in the I3C DNS for  ncbi.nlm.gov.lsid.i3c.org,
> ebi.ack.uk.lsid.i3c.org, ncbi.nlm.nih.gov.lsid.i3c.org and attached
> the appropriate SRV records to them, as described  in section 8.3
> in the OMG's LSID proposed specification document (
> http://www.omg.org/docs/lifesci/03-12-02.pdf ). The resolution
> process followed is to resolve these in exactly the same was as for
> any other LSID. There is no magic attempt to break up the authority
> string into two authorities. Consumers of these LSID's can simply
> look at them to see where the data is actually coming from - in
> this case clearly the I3C is the authority and is in the end
> responsible for the delivery of the associated data using whatever
> means it like (proxy to the original source, local copy of the
> original source etc). It is likely folks will see more of these
> "third party" LSID's in the next months as they provide LSID access
> & intergration features to information ahead of the 'OEM' data
> provider being ready to supply their own "native" LSID's under
> their own authority string.
>
> I hope this is clearer, but if there are further questions, please
> post or email me.
>
> Thanks, Sean
>
> --
> Sean Martin
> IBM Corp.
>
>
>
>
>
> Martin Senger <senger@ebi.ac.uk>
> Sent by: moby-l-bounces@portal.open-bio.org
> 02/13/2004 05:47 AM
>
> To
> moby-l@biomoby.org
> cc
>
> Subject
> [MOBY-l] Re: bioMoby - name space (fwd)
>
>
>
>
>
>
> These are some opinions on the name space problem we had discussed
> in this list from the main LSID promoter/author, Sean Martin from
> IBM. I am expecting other email from him regarding "faking" the
> authority field - I will post it when I have it...
>
> 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
>
> ---------- Forwarded message ----------
> Date: Thu, 12 Feb 2004 09:27:17 -0500
> From: Sean Martin <sjmm@us.ibm.com>
> To: Martin Senger <senger@ebi.ac.uk>
> Cc: Boris Steipe <boris.steipe@utoronto.ca>,
> markw_mobile2@illuminae.com, Benjamin H Szekely
> <bhszekel@us.ibm.com>, Alyssa Wolf
> <alyssaw@us.ibm.com>,
> Jordi A Albornoz <jordi@us.ibm.com>
> Subject: Re: bioMoby - name space
>
> Hi Martin,
> The way we have being thinking about it here is as follows (this is
> not to say it could not be extended as things move forward of
> course):
>
> Take a lsid  ->  urn:lsid:pdb.org:1aft-qwertyfoo:1
>
> In this case, when I resolve it, I get pointers to the data named
> by the LSID as well as any meta-data that may be associated with it
> from the PDB. The rule we have followed is that the only
> authoritative place to get data (actual bytes named) for that LSID
> would be the owning authority - in this case the PDB. However *any*
> resolver (including the PDB) may have also have pointers to
> meta-data related to that LSID.  Each organization that has
> meta-data is authoritative for the meta-data that it supplies. It
> is up to the client that retrieves meta-data to decide what weight
> (i.e. just how good is this meta-data?) to give a piece of
> meta-data depending on which authorities (the source of that bit of
> meta-data) provided it to them.  Naturally the weight for meta-data
> from the authority that actually is authoritative for the data
> would be high - although perhaps not as high as my own local
> database which gives me the information that in my own testing I
> (for instance) found an error in the official/original authorities
> data/meta-data. The client is free to ask any number of authorities
> (there is no mechanism yet for the discover of these third party
> resolvers - you just have to know them) if they have meta-data for
> any particular LSID. Meta-data from third part authorities is
> usually not the same meta-data that the "original naming" authority
> (in this case the PDB) lists for that LSID. So biomoby.org is quite
> at liberty to hold its own meta-data records for pdb.org or any
> other authority issued ID's. Biomoby clients would be programmed to
> know to query both the actual authority listed in the LSID and the
> biomoby resolver any time LSID resolution is performed.
>
> This mechanism allows third parties to attach meta-data/or
> otherwise assert facts about data stored in another authority e.g
> annotation.  In fact in our LSID resolver proxy implementations, I
> believe you can supply a list of 3rd party resolvers that you want
> queried any time an LSID is resolved. This allows things like
> checking a bunch of internal databases, or the databases of
> "friends & colleagues" or other source important to your research,
> for data related to any LSID you happen to be resolving.
>
> I hope this is reasonably clear. Please ask questions if not.
>
> Kindest regards, Sean
>
>
>
>
>
>
>
>
>
> Martin Senger <senger@ebi.ac.uk>
> 02/12/2004 04:18 AM
>
> To
> Sean Martin/Cambridge/IBM@IBMUS
> cc
> Boris Steipe <boris.steipe@utoronto.ca>,
> <markw_mobile2@illuminae.com> Subject
> bioMoby - name space
>
>
>
>
>
>
> Sean,
> Yesterday there was a discussion on the BioMoby list about
> authority field of the LSID - just in case you are not on that
> list, here is a very brief summary - because I have asked there for
> your expertise:
>
> 1) Boris asked:
>
> "What happened to the idea of namespacing like in LSIDs i.e. making
> a namespace valid only in the context of its issuing authority and
> thus effectively using the (working, sort of) ICANN resolution
> mechanism to ensure that namespaces remain unique ?"
>
> 2) Mark replied:
>
> "yes, that was the plan... and in effect it still *is* the plan.
> However, I cannot assign LSID's arbitrarily to another authority
> (this is something they must do on their own), so for the moment
> all namespace identifiers are in the "biomoby.org" LSID authority,
> and thus we have to be careful of collisions.
> Once LSID's become more widespread we will certainly stop using our
> own LSID authority prefix and use the "genuine" one, as assigned by
> the true naming authority, but until then... we're stuck."
>
> 3) I have said:
>
> "Just my 2c:
> The authority field is not important only as a way how to identify
> things world-wide uniquely (if it was only for that, all your
> arguments are completely valid) - but it *may* (the LSID spec does
> not mandate that but suggests it) be used also for finding an
> appropriate resolution service that can return data identified by
> this LSID. Therefore, if you put there pubmed.org, it may never
> find biomoby.org where it can be resolve.
> I think the solution may be (Sean, are you listening here? Am I
> right?) to have *both* in the authority - biomoby.org *and*
> pubmed.org - so the resolution software will find first biomoby.org
> and it knows that the rest of the authority can be ignored.
> "
>
> 4) Finally Mark concluded:
>
> "Cool - that's a trick I hadn't known about.  What is the separator
> character between the two authority identifiers?"
>
> Now, Sean, your opinion? Many 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
>
>
>
>
>
>
> _______________________________________________
> moby-l mailing list
> moby-l@biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l

-- 
Lincoln D. Stein
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724
From dwaddell at nutecsciences.com  Tue Feb 17 10:05:16 2004
From: dwaddell at nutecsciences.com (Dave Waddell)
Date: Tue Feb 17 14:10:52 2004
Subject: [MOBY-l] Java call to MOBY fails
Message-ID: <003201c3f567$7390ec60$5a0b000a@nutecsciences.com>

I'm trying to make a call to MOBY to retrieve a Genbank Flat File record
using:

	    String NCBI_Acc = "AA936757";
	    String XMLInput = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"
+
	    					"<moby:MOBY
xmlns:moby=\"http://www.biomoby.org/moby\">\n" +
	    					"<moby:Query>\n" +
        					"<moby:queryInput>\n" +
             				"<Simple articleName=''>\n" +
	    					"<Object
namespace=\"urn:lsid:biomoby.org:namespacetype:NCBI_Acc\" id=\"" + NCBI_Acc
+ "\"/>\n" +
             				"</Simple>\n" +
        					"</moby:queryInput>\n" +
	    					"</moby:Query>\n" +
	    					"</moby:MOBY>\n"; 
	    CentralImpl newCall = new
CentralImpl("http://mobycentral.cbr.nrc.ca/cgi-bin/Services/Services.cgi",
"http://biomoby.org/");
	    result = newCall.call("MOBYSHoundGetGenBankff", XMLInput);

but all I get back in "result" is:
<?xml version='1.0' encoding='UTF-8'?>
      <moby:MOBY xmlns:moby='http://www.biomoby.org/moby'
xmlns='http://www.biomoby.org/moby'>
        <moby:Response moby:authority='illuminae.com'>
        
        <moby:queryResponse moby:queryID=''/>
	
        </moby:Response>
      </moby:MOBY>

I have also tried feeding the namespace from:
String[] inputs = new String[]{"NCBI_gi", "NCBI_Acc"};
	    MobyService[] serviceInstance = worker.findService(inputs);
	    for (int j=0; i<serviceInstance.length; i++)
	    {	
	    	System.out.println("NCBI Service # " + i + "= " +
serviceInstance[i].toString());
	    }
	    "<Object namespace=\"" + inputs[0] + "\" id=\"" + NCBI_Acc +
"\"/>\n"

also:
	    					"<Object
namespace=\"urn:lsid:biomoby.org:namespacetype:NCBI_Acc:" + NCBI_Acc +
"\"/>\n" 

Which all give the same result. Any suggestions are appreciated.
Thanks, Dave.


From dwaddell at nutecsciences.com  Tue Feb 17 10:18:19 2004
From: dwaddell at nutecsciences.com (Dave Waddell)
Date: Tue Feb 17 14:10:55 2004
Subject: [MOBY-l] RE: Java call to MOBY fails
Message-ID: <003301c3f569$462fba10$5a0b000a@nutecsciences.com>

I noticed if I replace it with NCBI_gi and id=3094791 everything works fine.
Dave.

-----Original Message-----
From: Dave Waddell [mailto:dwaddell@nutecsciences.com] 
Sent: Tuesday, February 17, 2004 9:05 AM
To: ' (moby-l@biomoby.org)'
Subject: Java call to MOBY fails

I'm trying to make a call to MOBY to retrieve a Genbank Flat File record
using:

	    String NCBI_Acc = "AA936757";
	    String XMLInput = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"
+
	    					"<moby:MOBY
xmlns:moby=\"http://www.biomoby.org/moby\">\n" +
	    					"<moby:Query>\n" +
        					"<moby:queryInput>\n" +
             				"<Simple articleName=''>\n" +
	    					"<Object
namespace=\"urn:lsid:biomoby.org:namespacetype:NCBI_Acc\" id=\"" + NCBI_Acc
+ "\"/>\n" +
             				"</Simple>\n" +
        					"</moby:queryInput>\n" +
	    					"</moby:Query>\n" +
	    					"</moby:MOBY>\n"; 
	    CentralImpl newCall = new
CentralImpl("http://mobycentral.cbr.nrc.ca/cgi-bin/Services/Services.cgi",
"http://biomoby.org/");
	    result = newCall.call("MOBYSHoundGetGenBankff", XMLInput);

but all I get back in "result" is:
<?xml version='1.0' encoding='UTF-8'?>
      <moby:MOBY xmlns:moby='http://www.biomoby.org/moby'
xmlns='http://www.biomoby.org/moby'>
        <moby:Response moby:authority='illuminae.com'>
        
        <moby:queryResponse moby:queryID=''/>
	
        </moby:Response>
      </moby:MOBY>

I have also tried feeding the namespace from:
String[] inputs = new String[]{"NCBI_gi", "NCBI_Acc"};
	    MobyService[] serviceInstance = worker.findService(inputs);
	    for (int j=0; i<serviceInstance.length; i++)
	    {	
	    	System.out.println("NCBI Service # " + i + "= " +
serviceInstance[i].toString());
	    }
	    "<Object namespace=\"" + inputs[0] + "\" id=\"" + NCBI_Acc +
"\"/>\n"

also:
	    					"<Object
namespace=\"urn:lsid:biomoby.org:namespacetype:NCBI_Acc:" + NCBI_Acc +
"\"/>\n" 

Which all give the same result. Any suggestions are appreciated.
Thanks, Dave.


From MRBATESALAN at netscape.net  Tue Feb 17 19:24:19 2004
From: MRBATESALAN at netscape.net (MRBATESALAN@netscape.net)
Date: Tue Feb 17 19:29:13 2004
Subject: [MOBY-l] REPLY SOON
Message-ID: <WIN10563Ts2FZQTGQUE00004859@win10563>

Dear Friend,

As you read this, I don't want you to feel sorry for 
me, because, I believe everyone will die someday. 
My name is BATES ALAN a merchant in Dubai, in the 
U.A.E.I have been diagnosed with Esophageal cancer.
It has defiled all forms of medical treatment, and right now 
I have only about a few months to live, according to medical experts. 
I have not particularly lived my life so well, as I 
never really cared for anyone(not even myself)but my 
business. Though I am very rich, I was never 
generous, I was always hostile to people and only 
focused on my business as that was the only thing I 
cared for. But now I regret all this as I now know 
that there is more to life than just wanting to have 
or make all the money in the world. 
I believe when God gives me a second chance to come 
to this world I would live my life a different way 
from how I have lived it. Now that God has called 
me, I have willed and given most of my property 
and assets to my immediate and extended family 
members as well as a few close friends. 
I want God to be merciful to me and accept my soul 
so, I have decided to give alms to charity 
organizations, as I want this to be one of the last 
good deeds I do on earth. So far, I have distributed 
money to some charity organizations in the U.A.E, 
Algeria and Malaysia. Now that my health has 
deteriorated so badly, I cannot do this myself 
anymore. I once asked members of my family to close one 
of my accounts and distribute the money which I have 
there to charity organization in Bulgaria and 
Pakistan, they refused and kept the money to 
themselves. Hence, I do not trust them anymore, as 
they seem not to be contended with what I have left 
for them. 
The last of my money which no one knows of is the 
huge cash deposit of eighteen million dollars 
$18,000,000,00 that I have with a finance/Security Company 
abroad. I will want you to help me collect this deposit 
and dispatched it to charity organizations.
I have set aside 10% for you and for your time.
God be with you. 
BATES ALAN

From MRBATESALANN at netscape.net  Thu Feb 19 20:21:33 2004
From: MRBATESALANN at netscape.net (MRBATESALANN@netscape.net)
Date: Thu Feb 19 20:27:25 2004
Subject: [MOBY-l] REPLY SOON
Message-ID: <SHA_MAILcXwWfj7jYTd00003f20@sha_mail.sanfordha.com>

Dear Friend,

As you read this, I don't want you to feel sorry for 
me, because, I believe everyone will die someday. 
My name is BATES ALAN a merchant in Dubai, in the 
U.A.E.I have been diagnosed with Esophageal cancer.
It has defiled all forms of medical treatment, and right now 
I have only about a few months to live, according to medical experts. 
I have not particularly lived my life so well, as I 
never really cared for anyone(not even myself)but my 
business. Though I am very rich, I was never 
generous, I was always hostile to people and only 
focused on my business as that was the only thing I 
cared for. But now I regret all this as I now know 
that there is more to life than just wanting to have 
or make all the money in the world. 
I believe when God gives me a second chance to come 
to this world I would live my life a different way 
from how I have lived it. Now that God has called 
me, I have willed and given most of my property 
and assets to my immediate and extended family 
members as well as a few close friends. 
I want God to be merciful to me and accept my soul 
so, I have decided to give alms to charity 
organizations, as I want this to be one of the last 
good deeds I do on earth. So far, I have distributed 
money to some charity organizations in the U.A.E, 
Algeria and Malaysia. Now that my health has 
deteriorated so badly, I cannot do this myself 
anymore. I once asked members of my family to close one 
of my accounts and distribute the money which I have 
there to charity organization in Bulgaria and 
Pakistan, they refused and kept the money to 
themselves. Hence, I do not trust them anymore, as 
they seem not to be contended with what I have left 
for them. 
The last of my money which no one knows of is the 
huge cash deposit of eighteen million dollars 
$18,000,000,00 that I have with a finance/Security Company 
abroad. I will want you to help me collect this deposit 
and dispatched it to charity organizations.
I have set aside 10% for you and for your time.
God be with you. 
BATES ALAN

From MRBATESALANN at netscape.net  Thu Feb 19 21:46:10 2004
From: MRBATESALANN at netscape.net (MRBATESALANN@netscape.net)
Date: Thu Feb 19 21:52:03 2004
Subject: [MOBY-l] REPLY SOON
Message-ID: <SHA_MAIL4RCIlWrdFOS00007134@sha_mail.sanfordha.com>

Dear Friend,

As you read this, I don't want you to feel sorry for 
me, because, I believe everyone will die someday. 
My name is BATES ALAN a merchant in Dubai, in the 
U.A.E.I have been diagnosed with Esophageal cancer.
It has defiled all forms of medical treatment, and right now 
I have only about a few months to live, according to medical experts. 
I have not particularly lived my life so well, as I 
never really cared for anyone(not even myself)but my 
business. Though I am very rich, I was never 
generous, I was always hostile to people and only 
focused on my business as that was the only thing I 
cared for. But now I regret all this as I now know 
that there is more to life than just wanting to have 
or make all the money in the world. 
I believe when God gives me a second chance to come 
to this world I would live my life a different way 
from how I have lived it. Now that God has called 
me, I have willed and given most of my property 
and assets to my immediate and extended family 
members as well as a few close friends. 
I want God to be merciful to me and accept my soul 
so, I have decided to give alms to charity 
organizations, as I want this to be one of the last 
good deeds I do on earth. So far, I have distributed 
money to some charity organizations in the U.A.E, 
Algeria and Malaysia. Now that my health has 
deteriorated so badly, I cannot do this myself 
anymore. I once asked members of my family to close one 
of my accounts and distribute the money which I have 
there to charity organization in Bulgaria and 
Pakistan, they refused and kept the money to 
themselves. Hence, I do not trust them anymore, as 
they seem not to be contended with what I have left 
for them. 
The last of my money which no one knows of is the 
huge cash deposit of eighteen million dollars 
$18,000,000,00 that I have with a finance/Security Company 
abroad. I will want you to help me collect this deposit 
and dispatched it to charity organizations.
I have set aside 10% for you and for your time.
God be with you. 
BATES ALAN

From MRBATESALANN at netscape.net  Sat Feb 21 07:45:06 2004
From: MRBATESALANN at netscape.net (MRBATESALANN@netscape.net)
Date: Sat Feb 21 07:51:21 2004
Subject: [MOBY-l] REPLY SOON
Message-ID: <NT4-RH1pxtjeuZO5cgv00035c74@nt4-rh.rh.local>

Dear Friend,

As you read this, I don't want you to feel sorry for 
me, because, I believe everyone will die someday. 
My name is BATES ALAN a merchant in Dubai, in the 
U.A.E.I have been diagnosed with Esophageal cancer.
It has defiled all forms of medical treatment, and right now 
I have only about a few months to live, according to medical experts. 
I have not particularly lived my life so well, as I 
never really cared for anyone(not even myself)but my 
business. Though I am very rich, I was never 
generous, I was always hostile to people and only 
focused on my business as that was the only thing I 
cared for. But now I regret all this as I now know 
that there is more to life than just wanting to have 
or make all the money in the world. 
I believe when God gives me a second chance to come 
to this world I would live my life a different way 
from how I have lived it. Now that God has called 
me, I have willed and given most of my property 
and assets to my immediate and extended family 
members as well as a few close friends. 
I want God to be merciful to me and accept my soul 
so, I have decided to give alms to charity 
organizations, as I want this to be one of the last 
good deeds I do on earth. So far, I have distributed 
money to some charity organizations in the U.A.E, 
Algeria and Malaysia. Now that my health has 
deteriorated so badly, I cannot do this myself 
anymore. I once asked members of my family to close one 
of my accounts and distribute the money which I have 
there to charity organization in Bulgaria and 
Pakistan, they refused and kept the money to 
themselves. Hence, I do not trust them anymore, as 
they seem not to be contended with what I have left 
for them. 
The last of my money which no one knows of is the 
huge cash deposit of eighteen million dollars 
$18,000,000,00 that I have with a finance/Security Company 
abroad. I will want you to help me collect this deposit 
and dispatched it to charity organizations.
I have set aside 10% for you and for your time.
God be with you. 
BATES ALAN

From r.bruskiewich at cgiar.org  Sun Feb 22 06:58:34 2004
From: r.bruskiewich at cgiar.org (Richard Bruskiewich)
Date: Sun Feb 22 06:55:41 2004
Subject: [MOBY-l] Proposed dates for MOBY meeting
In-Reply-To: <200402131733.08070.lstein@cshl.edu>
Message-ID: <BC5EBA6A.589%r.bruskiewich@cgiar.org>

Hi Lincoln,

We've just had our planning meeting for the first year informatics work plan
for big genetic resources mega-project I've been telling you folks about for
some time now. To keep a long story short, I've been given the leadership of
both the functional genomics platform component and the network (read: MOBY
integration + plant ontology, etc.) component.  Graham McLaren has the
germplasm database coordination.

Given this situation, I'm going to try to identify how we can get somebody
to CSHL for your next MOBY meeting, since network level web services
technologies are a key tool in our project arsenal for information system
integration globally.

Cheers
Richard

On 2/13/04 11:33 PM, "Lincoln Stein" <lstein@cshl.edu> wrote:

> Hi,
> 
> How about the weekends of April 3-4 or April 10-11 for the next MOBY
> meeting?  I would be happy to host it at CSHL.  Before that I'm
> pretty busy with various meetings, and after that Gary is traveling.
> 
> Lincoln

-- 


From markw at illuminae.com  Wed Feb 25 20:16:33 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Feb 25 20:22:34 2004
Subject: [MOBY-l] Acknowledging MOBY-S in your code and on your pages
Message-ID: <1077758193.1916.43.camel@localilluminae.com>

Hi all, 

In an effort to get a more accurate measure of "impact" for the granting
agencies, I have made a "powered by" icon.  I would greatly appreciate
it if anyone who is building web pages that include content derived by
calls to MOBY Central or MOBY Services could link to this icon so that I
can measure hits/distribution.

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

Thanks a lot everyone!

Mark
-- 
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
 
------------------------------------------------------------------------
It just goes to show you that SOAP::Lite is more intuitive than 
you might think, if you know enough Perl and have the patience 
to dive into the source code.
                -Byrne Reese
                -http://builder.com.com/5100-6389_14-1045078-2.html
------------------------------------------------------------------------
From lstein at cshl.edu  Fri Feb 27 10:40:49 2004
From: lstein at cshl.edu (Lincoln Stein)
Date: Fri Feb 27 10:47:01 2004
Subject: [MOBY-l] April 3-4 meeting
In-Reply-To: <1077758193.1916.43.camel@localilluminae.com>
References: <1077758193.1916.43.camel@localilluminae.com>
Message-ID: <200402271740.49773.lstein@cshl.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am waiting for CSHL to get back to me on the availability of housing 
and rooms, but should know early next week whether I can confirm the 
April 3-4 dates.

Lincoln

- -- 
Lincoln D. Stein
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAP2UB0CIvUP7P+AkRAoN3AJ0TkJBdreyQX4wH6PvlGiUVoX+CSACfb180
gbFv0o1B6DxN8GHZVLqr5dY=
=ZEuI
-----END PGP SIGNATURE-----
From markw at illuminae.com  Fri Feb 27 19:12:23 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri Feb 27 19:18:18 2004
Subject: [MOBY-l] Those who were testing Wx on Mac OS... any news?
Message-ID: <1077927143.4365.3.camel@localilluminae.com>

Hi all, 

There were a few of you who had offered to test the Wx code on Mac OS -
did anyone ever get it to work?  I didn't hear back from anyone...

Cheers!
M


-- 
Mark Wilkinson (mwilkinson@mrl.ubc.ca)
University of British Columbia iCAPTURE Centre
From lstein at cshl.edu  Mon Feb  2 07:45:11 2004
From: lstein at cshl.edu (Lincoln Stein)
Date: Mon, 02 Feb 2004 14:45:11 +0200
Subject: [MOBY-l] Re: namespace
In-Reply-To: <Pine.GSO.4.30.0401280901010.24283-100000@groucho.sdsc.edu>
References: <Pine.GSO.4.30.0401280901010.24283-100000@groucho.sdsc.edu>
Message-ID: <200402021445.11518.lstein@cshl.edu>

When you search MOBY central, can you tell it that you're just 
interested in objects from a particular namesspace?  This would 
really help for sharpening the search.

Lincoln

On Wednesday 28 January 2004 07:07 pm, Ken Steube wrote:
> I'm not sure I understand the question...I'll try to answer and you
> can reply for more info.
>
> An object belongs to a particular namespace
> <Object namespace=AGI_LocusCode id=At3g19100/>
> belongs to AGI_LocusCode. Sometimes you might see the namespace
> might being left blank if it's not important (such as for the
> Integer object inside a GenericSequence).
>
> I wouldn't really say a service belongs to a namespace, rather we
> say it accepts objects from particular namespaces. Or a service
> might accept objects of a certain type from any namespace if the
> namespace isn't important (such as BLAST: can accept a DNA seq from
> any namespace so the namespace isn't generally critical info for
> BLAST).
>
> Ken
>
> On Wed, 28 Jan 2004, Ardavan Kanani wrote:
> > Ken,
> >
> > Thanks for responding to my question.  My question is more about
> > an object belonging to a namespace or services belonging to a
> > namespace and not accepting or outputting objects from a
> > particular namespace. Do objects belong to particular namespaces?
> >  If that's the case where in the object registration should I
> > declare its namespace?  Since services are, sort of, objects too,
> > where do I specify what namespace they belong to.  I am trying to
> > create all my objects and services under a namespace called
> > "haplotyping_study"  I might be totally confused as how the
> > namespaces work on MOBY.  I am coming from an object oriented
> > world.  So when I see the disjoint between objects and services
> > in MOBY I get confused.
> >
> > Thanks, Ardavan Kanani
> >
> > On Jan 28, 2004, at 11:36 AM, Ken Steube wrote:
> > > On Wed, 28 Jan 2004, Ardavan Kanani wrote:
> > >> Mark,
> > >> How would I register an object or a service under a particular
> > >> namespace?  I looked at the API doc and the signature for
> > >> registerObjectClass and registerServiceName/Type does not
> > >> include a namespace parameter.
> > >
> > > Here is the script that registers my plantspGetProtein service
> > > to accept an Object from any of the namespaces
> > > ['AGI_LocusCode', 'NCBI_gi', 'SDSC_fg'].
> > >
> > > Ken
> > >
> > >
> > >
> > >
> > >
> > > #!/usr/local/bin/perl5.6.1
> > > use warnings 'all';	# Issue warnings about suspicious
> > > programming use strict;		# Must declare and initialize all
> > > variables
> > >
> > > ###############################################################
> > >######## ##
> > > # This script will register the plantspGetProtein MOBY service
> > > ###############################################################
> > >######## ##
> > >
> > > use MOBY::Client::Central;
> > > use MOBY::Client::Service;
> > >
> > > my $Central = MOBY::Client::Central->new();
> > >
> > > my $reg = $Central->registerService(
> > >   serviceName  => 'plantspGetProtein',
> > >   authURI      => 'www.sdsc.edu',
> > >   contactEmail => 'steube at sdsc.edu',
> > >   description  => "Retrieves a protein sequence from the
> > > PlantsP database (proteins related to phosphorylation,
> > > transporters and ubiquitin)",
> > >   URL          =>
> > > 'http://plantsp.sdsc.edu/cgi-bin/MOBY/PlantsP_dispatcher.cgi',
> > >   input        => [ ['', ["Object" => ['AGI_LocusCode',
> > > 'NCBI_gi', 'SDSC_fg']]], ],
> > >   output       => [ ['', ["AminoAcidSequence" => []]], ],
> > >   category     => "moby",
> > >   serviceType  => "Retrieval",
> > > );
> > > die "Bad return value from registerService" unless $reg;
> > > if ($reg->success == 1){
> > >   print "Registration successful\n\n";
> > > }
> > > else {
> > >   print "Registration failed: ", $reg->message, "\n";
> > > }
> > >
> > >
> > > --
> > > --
> > > --
> > > Ken Steube
> > > San Diego Supercomputer Center
> > > University of California, San Diego
> > > Mail code 0537, CRB room 207
> > > 9500 Gilman Drive
> > > San Diego, California, 92093-0537  USA
> > > FAX (858) 822-3610

-- 
Lincoln D. Stein
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724


From mwilkinson at mobile.rogers.com  Mon Feb  2 09:50:33 2004
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Mon, 2 Feb 2004 09:50:33 -0500
Subject: [MOBY-l] Re: namespace
Message-ID: <200402021504.i12F4OEs025278@portal.open-bio.org>

Yes, you can.

M

(hi from sunny Vancouver!)


!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!


From VNarayan at mail.brc.mcw.edu  Mon Feb  2 15:08:35 2004
From: VNarayan at mail.brc.mcw.edu (Vijay Narayanasamy)
Date: Mon, 2 Feb 2004 14:08:35 -0600 
Subject: [MOBY-l] moby-l@biomoby.org
Message-ID: <295CC5EB4257D411B34D00D0B7748F4432DE8C@baldar.brc.mcw.edu>

Hi Mark,

I am currently developing a PubFetch Service for Agricola literature
database similar to PubFetch service for PubMed.

I have two services. Both use namespace "Global_Keyword" for inputs and
outputs and the object is "Object" (I'll change the namespace and object
type once I get it working)

One service takes the query and retrieves the Agricola accession numbers.
This works OK!


The second service takes the Agricola accession numbers as input and gets
the document in Medline Like format as shown in the following MOBY response

<?xml version='1.0' encoding='UTF-8'?>
      <moby:MOBY xmlns:moby='http://www.biomoby.org/moby'>
        <moby:Response moby:authority='http://www.illuminae.com'>
        
        <moby:queryResponse>
            <Simple><moby:Object namespace='Global_Keyword'
id='IND23321742'><![CDATA[
AN -   IND23321742   
XX -   3321-74260
OWN -   AGL
XX -   F600
XX -   F200
AU -   Lee, G.I.
TI -   1H, 13C and 15N resonance assignments of the kinase-interacting FHA
domain of Arabidopsis thaliana kinase-associated protein phosphatase.
PG -   p. 253-254.
GN -   Letter to the editor.
XX -   Includes references
OT -   spectral analysis
OT -   nuclear magnetic resonance spectroscopy
OT -   amino acid sequences  Internet-resource.
AU -   Li, J.
AU -   Walker, J.C.
AU -   Van Doren, S.R.
SO -   Journal of biomolecular NMR.  J. biomol. NMR  Mar 2003. v. 25 (3)
0925-2738  JBNME9  nnas  jnl52412
XX -   0667-68060
CA -     QP519.9.N83 J68
http://www.kluweronline.com/issn/0925-2738/contents
XX -   20030508  20030509  00000000  IND  GK1
Non-US]]></moby:Object></Simple>
        </moby:queryResponse>
        
    </moby:Response>
      </moby:MOBY>


But the MOBY client (Old Client) reports "service unavailable" for this
service. I don't see any error message in the apache log files. What could
be a possible reason? 

Thank you,

Vijay



Vijay Narayanasamy
Project Programmer / Analyst
Bioinformatics Program, Human and Molecular Genetics Center
Medical College of Wisconsin
8701, W. Watertown Plank Road
Milwaukee, WI 53226
414-456-8026
vnarayan at mcw.edu 
http://brc.mcw.edu/ 




From VNarayan at mail.brc.mcw.edu  Mon Feb  2 18:39:05 2004
From: VNarayan at mail.brc.mcw.edu (Vijay Narayanasamy)
Date: Mon, 2 Feb 2004 17:39:05 -0600 
Subject: [MOBY-l] moby-l@biomoby.org
Message-ID: <295CC5EB4257D411B34D00D0B7748F4432DE92@baldar.brc.mcw.edu>

Thank you Ken, The problem was caused by printing from the Java code
(System.out.println()). I use Perl Inline Java module to wrap the Java
Pubfetch program for Agricola.

The PubFetch service for Agricola works OK now at my local BioMOBY. I will
register the service with public BioMOBY soon.

Thank you,

Vijay

-----Original Message-----
From: Ken Steube [mailto:steube at sdsc.edu] 
Sent: Monday, February 02, 2004 3:22 PM
To: Vijay Narayanasamy
Cc: 'Mark Wilkinson'; Twigger, Simon; 'moby-l at biomoby.org'
Subject: Re: [MOBY-l] moby-l at biomoby.org

Mark may still be preoccupied with moving so I'll take a crack at this.

> But the MOBY client (Old Client) reports "service unavailable"

You can't always debug a service thru the client...you don't get any error
messages. Here's a summary of what I usually do when in your situation:

There are several reasons services fail and you have to do some
experiments to figure it out:

1) Maybe the CGI is not being called.  Go to the top of your dispatcher
CGI (the one you give when you register the service) and before the
dispatch_with() call add this:

  die "testing xxxxxx";

If you see xxxxxx in your http error log you know it's getting to this
CGI.

2) Maybe it's not dispatching. Go to the top of the method for your
service (sub has the same name as the service) and add a line at the top

  return("testing yyyyyy");

Run the service from a script at the command line and see if you get this
yyyyyy line returned from the service. Once you get it you know the
service is being called.

3) Maybe your service has a compile-time error and the error message
doesn't wind up in the http error log for some reason. Run a script like
the attached to execute your service at the command line. The attached
script runs the method of a service by calling it as a subroutine with no
SOAP involvement. Look for compiler errors.

Ken




On Mon, 2 Feb 2004, Vijay Narayanasamy wrote:

> Hi Mark,
>
> I am currently developing a PubFetch Service for Agricola literature
> database similar to PubFetch service for PubMed.
>
> I have two services. Both use namespace "Global_Keyword" for inputs and
> outputs and the object is "Object" (I'll change the namespace and object
> type once I get it working)
>
> One service takes the query and retrieves the Agricola accession numbers.
> This works OK!
>
>
> The second service takes the Agricola accession numbers as input and gets
> the document in Medline Like format as shown in the following MOBY
response
>
> <?xml version='1.0' encoding='UTF-8'?>
>       <moby:MOBY xmlns:moby='http://www.biomoby.org/moby'>
>         <moby:Response moby:authority='http://www.illuminae.com'>
>
>         <moby:queryResponse>
>             <Simple><moby:Object namespace='Global_Keyword'
> id='IND23321742'><![CDATA[
> AN -   IND23321742
> XX -   3321-74260
> OWN -   AGL
> XX -   F600
> XX -   F200
> AU -   Lee, G.I.
> TI -   1H, 13C and 15N resonance assignments of the kinase-interacting FHA
> domain of Arabidopsis thaliana kinase-associated protein phosphatase.
> PG -   p. 253-254.
> GN -   Letter to the editor.
> XX -   Includes references
> OT -   spectral analysis
> OT -   nuclear magnetic resonance spectroscopy
> OT -   amino acid sequences  Internet-resource.
> AU -   Li, J.
> AU -   Walker, J.C.
> AU -   Van Doren, S.R.
> SO -   Journal of biomolecular NMR.  J. biomol. NMR  Mar 2003. v. 25 (3)
> 0925-2738  JBNME9  nnas  jnl52412
> XX -   0667-68060
> CA -     QP519.9.N83 J68
> http://www.kluweronline.com/issn/0925-2738/contents
> XX -   20030508  20030509  00000000  IND  GK1
> Non-US]]></moby:Object></Simple>
>         </moby:queryResponse>
>
>     </moby:Response>
>       </moby:MOBY>
>
>
> But the MOBY client (Old Client) reports "service unavailable" for this
> service. I don't see any error message in the apache log files. What could
> be a possible reason?
>
> Thank you,
>
> Vijay
>
>
>
> Vijay Narayanasamy
> Project Programmer / Analyst
> Bioinformatics Program, Human and Molecular Genetics Center
> Medical College of Wisconsin
> 8701, W. Watertown Plank Road
> Milwaukee, WI 53226
> 414-456-8026
> vnarayan at mcw.edu
> http://brc.mcw.edu/
>
>
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
>

-- 
--
--
Ken Steube
San Diego Supercomputer Center
University of California, San Diego, MC 0505
9500 Gilman Drive
San Diego, California, 92093-0505  USA
FAX (858) 822-3610


From mwilkinson at mobile.rogers.com  Mon Feb  2 22:17:15 2004
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Mon, 2 Feb 2004 22:17:15 -0500
Subject: [MOBY-l] moby-l@biomoby.org
Message-ID: <200402030328.i133SkHH031642@portal.open-bio.org>

Is it still the case that nobody has been able to access a moby service using Java without needing inline perl?  If so, then we really need to figure out why ASAP!

I am pretty sure that Martin and I figured out how to do it at the last I3C meeting, but we might not have disseminated the information to others.

Can someone please say "aye" if they have working code in Java?  Thanks!

Mark


!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!


From steube at sdsc.edu  Mon Feb  2 16:21:31 2004
From: steube at sdsc.edu (Ken Steube)
Date: Mon, 2 Feb 2004 13:21:31 -0800 (PST)
Subject: [MOBY-l] moby-l@biomoby.org
In-Reply-To: <295CC5EB4257D411B34D00D0B7748F4432DE8C@baldar.brc.mcw.edu>
Message-ID: <Pine.GSO.4.30.0402021312160.5579-200000@groucho.sdsc.edu>

Mark may still be preoccupied with moving so I'll take a crack at this.

> But the MOBY client (Old Client) reports "service unavailable"

You can't always debug a service thru the client...you don't get any error
messages. Here's a summary of what I usually do when in your situation:

There are several reasons services fail and you have to do some
experiments to figure it out:

1) Maybe the CGI is not being called.  Go to the top of your dispatcher
CGI (the one you give when you register the service) and before the
dispatch_with() call add this:

  die "testing xxxxxx";

If you see xxxxxx in your http error log you know it's getting to this
CGI.

2) Maybe it's not dispatching. Go to the top of the method for your
service (sub has the same name as the service) and add a line at the top

  return("testing yyyyyy");

Run the service from a script at the command line and see if you get this
yyyyyy line returned from the service. Once you get it you know the
service is being called.

3) Maybe your service has a compile-time error and the error message
doesn't wind up in the http error log for some reason. Run a script like
the attached to execute your service at the command line. The attached
script runs the method of a service by calling it as a subroutine with no
SOAP involvement. Look for compiler errors.

Ken




On Mon, 2 Feb 2004, Vijay Narayanasamy wrote:

> Hi Mark,
>
> I am currently developing a PubFetch Service for Agricola literature
> database similar to PubFetch service for PubMed.
>
> I have two services. Both use namespace "Global_Keyword" for inputs and
> outputs and the object is "Object" (I'll change the namespace and object
> type once I get it working)
>
> One service takes the query and retrieves the Agricola accession numbers.
> This works OK!
>
>
> The second service takes the Agricola accession numbers as input and gets
> the document in Medline Like format as shown in the following MOBY response
>
> <?xml version='1.0' encoding='UTF-8'?>
>       <moby:MOBY xmlns:moby='http://www.biomoby.org/moby'>
>         <moby:Response moby:authority='http://www.illuminae.com'>
>
>         <moby:queryResponse>
>             <Simple><moby:Object namespace='Global_Keyword'
> id='IND23321742'><![CDATA[
> AN -   IND23321742
> XX -   3321-74260
> OWN -   AGL
> XX -   F600
> XX -   F200
> AU -   Lee, G.I.
> TI -   1H, 13C and 15N resonance assignments of the kinase-interacting FHA
> domain of Arabidopsis thaliana kinase-associated protein phosphatase.
> PG -   p. 253-254.
> GN -   Letter to the editor.
> XX -   Includes references
> OT -   spectral analysis
> OT -   nuclear magnetic resonance spectroscopy
> OT -   amino acid sequences  Internet-resource.
> AU -   Li, J.
> AU -   Walker, J.C.
> AU -   Van Doren, S.R.
> SO -   Journal of biomolecular NMR.  J. biomol. NMR  Mar 2003. v. 25 (3)
> 0925-2738  JBNME9  nnas  jnl52412
> XX -   0667-68060
> CA -     QP519.9.N83 J68
> http://www.kluweronline.com/issn/0925-2738/contents
> XX -   20030508  20030509  00000000  IND  GK1
> Non-US]]></moby:Object></Simple>
>         </moby:queryResponse>
>
>     </moby:Response>
>       </moby:MOBY>
>
>
> But the MOBY client (Old Client) reports "service unavailable" for this
> service. I don't see any error message in the apache log files. What could
> be a possible reason?
>
> Thank you,
>
> Vijay
>
>
>
> Vijay Narayanasamy
> Project Programmer / Analyst
> Bioinformatics Program, Human and Molecular Genetics Center
> Medical College of Wisconsin
> 8701, W. Watertown Plank Road
> Milwaukee, WI 53226
> 414-456-8026
> vnarayan at mcw.edu
> http://brc.mcw.edu/
>
>
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
>

-- 
--
--
Ken Steube
San Diego Supercomputer Center
University of California, San Diego, MC 0505
9500 Gilman Drive
San Diego, California, 92093-0505  USA
FAX (858) 822-3610
-------------- next part --------------
#!/usr/local/bin/perl5.6.1

# Name of .pm file containing service method "test_SequenceToFASTA"
use MobyEd_services;

# This is a sample input to a service
my $query = qq{<?xml version='1.0' encoding='UTF-8'?>
<moby:MOBY xmlns:moby='http://www.biomoby.org/moby-s'>
<moby:Query>
<moby:queryInput moby:articleName=''>
<moby:Simple>
<moby:GenericSequence namespace='AGI_LocusCode' id='At3g19100'>
<moby:Integer namespace='' id='' articleName='Length'>599</moby:Integer>
<moby:String namespace='' id='' articleName='SequenceString'>MGGCTSKPSSSVKPNPYAPKDAVLQNDDSTPAHPGKSPVRSSPAVKASPFFPFYTPSPARHRRNKSRDGGGGESKSVTSTPLRQLARAFHPPSPARHIRDVLRRRKEKKEAALPAARQQKEEEEREEVGLDKRFGFSKELQSRIELGEEIGRGHFGYTCSAKFKKGELKDQEVAVKVIPKSKMTSAISIEDVRREVKILRALSGHQNLVQFYDAFEDNANVYIVMELCGGGELLDRILARGGKYSEDDAKAVLIQILNVVAFCHLQGVVHRDLKPENFLYTSKEENSMLKVIDFGLSDFVRPDERLNDIVGSAYYVAPEVLHRSYTTEADVWSIGVIAYILLCGSRPFWARTESGIFRAVLKADPSFDEPPWPSLSFEAKDFVKRLLYKDPRKRMTASQALMHPWIAGYKKIDIPFDILIFKQIKAYLRSSSLRKAALMALSKTLTTDELLYLKAQFAHLAPNKNGLITLDSIRLALATNATEAMKESRIPDFLALLNGLQYKGMDFEEFCAASISVHQHESLDCWEQSIRHAYELFEMNGNRVIVIEELASELGVGSSIPVHTILNDWIRHTDGKLSFLGFVKLLHGVSTRQSLAKTR</moby:String>
</moby:GenericSequence>
</moby:Simple>
</moby:queryInput>
</moby:Query>
</moby:MOBY>
};

# Run the service without SOAP
my $result = MobyEd_services->test_SequenceToFASTA($query);

print "Result of debugging run:\n\n", $result;


From viji at gsf.de  Wed Feb  4 08:16:05 2004
From: viji at gsf.de (Viji)
Date: Wed, 04 Feb 2004 14:16:05 +0100
Subject: [MOBY-l] To access moby service using Java
Message-ID: <4020F095.9050200@gsf.de>

Hi,

I could successfully write and access a moby (test)service in Java. This 
service has an object input and String output.

I would like to know how an output moby object of type "text-xml" should 
look like.

I tried as below.

<moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
    <moby:Response moby:authority="http://mips.gsf.de">
        <moby:queryResponse queryID="">
            <Simple>
                <moby:text-xml namespace="Global_Keyword" id="431260" 
articleName="odata1">
<?xml version="1.0 encoding="UTF-8"?><element 
id="10"><desc>431260</desc></element>
                </moby:text-xml>
            </Simple>
        </moby:queryResponse>
    </moby:Response>
</moby:MOBY>

If you have worked with "text-xml" object(moby specific) types , kindly 
correct me.

Thanks
Viji



From steube at sdsc.edu  Wed Feb  4 10:53:41 2004
From: steube at sdsc.edu (Ken Steube)
Date: Wed, 4 Feb 2004 07:53:41 -0800 (PST)
Subject: [MOBY-l] To access moby service using Java
In-Reply-To: <4020F095.9050200@gsf.de>
Message-ID: <Pine.GSO.4.30.0402040750530.12749-100000@groucho.sdsc.edu>

A text-xml is really just a String, but with a different name. What you
have is correct.

You can find out what an object looks like by going to a URL like this
one:

http://plantsp.sdsc.edu/cgi-bin/MOBY/MOBY_display_object_xml.cgi?obj=text-xml

Ken

On Wed, 4 Feb 2004, Viji wrote:

> Hi,
>
> I could successfully write and access a moby (test)service in Java. This
> service has an object input and String output.
>
> I would like to know how an output moby object of type "text-xml" should
> look like.
>
> I tried as below.
>
> <moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
>     <moby:Response moby:authority="http://mips.gsf.de">
>         <moby:queryResponse queryID="">
>             <Simple>
>                 <moby:text-xml namespace="Global_Keyword" id="431260"
> articleName="odata1">
> <?xml version="1.0 encoding="UTF-8"?><element
> id="10"><desc>431260</desc></element>
>                 </moby:text-xml>
>             </Simple>
>         </moby:queryResponse>
>     </moby:Response>
> </moby:MOBY>
>
> If you have worked with "text-xml" object(moby specific) types , kindly
> correct me.
>
> Thanks
> Viji
>
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
>

-- 
--
--
Ken Steube
San Diego Supercomputer Center
University of California, San Diego, MC 0505
9500 Gilman Drive
San Diego, California, 92093-0505  USA
FAX (858) 822-3610



From gordonp at cbr.nrc.ca  Wed Feb  4 11:46:47 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Wed, 04 Feb 2004 09:46:47 -0700
Subject: [MOBY-l] To access moby service using Java
In-Reply-To: <Pine.GSO.4.30.0402040750530.12749-100000@groucho.sdsc.edu>
References: <Pine.GSO.4.30.0402040750530.12749-100000@groucho.sdsc.edu>
Message-ID: <402121F7.30704@cbr.nrc.ca>

We should be careful.  The example below includes a complete xml 
document (albeit with no xml namespace for the data).  What would 
normally be an XML declaration on the first line of a file turns out to 
be an XML processing instruction (<?xml...) in the middle.  This 
document will not be well-formed, because the BNF definition of a 
well-formed XML document's processing instructions in the XML 1.0 
standard excludes "xml" as a PI target:


	|PI| 	   ::=    	|'<?' PITarget 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-PITarget> (S 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-S> (Char 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* - (Char 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* '?>' Char 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>*)))? '?>'|

	|PITarget| 	   ::=    	|Name 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Name> - (('X' | 'x') 
('M' | 'm') ('L' | 'l'))|


So I guess my point is that there are basically two options:

1. Wrap the moby:text-xml contents in a CDATA section so no payload 
syntax will mess up the well-formed nature of the moby document
2. Make sure we don't send xml declarations and other potentially 
dangerous data down the pipe.

The advantage to the 1st method is a guaranteed clean MOBY document 
every time.  But this also requires everyone to agree that when they see 
a moby:text-xml element, they will consider that the contents needs to 
be unescaped (i.e. the structure of the payload is not accessible from 
the MOBY document DOM, it will have to be parsed separately).  The 
second option allows the payload data and its logical partitions to be 
accessible from the MOBY DOM, but if the contents are not valid, the 
MOBY message as a whole is invalid.

The second option is convenient, but I'm leaning towards a clean 
separation of the whole thing into three layers:  SOAP network 
transport, MOBY transaction envelope, application XML contents.

My CDN$0.02.  Anyone agree, disagree, not care?

Ken Steube wrote:

>><moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
>>    <moby:Response moby:authority="http://mips.gsf.de">
>>        <moby:queryResponse queryID="">
>>            <Simple>
>>                <moby:text-xml namespace="Global_Keyword" id="431260"
>>articleName="odata1">
>><?xml version="1.0 encoding="UTF-8"?><element
>>id="10"><desc>431260</desc></element>
>>                </moby:text-xml>
>>            </Simple>
>>        </moby:queryResponse>
>>    </moby:Response>
>></moby:MOBY>
>>
>>If you have worked with "text-xml" object(moby specific) types , kindly
>>correct me.
>>
>>Thanks
>>Viji
>>
>>_______________________________________________
>>moby-l mailing list
>>moby-l at biomoby.org
>>http://biomoby.org/mailman/listinfo/moby-l
>>
>>    
>>
>
>  
>




From mwilkinson at mobile.rogers.com  Wed Feb  4 12:23:07 2004
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Wed, 4 Feb 2004 12:23:07 -0500
Subject: [MOBY-l] To access moby service using Java
Message-ID: <200402041734.i14HYtHH024177@portal.open-bio.org>

Yeah, I said the same thing, but I forgot to answer to the whole list.

It should be contained in a CDATA element.

Thanks Paul!

M


-----Original Message-----
From: Paul Gordon <gordonp at cbr.nrc.ca>
Date: Wed, 04 Feb 2004 09:46:47 
To:moby-l at biomoby.org
Subject: Re: [MOBY-l] To access moby service using Java

We should be careful.  The example below includes a complete xml 
document (albeit with no xml namespace for the data).  What would 
normally be an XML declaration on the first line of a file turns out to 
be an XML processing instruction (<?xml...) in the middle.  This 
document will not be well-formed, because the BNF definition of a 
well-formed XML document's processing instructions in the XML 1.0 
standard excludes "xml" as a PI target:


	|PI| 	   ::=    	|'<?' PITarget 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-PITarget> (S 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-S> (Char 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* - (Char 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* '?>' Char 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>*)))? '?>'|

	|PITarget| 	   ::=    	|Name 
<http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Name> - (('X' | 'x') 
('M' | 'm') ('L' | 'l'))|


So I guess my point is that there are basically two options:

1. Wrap the moby:text-xml contents in a CDATA section so no payload 
syntax will mess up the well-formed nature of the moby document
2. Make sure we don't send xml declarations and other potentially 
dangerous data down the pipe.

The advantage to the 1st method is a guaranteed clean MOBY document 
every time.  But this also requires everyone to agree that when they see 
a moby:text-xml element, they will consider that the contents needs to 
be unescaped (i.e. the structure of the payload is not accessible from 
the MOBY document DOM, it will have to be parsed separately).  The 
second option allows the payload data and its logical partitions to be 
accessible from the MOBY DOM, but if the contents are not valid, the 
MOBY message as a whole is invalid.

The second option is convenient, but I'm leaning towards a clean 
separation of the whole thing into three layers:  SOAP network 
transport, MOBY transaction envelope, application XML contents.

My CDN$0.02.  Anyone agree, disagree, not care?

Ken Steube wrote:

>><moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
>>    <moby:Response moby:authority="http://mips.gsf.de">
>>        <moby:queryResponse queryID="">
>>            <Simple>
>>                <moby:text-xml namespace="Global_Keyword" id="431260"
>>articleName="odata1">
>><?xml version="1.0 encoding="UTF-8"?><element
>>id="10"><desc>431260</desc></element>
>>                </moby:text-xml>
>>            </Simple>
>>        </moby:queryResponse>
>>    </moby:Response>
>></moby:MOBY>
>>
>>If you have worked with "text-xml" object(moby specific) types , kindly
>>correct me.
>>
>>Thanks
>>Viji
>>
>>_______________________________________________
>>moby-l mailing list
>>moby-l at biomoby.org
>>http://biomoby.org/mailman/listinfo/moby-l
>>
>>    
>>
>
>  
>


_______________________________________________
moby-l mailing list
moby-l at biomoby.org
http://biomoby.org/mailman/listinfo/moby-l

!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!


From gordonp at cbr.nrc.ca  Wed Feb  4 12:56:27 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Wed, 04 Feb 2004 10:56:27 -0700
Subject: [MOBY-l] To access moby service using Java
In-Reply-To: <200402041728.i14HSh0r026819@furry.cbr.nrc.ca>
References: <200402041728.i14HSh0r026819@furry.cbr.nrc.ca>
Message-ID: <4021324B.4010809@cbr.nrc.ca>

Pedantic Paul on the prowl, sorry :-)

It's a common error, but technically "element" in XML refers the 
<start-tag>...</endtag> or <inline-tag/> parts of the document.  Things 
like processing instructions, comments, are "tags" or "nodes".  It's a 
CDATA Section.  Pedantic people read further.

An XML document has one or more elements, so a document that's just a 
comment is not an XML document.  In fact, the XML prolog <?xml...?> tag 
and any comments/whitespace/processing instructions after or before the 
root element close tag are not considered part of the XML document.  
Most DOM implementations will not let you access anything from the 
prolog except the document type declaration(<!DOCTYPE>), so be careful!

>It should be contained in a CDATA element.
>
>Thanks Paul!
>
>M
>
>
>-----Original Message-----
>From: Paul Gordon <gordonp at cbr.nrc.ca>
>Date: Wed, 04 Feb 2004 09:46:47 
>To:moby-l at biomoby.org
>Subject: Re: [MOBY-l] To access moby service using Java
>
>We should be careful.  The example below includes a complete xml 
>document (albeit with no xml namespace for the data).  What would 
>normally be an XML declaration on the first line of a file turns out to 
>be an XML processing instruction (<?xml...) in the middle.  This 
>document will not be well-formed, because the BNF definition of a 
>well-formed XML document's processing instructions in the XML 1.0 
>standard excludes "xml" as a PI target:
>
>
>	|PI| 	   ::=    	|'<?' PITarget 
><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-PITarget> (S 
><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-S> (Char 
><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* - (Char 
><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* '?>' Char 
><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>*)))? '?>'|
>
>	|PITarget| 	   ::=    	|Name 
><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Name> - (('X' | 'x') 
>('M' | 'm') ('L' | 'l'))|
>
>
>So I guess my point is that there are basically two options:
>
>1. Wrap the moby:text-xml contents in a CDATA section so no payload 
>syntax will mess up the well-formed nature of the moby document
>2. Make sure we don't send xml declarations and other potentially 
>dangerous data down the pipe.
>
>The advantage to the 1st method is a guaranteed clean MOBY document 
>every time.  But this also requires everyone to agree that when they see 
>a moby:text-xml element, they will consider that the contents needs to 
>be unescaped (i.e. the structure of the payload is not accessible from 
>the MOBY document DOM, it will have to be parsed separately).  The 
>second option allows the payload data and its logical partitions to be 
>accessible from the MOBY DOM, but if the contents are not valid, the 
>MOBY message as a whole is invalid.
>
>The second option is convenient, but I'm leaning towards a clean 
>separation of the whole thing into three layers:  SOAP network 
>transport, MOBY transaction envelope, application XML contents.
>
>My CDN$0.02.  Anyone agree, disagree, not care?
>
>Ken Steube wrote:
>
>  
>
>>><moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
>>>   <moby:Response moby:authority="http://mips.gsf.de">
>>>       <moby:queryResponse queryID="">
>>>           <Simple>
>>>               <moby:text-xml namespace="Global_Keyword" id="431260"
>>>articleName="odata1">
>>><?xml version="1.0 encoding="UTF-8"?><element
>>>id="10"><desc>431260</desc></element>
>>>               </moby:text-xml>
>>>           </Simple>
>>>       </moby:queryResponse>
>>>   </moby:Response>
>>></moby:MOBY>
>>>
>>>If you have worked with "text-xml" object(moby specific) types , kindly
>>>correct me.
>>>
>>>Thanks
>>>Viji
>>>
>>>_______________________________________________
>>>moby-l mailing list
>>>moby-l at biomoby.org
>>>http://biomoby.org/mailman/listinfo/moby-l
>>>
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>
>
>_______________________________________________
>moby-l mailing list
>moby-l at biomoby.org
>http://biomoby.org/mailman/listinfo/moby-l
>
>!!!!!!!!!!!!!!!!
>To respond to this message you MUST send your response to (note new address!)
>
>markw_mobile2 at illuminae dot com
>
>Responses to the reply-to address go directly to trash!
>!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
>  
>




From markw at illuminae.com  Wed Feb  4 15:49:09 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 04 Feb 2004 14:49:09 -0600
Subject: [MOBY] Re: [MOBY-l] To access moby service using Java
In-Reply-To: <4021324B.4010809@cbr.nrc.ca>
References: <200402041728.i14HSh0r026819@furry.cbr.nrc.ca>
	<4021324B.4010809@cbr.nrc.ca>
Message-ID: <1075927749.2138.22.camel@localilluminae.com>

If more people were as pedantic as you we would have more successful
first-tries at MOBY service building ;-)

M

On Wed, 2004-02-04 at 11:56, Paul Gordon wrote:
> Pedantic Paul on the prowl, sorry :-)
> 
> It's a common error, but technically "element" in XML refers the 
> <start-tag>...</endtag> or <inline-tag/> parts of the document.  Things 
> like processing instructions, comments, are "tags" or "nodes".  It's a 
> CDATA Section.  Pedantic people read further.
> 
> An XML document has one or more elements, so a document that's just a 
> comment is not an XML document.  In fact, the XML prolog <?xml...?> tag 
> and any comments/whitespace/processing instructions after or before the 
> root element close tag are not considered part of the XML document.  
> Most DOM implementations will not let you access anything from the 
> prolog except the document type declaration(<!DOCTYPE>), so be careful!
> 
> >It should be contained in a CDATA element.
> >
> >Thanks Paul!
> >
> >M
> >
> >
> >-----Original Message-----
> >From: Paul Gordon <gordonp at cbr.nrc.ca>
> >Date: Wed, 04 Feb 2004 09:46:47 
> >To:moby-l at biomoby.org
> >Subject: Re: [MOBY-l] To access moby service using Java
> >
> >We should be careful.  The example below includes a complete xml 
> >document (albeit with no xml namespace for the data).  What would 
> >normally be an XML declaration on the first line of a file turns out to 
> >be an XML processing instruction (<?xml...) in the middle.  This 
> >document will not be well-formed, because the BNF definition of a 
> >well-formed XML document's processing instructions in the XML 1.0 
> >standard excludes "xml" as a PI target:
> >
> >
> >	|PI| 	   ::=    	|'<?' PITarget 
> ><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-PITarget> (S 
> ><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-S> (Char 
> ><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* - (Char 
> ><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>* '?>' Char 
> ><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char>*)))? '?>'|
> >
> >	|PITarget| 	   ::=    	|Name 
> ><http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Name> - (('X' | 'x') 
> >('M' | 'm') ('L' | 'l'))|
> >
> >
> >So I guess my point is that there are basically two options:
> >
> >1. Wrap the moby:text-xml contents in a CDATA section so no payload 
> >syntax will mess up the well-formed nature of the moby document
> >2. Make sure we don't send xml declarations and other potentially 
> >dangerous data down the pipe.
> >
> >The advantage to the 1st method is a guaranteed clean MOBY document 
> >every time.  But this also requires everyone to agree that when they see 
> >a moby:text-xml element, they will consider that the contents needs to 
> >be unescaped (i.e. the structure of the payload is not accessible from 
> >the MOBY document DOM, it will have to be parsed separately).  The 
> >second option allows the payload data and its logical partitions to be 
> >accessible from the MOBY DOM, but if the contents are not valid, the 
> >MOBY message as a whole is invalid.
> >
> >The second option is convenient, but I'm leaning towards a clean 
> >separation of the whole thing into three layers:  SOAP network 
> >transport, MOBY transaction envelope, application XML contents.
> >
> >My CDN$0.02.  Anyone agree, disagree, not care?
> >
> >Ken Steube wrote:
> >
> >  
> >
> >>><moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
> >>>   <moby:Response moby:authority="http://mips.gsf.de">
> >>>       <moby:queryResponse queryID="">
> >>>           <Simple>
> >>>               <moby:text-xml namespace="Global_Keyword" id="431260"
> >>>articleName="odata1">
> >>><?xml version="1.0 encoding="UTF-8"?><element
> >>>id="10"><desc>431260</desc></element>
> >>>               </moby:text-xml>
> >>>           </Simple>
> >>>       </moby:queryResponse>
> >>>   </moby:Response>
> >>></moby:MOBY>
> >>>
> >>>If you have worked with "text-xml" object(moby specific) types , kindly
> >>>correct me.
> >>>
> >>>Thanks
> >>>Viji
> >>>
> >>>_______________________________________________
> >>>moby-l mailing list
> >>>moby-l at biomoby.org
> >>>http://biomoby.org/mailman/listinfo/moby-l
> >>>
> >>>   
> >>>
> >>>      
> >>>
> >> 
> >>
> >>    
> >>
> >
> >
> >_______________________________________________
> >moby-l mailing list
> >moby-l at biomoby.org
> >http://biomoby.org/mailman/listinfo/moby-l
> >
> >!!!!!!!!!!!!!!!!
> >To respond to this message you MUST send your response to (note new address!)
> >
> >markw_mobile2 at illuminae dot com
> >
> >Responses to the reply-to address go directly to trash!
> >!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> >
> >  
> >
> 
> 
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
-- 
Mark Wilkinson <markw at illuminae.com>
Illuminae


From steube at sdsc.edu  Wed Feb  4 16:17:22 2004
From: steube at sdsc.edu (Ken Steube)
Date: Wed, 4 Feb 2004 13:17:22 -0800 (PST)
Subject: [MOBY] Re: [MOBY-l] To access moby service using Java
In-Reply-To: <1075927749.2138.22.camel@localilluminae.com>
Message-ID: <Pine.GSO.4.30.0402041314550.13023-100000@groucho.sdsc.edu>

I just updated my section on CDATA in my workshop material at

  http://plantgenome.sdsc.edu/mobyed2/Talks/introduction.html

I had glossed over it before, but now I have it right.

Thx for the info.

Ken



From gordonp at cbr.nrc.ca  Wed Feb  4 17:22:11 2004
From: gordonp at cbr.nrc.ca (Paul Gordon)
Date: Wed, 04 Feb 2004 15:22:11 -0700
Subject: [MOBY] Re: [MOBY-l] To access moby service using Java
In-Reply-To: <Pine.GSO.4.30.0402041314550.13023-100000@groucho.sdsc.edu>
References: <Pine.GSO.4.30.0402041314550.13023-100000@groucho.sdsc.edu>
Message-ID: <40217093.8090900@cbr.nrc.ca>

Almost.  Your CDATA section starts "\n<?xml...".  According to spec, 
"<?xml" must be the start of the parsed data (with the rare exception of 
a platform specific character marking the file as to be read in Text 
Mode or not, like in DOS).  That is, if the XML declaration exists at 
all (it's optional, but very strongly recommended). 

So take out the leading carriage run and you're set!

Cool runnings,

Paul

Ken Steube wrote:

>I just updated my section on CDATA in my workshop material at
>
>  http://plantgenome.sdsc.edu/mobyed2/Talks/introduction.html
>
>I had glossed over it before, but now I have it right.
>
>Thx for the info.
>
>Ken
>
>_______________________________________________
>moby-l mailing list
>moby-l at biomoby.org
>http://biomoby.org/mailman/listinfo/moby-l
>
>  
>




From rebecca.ernst at gsf.de  Thu Feb  5 10:15:19 2004
From: rebecca.ernst at gsf.de (Rebecca Ernst)
Date: Thu, 05 Feb 2004 16:15:19 +0100
Subject: [MOBY-l] collection articles
In-Reply-To: <200402021504.i12F4OEs025278@portal.open-bio.org>
References: <200402021504.i12F4OEs025278@portal.open-bio.org>
Message-ID: <40225E07.1040300@gsf.de>

Hi Mark (and others)!

Heiko and I had some discussions on the primary articles Simple and 
Collection today.

We couldn't imagine a scenario that made a collection article necessary. 
As far as I saw in your (Mark's) services (which give collections back) 
you could have also taken simples instead.

Could you please bring light into the mystery of the collection article? ;-)

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 markw at illuminae.com  Thu Feb  5 15:53:11 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Thu, 05 Feb 2004 14:53:11 -0600
Subject: [MOBY] [MOBY-l] collection articles
In-Reply-To: <40225E07.1040300@gsf.de>
References: <200402021504.i12F4OEs025278@portal.open-bio.org>
	<40225E07.1040300@gsf.de>
Message-ID: <1076014391.2033.22.camel@localilluminae.com>

On Thu, 2004-02-05 at 09:15, Rebecca Ernst wrote:

> We couldn't imagine a scenario that made a collection article necessary. 
> As far as I saw in your (Mark's) services (which give collections back) 
> you could have also taken simples instead.

Well... not really.  If I knew at registration-time exactly how many
simples I was going to pass back in response, then I could register my
service as returning that many simples.  However, in the case of all of
my services that return Collections, I do not know a priori how many
individual responses there will be to the query, so I have to use a
collection.

The service signature is very strict in that regard.  If I say that I
return 'Simple', then I return EXACTLY ONE 'Simple'.  If I return a
defined number of simples, for example 3, then I can register my service
as returning <Simple/><Simple/><Simple/> if the meaning of each Simple
is implicit, or <Simple articleName1/><Simple articleName2/><Simple
articleName3/> if the meaning of each Simple component of the response
has to be clarified.  However, if I am returning an undefined number of
Simples, then I must register it as a Collection.  Moreover, you use
Collections when part of your response is to be considered as a single
unit.  For example, in the following (C = Collection, S = Simple):

<C articleName=alignments>
	<S>
		<align1/>
	</S>
	<S>
		<align2/>
	<S>
		<align3/>
	</S>
</Collection>
<S>
	<align4>
</S>
<S>
	<Annotated GIF>
</S>
<S>
	<Consensus>
</S>

In this case, your input results in a [set of alignments], a [GIF
image], and a [Consensus] - three parts, not six :-)  Moreover, the
number of alignments in the Collection probably wasn't predictable,
since it would depend on the number of sequences passed into the service
(probably also as a Collection input).
 
Hi from my new office!!

Mark

-- 
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

------------------------------------------------------------------------
It just goes to show you that SOAP::Lite is more intuitive than you might 
think, if you know enough Perl and have the patience to dive into the 
source code.
		-Byrne Reese
		-http://builder.com.com/5100-6389_14-1045078-2.html
------------------------------------------------------------------------


From Martin.Leucker at it.uu.se  Mon Feb  9 03:41:02 2004
From: Martin.Leucker at it.uu.se (Martin Leucker)
Date: Mon, 9 Feb 2004 09:41:02 +0100
Subject: [MOBY-l] PDMC'04 - 1st CfP
Message-ID: <20040209084102.GA6004@hamberg.it.uu.se>


        [[ -- Apologies for multiple copies of this message -- ]]

=============================================================================

                              Call for Papers

                      3rd International Workshop on 
              PARALLEL AND DISTRIBUTED METHODS IN VERIFICATION
                              (PDMC 2004)

                   September 4, 2004, London, U.K.
      Workshop affiliated to CONCUR'04, 31 August - 3 September 2004.
             
                  http://www.fi.muni.cz/~brim/PDMC04
 
=============================================================================

OBJECTIVES: The growing importance of automated formal verification in
industry is driving a growing interest in those aspects which have a
direct impact on its applicability to real world problems. One of the
main technical challenges is in devising tools that allow to handle
large state spaces. Over the last years numerous approaches have been
developed. Recently, an increasing interest is in parallelizing and
distributing of verification techniques.

The aim of the PDMC workshop series is to cover all aspects of
parallel and distributed methods and techniques for formal
verification. Theoretical results, algorithms and case studies are
equally welcome. After two successful meetings in 2002 and 2003 with
primary focus on parallelization of model checking, the scope of the
workshop have been extended to cover all approaches where parallel and
distributed techniques can make the automated verification more
effective and/or extend its applicability. This extension is also
reflected in the new name of the workshop.

The PDMC workshop aims to provide a working forum for presenting,
sharing, and discussing recent achievements in the field of parallel
and distributed verification. The workshop will consist of invited
talks and a selection from submitted papers.

SCOPE AND TOPICS: Papers describing recent work on all aspects of
parallel and distributed verification are solicited as contributions
to PDMC. Topics of interest include, but are not limited to:

* parallel and distributed model checking 
* parallel and distributed equivalence checking 
* parallel and distributed satisfiability checking
* slicing and distributing the state space
* distributed theorem proving
* distributed constraints solving
* parallel methods in probabilistic model checking
* file systems for distributed transitions systems
* parallel methods in performance evaluation
* tools and case studies
* industrial applications  
 
SUBMISSION GUIDELINES: There are two categories of submissions:
regular papers and presentations.

    * Manuscripts of regular papers are limited to a maximum of 10
      pages (excluding bibliography and technical appendices) in
      postscript or PDF format (ENTCS style strongly recommended).

    * Presentations report on relevant results submitted to other
      forums or already published or on not yet finished work in
      progress. Presentations will appear in the workshop preliminary
      proceedings, but will not be considered for the final workshop
      proceedings. The space limit for presentations is 10 pages
      (excluding bibliography and technical appendices) in postscript
      or PDF format (ENTCS style strongly recommended).

Submissions should be made electronically using PDMC'04 Submission Page.

PROCEEDINGS: The preliminary workshop proceedings will be available as
a Research Report of Imperial College London. The final proceedings
appear as a volume of Electronic Notes in Theoretical Computer
Science. After the workshop, selected authors will be invited to
submit full versions of their papers (regular papers or presentation
results not submitted for journal publication) to a special section
of a journal (under negotiation).


IMPORTANT DATES:
    *  May 29, 2004: Submission deadline for regular papers.
    * July  5, 2004: Notification of acceptance.
    * July 10, 2004: Deadline for presentations.
    * July 31, 2004: Camera ready copy for proceedings.

 
INVITED SPEAKER:   
Boi B. Faltings (Swiss Federal Institute of Technology, Lausanne)

PROGRAM COMMITTEE:
    * Howard Barringer (Manchester Univ., UK)
    * Lubos Brim (Masaryk Univ., CZ) - Co-chair
    * Gianpiero Cabodi (Torino, IT)
    * Wan Fokkink (CWI Amsterdam, NL)
    * Hubert Garavel (INRIA, FR)
    * Hanne Gottliebsen (Queen Mary Univ. of London, UK)
    * Orna Grumberg (Haifa, Israel) 
    * Boudewijn R. Haverkort (Univ. of Twente, NL)
    * Michael Jones (Brigham Young Univ., USA)
    * Marta Kwiatkowska (Univ. of Birmingham, UK)
    * Martin Lange (LMU Muenchen, DE)
    * Martin Leucker (Uppsala Univ., SE) - Co-chair
    * Sharad Malik (Princeton Univ., USA)
    * Eric Mercer (Brigham Young Univ., USA)
    * Michel Rueher (Universite Nice Sophia Antipolis, FR)
    * Pascal Van Hentenryck (Brown University, USA)
    * Willem Visser (NASA Ames Research Center, USA) 


Lubos Brim & Martin Leucker
workshop organizers











From viji at gsf.de  Wed Feb  4 07:07:34 2004
From: viji at gsf.de (Viji)
Date: Wed, 04 Feb 2004 13:07:34 +0100
Subject: [MOBY-l] A moby service in Java
Message-ID: <4020E086.4030409@gsf.de>

Hi Mark,

I could successfully write and access a moby (test)service in Java. This 
service has an object input and String output.

I would like to know how an output moby object of type "text-xml" should 
look like.

I tried as below.

<moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
    <moby:Response moby:authority="http://mips.gsf.de">
        <moby:queryResponse queryID="">
            <Simple>
                <moby:text-xml namespace="Global_Keyword" id="431260" 
articleName="odata1">
<?xml version="1.0 encoding="UTF-8"?><element 
id="10"><desc>431260</desc></element>
                </moby:text-xml>
            </Simple>
        </moby:queryResponse>
    </moby:Response>
</moby:MOBY>

If you have worked with "text-xml" object(moby specific) types , kindly 
correct me.

Thanks
Viji

From viji at gsf.de  Tue Feb 10 09:28:46 2004
From: viji at gsf.de (Viji)
Date: Tue, 10 Feb 2004 15:28:46 +0100
Subject: [MOBY-l] Source code in Java for registering and accessing moby
 compliant services
Message-ID: <4028EA9E.4010500@gsf.de>

Hi,

Herewith I have enclosed a jar file containing 3 java files within.

1. ServiceRegistrationHelper.java   -   Helper class to register a moby 
compliant service.
2. MobyWrapper.java                    -   Again a helper class that 
unwraps and wraps the input and output MOBY objects resp.
3. TestAxis.java                             -   Main class for which I 
want to establish a moby service for the methods present in it (like 
getTestMessage or getTestXMLOutput).

Note that the authURL for the moby services, getTestMessage or 
getTestXMLOutput is the endpoint of Apache Axis web service.
To be more clear, I have already implemented a web service for the above 
class (TestAxis.java) using Apache axis(deployed in my application 
server). Then, used the endpoint as authURL for registering moby service.

Axis don't need as many services as the number of methods in the class. 
Just a single endpoint can point to all the methods present in it.

Revert back for any clarifications. I'll try to explain to the best of 
my knowledge.

Thanks
Viji
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SampleMobyServiceInJava.jar
Type: application/octet-stream
Size: 3713 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-l/attachments/20040210/6bafb632/SampleMobyServiceInJava-0002.obj

From viji at gsf.de  Tue Feb 10 09:31:38 2004
From: viji at gsf.de (Viji)
Date: Tue, 10 Feb 2004 15:31:38 +0100
Subject: [MOBY-l] Java code for registering and accessing
Message-ID: <4028EB4A.9000407@gsf.de>

Hi,

Herewith I have enclosed a jar file containing 3 java files within.

1. ServiceRegistrationHelper.java   -   Helper class to register a moby 
compliant service.
2. MobyWrapper.java                    -   Again a helper class that 
unwraps and wraps the input and output MOBY objects resp.
3. TestAxis.java                             -   Main class for which I 
want to establish a moby service for the methods present in it (like 
getTestMessage or getTestXMLOutput).

Note that the authURL for the moby services, getTestMessage or 
getTestXMLOutput is the endpoint of Apache Axis web service.
To be more clear, I have already implemented a web service for the above 
class (TestAxis.java) using Apache axis(deployed in my application 
server). Then, used the endpoint as authURL for registering moby service.

Axis don't need as many services as the number of methods in the class. 
Just a single endpoint can point to all the methods present in it.

Revert back for any clarifications. I'll try to explain to the best of 
my knowledge.

Thanks
Viji
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SampleMobyServiceInJava.jar
Type: application/octet-stream
Size: 3713 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-l/attachments/20040210/9b988874/SampleMobyServiceInJava-0002.obj

From viji at gsf.de  Tue Feb 10 09:41:45 2004
From: viji at gsf.de (Viji)
Date: Tue, 10 Feb 2004 15:41:45 +0100
Subject: [MOBY-l] Moby Compliant service in Java
Message-ID: <4028EDA9.6030607@gsf.de>

Hi,

Herewith I have enclosed a jar file containing 3 java files within.

1. ServiceRegistrationHelper.java   -   Helper class to register a moby 
compliant service.
2. MobyWrapper.java                    -   Again a helper class that 
unwraps and wraps the input and output MOBY objects resp.
3. TestAxis.java                             -   Main class for which I 
want to establish a moby service for the methods present in it (like 
getTestMessage or getTestXMLOutput).

Note that the authURL for the moby services, getTestMessage or 
getTestXMLOutput is the endpoint of Apache Axis web service.
To be more clear, I have already implemented a web service for the above 
class (TestAxis.java) using Apache axis(deployed in my application 
server). Then, used the endpoint as authURL for registering moby service.

Axis don't need as many services as the number of methods in the class. 
Just a single endpoint can point to all the methods present in it.

Revert back for any clarifications. I'll try to explain to the best of 
my knowledge.

Thanks
Viji
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SampleMobyServiceInJava.jar
Type: application/octet-stream
Size: 3713 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-l/attachments/20040210/d4ca566a/SampleMobyServiceInJava-0002.obj

From VNarayan at mail.brc.mcw.edu  Wed Feb 11 16:18:03 2004
From: VNarayan at mail.brc.mcw.edu (Vijay Narayanasamy)
Date: Wed, 11 Feb 2004 15:18:03 -0600
Subject: [MOBY-l] Name Space
Message-ID: <295CC5EB4257D411B34D00D0B7748F4432DEBF@baldar.brc.mcw.edu>

Hi Mark,
?
I want a NameSpace for Agricola. 
?
In the GO http://www.geneontology.org/doc/GO.xrf_abbs there are three
entries for Agricola. 
?
'NAL', 'bib' and 'IND' 
?
With release of new Agricola website http://agricola.nal.usda.gov the
services I developed based on 'bib' became irrelevant.
?
I have developed new BioMOBY PubFetch services for Agricola using accession
number (e.g. IND84014403)
?
I want to use the namespace IND for my services. 
?
The following is the entry in GO
?
abbreviation: IND
database: AGRICOLA
object: call number
example: IND84014403
generic_url: http://agricola.cos.com/
?
The way I will use IND
?
abbreviation: IND
database: AGRICOLA
object: accession number
example: IND84014403
generic_url: http://agricola.nal.usda.gov 
example_url:
http://agricola.nal.usda.gov/cgi-bin/Pwebrecon.cgi?DB=local&CNT=1&Search_Arg
=IND84014403&Search_Code=GKEY&STARTDB=AGRIDB 
?
?
I want your consent on this namespace before I register it in MOBY.
?
Thank you,
?
Vijay
?
?
Vijay Narayanasamy
Project Programmer / Analyst
Bioinformatics Program, Human and Molecular Genetics Center
Medical College of Wisconsin
8701, W. Watertown Plank Road
Milwaukee, WI 53226
414-456-8026
vnarayan at mcw.edu 
http://brc.mcw.edu/ 
?





From markw at illuminae.com  Wed Feb 11 15:00:19 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 11 Feb 2004 14:00:19 -0600
Subject: [MOBY-l] Re: [MOBY] Name Space
In-Reply-To: <295CC5EB4257D411B34D00D0B7748F4432DEBE@baldar.brc.mcw.edu>
References: <295CC5EB4257D411B34D00D0B7748F4432DEBE@baldar.brc.mcw.edu>
Message-ID: <1076529619.1675.92.camel@localilluminae.com>

On Wed, 2004-02-11 at 15:15, Vijay Narayanasamy wrote:

> 'NAL', 'bib' and 'IND' 

I see them.
>  

> I have developed new BioMOBY PubFetch services for Agricola using
> accession number (e.g. IND84014403)
> I want to use the namespace IND for my services. 

Great!

> The following is the entry in GO
> abbreviation: IND
> database: AGRICOLA
> object: call number
> example: IND84014403
> 
> generic_url: http://agricola.cos.com/

> The way I will use IND
> abbreviation: IND
> database: AGRICOLA
> object: accession number
> example: IND84014403
> 
> generic_url: http://agricola.nal.usda.gov
> example_url:
> http://agricola.nal.usda.gov/cgi-bin/Pwebrecon.cgi?DB=local&CNT=1&Search_Arg=IND84014403&Search_Code=GKEY&STARTDB=AGRIDB

I don't see any difference in the namespace portion of these two
records.  Just to be sure I am understanding you - you want to use the
IND namespace with *exactly* the same semantic meaning as it currently
has in GO, correct?  If so, then please go ahead.  I was planning to
re-parse the GO xref abbs document into MOBY sometime soon anyway, but
it you need that one right away feel free to register it... so long as
you are not trying to change its intended meaning v.v. what IND means in
the GO xref_abbs - otherwise you will get clobbered next time I parse
the file!

We have been given permission by the GO consortium to take over the
curation of this list in any case.  I just need to find time to build
the tools that will output our database in the GO_xref_abbs file format
so that we don't bugger up the GO people when we do so!  hopefully in a
week or two I'll have done that... hopefully...

Cheers!

M



From suzi at fruitfly.org  Wed Feb 11 17:14:43 2004
From: suzi at fruitfly.org (Suzanna Lewis)
Date: Wed, 11 Feb 2004 14:14:43 -0800
Subject: [MOBY-l] Re: [MOBY] Name Space
In-Reply-To: <1076529619.1675.92.camel@localilluminae.com>
References: <295CC5EB4257D411B34D00D0B7748F4432DEBE@baldar.brc.mcw.edu>
	<1076529619.1675.92.camel@localilluminae.com>
Message-ID: <402AA953.3030508@fruitfly.org>

That will be lovely Mark

>We have been given permission by the GO consortium to take over the
>curation of this list in any case.  I just need to find time to build
>the tools that will output our database in the GO_xref_abbs file format
>so that we don't bugger up the GO people when we do so!  hopefully in a
>week or two I'll have done that... hopefully...
>
>Cheers!
>
>M
>
>_______________________________________________
>moby-l mailing list
>moby-l at biomoby.org
>http://biomoby.org/mailman/listinfo/moby-l
>  
>



From VNarayan at mail.brc.mcw.edu  Wed Feb 11 17:48:09 2004
From: VNarayan at mail.brc.mcw.edu (Vijay Narayanasamy)
Date: Wed, 11 Feb 2004 16:48:09 -0600
Subject: [MOBY-l] RE: [MOBY] Name Space
Message-ID: <295CC5EB4257D411B34D00D0B7748F4432DEC0@baldar.brc.mcw.edu>

Thanks Mark. 

I have published the following services

FetchFull
Authority      prometheus.brc.mcw.edu
Description    Get FullText for given PMID
Input          Object (namespaces: PMID) 
Output         PubMed-MEDLINE (namespaces: PMID)


fetchAgID
Authority      prometheus.brc.mcw.edu
Description    Search Agricola for given query and get Agricola accession
numbers
Input          Object (namespaces: Global_Keyword) 
Output         Object (namespaces: IND) 


fetchAgDoc
Authority      prometheus.brc.mcw.edu
Description    Get Agricola document in MEDLINE like format for given
Agricola accession number
Input          Object (namespaces: IND) 
Output         text-formatted (namespaces: IND) 

-Vijay

-----Original Message-----
From: Mark Wilkinson [mailto:markw at illuminae.com] 
Sent: Wednesday, February 11, 2004 2:00 PM
To: Vijay Narayanasamy
Cc: 'moby-l at biomoby.org'; 'Midori Harris'; 'Suparna Mundodi';
'gmod-pubsearch-dv at lists.sourceforge.net'; Simon Twigger; 'Sue Rhee'
Subject: Re: [MOBY] Name Space

On Wed, 2004-02-11 at 15:15, Vijay Narayanasamy wrote:

> 'NAL', 'bib' and 'IND' 

I see them.
>  

> I have developed new BioMOBY PubFetch services for Agricola using
> accession number (e.g. IND84014403)
> I want to use the namespace IND for my services. 

Great!

> The following is the entry in GO
> abbreviation: IND
> database: AGRICOLA
> object: call number
> example: IND84014403
> 
> generic_url: http://agricola.cos.com/

> The way I will use IND
> abbreviation: IND
> database: AGRICOLA
> object: accession number
> example: IND84014403
> 
> generic_url: http://agricola.nal.usda.gov
> example_url:
>
http://agricola.nal.usda.gov/cgi-bin/Pwebrecon.cgi?DB=local&CNT=1&Search_Arg
=IND84014403&Search_Code=GKEY&STARTDB=AGRIDB

I don't see any difference in the namespace portion of these two
records.  Just to be sure I am understanding you - you want to use the
IND namespace with *exactly* the same semantic meaning as it currently
has in GO, correct?  If so, then please go ahead.  I was planning to
re-parse the GO xref abbs document into MOBY sometime soon anyway, but
it you need that one right away feel free to register it... so long as
you are not trying to change its intended meaning v.v. what IND means in
the GO xref_abbs - otherwise you will get clobbered next time I parse
the file!

We have been given permission by the GO consortium to take over the
curation of this list in any case.  I just need to find time to build
the tools that will output our database in the GO_xref_abbs file format
so that we don't bugger up the GO people when we do so!  hopefully in a
week or two I'll have done that... hopefully...

Cheers!

M


From boris.steipe at utoronto.ca  Wed Feb 11 18:37:04 2004
From: boris.steipe at utoronto.ca (Boris Steipe)
Date: Wed, 11 Feb 2004 18:37:04 -0500
Subject: [MOBY-l] Name Space
In-Reply-To: <295CC5EB4257D411B34D00D0B7748F4432DEBF@baldar.brc.mcw.edu>
Message-ID: <32A2C60C-5CEB-11D8-A483-000A9577512E@utoronto.ca>


On Wednesday, Feb 11, 2004, at 16:18 Canada/Eastern, Vijay Narayanasamy 
wrote:

> Hi Mark,
> ?
> I want a NameSpace for Agricola.
> ?
> In the GO http://www.geneontology.org/doc/GO.xrf_abbs there are three
> entries for Agricola.
> ?
> 'NAL', 'bib' and 'IND'
> ?

What happened to the idea of namespacing like in LSIDs i.e. making a 
namespace valid only in the context of its issuing authority and thus 
effectively using the (working, sort of) ICANN resolution mechanism to 
ensure that namespaces remain unique ?

The LSID of the object that Vijay describes apparently would be:
urn:lsid:agricola.cos.com:IND:84014403

The huge advantage is that this distributes the task of maintaining 
namespaces to the data providers - no need to register with a central 
authority.

Sure, LSIDs are meant to be permanent and not every provider supports 
them yet, but that does not prevent anyone from using the principle on 
accession numbers from elsewhere, even if the other authority has no 
mechanism to ensure uniqueness and permanence in place - it just 
wouldn't be a proper LSID yet, even if it would be structured like one. 
But it would still serve the purpose at least as well as what's 
available already.

I can't remember what the plan was, regarding that concept.

Best regards,


Boris

---
Boris Steipe
University of Toronto
Program in Proteomics & Bioinformatics
Departments of Biochemistry & Molecular and Medical Genetics
http://biochemistry.utoronto.ca/steipe/



From markw at illuminae.com  Wed Feb 11 17:16:45 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 11 Feb 2004 16:16:45 -0600
Subject: [MOBY] Re: [MOBY-l] Name Space
In-Reply-To: <32A2C60C-5CEB-11D8-A483-000A9577512E@utoronto.ca>
References: <32A2C60C-5CEB-11D8-A483-000A9577512E@utoronto.ca>
Message-ID: <1076537805.1723.130.camel@localilluminae.com>

yes, that was the plan... and in effect it still *is* the plan. 
However, I cannot assign LSID's arbitrarily to another authority (this
is something they must do on their own), so for the moment all namespace
identifiers are in the "biomoby.org" LSID authority, and thus we have to
be careful of collisions.

Once LSID's become more widespread we will certainly stop using our own
LSID authority prefix and use the "genuine" one, as assigned by the true
naming authority, but until then... we're stuck.

M


On Wed, 2004-02-11 at 17:37, Boris Steipe wrote:
> On Wednesday, Feb 11, 2004, at 16:18 Canada/Eastern, Vijay Narayanasamy 
> wrote:
> 
> > Hi Mark,
> >  
> > I want a NameSpace for Agricola.
> >  
> > In the GO http://www.geneontology.org/doc/GO.xrf_abbs there are three
> > entries for Agricola.
> >  
> > 'NAL', 'bib' and 'IND'
> >  
> 
> What happened to the idea of namespacing like in LSIDs i.e. making a 
> namespace valid only in the context of its issuing authority and thus 
> effectively using the (working, sort of) ICANN resolution mechanism to 
> ensure that namespaces remain unique ?
> 
> The LSID of the object that Vijay describes apparently would be:
> urn:lsid:agricola.cos.com:IND:84014403
> 
> The huge advantage is that this distributes the task of maintaining 
> namespaces to the data providers - no need to register with a central 
> authority.
> 
> Sure, LSIDs are meant to be permanent and not every provider supports 
> them yet, but that does not prevent anyone from using the principle on 
> accession numbers from elsewhere, even if the other authority has no 
> mechanism to ensure uniqueness and permanence in place - it just 
> wouldn't be a proper LSID yet, even if it would be structured like one. 
> But it would still serve the purpose at least as well as what's 
> available already.
> 
> I can't remember what the plan was, regarding that concept.
> 
> Best regards,
> 
> 
> Boris
> 
> ---
> Boris Steipe
> University of Toronto
> Program in Proteomics & Bioinformatics
> Departments of Biochemistry & Molecular and Medical Genetics
> http://biochemistry.utoronto.ca/steipe/
> 
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
-- 
Mark Wilkinson <markw at illuminae.com>
Illuminae


From boris.steipe at utoronto.ca  Wed Feb 11 20:24:03 2004
From: boris.steipe at utoronto.ca (Boris Steipe)
Date: Wed, 11 Feb 2004 20:24:03 -0500
Subject: [MOBY] Re: [MOBY-l] Name Space
In-Reply-To: <1076537805.1723.130.camel@localilluminae.com>
Message-ID: <24A79638-5CFA-11D8-A483-000A9577512E@utoronto.ca>


On Wednesday, Feb 11, 2004, at 17:16 Canada/Eastern, Mark Wilkinson 
wrote:

Again: what would prevent you from constructing and using them "as if"? 
I don't think the potential amount of migration would be larger 
(probably smaller) than migrating say, all the moby LSIDs to whatever 
their proper authority is once that authority starts using proper 
LSIDS. Remember, you are supposed to commit to keeping LSIDs 
permanently, for hundreds of years. Do you really want to do that ? On 
the other hand I could not imagine that you would even *allow* e.g. a 
biomoby.org:pubmed to diverge in its semantics from the NCBI one.

I would suggest not assigning biomoby.org LSIDs but simply and 
pragmatically requiring an object to disambiguate its namespace by 
providing an authority. Then everyone could create/maintain their own 
namespaces - either semantically linking them to another provider's 
definition through the domain name, or rolling their own. The nice 
thing is that this would be forward compatible. Whether this tuple is 
prefixed by nothing or by urn:lsid doesn't really make a difference, 
does it ? And even if it did, it would make more sense to use 
urn:biomoby_id:authority:ns    ...

To my mind, the neatest thing about the LSIDs is not their resolve to 
maintain universal and permanent identifiers, but the elegant way of 
piggybacking on the ICANN solution to creating unique namespaces.

Sense ?


B.

(Or maybe I should start registering a batch of biomoby.org namespaces 
as a potential source of future income... Hm.   ;-)


> yes, that was the plan... and in effect it still *is* the plan.
> However, I cannot assign LSID's arbitrarily to another authority (this
> is something they must do on their own), so for the moment all 
> namespace
> identifiers are in the "biomoby.org" LSID authority, and thus we have 
> to
> be careful of collisions.
>
> Once LSID's become more widespread we will certainly stop using our own
> LSID authority prefix and use the "genuine" one, as assigned by the 
> true
> naming authority, but until then... we're stuck.
>
> M
>
>
> On Wed, 2004-02-11 at 17:37, Boris Steipe wrote:
>> On Wednesday, Feb 11, 2004, at 16:18 Canada/Eastern, Vijay 
>> Narayanasamy
>> wrote:
>>
>>> Hi Mark,
>>>
>>> I want a NameSpace for Agricola.
>>>
>>> In the GO http://www.geneontology.org/doc/GO.xrf_abbs there are three
>>> entries for Agricola.
>>>
>>> 'NAL', 'bib' and 'IND'
>>>
>>
>> What happened to the idea of namespacing like in LSIDs i.e. making a
>> namespace valid only in the context of its issuing authority and thus
>> effectively using the (working, sort of) ICANN resolution mechanism to
>> ensure that namespaces remain unique ?
>>
>> The LSID of the object that Vijay describes apparently would be:
>> urn:lsid:agricola.cos.com:IND:84014403
>>
>> The huge advantage is that this distributes the task of maintaining
>> namespaces to the data providers - no need to register with a central
>> authority.
>>
>> Sure, LSIDs are meant to be permanent and not every provider supports
>> them yet, but that does not prevent anyone from using the principle on
>> accession numbers from elsewhere, even if the other authority has no
>> mechanism to ensure uniqueness and permanence in place - it just
>> wouldn't be a proper LSID yet, even if it would be structured like 
>> one.
>> But it would still serve the purpose at least as well as what's
>> available already.
>>
>> I can't remember what the plan was, regarding that concept.
>>
>> Best regards,
>>
>>
>> Boris
>>
>> ---
>> Boris Steipe
>> University of Toronto
>> Program in Proteomics & Bioinformatics
>> Departments of Biochemistry & Molecular and Medical Genetics
>> http://biochemistry.utoronto.ca/steipe/
>>
>> _______________________________________________
>> moby-l mailing list
>> moby-l at biomoby.org
>> http://biomoby.org/mailman/listinfo/moby-l
> -- 
> Mark Wilkinson <markw at illuminae.com>
> Illuminae
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
>

Best regards,


Boris

---
Boris Steipe
University of Toronto
Program in Proteomics & Bioinformatics
Departments of Biochemistry & Molecular and Medical Genetics
http://biochemistry.utoronto.ca/steipe/



From senger at ebi.ac.uk  Wed Feb 11 20:39:12 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 12 Feb 2004 01:39:12 +0000 (GMT)
Subject: [MOBY] Re: [MOBY-l] Name Space
In-Reply-To: <24A79638-5CFA-11D8-A483-000A9577512E@utoronto.ca>
Message-ID: <Pine.OSF.4.10.10402120132310.1047662-100000@ice.ebi.ac.uk>

Just my 2c:
   The authority field is not important only as a way how to identify
things world-wide uniquely (if it was only for that, all your arguments
are completely valid) - but it *may* (the LSID spec does not mandate that 
but suggests it) be used also for finding an appropriate resolution
service that can return data identified by this LSID. Therefore, if you
put there pubmed.org, it may never find biomoby.org where it can be
resolve.
   I think the solution may be (Sean, are you listening here? Am I right?)
to have *both* in the authority - biomoby.org *and* pubmed.org - so the
resolution software will find first biomoby.org and it knows that the rest
of the authority can be ignored.

   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 markw at illuminae.com  Wed Feb 11 18:49:13 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 11 Feb 2004 17:49:13 -0600
Subject: [MISC] Re: [MOBY] Re: [MOBY-l] Name Space
In-Reply-To: <24A79638-5CFA-11D8-A483-000A9577512E@utoronto.ca>
References: <24A79638-5CFA-11D8-A483-000A9577512E@utoronto.ca>
Message-ID: <1076543352.1723.157.camel@localilluminae.com>

Yes... and no... the problem is that an LSID kinda sorta inferrs that
there is a resolver out there who can resolve it to data or metadata. 
Since I cannot force e.g. NCBI to set up a resolver, and neither can I
force LSID's with the ncbi.nlm.nih.gov authority to come to biomoby.org
for their resolution (since the resolver address is embedded in the
LSID), I cannot make valid LSID's in any namespace that I do not
control.  

This is irrelevant, of course, if we don't plan to resolve them... but
we already have various tools that DO resolve them, so we need to have
them resolvable... so we have to put them in our own namespace.

By using an LSID, I only promise that I will never change its meaning -
I neither promise that it will always be valid, nor that there will
never be another LSID with an identical meaning... so what we are doing
does not break the rules (though I agree it is unfortunate in the way it
is playing out)

M

On Wed, 2004-02-11 at 19:24, Boris Steipe wrote:

> Again: what would prevent you from constructing and using them "as if"? 
> I don't think the potential amount of migration would be larger 
> (probably smaller) than migrating say, all the moby LSIDs to whatever 
> their proper authority is once that authority starts using proper 
> LSIDS. Remember, you are supposed to commit to keeping LSIDs 
> permanently, for hundreds of years. Do you really want to do that ? On 
> the other hand I could not imagine that you would even *allow* e.g. a 
> biomoby.org:pubmed to diverge in its semantics from the NCBI one.
> 
> I would suggest not assigning biomoby.org LSIDs but simply and 
> pragmatically requiring an object to disambiguate its namespace by 
> providing an authority. Then everyone could create/maintain their own 
> namespaces - either semantically linking them to another provider's 
> definition through the domain name, or rolling their own. The nice 
> thing is that this would be forward compatible. Whether this tuple is 
> prefixed by nothing or by urn:lsid doesn't really make a difference, 
> does it ? And even if it did, it would make more sense to use 
> urn:biomoby_id:authority:ns    ...
> 
> To my mind, the neatest thing about the LSIDs is not their resolve to 
> maintain universal and permanent identifiers, but the elegant way of 
> piggybacking on the ICANN solution to creating unique namespaces.
> 
> Sense ?
> 
> 
> B.
> 
> (Or maybe I should start registering a batch of biomoby.org namespaces 
> as a potential source of future income... Hm.   ;-)
> 
> 
> > yes, that was the plan... and in effect it still *is* the plan.
> > However, I cannot assign LSID's arbitrarily to another authority (this
> > is something they must do on their own), so for the moment all 
> > namespace
> > identifiers are in the "biomoby.org" LSID authority, and thus we have 
> > to
> > be careful of collisions.
> >
> > Once LSID's become more widespread we will certainly stop using our own
> > LSID authority prefix and use the "genuine" one, as assigned by the 
> > true
> > naming authority, but until then... we're stuck.
> >
> > M
> >
> >
> > On Wed, 2004-02-11 at 17:37, Boris Steipe wrote:
> >> On Wednesday, Feb 11, 2004, at 16:18 Canada/Eastern, Vijay 
> >> Narayanasamy
> >> wrote:
> >>
> >>> Hi Mark,
> >>>
> >>> I want a NameSpace for Agricola.
> >>>
> >>> In the GO http://www.geneontology.org/doc/GO.xrf_abbs there are three
> >>> entries for Agricola.
> >>>
> >>> 'NAL', 'bib' and 'IND'
> >>>
> >>
> >> What happened to the idea of namespacing like in LSIDs i.e. making a
> >> namespace valid only in the context of its issuing authority and thus
> >> effectively using the (working, sort of) ICANN resolution mechanism to
> >> ensure that namespaces remain unique ?
> >>
> >> The LSID of the object that Vijay describes apparently would be:
> >> urn:lsid:agricola.cos.com:IND:84014403
> >>
> >> The huge advantage is that this distributes the task of maintaining
> >> namespaces to the data providers - no need to register with a central
> >> authority.
> >>
> >> Sure, LSIDs are meant to be permanent and not every provider supports
> >> them yet, but that does not prevent anyone from using the principle on
> >> accession numbers from elsewhere, even if the other authority has no
> >> mechanism to ensure uniqueness and permanence in place - it just
> >> wouldn't be a proper LSID yet, even if it would be structured like 
> >> one.
> >> But it would still serve the purpose at least as well as what's
> >> available already.
> >>
> >> I can't remember what the plan was, regarding that concept.
> >>
> >> Best regards,
> >>
> >>
> >> Boris
> >>
> >> ---
> >> Boris Steipe
> >> University of Toronto
> >> Program in Proteomics & Bioinformatics
> >> Departments of Biochemistry & Molecular and Medical Genetics
> >> http://biochemistry.utoronto.ca/steipe/
> >>
> >> _______________________________________________
> >> moby-l mailing list
> >> moby-l at biomoby.org
> >> http://biomoby.org/mailman/listinfo/moby-l
> > -- 
> > Mark Wilkinson <markw at illuminae.com>
> > Illuminae
> > _______________________________________________
> > moby-l mailing list
> > moby-l at biomoby.org
> > http://biomoby.org/mailman/listinfo/moby-l
> >
> 
> Best regards,
> 
> 
> Boris
> 
> ---
> Boris Steipe
> University of Toronto
> Program in Proteomics & Bioinformatics
> Departments of Biochemistry & Molecular and Medical Genetics
> http://biochemistry.utoronto.ca/steipe/
-- 
Mark Wilkinson <markw at illuminae.com>
Illuminae


From mwilkinson at mobile.rogers.com  Wed Feb 11 21:18:39 2004
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Wed, 11 Feb 2004 21:18:39 -0500
Subject: [MOBY] Re: [MOBY-l] Name Space
Message-ID: <200402120224.i1C2Ov6I032729@portal.open-bio.org>

Cool - that's a trick I hadn't known about.  What is the separator character between the two authority identifiers?

I'm not sure that Sean is on this list...

M

!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!


From boris.steipe at utoronto.ca  Thu Feb 12 02:11:19 2004
From: boris.steipe at utoronto.ca (Boris Steipe)
Date: Thu, 12 Feb 2004 02:11:19 -0500
Subject: [MOBY] Re: [MOBY-l] Name Space
In-Reply-To: <Pine.OSF.4.10.10402120132310.1047662-100000@ice.ebi.ac.uk>
Message-ID: <A7BF558C-5D2A-11D8-A483-000A9577512E@utoronto.ca>


On Wednesday, Feb 11, 2004, at 20:39 Canada/Eastern, Martin Senger 
wrote:

Point taken- but:

To my understanding, the LSID memo does not talk about the resolution 
*mechanism* at all - in the sense of specifying *how* a conforming 
query would need to be structured to be understood by the resolver.

So in practice the client will need to figure this out anyway. Since no 
mechanism is defined you can't use it in practice to resolve anything 
since you don't know how to structure a query. Human clients will go to 
the website, use the namespace to access the proper service and paste 
the acc to retrieve the data. Silicon clients will ... format it as a 
Moby query and send it to Moby  to have Moby resolve it for them? I 
guess thats the whole point here. The only thing that needs to be 
avoided is that the client is tricked into believing this is a real 
LSID, when it isn't. "urn:lsid" could either be optional (if present, 
assume there is a resolver, but you may want to use Moby anyway). Or 
one could use urn:biomoby_id:... to specify that Moby is the resolver 
but the namespace semantics are defined elsewhere. I guess it is not a 
Good Thing to use the same string to define both namespace and 
resolution protocol.

Bottom line: I suggest that Moby use LSIDs when available, create LSIDs 
only for objects that are truly Moby objects, require that all 
namespace be prefixed with an authority that defines that namespace's 
semantics and not define LSIDs for objects not under its semantic 
authority.

My concern would be that there might be a profusion of incompatible 
namespaces otherwise. After all, how would a client know that 
biomoby.org:pubmed has the same semantics as ncbi.nlm.nih.gov:pubmed . 
That strikes me as the larger Problem.

Not ?


Boris

> Just my 2c:
>    The authority field is not important only as a way how to identify
> things world-wide uniquely (if it was only for that, all your arguments
> are completely valid) - but it *may* (the LSID spec does not mandate 
> that
> but suggests it) be used also for finding an appropriate resolution
> service that can return data identified by this LSID. Therefore, if you
> put there pubmed.org, it may never find biomoby.org where it can be
> resolve.
>    I think the solution may be (Sean, are you listening here? Am I 
> right?)
> to have *both* in the authority - biomoby.org *and* pubmed.org - so the
> resolution software will find first biomoby.org and it knows that the 
> rest
> of the authority can be ignored.
>
>    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
>
>



Best regards,


Boris

---
Boris Steipe
University of Toronto
Program in Proteomics & Bioinformatics
Departments of Biochemistry & Molecular and Medical Genetics
http://biochemistry.utoronto.ca/steipe/



Best regards,


Boris

---
Boris Steipe
University of Toronto
Program in Proteomics & Bioinformatics
Departments of Biochemistry & Molecular and Medical Genetics
http://biochemistry.utoronto.ca/steipe/



From jmfernandez at cnb.uam.es  Thu Feb 12 09:40:23 2004
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Thu, 12 Feb 2004 15:40:23 +0100
Subject: [MOBY-l] How to debug multi-parameter services
Message-ID: <402B9057.9050002@cnb.uam.es>

Hi everybody,
	I have developed a couple of services which take two arguments as 
input, and now, how do I debug them? The 'debugYourService' script (very 
useful) only works with single Simple input services.

	I have read the MOBY Client API (Service and ServiceInstance), and as I 
have understood you can invoke a service with a Simple parameter, a 
service with a Collection parameter but I'm unable to see the way to 
invoke a service with two Simple parameters.

	Thanks in advance,
		Jos? Mar?a Fern?ndez
-- 
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
Campus Universidad Aut?noma. Cantoblanco, Madrid (Spain).


From boris.steipe at utoronto.ca  Thu Feb 12 11:39:03 2004
From: boris.steipe at utoronto.ca (Boris Steipe)
Date: Thu, 12 Feb 2004 11:39:03 -0500
Subject: [MOBY-l] Re: MOBY LSID's
In-Reply-To: <1076597695.1735.13.camel@localilluminae.com>
Message-ID: <F7D6CBE6-5D79-11D8-A483-000A9577512E@utoronto.ca>


On Thursday, Feb 12, 2004, at 09:54 Canada/Eastern, Mark Wilkinson 
wrote:
[...]
>
> The important point that I think is being misunderstood here is that we
> are talking about LSID's that *represent namespaces*, NOT LSID's that
> represent data within that namespace!!  As such, biomoby.org is
> *absolutely* the correct authority for namespace LSID's, since
> biomoby.org controls the namespace ontology (as of last week!).

Ok. Thanks! This clarifies my misunderstanding. And I won't harp on the 
aspect of resolution because it's beside this point. Even though I 
believe implicit behavior is never a Good Thing, like LSID sort of 
implying a resolution mechanism. Brrr.

But back to Vijay's original namespace request for IND, bib ... : 
registering not the namespace but the namespacetype doesn't solve the 
problem but moves it to a metalevel.

I understand you would register

    urn:lsid:biomoby.org:namespacetype:IND

But this inherits the problem, it would require something like the 
following to be unique.

urn:lsid:biomoby.org:namespacetype:agricola.cos.com<some separator 
here>IND

... or do I still not get it ?


Boris

>
>
> I discuss this point in various places, but in particular it is
> discussed in my latest paper (get it from the biomoby.org website).  In
> there I have a paragraph clarifying the problem that MOBY has with 
> using
> LSID's "verbatim" (the crux being that LSID's are opaque and DO NOT
> represent underlying data-types without resolution - where the 
> knowledge
> of the underlying data-type is critical to service discovery).  I think
> we are confusing the issue by conflating an identifier WITHIN a
> namespace - for which Boris' argument is absolutely correct and I don't
> think anyone could argue with him - with an identifier that REPRESENTS 
> a
> namespace, for which MOBY is the only authority that exists.
>
> urn:lsid:biomoby.org:namespacetype:DragonDB_Allele
>
> vs.
>
> urn:lsid:antirrhinum.org:allele_id:AG113328
>
> I believe that this is the misunderstanding that is leading to this
> argument, and that once this is clear, the argument goes away.  If not,
> then please read my paragraph about it in the manuscript as I deal with
> it more comprehensively there.
>
> If you all could give me the OK I will forward this message back to the
> public list and we can finish the conversation there.
>
> Thanks!
>
> Mark
>
> -- 
> Mark Wilkinson <markw at illuminae.com>
> Illuminae
>



Best regards,


Boris

---
Boris Steipe
University of Toronto
Program in Proteomics & Bioinformatics
Departments of Biochemistry & Molecular and Medical Genetics
http://biochemistry.utoronto.ca/steipe/



From senger at ebi.ac.uk  Fri Feb 13 05:47:45 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 13 Feb 2004 10:47:45 +0000 (GMT)
Subject: [MOBY-l] Re: bioMoby - name space (fwd)
Message-ID: <Pine.LNX.4.44.0402131046180.28463-100000@bagheera.ebi.ac.uk>

These are some opinions on the name space problem we had discussed in this 
list from the main LSID promoter/author, Sean Martin from IBM. I am 
expecting other email from him regarding "faking" the authority field - I 
will post it when I have it...

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

---------- Forwarded message ----------
Date: Thu, 12 Feb 2004 09:27:17 -0500
From: Sean Martin <sjmm at us.ibm.com>
To: Martin Senger <senger at ebi.ac.uk>
Cc: Boris Steipe <boris.steipe at utoronto.ca>, markw_mobile2 at illuminae.com,
     Benjamin H Szekely <bhszekel at us.ibm.com>, Alyssa Wolf <alyssaw at us.ibm.com>,
     Jordi A Albornoz <jordi at us.ibm.com>
Subject: Re: bioMoby - name space

Hi Martin,
The way we have being thinking about it here is as follows (this is not to 
say it could not be extended as things move forward of course):

Take a lsid  ->  urn:lsid:pdb.org:1aft-qwertyfoo:1 

In this case, when I resolve it, I get pointers to the data named by the 
LSID as well as any meta-data that may be associated with it from the PDB. 
The rule we have followed is that the only authoritative place to get data 
(actual bytes named) for that LSID would be the owning authority - in this 
case the PDB. However *any* resolver (including the PDB) may have also 
have pointers to meta-data related to that LSID.  Each organization that 
has meta-data is authoritative for the meta-data that it supplies. It is 
up to the client that retrieves meta-data to decide what weight (i.e. just 
how good is this meta-data?) to give a piece of meta-data depending on 
which authorities (the source of that bit of meta-data) provided it to 
them.  Naturally the weight for meta-data from the authority that actually 
is authoritative for the data would be high - although perhaps not as high 
as my own local database which gives me the information that in my own 
testing I (for instance) found an error in the official/original 
authorities data/meta-data. The client is free to ask any number of 
authorities (there is no mechanism yet for the discover of these third 
party resolvers - you just have to know them) if they have meta-data for 
any particular LSID. Meta-data from third part authorities is usually not 
the same meta-data that the "original naming" authority (in this case the 
PDB) lists for that LSID. So biomoby.org is quite at liberty to hold its 
own meta-data records for pdb.org or any other authority issued ID's. 
Biomoby clients would be programmed to know to query both the actual 
authority listed in the LSID and the biomoby resolver any time LSID 
resolution is performed. 

This mechanism allows third parties to attach meta-data/or otherwise 
assert facts about data stored in another authority e.g annotation.  In 
fact in our LSID resolver proxy implementations, I believe you can supply 
a list of 3rd party resolvers that you want queried any time an LSID is 
resolved. This allows things like checking a bunch of internal databases, 
or the databases of "friends & colleagues" or other source important to 
your research, for data related to any LSID you happen to be resolving.

I hope this is reasonably clear. Please ask questions if not.

Kindest regards, Sean
:








Martin Senger <senger at ebi.ac.uk> 
02/12/2004 04:18 AM

To
Sean Martin/Cambridge/IBM at IBMUS
cc
Boris Steipe <boris.steipe at utoronto.ca>, <markw_mobile2 at illuminae.com>
Subject
bioMoby - name space






Sean,
Yesterday there was a discussion on the BioMoby list about authority
field of the LSID - just in case you are not on that list, here is a very
brief summary - because I have asked there for your expertise:

1) Boris asked:

"What happened to the idea of namespacing like in LSIDs i.e. making a
namespace valid only in the context of its issuing authority and thus
effectively using the (working, sort of) ICANN resolution mechanism to
ensure that namespaces remain unique ?"

2) Mark replied:

"yes, that was the plan... and in effect it still *is* the plan. However,
I cannot assign LSID's arbitrarily to another authority (this is something
they must do on their own), so for the moment all namespace identifiers
are in the "biomoby.org" LSID authority, and thus we have to be careful of
collisions.
Once LSID's become more widespread we will certainly stop using our own
LSID authority prefix and use the "genuine" one, as assigned by the true
naming authority, but until then... we're stuck."

3) I have said:

"Just my 2c:
The authority field is not important only as a way how to identify
things world-wide uniquely (if it was only for that, all your arguments
are completely valid) - but it *may* (the LSID spec does not mandate that
but suggests it) be used also for finding an appropriate resolution
service that can return data identified by this LSID. Therefore, if you
put there pubmed.org, it may never find biomoby.org where it can be
resolve.
I think the solution may be (Sean, are you listening here? Am I right?)
to have *both* in the authority - biomoby.org *and* pubmed.org - so the
resolution software will find first biomoby.org and it knows that the rest
of the authority can be ignored.
"

4) Finally Mark concluded:

"Cool - that's a trick I hadn't known about.  What is the separator
character between the two authority identifiers?"

Now, Sean, your opinion? Many 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 lstein at cshl.edu  Fri Feb 13 10:33:08 2004
From: lstein at cshl.edu (Lincoln Stein)
Date: Fri, 13 Feb 2004 17:33:08 +0200
Subject: [MOBY-l] Proposed dates for MOBY meeting
Message-ID: <200402131733.08070.lstein@cshl.edu>

Hi,

How about the weekends of April 3-4 or April 10-11 for the next MOBY 
meeting?  I would be happy to host it at CSHL.  Before that I'm 
pretty busy with various meetings, and after that Gary is traveling.

Lincoln

-- 
Lincoln D. Stein
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724


From lstein at cshl.edu  Fri Feb 13 10:58:26 2004
From: lstein at cshl.edu (Lincoln Stein)
Date: Fri, 13 Feb 2004 17:58:26 +0200
Subject: [MOBY-l] Proposed dates for MOBY meeting
In-Reply-To: <200402131733.08070.lstein@cshl.edu>
References: <200402131733.08070.lstein@cshl.edu>
Message-ID: <200402131758.26132.lstein@cshl.edu>

Sorry folks, I'm afraid the previous letter was intended for the MOBY 
developers' list.

Lincoln

-- 
Lincoln D. Stein
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724


From senger at ebi.ac.uk  Fri Feb 13 11:21:11 2004
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 13 Feb 2004 16:21:11 +0000 (GMT)
Subject: [MOBY-l] Proposed dates for MOBY meeting
In-Reply-To: <200402131733.08070.lstein@cshl.edu>
Message-ID: <Pine.LNX.4.44.0402131620270.28463-100000@bagheera.ebi.ac.uk>

> How about the weekends of April 3-4 or April 10-11 for the next MOBY 
> meeting?
>
   3-4 April much better, because April 9-12 are Easter Holidays
   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 kanani at cshl.org  Fri Feb 13 11:37:12 2004
From: kanani at cshl.org (Ardavan Kanani)
Date: Fri, 13 Feb 2004 11:37:12 -0500
Subject: [MOBY-l] object deregister and find service
Message-ID: <DFD21772-5E42-11D8-ACB3-000A9591E2C8@cshl.org>

Hello all,

Lincoln wanted me to find out what would happen if an object that 
already has children was to be de-registered.  I tried this and a 
parent object, including its children, were de-registered without any 
complains from MOBY.  Is this normal or this is a bug?

I have more questions that I will bring up after more testing to make 
sure I am not doing anything wrong.


Ardavan



From markw at illuminae.com  Fri Feb 13 11:50:27 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 13 Feb 2004 10:50:27 -0600
Subject: [MOBY] [MOBY-l] object deregister and find service
In-Reply-To: <DFD21772-5E42-11D8-ACB3-000A9591E2C8@cshl.org>
References: <DFD21772-5E42-11D8-ACB3-000A9591E2C8@cshl.org>
Message-ID: <1076691026.2026.10.camel@localilluminae.com>

I can't duplicate this behaviour when I do it (in fact, it is part of my
own test-suite, so I run that test often!).   If it is really happening,
then it is definitely BAD BAD BAD!

There are, in fact, two levels of checking - the first is within MOBY
Central where it checks the service registry to see if any services are
registered that use the object.  If so, then deregistration fails.  It
then hands the request off to the OntologyServer which checks the
ontology for child nodes, and fails if they exist...

Please send me the code you are using that reveals this bug.  I wont get
to it until late next week as I am flying out to Madrid to present MOBY
to the PlaNet meeting tomorrow, but if you can show me how do duplicate
the error I will fix it ASAP, as it really is a serious bug!

Thanks!

Mark


On Fri, 2004-02-13 at 10:37, Ardavan Kanani wrote:
> Hello all,
> 
> Lincoln wanted me to find out what would happen if an object that 
> already has children was to be de-registered.  I tried this and a 
> parent object, including its children, were de-registered without any 
> complains from MOBY.  Is this normal or this is a bug?
> 
> I have more questions that I will bring up after more testing to make 
> sure I am not doing anything wrong.
> 
> 
> Ardavan
> 
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
-- 
Mark Wilkinson <markw at illuminae.com>
Illuminae


From markw at illuminae.com  Fri Feb 13 11:52:19 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 13 Feb 2004 10:52:19 -0600
Subject: [MOBY] Re: [MOBY-l] Proposed dates for MOBY meeting
In-Reply-To: <Pine.LNX.4.44.0402131620270.28463-100000@bagheera.ebi.ac.uk>
References: <Pine.LNX.4.44.0402131620270.28463-100000@bagheera.ebi.ac.uk>
Message-ID: <1076691139.2024.13.camel@localilluminae.com>

Hi Lincoln!

Thanks for the invitation!

I could probably swing it for April as well.  The earlier dates are much
better for me also.

Mark


On Fri, 2004-02-13 at 10:21, Martin Senger wrote:
> > How about the weekends of April 3-4 or April 10-11 for the next MOBY 
> > meeting?
> >
>    3-4 April much better, because April 9-12 are Easter Holidays
>    Martin
-- 
Mark Wilkinson <markw at illuminae.com>
Illuminae


From sjmm at us.ibm.com  Fri Feb 13 13:45:03 2004
From: sjmm at us.ibm.com (Sean Martin)
Date: Fri, 13 Feb 2004 13:45:03 -0500
Subject: [MOBY-l] Re: bioMoby - name space (fwd)
In-Reply-To: <Pine.LNX.4.44.0402131046180.28463-100000@bagheera.ebi.ac.uk>
Message-ID: <OF21ACD00A.2AE94C25-ON85256E39.0061EEAE-85256E39.0067008F@us.ibm.com>

Now that I have the context after speaking to Martin, I only have a couple 
of things to add. Firstly, Marks comments to Martin and Boris, as pasted 
below are exactly right.

--------------start Mark's comments -------------------------

My comments after sleeping on the problem overnight are as follows:

The important point that I think is being misunderstood here is that we
are talking about LSID's that *represent namespaces*, NOT LSID's that
represent data within that namespace!!  As such, biomoby.org is
*absolutely* the correct authority for namespace LSID's, since
biomoby.org controls the namespace ontology (as of last week!).

I discuss this point in various places, but in particular it is
discussed in my latest paper (get it from the biomoby.org website).  In
there I have a paragraph clarifying the problem that MOBY has with using
LSID's "verbatim" (the crux being that LSID's are opaque and DO NOT
represent underlying data-types without resolution - where the knowledge
of the underlying data-type is critical to service discovery).  I think
we are confusing the issue by conflating an identifier WITHIN a
namespace - for which Boris' argument is absolutely correct and I don't
think anyone could argue with him - with an identifier that REPRESENTS a
namespace, for which MOBY is the only authority that exists.

urn:lsid:biomoby.org:namespacetype:DragonDB_Allele

vs.

urn:lsid:antirrhinum.org:allele_id:AG113328

I believe that this is the misunderstanding that is leading to this
argument, and that once this is clear, the argument goes away.  If not,
then please read my paragraph about it in the manuscript as I deal with
it more comprehensively there.

If you all could give me the OK I will forward this message back to the
public list and we can finish the conversation there.

Thanks!

Mark

--
Mark Wilkinson <markw at illuminae.com>
---------------------------------- end of Mark's comments 
----------------------------------

Secondly, I can shed light the (I believe unrelated) LSID authority naming 
"convention" that Martin was trying to get out of me in his first note. In 
the case where one party needs LSID's for a particular data source that 
they do not own, but which is available through some non-LSID based means 
- perhaps via the web in real-time or perhaps as a download of the latest 
database from that data source, they may if they choose, assign LSID's 
under their own authority for that 3rd party data. The authority string 
naming convention we chose to do this at an I3C hackathon was really 
simple. All one needs to do is take the authority name that one thinks 
would be a logical authority name for the data source you are interested 
in, and concatenated it with your own authority name (in this case it was 
lsid.i3c.org). Here follow some (working and resolvable) example LSID's 
assigned by the I3C during that hackathon:

urn:lsid:ensembl.org.lsid.i3c.org:homosapiens_ref:234325  -  uses the 
ensemble library to contact ensemble.orgt
urn:lsid:ncbi.nlm.gov.lsid.i3c.org:pubmed:11385576 - proxies the request 
to the NCBI machines using the XML interface
urn:lsid:ncbi.nlm.nih.gov.lsid.i3c.org:genbank:bm872070 - proxies the 
request to the NCBI machines using the XML interface

We made entries in the I3C DNS for  ncbi.nlm.gov.lsid.i3c.org, 
ebi.ack.uk.lsid.i3c.org, ncbi.nlm.nih.gov.lsid.i3c.org and attached the 
appropriate SRV records to them, as described  in section 8.3 in the OMG's 
LSID proposed specification document ( 
http://www.omg.org/docs/lifesci/03-12-02.pdf ). The resolution process 
followed is to resolve these in exactly the same was as for any other 
LSID. There is no magic attempt to break up the authority string into two 
authorities. Consumers of these LSID's can simply look at them to see 
where the data is actually coming from - in this case clearly the I3C is 
the authority and is in the end responsible for the delivery of the 
associated data using whatever means it like (proxy to the original 
source, local copy of the original source etc). It is likely folks will 
see more of these "third party" LSID's in the next months as they provide 
LSID access & intergration features to information ahead of the 'OEM' data 
provider being ready to supply their own "native" LSID's under their own 
authority string.

I hope this is clearer, but if there are further questions, please post or 
email me.

Thanks, Sean

--
Sean Martin
IBM Corp.





Martin Senger <senger at ebi.ac.uk> 
Sent by: moby-l-bounces at portal.open-bio.org
02/13/2004 05:47 AM

To
moby-l at biomoby.org
cc

Subject
[MOBY-l] Re: bioMoby - name space (fwd)






These are some opinions on the name space problem we had discussed in this
list from the main LSID promoter/author, Sean Martin from IBM. I am
expecting other email from him regarding "faking" the authority field - I
will post it when I have it...

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

---------- Forwarded message ----------
Date: Thu, 12 Feb 2004 09:27:17 -0500
From: Sean Martin <sjmm at us.ibm.com>
To: Martin Senger <senger at ebi.ac.uk>
Cc: Boris Steipe <boris.steipe at utoronto.ca>, markw_mobile2 at illuminae.com,
Benjamin H Szekely <bhszekel at us.ibm.com>, Alyssa Wolf 
<alyssaw at us.ibm.com>,
Jordi A Albornoz <jordi at us.ibm.com>
Subject: Re: bioMoby - name space

Hi Martin,
The way we have being thinking about it here is as follows (this is not to
say it could not be extended as things move forward of course):

Take a lsid  ->  urn:lsid:pdb.org:1aft-qwertyfoo:1

In this case, when I resolve it, I get pointers to the data named by the
LSID as well as any meta-data that may be associated with it from the PDB.
The rule we have followed is that the only authoritative place to get data
(actual bytes named) for that LSID would be the owning authority - in this
case the PDB. However *any* resolver (including the PDB) may have also
have pointers to meta-data related to that LSID.  Each organization that
has meta-data is authoritative for the meta-data that it supplies. It is
up to the client that retrieves meta-data to decide what weight (i.e. just
how good is this meta-data?) to give a piece of meta-data depending on
which authorities (the source of that bit of meta-data) provided it to
them.  Naturally the weight for meta-data from the authority that actually
is authoritative for the data would be high - although perhaps not as high
as my own local database which gives me the information that in my own
testing I (for instance) found an error in the official/original
authorities data/meta-data. The client is free to ask any number of
authorities (there is no mechanism yet for the discover of these third
party resolvers - you just have to know them) if they have meta-data for
any particular LSID. Meta-data from third part authorities is usually not
the same meta-data that the "original naming" authority (in this case the
PDB) lists for that LSID. So biomoby.org is quite at liberty to hold its
own meta-data records for pdb.org or any other authority issued ID's.
Biomoby clients would be programmed to know to query both the actual
authority listed in the LSID and the biomoby resolver any time LSID
resolution is performed.

This mechanism allows third parties to attach meta-data/or otherwise
assert facts about data stored in another authority e.g annotation.  In
fact in our LSID resolver proxy implementations, I believe you can supply
a list of 3rd party resolvers that you want queried any time an LSID is
resolved. This allows things like checking a bunch of internal databases,
or the databases of "friends & colleagues" or other source important to
your research, for data related to any LSID you happen to be resolving.

I hope this is reasonably clear. Please ask questions if not.

Kindest regards, Sean
:








Martin Senger <senger at ebi.ac.uk>
02/12/2004 04:18 AM

To
Sean Martin/Cambridge/IBM at IBMUS
cc
Boris Steipe <boris.steipe at utoronto.ca>, <markw_mobile2 at illuminae.com>
Subject
bioMoby - name space






Sean,
Yesterday there was a discussion on the BioMoby list about authority
field of the LSID - just in case you are not on that list, here is a very
brief summary - because I have asked there for your expertise:

1) Boris asked:

"What happened to the idea of namespacing like in LSIDs i.e. making a
namespace valid only in the context of its issuing authority and thus
effectively using the (working, sort of) ICANN resolution mechanism to
ensure that namespaces remain unique ?"

2) Mark replied:

"yes, that was the plan... and in effect it still *is* the plan. However,
I cannot assign LSID's arbitrarily to another authority (this is something
they must do on their own), so for the moment all namespace identifiers
are in the "biomoby.org" LSID authority, and thus we have to be careful of
collisions.
Once LSID's become more widespread we will certainly stop using our own
LSID authority prefix and use the "genuine" one, as assigned by the true
naming authority, but until then... we're stuck."

3) I have said:

"Just my 2c:
The authority field is not important only as a way how to identify
things world-wide uniquely (if it was only for that, all your arguments
are completely valid) - but it *may* (the LSID spec does not mandate that
but suggests it) be used also for finding an appropriate resolution
service that can return data identified by this LSID. Therefore, if you
put there pubmed.org, it may never find biomoby.org where it can be
resolve.
I think the solution may be (Sean, are you listening here? Am I right?)
to have *both* in the authority - biomoby.org *and* pubmed.org - so the
resolution software will find first biomoby.org and it knows that the rest
of the authority can be ignored.
"

4) Finally Mark concluded:

"Cool - that's a trick I hadn't known about.  What is the separator
character between the two authority identifiers?"

Now, Sean, your opinion? Many 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






_______________________________________________
moby-l mailing list
moby-l at biomoby.org
http://biomoby.org/mailman/listinfo/moby-l

From steube at sdsc.edu  Sat Feb 14 16:35:31 2004
From: steube at sdsc.edu (steube@sdsc.edu)
Date: Sat, 14 Feb 2004 13:35:31 -0800 (PST)
Subject: [MOBY-l] Proposed dates for MOBY meeting
In-Reply-To: <200402131733.08070.lstein@cshl.edu>
References: <200402131733.08070.lstein@cshl.edu>
Message-ID: <1509.200.71.12.137.1076794531.squirrel@uhura.sdsc.edu>

Hi all from Montevideo, Uruguay. I gave a MOBY presentation earlier
this week and next  another next week.

Apr 3, 4  sounds good to me and Gribskov can probably attend, too.

Ken


> Hi,
>
> How about the weekends of April 3-4 or April 10-11 for the next MOBY
> meeting?  I would be happy to host it at CSHL.  Before that I'm
> pretty busy with various meetings, and after that Gary is traveling.
>
> Lincoln
>
> --
> Lincoln D. Stein
> Cold Spring Harbor Laboratory
> 1 Bungtown Road
> Cold Spring Harbor, NY 11724
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
>



From mwilkinson at mobile.rogers.com  Sat Feb 14 16:42:16 2004
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Sat, 14 Feb 2004 16:42:16 -0500
Subject: [MOBY-l] Proposed dates for MOBY meeting
Message-ID: <200402142152.i1ELq66I022821@portal.open-bio.org>

Hello from Montreal Dorval airport!  

I'm giving a Moby presentation in Madrid, Spain, tomorrow... Uruguay, Spain... We will soon take over the world! >-)

Ken, you ROCK dude!  Thanks for all your leg-work!

Cheers from the airport lounge - I'm priming myself for a week of Rebecca's bad influence ;-)

M



!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!


From lstein at cshl.edu  Mon Feb 16 04:03:07 2004
From: lstein at cshl.edu (Lincoln Stein)
Date: Mon, 16 Feb 2004 11:03:07 +0200
Subject: [MOBY-l] Re: bioMoby - name space (fwd)
In-Reply-To: <OF21ACD00A.2AE94C25-ON85256E39.0061EEAE-85256E39.0067008F@us.ibm.com>
References: <OF21ACD00A.2AE94C25-ON85256E39.0061EEAE-85256E39.0067008F@us.ibm.com>
Message-ID: <200402161103.07740.lstein@cshl.edu>

Thank you.  The issue is much clearer now.

Lincoln

On Friday 13 February 2004 08:45 pm, Sean Martin wrote:
> Now that I have the context after speaking to Martin, I only have a
> couple of things to add. Firstly, Marks comments to Martin and
> Boris, as pasted below are exactly right.
>
> --------------start Mark's comments -------------------------
>
> My comments after sleeping on the problem overnight are as follows:
>
> The important point that I think is being misunderstood here is
> that we are talking about LSID's that *represent namespaces*, NOT
> LSID's that represent data within that namespace!!  As such,
> biomoby.org is *absolutely* the correct authority for namespace
> LSID's, since biomoby.org controls the namespace ontology (as of
> last week!).
>
> I discuss this point in various places, but in particular it is
> discussed in my latest paper (get it from the biomoby.org website).
>  In there I have a paragraph clarifying the problem that MOBY has
> with using LSID's "verbatim" (the crux being that LSID's are opaque
> and DO NOT represent underlying data-types without resolution -
> where the knowledge of the underlying data-type is critical to
> service discovery).  I think we are confusing the issue by
> conflating an identifier WITHIN a namespace - for which Boris'
> argument is absolutely correct and I don't think anyone could argue
> with him - with an identifier that REPRESENTS a namespace, for
> which MOBY is the only authority that exists.
>
> urn:lsid:biomoby.org:namespacetype:DragonDB_Allele
>
> vs.
>
> urn:lsid:antirrhinum.org:allele_id:AG113328
>
> I believe that this is the misunderstanding that is leading to this
> argument, and that once this is clear, the argument goes away.  If
> not, then please read my paragraph about it in the manuscript as I
> deal with it more comprehensively there.
>
> If you all could give me the OK I will forward this message back to
> the public list and we can finish the conversation there.
>
> Thanks!
>
> Mark
>
> --
> Mark Wilkinson <markw at illuminae.com>
> ---------------------------------- end of Mark's comments
> ----------------------------------
>
> Secondly, I can shed light the (I believe unrelated) LSID authority
> naming "convention" that Martin was trying to get out of me in his
> first note. In the case where one party needs LSID's for a
> particular data source that they do not own, but which is available
> through some non-LSID based means - perhaps via the web in
> real-time or perhaps as a download of the latest database from that
> data source, they may if they choose, assign LSID's under their own
> authority for that 3rd party data. The authority string naming
> convention we chose to do this at an I3C hackathon was really
> simple. All one needs to do is take the authority name that one
> thinks would be a logical authority name for the data source you
> are interested in, and concatenated it with your own authority name
> (in this case it was lsid.i3c.org). Here follow some (working and
> resolvable) example LSID's assigned by the I3C during that
> hackathon:
>
> urn:lsid:ensembl.org.lsid.i3c.org:homosapiens_ref:234325  -  uses
> the ensemble library to contact ensemble.orgt
> urn:lsid:ncbi.nlm.gov.lsid.i3c.org:pubmed:11385576 - proxies the
> request to the NCBI machines using the XML interface
> urn:lsid:ncbi.nlm.nih.gov.lsid.i3c.org:genbank:bm872070 - proxies
> the request to the NCBI machines using the XML interface
>
> We made entries in the I3C DNS for  ncbi.nlm.gov.lsid.i3c.org,
> ebi.ack.uk.lsid.i3c.org, ncbi.nlm.nih.gov.lsid.i3c.org and attached
> the appropriate SRV records to them, as described  in section 8.3
> in the OMG's LSID proposed specification document (
> http://www.omg.org/docs/lifesci/03-12-02.pdf ). The resolution
> process followed is to resolve these in exactly the same was as for
> any other LSID. There is no magic attempt to break up the authority
> string into two authorities. Consumers of these LSID's can simply
> look at them to see where the data is actually coming from - in
> this case clearly the I3C is the authority and is in the end
> responsible for the delivery of the associated data using whatever
> means it like (proxy to the original source, local copy of the
> original source etc). It is likely folks will see more of these
> "third party" LSID's in the next months as they provide LSID access
> & intergration features to information ahead of the 'OEM' data
> provider being ready to supply their own "native" LSID's under
> their own authority string.
>
> I hope this is clearer, but if there are further questions, please
> post or email me.
>
> Thanks, Sean
>
> --
> Sean Martin
> IBM Corp.
>
>
>
>
>
> Martin Senger <senger at ebi.ac.uk>
> Sent by: moby-l-bounces at portal.open-bio.org
> 02/13/2004 05:47 AM
>
> To
> moby-l at biomoby.org
> cc
>
> Subject
> [MOBY-l] Re: bioMoby - name space (fwd)
>
>
>
>
>
>
> These are some opinions on the name space problem we had discussed
> in this list from the main LSID promoter/author, Sean Martin from
> IBM. I am expecting other email from him regarding "faking" the
> authority field - I will post it when I have it...
>
> 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
>
> ---------- Forwarded message ----------
> Date: Thu, 12 Feb 2004 09:27:17 -0500
> From: Sean Martin <sjmm at us.ibm.com>
> To: Martin Senger <senger at ebi.ac.uk>
> Cc: Boris Steipe <boris.steipe at utoronto.ca>,
> markw_mobile2 at illuminae.com, Benjamin H Szekely
> <bhszekel at us.ibm.com>, Alyssa Wolf
> <alyssaw at us.ibm.com>,
> Jordi A Albornoz <jordi at us.ibm.com>
> Subject: Re: bioMoby - name space
>
> Hi Martin,
> The way we have being thinking about it here is as follows (this is
> not to say it could not be extended as things move forward of
> course):
>
> Take a lsid  ->  urn:lsid:pdb.org:1aft-qwertyfoo:1
>
> In this case, when I resolve it, I get pointers to the data named
> by the LSID as well as any meta-data that may be associated with it
> from the PDB. The rule we have followed is that the only
> authoritative place to get data (actual bytes named) for that LSID
> would be the owning authority - in this case the PDB. However *any*
> resolver (including the PDB) may have also have pointers to
> meta-data related to that LSID.  Each organization that has
> meta-data is authoritative for the meta-data that it supplies. It
> is up to the client that retrieves meta-data to decide what weight
> (i.e. just how good is this meta-data?) to give a piece of
> meta-data depending on which authorities (the source of that bit of
> meta-data) provided it to them.  Naturally the weight for meta-data
> from the authority that actually is authoritative for the data
> would be high - although perhaps not as high as my own local
> database which gives me the information that in my own testing I
> (for instance) found an error in the official/original authorities
> data/meta-data. The client is free to ask any number of authorities
> (there is no mechanism yet for the discover of these third party
> resolvers - you just have to know them) if they have meta-data for
> any particular LSID. Meta-data from third part authorities is
> usually not the same meta-data that the "original naming" authority
> (in this case the PDB) lists for that LSID. So biomoby.org is quite
> at liberty to hold its own meta-data records for pdb.org or any
> other authority issued ID's. Biomoby clients would be programmed to
> know to query both the actual authority listed in the LSID and the
> biomoby resolver any time LSID resolution is performed.
>
> This mechanism allows third parties to attach meta-data/or
> otherwise assert facts about data stored in another authority e.g
> annotation.  In fact in our LSID resolver proxy implementations, I
> believe you can supply a list of 3rd party resolvers that you want
> queried any time an LSID is resolved. This allows things like
> checking a bunch of internal databases, or the databases of
> "friends & colleagues" or other source important to your research,
> for data related to any LSID you happen to be resolving.
>
> I hope this is reasonably clear. Please ask questions if not.
>
> Kindest regards, Sean
>
>
>
>
>
>
>
>
>
> Martin Senger <senger at ebi.ac.uk>
> 02/12/2004 04:18 AM
>
> To
> Sean Martin/Cambridge/IBM at IBMUS
> cc
> Boris Steipe <boris.steipe at utoronto.ca>,
> <markw_mobile2 at illuminae.com> Subject
> bioMoby - name space
>
>
>
>
>
>
> Sean,
> Yesterday there was a discussion on the BioMoby list about
> authority field of the LSID - just in case you are not on that
> list, here is a very brief summary - because I have asked there for
> your expertise:
>
> 1) Boris asked:
>
> "What happened to the idea of namespacing like in LSIDs i.e. making
> a namespace valid only in the context of its issuing authority and
> thus effectively using the (working, sort of) ICANN resolution
> mechanism to ensure that namespaces remain unique ?"
>
> 2) Mark replied:
>
> "yes, that was the plan... and in effect it still *is* the plan.
> However, I cannot assign LSID's arbitrarily to another authority
> (this is something they must do on their own), so for the moment
> all namespace identifiers are in the "biomoby.org" LSID authority,
> and thus we have to be careful of collisions.
> Once LSID's become more widespread we will certainly stop using our
> own LSID authority prefix and use the "genuine" one, as assigned by
> the true naming authority, but until then... we're stuck."
>
> 3) I have said:
>
> "Just my 2c:
> The authority field is not important only as a way how to identify
> things world-wide uniquely (if it was only for that, all your
> arguments are completely valid) - but it *may* (the LSID spec does
> not mandate that but suggests it) be used also for finding an
> appropriate resolution service that can return data identified by
> this LSID. Therefore, if you put there pubmed.org, it may never
> find biomoby.org where it can be resolve.
> I think the solution may be (Sean, are you listening here? Am I
> right?) to have *both* in the authority - biomoby.org *and*
> pubmed.org - so the resolution software will find first biomoby.org
> and it knows that the rest of the authority can be ignored.
> "
>
> 4) Finally Mark concluded:
>
> "Cool - that's a trick I hadn't known about.  What is the separator
> character between the two authority identifiers?"
>
> Now, Sean, your opinion? Many 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
>
>
>
>
>
>
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l

-- 
Lincoln D. Stein
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724


From dwaddell at nutecsciences.com  Tue Feb 17 10:05:16 2004
From: dwaddell at nutecsciences.com (Dave Waddell)
Date: Tue, 17 Feb 2004 09:05:16 -0600
Subject: [MOBY-l] Java call to MOBY fails
Message-ID: <003201c3f567$7390ec60$5a0b000a@nutecsciences.com>

I'm trying to make a call to MOBY to retrieve a Genbank Flat File record
using:

	    String NCBI_Acc = "AA936757";
	    String XMLInput = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"
+
	    					"<moby:MOBY
xmlns:moby=\"http://www.biomoby.org/moby\">\n" +
	    					"<moby:Query>\n" +
        					"<moby:queryInput>\n" +
             				"<Simple articleName=''>\n" +
	    					"<Object
namespace=\"urn:lsid:biomoby.org:namespacetype:NCBI_Acc\" id=\"" + NCBI_Acc
+ "\"/>\n" +
             				"</Simple>\n" +
        					"</moby:queryInput>\n" +
	    					"</moby:Query>\n" +
	    					"</moby:MOBY>\n"; 
	    CentralImpl newCall = new
CentralImpl("http://mobycentral.cbr.nrc.ca/cgi-bin/Services/Services.cgi",
"http://biomoby.org/");
	    result = newCall.call("MOBYSHoundGetGenBankff", XMLInput);

but all I get back in "result" is:
<?xml version='1.0' encoding='UTF-8'?>
      <moby:MOBY xmlns:moby='http://www.biomoby.org/moby'
xmlns='http://www.biomoby.org/moby'>
        <moby:Response moby:authority='illuminae.com'>
        
        <moby:queryResponse moby:queryID=''/>
	
        </moby:Response>
      </moby:MOBY>

I have also tried feeding the namespace from:
String[] inputs = new String[]{"NCBI_gi", "NCBI_Acc"};
	    MobyService[] serviceInstance = worker.findService(inputs);
	    for (int j=0; i<serviceInstance.length; i++)
	    {	
	    	System.out.println("NCBI Service # " + i + "= " +
serviceInstance[i].toString());
	    }
	    "<Object namespace=\"" + inputs[0] + "\" id=\"" + NCBI_Acc +
"\"/>\n"

also:
	    					"<Object
namespace=\"urn:lsid:biomoby.org:namespacetype:NCBI_Acc:" + NCBI_Acc +
"\"/>\n" 

Which all give the same result. Any suggestions are appreciated.
Thanks, Dave.




From dwaddell at nutecsciences.com  Tue Feb 17 10:18:19 2004
From: dwaddell at nutecsciences.com (Dave Waddell)
Date: Tue, 17 Feb 2004 09:18:19 -0600
Subject: [MOBY-l] RE: Java call to MOBY fails
Message-ID: <003301c3f569$462fba10$5a0b000a@nutecsciences.com>

I noticed if I replace it with NCBI_gi and id=3094791 everything works fine.
Dave.

-----Original Message-----
From: Dave Waddell [mailto:dwaddell at nutecsciences.com] 
Sent: Tuesday, February 17, 2004 9:05 AM
To: ' (moby-l at biomoby.org)'
Subject: Java call to MOBY fails

I'm trying to make a call to MOBY to retrieve a Genbank Flat File record
using:

	    String NCBI_Acc = "AA936757";
	    String XMLInput = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"
+
	    					"<moby:MOBY
xmlns:moby=\"http://www.biomoby.org/moby\">\n" +
	    					"<moby:Query>\n" +
        					"<moby:queryInput>\n" +
             				"<Simple articleName=''>\n" +
	    					"<Object
namespace=\"urn:lsid:biomoby.org:namespacetype:NCBI_Acc\" id=\"" + NCBI_Acc
+ "\"/>\n" +
             				"</Simple>\n" +
        					"</moby:queryInput>\n" +
	    					"</moby:Query>\n" +
	    					"</moby:MOBY>\n"; 
	    CentralImpl newCall = new
CentralImpl("http://mobycentral.cbr.nrc.ca/cgi-bin/Services/Services.cgi",
"http://biomoby.org/");
	    result = newCall.call("MOBYSHoundGetGenBankff", XMLInput);

but all I get back in "result" is:
<?xml version='1.0' encoding='UTF-8'?>
      <moby:MOBY xmlns:moby='http://www.biomoby.org/moby'
xmlns='http://www.biomoby.org/moby'>
        <moby:Response moby:authority='illuminae.com'>
        
        <moby:queryResponse moby:queryID=''/>
	
        </moby:Response>
      </moby:MOBY>

I have also tried feeding the namespace from:
String[] inputs = new String[]{"NCBI_gi", "NCBI_Acc"};
	    MobyService[] serviceInstance = worker.findService(inputs);
	    for (int j=0; i<serviceInstance.length; i++)
	    {	
	    	System.out.println("NCBI Service # " + i + "= " +
serviceInstance[i].toString());
	    }
	    "<Object namespace=\"" + inputs[0] + "\" id=\"" + NCBI_Acc +
"\"/>\n"

also:
	    					"<Object
namespace=\"urn:lsid:biomoby.org:namespacetype:NCBI_Acc:" + NCBI_Acc +
"\"/>\n" 

Which all give the same result. Any suggestions are appreciated.
Thanks, Dave.




From MRBATESALAN at netscape.net  Tue Feb 17 19:24:19 2004
From: MRBATESALAN at netscape.net (MRBATESALAN@netscape.net)
Date: 17 Feb 2004 19:24:19 -0500
Subject: [MOBY-l] REPLY SOON
Message-ID: <WIN10563Ts2FZQTGQUE00004859@win10563>

Dear Friend,

As you read this, I don't want you to feel sorry for 
me, because, I believe everyone will die someday. 
My name is BATES ALAN a merchant in Dubai, in the 
U.A.E.I have been diagnosed with Esophageal cancer.
It has defiled all forms of medical treatment, and right now 
I have only about a few months to live, according to medical experts. 
I have not particularly lived my life so well, as I 
never really cared for anyone(not even myself)but my 
business. Though I am very rich, I was never 
generous, I was always hostile to people and only 
focused on my business as that was the only thing I 
cared for. But now I regret all this as I now know 
that there is more to life than just wanting to have 
or make all the money in the world. 
I believe when God gives me a second chance to come 
to this world I would live my life a different way 
from how I have lived it. Now that God has called 
me, I have willed and given most of my property 
and assets to my immediate and extended family 
members as well as a few close friends. 
I want God to be merciful to me and accept my soul 
so, I have decided to give alms to charity 
organizations, as I want this to be one of the last 
good deeds I do on earth. So far, I have distributed 
money to some charity organizations in the U.A.E, 
Algeria and Malaysia. Now that my health has 
deteriorated so badly, I cannot do this myself 
anymore. I once asked members of my family to close one 
of my accounts and distribute the money which I have 
there to charity organization in Bulgaria and 
Pakistan, they refused and kept the money to 
themselves. Hence, I do not trust them anymore, as 
they seem not to be contended with what I have left 
for them. 
The last of my money which no one knows of is the 
huge cash deposit of eighteen million dollars 
$18,000,000,00 that I have with a finance/Security Company 
abroad. I will want you to help me collect this deposit 
and dispatched it to charity organizations.
I have set aside 10% for you and for your time.
God be with you. 
BATES ALAN



From MRBATESALANN at netscape.net  Thu Feb 19 20:21:33 2004
From: MRBATESALANN at netscape.net (MRBATESALANN@netscape.net)
Date: 19 Feb 2004 20:21:33 -0500
Subject: [MOBY-l] REPLY SOON
Message-ID: <SHA_MAILcXwWfj7jYTd00003f20@sha_mail.sanfordha.com>

Dear Friend,

As you read this, I don't want you to feel sorry for 
me, because, I believe everyone will die someday. 
My name is BATES ALAN a merchant in Dubai, in the 
U.A.E.I have been diagnosed with Esophageal cancer.
It has defiled all forms of medical treatment, and right now 
I have only about a few months to live, according to medical experts. 
I have not particularly lived my life so well, as I 
never really cared for anyone(not even myself)but my 
business. Though I am very rich, I was never 
generous, I was always hostile to people and only 
focused on my business as that was the only thing I 
cared for. But now I regret all this as I now know 
that there is more to life than just wanting to have 
or make all the money in the world. 
I believe when God gives me a second chance to come 
to this world I would live my life a different way 
from how I have lived it. Now that God has called 
me, I have willed and given most of my property 
and assets to my immediate and extended family 
members as well as a few close friends. 
I want God to be merciful to me and accept my soul 
so, I have decided to give alms to charity 
organizations, as I want this to be one of the last 
good deeds I do on earth. So far, I have distributed 
money to some charity organizations in the U.A.E, 
Algeria and Malaysia. Now that my health has 
deteriorated so badly, I cannot do this myself 
anymore. I once asked members of my family to close one 
of my accounts and distribute the money which I have 
there to charity organization in Bulgaria and 
Pakistan, they refused and kept the money to 
themselves. Hence, I do not trust them anymore, as 
they seem not to be contended with what I have left 
for them. 
The last of my money which no one knows of is the 
huge cash deposit of eighteen million dollars 
$18,000,000,00 that I have with a finance/Security Company 
abroad. I will want you to help me collect this deposit 
and dispatched it to charity organizations.
I have set aside 10% for you and for your time.
God be with you. 
BATES ALAN



From MRBATESALANN at netscape.net  Thu Feb 19 21:46:10 2004
From: MRBATESALANN at netscape.net (MRBATESALANN@netscape.net)
Date: 19 Feb 2004 21:46:10 -0500
Subject: [MOBY-l] REPLY SOON
Message-ID: <SHA_MAIL4RCIlWrdFOS00007134@sha_mail.sanfordha.com>

Dear Friend,

As you read this, I don't want you to feel sorry for 
me, because, I believe everyone will die someday. 
My name is BATES ALAN a merchant in Dubai, in the 
U.A.E.I have been diagnosed with Esophageal cancer.
It has defiled all forms of medical treatment, and right now 
I have only about a few months to live, according to medical experts. 
I have not particularly lived my life so well, as I 
never really cared for anyone(not even myself)but my 
business. Though I am very rich, I was never 
generous, I was always hostile to people and only 
focused on my business as that was the only thing I 
cared for. But now I regret all this as I now know 
that there is more to life than just wanting to have 
or make all the money in the world. 
I believe when God gives me a second chance to come 
to this world I would live my life a different way 
from how I have lived it. Now that God has called 
me, I have willed and given most of my property 
and assets to my immediate and extended family 
members as well as a few close friends. 
I want God to be merciful to me and accept my soul 
so, I have decided to give alms to charity 
organizations, as I want this to be one of the last 
good deeds I do on earth. So far, I have distributed 
money to some charity organizations in the U.A.E, 
Algeria and Malaysia. Now that my health has 
deteriorated so badly, I cannot do this myself 
anymore. I once asked members of my family to close one 
of my accounts and distribute the money which I have 
there to charity organization in Bulgaria and 
Pakistan, they refused and kept the money to 
themselves. Hence, I do not trust them anymore, as 
they seem not to be contended with what I have left 
for them. 
The last of my money which no one knows of is the 
huge cash deposit of eighteen million dollars 
$18,000,000,00 that I have with a finance/Security Company 
abroad. I will want you to help me collect this deposit 
and dispatched it to charity organizations.
I have set aside 10% for you and for your time.
God be with you. 
BATES ALAN



From MRBATESALANN at netscape.net  Sat Feb 21 07:45:06 2004
From: MRBATESALANN at netscape.net (MRBATESALANN@netscape.net)
Date: 21 Feb 2004 04:45:06 -0800
Subject: [MOBY-l] REPLY SOON
Message-ID: <NT4-RH1pxtjeuZO5cgv00035c74@nt4-rh.rh.local>

Dear Friend,

As you read this, I don't want you to feel sorry for 
me, because, I believe everyone will die someday. 
My name is BATES ALAN a merchant in Dubai, in the 
U.A.E.I have been diagnosed with Esophageal cancer.
It has defiled all forms of medical treatment, and right now 
I have only about a few months to live, according to medical experts. 
I have not particularly lived my life so well, as I 
never really cared for anyone(not even myself)but my 
business. Though I am very rich, I was never 
generous, I was always hostile to people and only 
focused on my business as that was the only thing I 
cared for. But now I regret all this as I now know 
that there is more to life than just wanting to have 
or make all the money in the world. 
I believe when God gives me a second chance to come 
to this world I would live my life a different way 
from how I have lived it. Now that God has called 
me, I have willed and given most of my property 
and assets to my immediate and extended family 
members as well as a few close friends. 
I want God to be merciful to me and accept my soul 
so, I have decided to give alms to charity 
organizations, as I want this to be one of the last 
good deeds I do on earth. So far, I have distributed 
money to some charity organizations in the U.A.E, 
Algeria and Malaysia. Now that my health has 
deteriorated so badly, I cannot do this myself 
anymore. I once asked members of my family to close one 
of my accounts and distribute the money which I have 
there to charity organization in Bulgaria and 
Pakistan, they refused and kept the money to 
themselves. Hence, I do not trust them anymore, as 
they seem not to be contended with what I have left 
for them. 
The last of my money which no one knows of is the 
huge cash deposit of eighteen million dollars 
$18,000,000,00 that I have with a finance/Security Company 
abroad. I will want you to help me collect this deposit 
and dispatched it to charity organizations.
I have set aside 10% for you and for your time.
God be with you. 
BATES ALAN



From r.bruskiewich at cgiar.org  Sun Feb 22 06:58:34 2004
From: r.bruskiewich at cgiar.org (Richard Bruskiewich)
Date: Sun, 22 Feb 2004 19:58:34 +0800
Subject: [MOBY-l] Proposed dates for MOBY meeting
In-Reply-To: <200402131733.08070.lstein@cshl.edu>
Message-ID: <BC5EBA6A.589%r.bruskiewich@cgiar.org>

Hi Lincoln,

We've just had our planning meeting for the first year informatics work plan
for big genetic resources mega-project I've been telling you folks about for
some time now. To keep a long story short, I've been given the leadership of
both the functional genomics platform component and the network (read: MOBY
integration + plant ontology, etc.) component.  Graham McLaren has the
germplasm database coordination.

Given this situation, I'm going to try to identify how we can get somebody
to CSHL for your next MOBY meeting, since network level web services
technologies are a key tool in our project arsenal for information system
integration globally.

Cheers
Richard

On 2/13/04 11:33 PM, "Lincoln Stein" <lstein at cshl.edu> wrote:

> Hi,
> 
> How about the weekends of April 3-4 or April 10-11 for the next MOBY
> meeting?  I would be happy to host it at CSHL.  Before that I'm
> pretty busy with various meetings, and after that Gary is traveling.
> 
> Lincoln

-- 




From markw at illuminae.com  Wed Feb 25 20:16:33 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 25 Feb 2004 17:16:33 -0800
Subject: [MOBY-l] Acknowledging MOBY-S in your code and on your pages
Message-ID: <1077758193.1916.43.camel@localilluminae.com>

Hi all, 

In an effort to get a more accurate measure of "impact" for the granting
agencies, I have made a "powered by" icon.  I would greatly appreciate
it if anyone who is building web pages that include content derived by
calls to MOBY Central or MOBY Services could link to this icon so that I
can measure hits/distribution.

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

Thanks a lot everyone!

Mark
-- 
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
 
------------------------------------------------------------------------
It just goes to show you that SOAP::Lite is more intuitive than 
you might think, if you know enough Perl and have the patience 
to dive into the source code.
                -Byrne Reese
                -http://builder.com.com/5100-6389_14-1045078-2.html
------------------------------------------------------------------------


From lstein at cshl.edu  Fri Feb 27 10:40:49 2004
From: lstein at cshl.edu (Lincoln Stein)
Date: Fri, 27 Feb 2004 17:40:49 +0200
Subject: [MOBY-l] April 3-4 meeting
In-Reply-To: <1077758193.1916.43.camel@localilluminae.com>
References: <1077758193.1916.43.camel@localilluminae.com>
Message-ID: <200402271740.49773.lstein@cshl.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am waiting for CSHL to get back to me on the availability of housing 
and rooms, but should know early next week whether I can confirm the 
April 3-4 dates.

Lincoln

- -- 
Lincoln D. Stein
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAP2UB0CIvUP7P+AkRAoN3AJ0TkJBdreyQX4wH6PvlGiUVoX+CSACfb180
gbFv0o1B6DxN8GHZVLqr5dY=
=ZEuI
-----END PGP SIGNATURE-----


From markw at illuminae.com  Fri Feb 27 19:12:23 2004
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 27 Feb 2004 16:12:23 -0800
Subject: [MOBY-l] Those who were testing Wx on Mac OS... any news?
Message-ID: <1077927143.4365.3.camel@localilluminae.com>

Hi all, 

There were a few of you who had offered to test the Wx code on Mac OS -
did anyone ever get it to work?  I didn't hear back from anyone...

Cheers!
M


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