Google Gadgets for BioMoby

I love it when a bunch of open APIs come together into something greater than the sum of the parts :-)

Thanks to the good folks at Google and their Google Gadgets for making things so darn simple! It only took an hour or so to write a script that wrapped every BioMoby Web service (more than 1400 of them!) with a Google Gadget. Now it is an absolute a no-brainer to create an amazing mashup of bioinformatics data by simply selecting the various services you are interested in and dropping their Gadgets on your iGoogle page. You might even make a variety of different Gadget tabs with different combinations of services to provide different views.

I'm still working on getting the rendering to be more size-appropriate (currently I am using the same rendering engine as I used in Gbrowse_moby) but I think it's pretty good for a first-pass!

Try them for yourself: http://mobycentral.icapture.ubc.ca/Gadgets

An LSID client

The last post was on how to build a resolver. This post is on how to build a client. The simple Perl client below retrieves metadata only (but I think it's fairly obvious which line needs to be changed to retrieve data ;-) )

Here we go!

use LS::ID;
use LS::Locator;

$lsid = LS::ID->new(
'urn:lsid:biomoby.org:servicetype:Retrieval:2001-09-21T16-00-00Z'
);

$locator = LS::Locator->new();
$authority = $locator->resolveAuthority($lsid);
$resource = $authority->getResource($lsid);
$data = $resource->getMetadata();
$response_filehandle = $data->response;
print <$response_filehandle>;
print "\n";

Voila! You hopefully have a bunch of RDF on your screen right now. Sure, that's a couple more lines than LWP::Simple, but some of that could be better encapsulated, so it really is only one or two lines more code than trying to do a GET... and with all sorts of benefits!

Oh! And here's how you get the LSID code from sourceforge. Get yourself a copy of Subversion, then cleck-out the code using subversion as so:

svn co http://lsids.svn.sourceforge.net/svnroot/lsids/trunk/lsid-perl lsids

(windows users will have a nice GUI for this)

Note that the sourceforge site indicates that it should be https://, but it works just as well as http, so you don't have to re-install Subversion to make it SSL compliant.

The Hello World LSID authority and metadata server

Since I'm out there advocating for LSIDs, and since the documentaton for LSIDs is hard to find and hard to work-through, I thought I'd take a stab at doing a "Hello World" LSID authority and metadata resolution server.

This is "as easy as it gets", but the process can be much more complex if needed. This solution requires no modification of the DNS/SRV records, and runs as a simple HTTP GET CGI service for metadata resolution.

Here we go! :-)


*** A HELLO WORLD LSID AUTHORITY ***
*** authority.pl ***

#!/usr/bin/perl
use strict;
use warnings;


use LS::Service::Authority;
use LS::Service::DataService;
use LS::HTTP::Service;
use LS::SOAP::Service transport=> 'HTTP::CGI';

my $location = 'http://';
if($ENV{'HTTP_HOST'} ) {
        $location .= $ENV{'HTTP_HOST'};
}
else {
        $location .= 'localhost:8080';
}


# FIRST create the authority service

my $authority_service = LS::Service::Authority->new(
        name=> 'Hello_World', 
        authority=> 'bioinfo.icapture.ubc.ca', 
        location=> $location);


# SECOND create an HTTP GET metadata port
# what comes in here will be:
# $location/authority/metadata?lsid=URN:LSID:blah.blah:nspace:id:version

my $metadata_port = 
     LS::Authority::WSDL::Simple::MetadataPort->newMetadata(
      portName=> 'Hello_there_World',
      endpoint=> "$location/authority/metadata",
      protocol=> $LS::Authority::WSDL::Constants::Protocols::HTTP,
  );
$authority_service->addPort(
    serviceName=> 'Hello_World', 
    port=> $metadata_port);


my $authority_server = LS::SOAP::Service->new();
$authority_server->authorityService($authority_service);

my $http_authority = LS::HTTP::Service->new();
$http_authority->dispatch_authority_to($authority_service);

$authority_server->httpServer($http_authority);
$authority_server->dispatch();

***** HELLO WORLD LSID METADATA SERVER *****
***** metadata.pl ******

#!/usr/bin/perl

use CGI qw/:all/;
my $C = CGI->new;

use strict;
use warnings;

use LS::ID;
use LS::Service::Response;
use LS::Service::Fault;
use LS::RDF::SimpleDocument;

my $lsid = param('lsid');
my $format = param('format') || "text/xml";

print header(-type => $format);
print getMetadata($lsid)->response;

sub getMetadata {
        my ($lsid, $format) = @_;
        $lsid = LS::ID->new($lsid);
        $lsid = $lsid->canonical();

        my $id = $lsid->object();
        $id .= ':' . $lsid->revision() if($lsid->revision());

        return LS::Service::Fault->serverFault(
                'Can not do what I cannot do', 500)
                unless($id);

        # Create a new RDF Document to add triples

        my $rdfDoc = LS::RDF::SimpleDocument->new();

        return LS::Service::Fault->serverFault(
           'Internal error, unable to initialize RDF document', 500) 
            unless($rdfDoc);

        return LS::Service::Fault->fault('Unknown LSID')
        unless(1);  # whatever conditions you want...


        $rdfDoc->addTripleLiteral(
            $lsid->as_string(), 
            'http://purl.org/dc/elements/1.1/#title', 
            "Hello World"); 

        $rdfDoc->addTripleResource(
              $lsid->as_string(), 
              'urn:lsid:example.com:predicates:another_lsid', 
              'urn:lsid:biomoby.org:objectclass:DNASequence');
  
        $format = 'application/xml' if(!$format);
        return LS::Service::Response->new(
            response=> '' . 
            $rdfDoc->output(),
            format=> $format);
}

