[MOBY-dev] Shims in BioMOBY

[Paul Gordon]

Sorry, I guess I want to usurp your word then :-)

I'd only put in my Shims category the very boring operations on *Object 
types*, such as DNASequence to FASTA_NA object conversion, or a multiple 
sequence alignment to a collection of sequences, etc., which are

1. purely syntactic
2. complete (all fields of the target object are meaningfully completed 
by the source object)
3. applicable for 100% of the possible source objects

That way I can present FastA service options to a user with a 
DNASequence, since the user *already has exactly this information*. 
These problems exist only because developers didn't agree on using the 
same ontology object, not because of a fundamental different in the 
data.  There should be no conscious decision necessary here, unlike 
decomposition and crossreferencing tasks. 

While you may call these Shims too, I think of these more as Adaptors.  
I guess this is why I made my original post :-)

How about a service type ontology like :

Conversion
    Shims
       Object types: e.g. DNASequence_to_FASTA, genbank_to_DNASequence

Then my program would automatically consider services of type Conversion 
-> Shims -> Object type
and I don't restrict your word :-)
> Hi Paul
>
> Paul Gordon wrote:
>
>> This is a very general question, especially for non-native-English 
>> speakers.  I was going to add  a top-level "Shim" category of 
>> services to the ontology,  but I'm pretty sure most 
>> non-native-English speakers would have no idea what this means.  I'm 
>> borrowing the term from
>>
>> D Hull, R Stevens, P Lord, C Wroe, C Goble (2004). Treating shimantic 
>> web syndrome with ontologies. First AKT workshop on Semantic Web 
>> Services (AKT-SWS04).
>>  
>>
> Since I'm first author of the paper [1] you mention, here are three 
> points on how I think shim services should be described, so that users 
> can find them. According to me, I am the first person to use the term 
> "shim" to describe bioinformatics services, although its been used in 
> hypermedia research [2] to describe similar operations in software.
>
> Firstly, it is probably useful to annotate services as a shims, 
> although this is information that the user  may not always want to 
> see. A service that maps between equivalent identifiers (GenBank to 
> EMBL for example) in one workflow might be considered a safe or 
> "boring" operation [3], with shim-like properties. However, the same 
> service in a different workflow constructed by a different user, might 
> not be a considered a shim, because the safeness of the operation 
> depends on the GenBank identifier the service takes as input. So it is 
> probably a useful annotation, and a useful concept in your ontology, 
> but the user will not always care wether a given service is a shim or 
> not.
>
> Secondly, one thing that characterises shims is the relation between 
> the input and the output. So, for example, a service that extracts the 
> protein sequence from a BLAST_report is a fairly boring shim, because 
> the relation between the input and the output is hasPart eg. a 
> BLAST_report hasPart protein_sequence. I personally think this 
> relation between input and output is one that will help distinguish 
> the shim from other services in the registry, and therefore aid 
> retrieval. So capturing this relation in the registry could be useful.
>
> Finally, if you're using a description logic reasoner, an interesting 
> solution would be to describe the properties of shim services, and let 
> the reasoner infer which services are shims based on these properties. 
> This would save you some of the trouble of annotating shims in your 
> registry, and would give you a clear definition of *exactly* what you 
> mean when you say "shim", since the word has several different 
> meanings....
>
> Speaking of which, a shim [4] can also mean a transexual person: "she 
> + him = shim", according to wikipedia :)
>
> Duncan
>
> [1] 
> http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-122/paper1.pdf 
>
> [2] http://eprints.ecs.soton.ac.uk/768/02/html/ [3] 
> http://taverna.sourceforge.net/usermanual/docs.word.html#_Toc107043031
> [4] http://en.wikipedia.org/wiki/Shim
>