
   
= 
= 
= 
= 
= 
= 
= 

               Request for Feedback from the BioMoby Community!

   

   Before I begin, I would just like to say that the BioMoby Project is    a  open  source,  community driven project. As such, it is key that if
   the  = community doesnt like how something is done, then the community
   should = fix it. If something is broken, doesnt work as intended or is
   vague,  = speak up and make your voice heard! BioMoby is not a one man
   project,  = but a community driven one. Things will only get better if
   we know what = is wrong and if people take initiative.
   

   So  I  (Eddie)  just  got  back  from  the INBs Technical Meeting in    beautiful Malaga, Spain and I have some items that the community needs
   =  to talk about below. Also, be sure to keep an eye out for proposals
   =  about  handling  asynchronous services as well as error handling in
   Moby.    

  1. API addition of a method called getResourcesURL:

   

   Returns  an  xml  document  that describes the location of RESOURCES    script  that  we hear so much about. It is the resources script that    contains the ontologies expressed in RDF/XML
   

   example:
   

     
<someRoot>
        <resources>
                <name>Services</name>
                <url>http://mobycentral.icapture.ubc.ca:8090/RESOURCES/MOBY-S/Services</url>
        </resources>
        <resources>
                <name>Objects</name>
                <url>http://mobycentral.icapture.ubc.ca:8090/RESOURCES/MOBY-S/Objects</url>
        </resources> 
        ... 
 </someRoot>    

     

   

  2. How do I know what predicates are available in the RDF documents = that
  describe the Moby ontologies?

   

     

     a.  should  we  provide  a  list of predicates and their intended      meanings (on a wiki, etc)?
     

     b.  should  we  provide  an RDF schema defining the predicates (*      probably the way to go)
     

     c.  Should  we  allow  the registration of new predicates, if so,      should we make this an api call, etc.
     

   

  3. LSID resolution services

   

     

     a. is the LSID attribute available and documented?
     

     b.  when  will this occur, i have heard so much about this, yet i      have seen nothing.
     

   

  4. LSIDs versus simple names

   

     

     a.  why  is  the  name  of an object, service, or service type is      sometimes a simple name and sometimes an LSID?
     

     b.  how  can  i  even retrieve the LSID of an object, service, or      service type?
     

     c.  should api calls be added to getName and getLSID for objects,      services and service types?
     

   

  5. LSIDs and Service Instances

   

     

     a..If a service instance is registered by 2 different authoritys,      should they have the same LSID?
     

     b.  if the service instance is registered in 2 registries, should      the LSIDs be the same?
     

     c. will modified service instances have versioning information?
     

   

  6. LSID resolution for objects in the BioMoby ontologies

   

     

     a. what should getData return for
     
 i.namespaces (the name of the namespace?)
 ii. service types (the name of the service type?)
 iii. objects (xml schema? - note that schemas for datatypes should be ready and available very soon :-) 
 iv. service instances (the name of the instance?)

     

     b.  should  we  allow  the  namespace  part  of  an  LSID  to  be      configurable?
     

     c.  should  we  allow  the  authority  part  of  an  LSID  to  be      configurable?
     

   

  7. Would you like to have 3rd party annotation of metadata?

   

     

     a. use case: adds mirroring
     

     b. use case: allows people to provide additional metadata
     

     

     i.  if  you  want  only one source for metadata, then ignore this      question.
     

     

   

  9. Predicates

   

     

     a.  should  we  add  the  following predicates to the metadata of      service instances?
     
  i.   sampleInputData - specifies valid input for the service instance
  ii.  sampleOutputData - specifies the output for the service instance based on the test input.
  iii. approvedBy - specifies whether this service has been approved. Currently, this would only be useful for the INB, but many more may find it useful.
    

     

     b. how should the sample input/output be formatted?
     

     c. should we allow the annotation of datatypes?
     

   

  10. API and Code versioning

   

     

     a. why are the api and code versions different?
     

   

  11. Datatype naming

   

     

     a. do you think that the names of datatypes should be regulated?
     
        i. what would be the right way to specify a datatypes name?
ii. what should we do with text_plain and text-plain?

     

   

  12. RDF Agent

   

     

     a.  do you think that there should be an api call, getUpdate that      tells  the agent to check for modifications to the service instance
     =   described   by   the  metadata  in  the  RDF  document  at  the
     signatureURL?
     

     b. what is the time line to get the agent running?
     

     c. besides curation, how is the agent useful to me?
     

   

  13. Service

   

     

     a.  should  article  names  for service instance input and output      datatypes be mandatory?
     

     b.  why  does  a service that advertise an output datatype called      'foo' return 'bar' instead?
     

   
= 
= 