***** APACHE Server Config ******
***** add these lines to your httpd.conf file ****

ScriptAlias /authority/metadata "/usr/local/apache2/LSID/metadata.pl"
ScriptAlias /authority "/usr/local/apache2/LSID/authority.pl"

    <Directory /usr/local/apache2/LSID>
        Options ExecCGI
        Order allow,deny
        Allow from all
    </Directory>

*** now put your files in the right place

Create a folder /usr/local/apache2/LSID/
save authority.pl to that folder
save metadata.pl to that folder
(get the permissions right!)

DONE!

You now have an LSID authority and metadata resolver! Enjoy!

More arguments for the LSID

I just realized that I forgot to mention the other way that the BioMoby project utilizes LSIDs.

The LSID spec includes versioning!

Our client software can, simply by string-comparison of LSIDs, detect when a BioMoby service has changed! The time-stamp that is appended to the LSID representing a service is updated for every change that the service-provider makes. This time-stamp is included in the "version" field of every LSID, so that every client program knows if it is looking at the same Web Service, or a modified one.

Again... let's see you do THAT using URLs! (without contorting yourself like a rubber-band man)

I state once more, that URLs are NOT the solution to the semantic web!

Let's get over it and move on!

Mark

The Dodo, The Turanian Tiger, and The Browser

One day I hope to see the Web Browser included in the web page of extinct animals. I want to re-iterate my opinion that The Web Browser should be an extinct technology in the near future.

No... let me correct that. The existence of a text-entry box where you type a URL will (should) become extinct. I keep going back to the conversation that Cartik and I had in the pub a few nights ago, that he captured in his blog entry. We were talking about AOL keywords, but also about bookmarks. The reason that we have bookmarks is not only so that we can re-find a resource that we want, but also so that we don't have to remember, or type-in, its URI. The Browser interface design has already shown us that people really don't want to have to deal with URIs, nor should they have to.

One of the things we are "promising" from the Semantic Web is that it will be more "human friendly" - able to locate information in a more intuitive and "human" way. Well, clearly, the first step to that end is that we do not expect our "humans" to type-in URIs.

So, I say again, and explicitly, that we should not be designing Semantic Web architectures with the constraint that typing-in a URI should cause information to be displayed in a browser. That's like designing a cell-phone system specifically to support a morse-code tapper! Old technologies should not be dictating the behaviours/architecture of new technologies.

Please, everyone... let's move on! Embedding Semantic Web inside of task-specific, non-browser applications is surely the future... or?

The argument for LSIDs

I posted this as a comment to Ben's blog post about LSIDs, but I want to re-post it here because it sounds like the working group is planning to contact me and Carole to discuss our use of LSIDs so I might as well make my arguments more visible and explicit. Cartik Kothari, a Post-Doc in my lab has also waded into the fray

here was my response to Ben's assertion that LSIDs should be abandoned:

I agree with only a part of what you [Ben] say, but think you aren't being ambitious enough. What we should be pushing for is that the LSID spec (or something very very similar to it) is re-branded and ADOPTED BY THE W3C!!

What worries me about NOT adopting a new identifier system as we move into the Semantic Web is that we start to hack and kludge our way to full functionality by adding novel behaiours on top of URLs, or start putting the "intelligence" of where to find data/metadata into redirects, purl URLs, or other nasty, centralized, and IMO unsustainable architectures.

LSIDs solve a very distinct set of problems - separation of identity from location; separation of data from metadata; and multiple end-points/protocols for both data and metadata retrieval. As far as I can tell, NONE of the solutions that have been proposed in the discussions within the HCLS community have come close to addressing these three issues in anywhere near as elegant a way as the LSID spec does, and some of the proposals have been a bit worrisome (e.g. "just add a ? to the end of your URL if you want metadata"... where is THAT in the HTTP spec??). Even more odd, to me, is that all of this contorting and hand-wringing is only because people want to be able to stick a URI in their browser and see something at the end of it. Frankly, I just don't see the point of designing architectures around browsers! (I quite liked Cartik's argument that, in the hey-day of AOL, you simply typed a keyword into your browser! **NOBODY** wants to type URLs (URIs) into their browser! Good Lord! The sooner we move the end-user away from the "guts" of the Web architecture the better!)

One of the keynote talks at the WWW2007 meeting was from a Microsoft fellow (can't remember his name) who reminded us that, within the next 10 years, the interfaces into the Web will become ubiquitous in our lives. "The Browser" is going the way of the Dodo! Why are we so concerned about designing next-generation architectures around last-generation interfaces?

In the BioMoby project we use LSIDs extensively (and by the way, I have almost never found the need to plug one of them into my browser...). Here's one of the uses we have for them:

A Web Service is identified by an LSID. The Moby Central registry knows certain things about that service (its inputs, its outputs, its semantic type, its authorship), and through an hourly "ping" it knows if that service is visible/available or not. This information is available as getMetadata from Moby Central. In addition, however, the service provider knows things about their own service. They know what example inputs and outputs might be, they know system maintenance schedules, etc. All of these things can be provided as getMetadata from the service provider. As a consumer, I want to know about a service, so I go to the LSID authority and say "where can I get information about this service?", the authority says "you can go here (Moby) and here (provider)", I do so, and I can combine the knowledge both resources have about that service. THIS IS ALL PART OF THE LSID SPEC! No hacks, no kludges, no new consensus was required within the community.

I don't know about you, but as for me and my family, we are going to continue using LSIDs until someone comes up with a BETTER alternative!

The semantic web in Haiku...

I stumbled over this site today while looking at the new interface to Ask.com (which is really quite appealing, but does not seem to have translated into additional market share...)

Here is the semantic web explained in Haiku

It made me chuckle :-)