[MOBY-dev] rfcf 5. LSIDs and Service Instances

[Martin Senger]

> Yup... that suggestion (to use the version position to denote 
> replication) would be very dangerous!  However, it is an interesting 
> problem, since I don't think the LSID communuty would be very 
> comfortable with a single LSID referring to multiple resources... even 
> if they are "identical".  Martin, do you have an opinion about this?
>
   This is about replicated services that were (afaik) first mentioned (at
least with some depth) in Vancouver. Before we decide about how to create
LSID for such kind of services, we need to define what are replicated
services. So far, each service was uniquely defined by three elements:
   - its endpoint,
   - its authority (in the Biomoby sense, not the LSID sense), and
   - its (simple) name (unique within its authority).
   So what are the replicated services? My take (after what I heard in
Vancouver) is that the replicated services will have the same two of the
attributes above: authority and name, but they will not share the same
endpoint. (Additionally, just in documenttaion, we claim that such
replicated services do the same data transformation - but this is not
check-able.) Is this how we want to define replicated services?
   If the answer is yes, here is how I would feel about the LSID:

   1) Resolving Data. Eddie mentioned that he (or he and Mark, I was not
sure) were/are thinking about using LSID resolution method 'getData' for
returning a WSDL of this service. I am not sure that I identify myself
with this idea. Mainly because we already have a way how to get the same
WSDL from the registry (there is an API method for that) so why to
duplicate it. And also because doing this we will immediately need
different LSID for replicated services (because the endpoint is - at
least, usully - part of such WSDL).
   So I would suggest to return nothing by this method. If this is
accepted, I ca elaborate further what to do with metadata.

   2) Resolving metadata. Mark is not sure that the replicated services
should have the same LSID. I am not sure either - but I am more inclined
to say 'Why not?'. They do the same think - except they some of them can
do it better (faster, more reliably etc.) But this can be reflected in
metadata - it includes the endpoint, so the user will see which metadata
refers to which replicated service. We would need to make some consensus
on the metadata predicates to assure that the metadata can be identified:
which are meant for all such replicated services, and which are meand only
for individual such services.
   If we do not want to have same LSID for replicated services we will
need to solve the following with more efforts:

   3) Problems with *not* having the same LSID for replicated services:
   a) The Registry API is going to change because of replicated services
(as we talked about it in V.) - but the change would have me more
significant than just to chnage the 'endpoint URL' to a set of 'endpoint
URLs' - because when the registry returns LSID, it must return more/many
LSIDs about the same service.

   b) The registry would have more problems to collect all available
metadata (or to send SignatureURLs of all of them) if their are more LSIDs
for the same service.

   These problems are surely solveable but I wonder why the LSID cannot be
same for the replicated services (I also feel that it is a bit strange,
but I cannot find the real arguments why not to do it.).

   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