[MOBY-dev] LSIDs in the ServiceInstance RDF

[Mark Wilkinson]

Hi all, 

Eddie and I have been going in circles in a discussion of LSIDs in the
ServiceInstance RDF, so we're hoping that a wider discussion can help
reveal the correct path forward.  

Here's the issue:

1)  The agent-based service update/register/deregister system is going
to use the Service Signature RDF document to extract its information

2)  At the moment, this document contains an LSID identifying the
service instance, of the form:
  urn:lsid:biomoby.org:serviceinstance: authority,servicename:Timestamp

3)  If the service provider updates this RDF with teh intention of
calling the agent to update their service, we would expect that the LSID
should also be updated.  This is because although we only resolve LSID
metadata, we have agreed amongst ourselves that it is important for
client programs (e.g. Dashboard) to know when the metadata has changed.
As such, the LSID timestamp *must* be updated when the service
registration is modified, and thus the service provider must do this.

4)  We have also agreed that, by convention, the timestamp of the LSID
is to take a certain format, and in fact we are allowing certain of our
software to parse and interpret that format.

5)  we have little control over how the service provider chooses to
modify their LSID when they update their Signature RDF. They might
change the timestamp format, or they might change the namespace
(authURI,servicename), or other things.

6)  We, as the LSID authority (biomoby.org) parse the LSID string
because we are supposed to be guaranteed to understand its form... but
now a third party is generating the LSID's that we are supposed to be
parsing and we can no longer guarantee that we will understand it even
though we are supposed to be able to resolve it!

(A)  One option would be to remove the LSID from the Signature RDF so
that the service provider cannot change it, but we feel that it is a
useful component of that document, especially if the RESOURCES script
(getResourceURLs) is used as the primary way that software bulk-
downloads the contents of the registry.

(B)  Another alternative would be for the RESOURCES script
(getResourceURLs) to generate RDF that includes the LSID, but for the
Signature RDF that is hosted by the service host not to include it.  The
documents would be otherwise identical.  This is an effective solution,
but "feels" wrong, since there are now two non-identical RDF
descriptions of a service.


Personally, I am in favour of option (B) because the service provider
will be adding a lot of additional annotation to their service signature
anyway, but Eddie doesn't really like that one.  Does anyone else have
software that would break if we pursued that option?  Are there other
options we haven't thought of?  Is there a strong feeling one way or the
other about this from anyone?

M



-- 

--
Mark Wilkinson
Asst. Professor, Dept. of Medical Genetics
University of British Columbia
PI in Bioinformatics, iCAPTURE Centre
St. Paul's Hospital, Rm. 166, 1081 Burrard St.
Vancouver, BC, V6Z 1Y6
tel: 604 682 2344 x62129
fax: 604 806 9274

"For most of this century we have viewed communications as a conduit, 
       a pipe between physical locations on the planet. 
What's happened now is that the conduit has become so big and interesting 
      that communication has become more than a conduit, 
       it has become a destination in its own right..."

                Paul Saffo - Director, Institute for the Future