Links to Exploration step
Le document en format XML
<record><TEI><teiHeader><fileDesc><titleStmt><title xml:lang="en">Clever generation of rich SPARQL queries from annotated relational schema: application to Semantic Web Service creation for biological databases</title><author><name sortKey="Wollbrett, Julien" sort="Wollbrett, Julien" uniqKey="Wollbrett J" first="Julien" last="Wollbrett">Julien Wollbrett</name><affiliation><nlm:aff id="I1">CIRAD, UMR AGAP, Montpellier F-34398, France</nlm:aff></affiliation><affiliation><nlm:aff id="I4">Institut de Biologie Computationnelle, 95 rue de la Galéra, 34095, Montpellier, France</nlm:aff></affiliation></author><author><name sortKey="Larmande, Pierre" sort="Larmande, Pierre" uniqKey="Larmande P" first="Pierre" last="Larmande">Pierre Larmande</name><affiliation><nlm:aff id="I2">IRD, UMR DIADE, Montpellier, France</nlm:aff></affiliation><affiliation><nlm:aff id="I4">Institut de Biologie Computationnelle, 95 rue de la Galéra, 34095, Montpellier, France</nlm:aff></affiliation></author><author><name sortKey="De Lamotte, Frederic" sort="De Lamotte, Frederic" uniqKey="De Lamotte F" first="Frédéric" last="De Lamotte">Frédéric De Lamotte</name><affiliation><nlm:aff id="I3">INRA, UMR AGAP, Montpellier F-34398, France</nlm:aff></affiliation></author><author><name sortKey="Ruiz, Manuel" sort="Ruiz, Manuel" uniqKey="Ruiz M" first="Manuel" last="Ruiz">Manuel Ruiz</name><affiliation><nlm:aff id="I1">CIRAD, UMR AGAP, Montpellier F-34398, France</nlm:aff></affiliation><affiliation><nlm:aff id="I4">Institut de Biologie Computationnelle, 95 rue de la Galéra, 34095, Montpellier, France</nlm:aff></affiliation></author></titleStmt><publicationStmt><idno type="wicri:source">PMC</idno><idno type="pmid">23586394</idno><idno type="pmc">3680174</idno><idno type="url">http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3680174</idno><idno type="RBID">PMC:3680174</idno><idno type="doi">10.1186/1471-2105-14-126</idno><date when="2013">2013</date><idno type="wicri:Area/Pmc/Corpus">000272</idno></publicationStmt><sourceDesc><biblStruct><analytic><title xml:lang="en" level="a" type="main">Clever generation of rich SPARQL queries from annotated relational schema: application to Semantic Web Service creation for biological databases</title><author><name sortKey="Wollbrett, Julien" sort="Wollbrett, Julien" uniqKey="Wollbrett J" first="Julien" last="Wollbrett">Julien Wollbrett</name><affiliation><nlm:aff id="I1">CIRAD, UMR AGAP, Montpellier F-34398, France</nlm:aff></affiliation><affiliation><nlm:aff id="I4">Institut de Biologie Computationnelle, 95 rue de la Galéra, 34095, Montpellier, France</nlm:aff></affiliation></author><author><name sortKey="Larmande, Pierre" sort="Larmande, Pierre" uniqKey="Larmande P" first="Pierre" last="Larmande">Pierre Larmande</name><affiliation><nlm:aff id="I2">IRD, UMR DIADE, Montpellier, France</nlm:aff></affiliation><affiliation><nlm:aff id="I4">Institut de Biologie Computationnelle, 95 rue de la Galéra, 34095, Montpellier, France</nlm:aff></affiliation></author><author><name sortKey="De Lamotte, Frederic" sort="De Lamotte, Frederic" uniqKey="De Lamotte F" first="Frédéric" last="De Lamotte">Frédéric De Lamotte</name><affiliation><nlm:aff id="I3">INRA, UMR AGAP, Montpellier F-34398, France</nlm:aff></affiliation></author><author><name sortKey="Ruiz, Manuel" sort="Ruiz, Manuel" uniqKey="Ruiz M" first="Manuel" last="Ruiz">Manuel Ruiz</name><affiliation><nlm:aff id="I1">CIRAD, UMR AGAP, Montpellier F-34398, France</nlm:aff></affiliation><affiliation><nlm:aff id="I4">Institut de Biologie Computationnelle, 95 rue de la Galéra, 34095, Montpellier, France</nlm:aff></affiliation></author></analytic><series><title level="j">BMC Bioinformatics</title><idno type="eISSN">1471-2105</idno><imprint><date when="2013">2013</date></imprint></series></biblStruct></sourceDesc></fileDesc><profileDesc><textClass></textClass></profileDesc></teiHeader><front><div type="abstract" xml:lang="en"><sec><title>Background</title><p>In recent years, a large amount of “-omics” data have been produced. However, these data are stored in many different species-specific databases that are managed by different institutes and laboratories. Biologists often need to find and assemble data from disparate sources to perform certain analyses. Searching for these data and assembling them is a time-consuming task. The Semantic Web helps to facilitate interoperability across databases. A common approach involves the development of wrapper systems that map a relational database schema onto existing domain ontologies. However, few attempts have been made to automate the creation of such wrappers.</p></sec><sec><title>Results</title><p>We developed a framework, named BioSemantic, for the creation of Semantic Web Services that are applicable to relational biological databases. This framework makes use of both Semantic Web and Web Services technologies and can be divided into two main parts: <italic>(i)</italic> the generation and semi-automatic annotation of an RDF view; and <italic>(ii)</italic> the automatic generation of SPARQL queries and their integration into Semantic Web Services backbones. We have used our framework to integrate genomic data from different plant databases.</p></sec><sec><title>Conclusions</title><p>BioSemantic is a framework that was designed to speed integration of relational databases. We present how it can be used to speed the development of Semantic Web Services for existing relational biological databases. Currently, it creates and annotates RDF views that enable the automatic generation of SPARQL queries. Web Services are also created and deployed automatically, and the semantic annotations of our Web Services are added automatically using SAWSDL attributes. BioSemantic is downloadable at <ext-link ext-link-type="uri" xlink:href="http://southgreen.cirad.fr/?q=content/Biosemantic">http://southgreen.cirad.fr/?q=content/Biosemantic</ext-link>.</p></sec></div></front><back><div1 type="bibliography"><listBibl><biblStruct><analytic><author><name sortKey="Tsesmetzis, N" uniqKey="Tsesmetzis N">N Tsesmetzis</name></author><author><name sortKey="Couchman, M" uniqKey="Couchman M">M Couchman</name></author><author><name sortKey="Higgins, J" uniqKey="Higgins J">J Higgins</name></author><author><name sortKey="Smith, A" uniqKey="Smith A">A Smith</name></author><author><name sortKey="Doonan, Jh" uniqKey="Doonan J">JH Doonan</name></author><author><name sortKey="Seifert, Gj" uniqKey="Seifert G">GJ Seifert</name></author><author><name sortKey="Schmidt, Ee" uniqKey="Schmidt E">EE Schmidt</name></author><author><name sortKey="Vastrik, I" uniqKey="Vastrik I">I Vastrik</name></author><author><name sortKey="Birney, E" uniqKey="Birney E">E Birney</name></author><author><name sortKey="Wu, G" uniqKey="Wu G">G Wu</name></author><author><name sortKey="D Ustachio, P" uniqKey="D Ustachio P">P D’Eustachio</name></author><author><name sortKey="Stein, Ld" uniqKey="Stein L">LD Stein</name></author><author><name sortKey="Morris, Rj" uniqKey="Morris R">RJ Morris</name></author><author><name sortKey="Bevan, Mw" uniqKey="Bevan M">MW Bevan</name></author><author><name sortKey="Walsh, Sv" uniqKey="Walsh S">SV Walsh</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Lysenko, A" uniqKey="Lysenko A">A Lysenko</name></author><author><name sortKey="Hindle, Mm" uniqKey="Hindle M">MM Hindle</name></author><author><name sortKey="Taubert, J" uniqKey="Taubert J">J Taubert</name></author><author><name sortKey="Saqi, M" uniqKey="Saqi M">M Saqi</name></author><author><name sortKey="Rawlings, Cj" uniqKey="Rawlings C">CJ Rawlings</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Stein, Ld" uniqKey="Stein L">LD Stein</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Goble, C" uniqKey="Goble C">C Goble</name></author><author><name sortKey="Stevens, R" uniqKey="Stevens R">R Stevens</name></author></analytic></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct><biblStruct><analytic><author><name sortKey="Swarbreck, D" uniqKey="Swarbreck D">D Swarbreck</name></author><author><name sortKey="Wilks, C" uniqKey="Wilks C">C Wilks</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Liang, C" uniqKey="Liang C">C Liang</name></author><author><name sortKey="Jaiswal, P" uniqKey="Jaiswal P">P Jaiswal</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Mclaren, Cg" uniqKey="Mclaren C">CG McLaren</name></author><author><name sortKey="Bruskiewich, Rm" uniqKey="Bruskiewich R">RM Bruskiewich</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Lawrence, Cj" uniqKey="Lawrence C">CJ Lawrence</name></author><author><name sortKey="Harper, Lc" uniqKey="Harper L">LC Harper</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Samson, D" uniqKey="Samson D">D Samson</name></author><author><name sortKey="Legeai, F" uniqKey="Legeai F">F Legeai</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Rubin, Dl" uniqKey="Rubin D">DL Rubin</name></author><author><name sortKey="Shah, Nh" uniqKey="Shah N">NH Shah</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Chepelev, Ll" uniqKey="Chepelev L">LL Chepelev</name></author><author><name sortKey="Dumontier, M" uniqKey="Dumontier M">M Dumontier</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Bruskiewich, R" uniqKey="Bruskiewich R">R Bruskiewich</name></author><author><name sortKey="Senger, M" uniqKey="Senger M">M Senger</name></author><author><name sortKey="Davenport, G" uniqKey="Davenport G">G Davenport</name></author><author><name sortKey="Ruiz, M" uniqKey="Ruiz M">M Ruiz</name></author><author><name sortKey="Rouard, M" uniqKey="Rouard M">M Rouard</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Goff, Sa" uniqKey="Goff S">SA Goff</name></author><author><name sortKey="Mckay, S" uniqKey="Mckay S">S McKay</name></author><author><name sortKey="Stapleton, Ae" uniqKey="Stapleton A">AE Stapleton</name></author><author><name sortKey="Hanlon, M" uniqKey="Hanlon M">M Hanlon</name></author><author><name sortKey="Mock, S" uniqKey="Mock S">S Mock</name></author><author><name sortKey="Helmke, M" uniqKey="Helmke M">M Helmke</name></author><author><name sortKey="Kubach, A" uniqKey="Kubach A">A Kubach</name></author><author><name sortKey="Noutsos, C" uniqKey="Noutsos C">C Noutsos</name></author><author><name sortKey="Gendler, K" uniqKey="Gendler K">K Gendler</name></author><author><name sortKey="Feng, X" uniqKey="Feng X">X Feng</name></author><author><name sortKey="Welch, Sm" uniqKey="Welch S">SM Welch</name></author><author><name sortKey="O Eara, B" uniqKey="O Eara B">B O’Meara</name></author><author><name sortKey="Brutnell, T" uniqKey="Brutnell T">T Brutnell</name></author><author><name sortKey="Leebens Mack, J" uniqKey="Leebens Mack J">J Leebens-Mack</name></author><author><name sortKey="Akoglu, A" uniqKey="Akoglu A">A Akoglu</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Wilkinson, Md" uniqKey="Wilkinson M">MD Wilkinson</name></author><author><name sortKey="Vandervalk, B" uniqKey="Vandervalk B">B Vandervalk</name></author><author><name sortKey="Mccarthy, L" uniqKey="Mccarthy L">L McCarthy</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Gessler, D" uniqKey="Gessler D">D Gessler</name></author><author><name sortKey="Schiltz, G" uniqKey="Schiltz G">G Schiltz</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Wilkinson, Md" uniqKey="Wilkinson M">MD Wilkinson</name></author><author><name sortKey="Vandervalk, B" uniqKey="Vandervalk B">B Vandervalk</name></author><author><name sortKey="Mccarthy, L" uniqKey="Mccarthy L">L McCarthy</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Wilkinson, Md" uniqKey="Wilkinson M">MD Wilkinson</name></author><author><name sortKey="Senger, M" uniqKey="Senger M">M Senger</name></author><author><name sortKey="Kawas, E" uniqKey="Kawas E">E Kawas</name></author><author><name sortKey="Bruskiewich, R" uniqKey="Bruskiewich R">R Bruskiewich</name></author><author><name sortKey="Gouzy, J" uniqKey="Gouzy J">J Gouzy</name></author><author><name sortKey="Noirot, C" uniqKey="Noirot C">C Noirot</name></author><author><name sortKey="Bardou, P" uniqKey="Bardou P">P Bardou</name></author><author><name sortKey="Ng, A" uniqKey="Ng A">A Ng</name></author><author><name sortKey="Haase, D" uniqKey="Haase D">D Haase</name></author><author><name sortKey="Saiz Ede, A" uniqKey="Saiz Ede A">A Saiz Ede</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Wilkinson, M" uniqKey="Wilkinson M">M Wilkinson</name></author><author><name sortKey="Mccarthy, L" uniqKey="Mccarthy L">L McCarthy</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Spanos, D E" uniqKey="Spanos D">D-E Spanos</name></author><author><name sortKey="Stavrou, P" uniqKey="Stavrou P">P Stavrou</name></author><author><name sortKey="Mitrou, N" uniqKey="Mitrou N">N Mitrou</name></author></analytic></biblStruct><biblStruct></biblStruct><biblStruct><analytic><author><name sortKey="Miles, A" uniqKey="Miles A">A Miles</name></author><author><name sortKey="Zhao, J" uniqKey="Zhao J">J Zhao</name></author><author><name sortKey="Klyne, G" uniqKey="Klyne G">G Klyne</name></author><author><name sortKey="White Cooper, H" uniqKey="White Cooper H">H White-Cooper</name></author><author><name sortKey="Shotton, D" uniqKey="Shotton D">D Shotton</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Cheung, Kh" uniqKey="Cheung K">KH Cheung</name></author><author><name sortKey="Yip, Ky" uniqKey="Yip K">KY Yip</name></author><author><name sortKey="Smith, A" uniqKey="Smith A">A Smith</name></author><author><name sortKey="Deknikker, R" uniqKey="Deknikker R">R Deknikker</name></author><author><name sortKey="Masiar, A" uniqKey="Masiar A">A Masiar</name></author><author><name sortKey="Gerstein, M" uniqKey="Gerstein M">M Gerstein</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Lam, Hyk" uniqKey="Lam H">HYK Lam</name></author><author><name sortKey="Marenco, L" uniqKey="Marenco L">L Marenco</name></author><author><name sortKey="Shepherd, Gm" uniqKey="Shepherd G">GM Shepherd</name></author><author><name sortKey="Miller, Pl" uniqKey="Miller P">PL Miller</name></author><author><name sortKey="Cheung, K H" uniqKey="Cheung K">K-H Cheung</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Bruskiewich, R" uniqKey="Bruskiewich R">R Bruskiewich</name></author><author><name sortKey="Davenport, G" uniqKey="Davenport G">G Davenport</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Rahayu, Jw" uniqKey="Rahayu J">JW Rahayu</name></author><author><name sortKey="Chang, E" uniqKey="Chang E">E Chang</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Tirmizi, S" uniqKey="Tirmizi S">S Tirmizi</name></author><author><name sortKey="Sequeda, J" uniqKey="Sequeda J">J Sequeda</name></author><author><name sortKey="Miranker, D" uniqKey="Miranker D">D Miranker</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Dijkstra, E" uniqKey="Dijkstra E">E Dijkstra</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Pettifer, S" uniqKey="Pettifer S">S Pettifer</name></author><author><name sortKey="Ison, J" uniqKey="Ison J">J Ison</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Kopeck, J" uniqKey="Kopeck J">J Kopecký</name></author><author><name sortKey="Vitvar, T" uniqKey="Vitvar T">T Vitvar</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Bhagat, J" uniqKey="Bhagat J">J Bhagat</name></author><author><name sortKey="Tanoh, F" uniqKey="Tanoh F">F Tanoh</name></author><author><name sortKey="Nzuobontane, E" uniqKey="Nzuobontane E">E Nzuobontane</name></author><author><name sortKey="Laurent, T" uniqKey="Laurent T">T Laurent</name></author><author><name sortKey="Orlowski, J" uniqKey="Orlowski J">J Orlowski</name></author><author><name sortKey="Roos, M" uniqKey="Roos M">M Roos</name></author><author><name sortKey="Wolstencroft, K" uniqKey="Wolstencroft K">K Wolstencroft</name></author><author><name sortKey="Aleksejevs, S" uniqKey="Aleksejevs S">S Aleksejevs</name></author><author><name sortKey="Stevens, R" uniqKey="Stevens R">R Stevens</name></author><author><name sortKey="Pettifer, S" uniqKey="Pettifer S">S Pettifer</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Ruiz, M" uniqKey="Ruiz M">M Ruiz</name></author><author><name sortKey="Rouard, M" uniqKey="Rouard M">M Rouard</name></author><author><name sortKey="Raboin, Lm" uniqKey="Raboin L">LM Raboin</name></author><author><name sortKey="Lartaud, M" uniqKey="Lartaud M">M Lartaud</name></author><author><name sortKey="Lagoda, P" uniqKey="Lagoda P">P Lagoda</name></author><author><name sortKey="Courtois, B" uniqKey="Courtois B">B Courtois</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Flicek, P" uniqKey="Flicek P">P Flicek</name></author><author><name sortKey="Amode, Mr" uniqKey="Amode M">MR Amode</name></author><author><name sortKey="Barrell, D" uniqKey="Barrell D">D Barrell</name></author><author><name sortKey="Beal, K" uniqKey="Beal K">K Beal</name></author><author><name sortKey="Brent, S" uniqKey="Brent S">S Brent</name></author><author><name sortKey="Carvalho Silva, D" uniqKey="Carvalho Silva D">D Carvalho-Silva</name></author><author><name sortKey="Clapham, P" uniqKey="Clapham P">P Clapham</name></author><author><name sortKey="Coates, G" uniqKey="Coates G">G Coates</name></author><author><name sortKey="Fairley, S" uniqKey="Fairley S">S Fairley</name></author><author><name sortKey="Fitzgerald, S" uniqKey="Fitzgerald S">S Fitzgerald</name></author><author><name sortKey="Gil, L" uniqKey="Gil L">L Gil</name></author><author><name sortKey="Gordon, L" uniqKey="Gordon L">L Gordon</name></author><author><name sortKey="Hendrix, M" uniqKey="Hendrix M">M Hendrix</name></author><author><name sortKey="Hourlier, T" uniqKey="Hourlier T">T Hourlier</name></author><author><name sortKey="Johnson, N" uniqKey="Johnson N">N Johnson</name></author><author><name sortKey="Kahari, Ak" uniqKey="Kahari A">AK Kahari</name></author><author><name sortKey="Keefe, D" uniqKey="Keefe D">D Keefe</name></author><author><name sortKey="Keenan, S" uniqKey="Keenan S">S Keenan</name></author><author><name sortKey="Kinsella, R" uniqKey="Kinsella R">R Kinsella</name></author><author><name sortKey="Komorowska, M" uniqKey="Komorowska M">M Komorowska</name></author><author><name sortKey="Koscielny, G" uniqKey="Koscielny G">G Koscielny</name></author><author><name sortKey="Kulesha, E" uniqKey="Kulesha E">E Kulesha</name></author><author><name sortKey="Larsson, P" uniqKey="Larsson P">P Larsson</name></author><author><name sortKey="Longden, I" uniqKey="Longden I">I Longden</name></author><author><name sortKey="Mclaren, W" uniqKey="Mclaren W">W McLaren</name></author><author><name sortKey="Muffato, M" uniqKey="Muffato M">M Muffato</name></author><author><name sortKey="Overduin, B" uniqKey="Overduin B">B Overduin</name></author><author><name sortKey="Pignatelli, M" uniqKey="Pignatelli M">M Pignatelli</name></author><author><name sortKey="Pritchard, B" uniqKey="Pritchard B">B Pritchard</name></author><author><name sortKey="Riat, Hs" uniqKey="Riat H">HS Riat</name></author><author><name sortKey="Ritchie, Grs" uniqKey="Ritchie G">GRS Ritchie</name></author><author><name sortKey="Ruffier, M" uniqKey="Ruffier M">M Ruffier</name></author><author><name sortKey="Schuster, M" uniqKey="Schuster M">M Schuster</name></author><author><name sortKey="Sobral, D" uniqKey="Sobral D">D Sobral</name></author><author><name sortKey="Tang, Ya" uniqKey="Tang Y">YA Tang</name></author><author><name sortKey="Taylor, K" uniqKey="Taylor K">K Taylor</name></author><author><name sortKey="Trevanion, S" uniqKey="Trevanion S">S Trevanion</name></author><author><name sortKey="Vandrovcova, J" uniqKey="Vandrovcova J">J Vandrovcova</name></author><author><name sortKey="White, S" uniqKey="White S">S White</name></author><author><name sortKey="Wilson, M" uniqKey="Wilson M">M Wilson</name></author><author><name sortKey="Wilder, Sp" uniqKey="Wilder S">SP Wilder</name></author><author><name sortKey="Aken, Bl" uniqKey="Aken B">BL Aken</name></author><author><name sortKey="Birney, E" uniqKey="Birney E">E Birney</name></author><author><name sortKey="Cunningham, F" uniqKey="Cunningham F">F Cunningham</name></author><author><name sortKey="Dunham, I" uniqKey="Dunham I">I Dunham</name></author><author><name sortKey="Durbin, R" uniqKey="Durbin R">R Durbin</name></author><author><name sortKey="Fernandez Suarez, Xm" uniqKey="Fernandez Suarez X">XM Fernandez-Suarez</name></author><author><name sortKey="Harrow, J" uniqKey="Harrow J">J Harrow</name></author><author><name sortKey="Herrero, J" uniqKey="Herrero J">J Herrero</name></author><author><name sortKey="Hubbard, Tjp" uniqKey="Hubbard T">TJP Hubbard</name></author><author><name sortKey="Parker, A" uniqKey="Parker A">A Parker</name></author><author><name sortKey="Proctor, G" uniqKey="Proctor G">G Proctor</name></author><author><name sortKey="Spudich, G" uniqKey="Spudich G">G Spudich</name></author><author><name sortKey="Vogel, J" uniqKey="Vogel J">J Vogel</name></author><author><name sortKey="Yates, A" uniqKey="Yates A">A Yates</name></author><author><name sortKey="Zadissa, A" uniqKey="Zadissa A">A Zadissa</name></author><author><name sortKey="Searle, Smj" uniqKey="Searle S">SMJ Searle</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Goble, Ca" uniqKey="Goble C">CA Goble</name></author><author><name sortKey="Bhagat, J" uniqKey="Bhagat J">J Bhagat</name></author><author><name sortKey="Aleksejevs, S" uniqKey="Aleksejevs S">S Aleksejevs</name></author><author><name sortKey="Cruickshank, D" uniqKey="Cruickshank D">D Cruickshank</name></author><author><name sortKey="Michaelides, D" uniqKey="Michaelides D">D Michaelides</name></author><author><name sortKey="Newman, D" uniqKey="Newman D">D Newman</name></author><author><name sortKey="Borkum, M" uniqKey="Borkum M">M Borkum</name></author><author><name sortKey="Bechhofer, S" uniqKey="Bechhofer S">S Bechhofer</name></author><author><name sortKey="Roos, M" uniqKey="Roos M">M Roos</name></author><author><name sortKey="Li, P" uniqKey="Li P">P Li</name></author><author><name sortKey="De Roure, D" uniqKey="De Roure D">D De Roure</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Droc, G" uniqKey="Droc G">G Droc</name></author><author><name sortKey="Perin, C" uniqKey="Perin C">C Périn</name></author></analytic></biblStruct><biblStruct></biblStruct><biblStruct><analytic><author><name sortKey="Shrestha, R" uniqKey="Shrestha R">R Shrestha</name></author><author><name sortKey="Arnaud, E" uniqKey="Arnaud E">E Arnaud</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Eilbeck, K" uniqKey="Eilbeck K">K Eilbeck</name></author><author><name sortKey="Lewis, S" uniqKey="Lewis S">S Lewis</name></author><author><name sortKey="Mungall, C" uniqKey="Mungall C">C Mungall</name></author><author><name sortKey="Yandell, M" uniqKey="Yandell M">M Yandell</name></author><author><name sortKey="Stein, L" uniqKey="Stein L">L Stein</name></author><author><name sortKey="Durbin, R" uniqKey="Durbin R">R Durbin</name></author><author><name sortKey="Ashburner, M" uniqKey="Ashburner M">M Ashburner</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Bizer, C" uniqKey="Bizer C">C Bizer</name></author><author><name sortKey="Schultz, A" uniqKey="Schultz A">A Schultz</name></author></analytic></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct></listBibl></div1></back></TEI><pmc article-type="product-review" xml:lang="en"><pmc-dir>properties open_access</pmc-dir>
<front><journal-meta><journal-id journal-id-type="nlm-ta">BMC Bioinformatics</journal-id><journal-id journal-id-type="iso-abbrev">BMC Bioinformatics</journal-id><journal-title-group><journal-title>BMC Bioinformatics</journal-title></journal-title-group><issn pub-type="epub">1471-2105</issn><publisher><publisher-name>BioMed Central</publisher-name></publisher></journal-meta><article-meta><article-id pub-id-type="pmid">23586394</article-id><article-id pub-id-type="pmc">3680174</article-id><article-id pub-id-type="publisher-id">1471-2105-14-126</article-id><article-id pub-id-type="doi">10.1186/1471-2105-14-126</article-id><article-categories><subj-group subj-group-type="heading"><subject>Software</subject></subj-group></article-categories><title-group><article-title>Clever generation of rich SPARQL queries from annotated relational schema: application to Semantic Web Service creation for biological databases</article-title></title-group><contrib-group><contrib contrib-type="author" corresp="yes" id="A1"><name><surname>Wollbrett</surname><given-names>Julien</given-names></name><xref ref-type="aff" rid="I1">1</xref><xref ref-type="aff" rid="I4">4</xref><email>julien.wollbrett@cirad.fr</email></contrib><contrib contrib-type="author" id="A2"><name><surname>Larmande</surname><given-names>Pierre</given-names></name><xref ref-type="aff" rid="I2">2</xref><xref ref-type="aff" rid="I4">4</xref><email>pierre.larmande@ird.fr</email></contrib><contrib contrib-type="author" id="A3"><name><surname>de Lamotte</surname><given-names>Frédéric</given-names></name><xref ref-type="aff" rid="I3">3</xref><email>lamotte@supagro.inra.fr</email></contrib><contrib contrib-type="author" corresp="yes" id="A4"><name><surname>Ruiz</surname><given-names>Manuel</given-names></name><xref ref-type="aff" rid="I1">1</xref><xref ref-type="aff" rid="I4">4</xref><email>manuel.ruiz@cirad.fr</email></contrib></contrib-group><aff id="I1"><label>1</label>CIRAD, UMR AGAP, Montpellier F-34398, France</aff><aff id="I2"><label>2</label>IRD, UMR DIADE, Montpellier, France</aff><aff id="I3"><label>3</label>INRA, UMR AGAP, Montpellier F-34398, France</aff><aff id="I4"><label>4</label>Institut de Biologie Computationnelle, 95 rue de la Galéra, 34095, Montpellier, France</aff><pub-date pub-type="collection"><year>2013</year></pub-date><pub-date pub-type="epub"><day>15</day><month>4</month><year>2013</year></pub-date><volume>14</volume><fpage>126</fpage><lpage>126</lpage><history><date date-type="received"><day>23</day><month>8</month><year>2012</year></date><date date-type="accepted"><day>25</day><month>3</month><year>2013</year></date></history><permissions><copyright-statement>Copyright © 2013 Wollbrett et al.; licensee BioMed Central Ltd.</copyright-statement><copyright-year>2013</copyright-year><copyright-holder>Wollbrett et al.; licensee BioMed Central Ltd.</copyright-holder><license license-type="open-access" xlink:href="http://creativecommons.org/licenses/by/2.0"><license-p>This is an Open Access article distributed under the terms of the Creative Commons Attribution License (<ext-link ext-link-type="uri" xlink:href="http://creativecommons.org/licenses/by/2.0">http://creativecommons.org/licenses/by/2.0</ext-link>), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</license-p></license></permissions><self-uri xlink:href="http://www.biomedcentral.com/1471-2105/14/126"></self-uri><abstract><sec><title>Background</title><p>In recent years, a large amount of “-omics” data have been produced. However, these data are stored in many different species-specific databases that are managed by different institutes and laboratories. Biologists often need to find and assemble data from disparate sources to perform certain analyses. Searching for these data and assembling them is a time-consuming task. The Semantic Web helps to facilitate interoperability across databases. A common approach involves the development of wrapper systems that map a relational database schema onto existing domain ontologies. However, few attempts have been made to automate the creation of such wrappers.</p></sec><sec><title>Results</title><p>We developed a framework, named BioSemantic, for the creation of Semantic Web Services that are applicable to relational biological databases. This framework makes use of both Semantic Web and Web Services technologies and can be divided into two main parts: <italic>(i)</italic> the generation and semi-automatic annotation of an RDF view; and <italic>(ii)</italic> the automatic generation of SPARQL queries and their integration into Semantic Web Services backbones. We have used our framework to integrate genomic data from different plant databases.</p></sec><sec><title>Conclusions</title><p>BioSemantic is a framework that was designed to speed integration of relational databases. We present how it can be used to speed the development of Semantic Web Services for existing relational biological databases. Currently, it creates and annotates RDF views that enable the automatic generation of SPARQL queries. Web Services are also created and deployed automatically, and the semantic annotations of our Web Services are added automatically using SAWSDL attributes. BioSemantic is downloadable at <ext-link ext-link-type="uri" xlink:href="http://southgreen.cirad.fr/?q=content/Biosemantic">http://southgreen.cirad.fr/?q=content/Biosemantic</ext-link>.</p></sec></abstract></article-meta></front><body><sec><title>Background</title><p>Currently, the large amount of plant high-throughput data that have been produced by different laboratories is distributed across many different crop-specific databases. Plant biologists and breeders often need to access several databases to perform tasks such as locating allelic variants for genetic markers in different crop populations and in a given environment or investigating the consequences of a mutation at the transcriptome, proteome, metabolome and phenome levels. The integration of these disparate databases would make complex analyses easier and could also reveal hidden knowledge [<xref ref-type="bibr" rid="B1">1</xref>,<xref ref-type="bibr" rid="B2">2</xref>].</p><p>However, biological data integration faces challenges because of syntactic and semantic heterogeneity. In their reviews, Stein LD [<xref ref-type="bibr" rid="B3">3</xref>] and Goble C & Stevens R [<xref ref-type="bibr" rid="B4">4</xref>] provide a fair criticism of the lack of integrated approaches and provide a similar vision for the future, which is that the Semantic Web (SW) can aid in data integration. According to the W3C, “the SW provides a common framework that allows data to be shared and reused across applications, enterprises, and community boundaries”<sup>a</sup>. The SW currently provides recommendations (RDF [<xref ref-type="bibr" rid="B5">5</xref>], SPARQL [<xref ref-type="bibr" rid="B6">6</xref>], OWL [<xref ref-type="bibr" rid="B7">7</xref>]) for enabling interoperability across databases. Furthermore, major plant databases, such as TAIR [<xref ref-type="bibr" rid="B8">8</xref>], Gramene [<xref ref-type="bibr" rid="B9">9</xref>], IRIS [<xref ref-type="bibr" rid="B10">10</xref>], MaizeGDB [<xref ref-type="bibr" rid="B11">11</xref>] and GnpIS [<xref ref-type="bibr" rid="B12">12</xref>], annotate their data using ontology terms to link different datasets and to facilitate queries across multiple databases. Guided by life science integration studies [<xref ref-type="bibr" rid="B13">13</xref>,<xref ref-type="bibr" rid="B14">14</xref>], annotating data with ontologies promotes the development of ontology-driven integration platforms [<xref ref-type="bibr" rid="B15">15</xref>,<xref ref-type="bibr" rid="B16">16</xref>].</p><p>In parallel, Web Services (WS) are becoming an increasingly popular way of establishing robust remote access to major bioinformatics resources, such as EMBL-EBI, KEGG and NCBI. WS are virtually platform-independent and are easily reusable. Indeed, analysis and data retrieval WSs can be rapidly combined and integrated into complex workflows.</p><p>The common use of the SW and WS standards has the promise of achieving integration and interoperability among the currently disparate bioinformatics resources on the Web [<xref ref-type="bibr" rid="B17">17</xref>]. There are currently existing efforts to describe Web Services with semantic annotations by using ontologies, such as SSWAP [<xref ref-type="bibr" rid="B18">18</xref>], SADI [<xref ref-type="bibr" rid="B19">19</xref>] and BioMoby [<xref ref-type="bibr" rid="B20">20</xref>]. However, none of these approaches are focused on the automation of business logic [<xref ref-type="bibr" rid="B21">21</xref>]. The implementation of new Semantic Web Services (SWS) can be time-consuming and requires the developer to know how to manipulate SW and WS standards and to have expertise on the database schema. To our knowledge, there are currently no ongoing efforts in the context of the automation of SWS creation that are both specific to relational databases and based only on W3C standards.</p><p>Our goal is to develop a framework for the creation of SWS for the field of biology by using both SW and WS technologies.</p><p>Bio-ontologies result from community reflexions in which each term and each relation are explicitly defined for an application domain. Biological data are annotated with terms from these ontologies, which add a semantic component to them. In BioSemantic, semantics is given by annotation with ontological terms of heterogeneous relational databases schema. These annotations will be used for automatic SWS creation. They will also be used to add semantics to these SWS by annotating their interfaces (input and output).</p><p>To make the process of WS development as easy as possible, we have developed a semi-automated framework to accelerate the development of SPARQL queries for relational databases. These queries are automatically added to SWS backbones allowing an easier integration of distributed relational databases. This article focuses on biological relational databases, but because of using only SW and WS standards, BioSemantic can potentially be applied to other science fields.</p></sec><sec><title>System and methods</title><sec><title>BioSemantic framework overview</title><p>The overall architecture of the BioSemantic framework is shown in Figure <xref ref-type="fig" rid="F1">1</xref>. One advantage of this architecture is that its decoupling takes place in two different steps, which might be achieved by different user profiles. In the first step, the data provider must publish the schema of its relational database. First, the local RDF view of the database schema is automatically created for each relational database to be integrated. Then, the RDF view must be manually annotated by experts with terms from existing bio-ontologies. The RDF views, both created and annotated, are stored in an RDF repository. Once the RDF view is available, the second step is the creation of the SWS. This step is uncoupled from the first step and could be realised by a data consumer without any knowledge of the database schema. The previous semantic annotations of RDF views are used to automatically create SWS containing SPARQL queries and to use the bio-ontological terms as input/output. SWS are then stored in a Semantic Web Services repository, from which they can be easily detected by clients. These clients can use the SWS as wrappers to overstep the heterogeneity of the relational databases.</p><fig id="F1" position="float"><label>Figure 1</label><caption><p><bold>Global architecture of the BioSemantic framework.</bold> The first contribution of our work is the automatic creation of an RDF view containing RDF metadata, which is necessary for the automatic creation of Semantic Web Services. The second contribution is the automatic creation and deployment of Semantic Web Services.</p></caption><graphic xlink:href="1471-2105-14-126-1"></graphic></fig><p>We will detail below the entire process for generating a BioSemantic SWS, which can be divided into two main parts: <italic>(i)</italic> the generation and semi-automatic annotation of an RDF view (Figure <xref ref-type="fig" rid="F2">2</xref>) and <italic>(ii)</italic> the automatic generation of the SWS (Figure <xref ref-type="fig" rid="F3">3</xref>).</p><fig id="F2" position="float"><label>Figure 2</label><caption><p><bold>Generation and semi-automatic annotation of the RDF view.</bold> D2RQ creates the D2RQ mapping file, and our BioSemantic API automatically adds new metadata about the database schema. Finally, the mapping file is stored in a repository. Annotation with bio-ontological terms is performed manually by an expert.</p></caption><graphic xlink:href="1471-2105-14-126-2"></graphic></fig><fig id="F3" position="float"><label>Figure 3</label><caption><p><bold>Automatic generation of Semantic Web Services.</bold> The Web Services developer selects the bio-ontological terms to be used as input/output. All of the mapping files, which are stored in the mapping file repository, are automatically parsed to find a path linking the input and output ontological terms. If such a path is found, it is used to create a SPARQL query. The query is integrated into a semantic Web Service that is then registered in a Web Service registry, such as BioCatalogue.</p></caption><graphic xlink:href="1471-2105-14-126-3"></graphic></fig></sec><sec><title>Generation and semi-automatic annotation of an RDF view</title><sec><title>Relational database-to-RDF mapping</title><p>The research in the domain of mapping between databases and ontologies is very active and corresponds to various motivations and approaches [<xref ref-type="bibr" rid="B22">22</xref>]. In BioSemantic, we use the mapping as an intermediate layer between the user and the stored data. This layer provides an abstraction of the database and allows the user to query databases without knowledge of the database schema. These characteristics correspond to the motivation known as “data access based on ontology”. For that purpose, we found only two tools that strictly use SW standards: Virtuoso [<xref ref-type="bibr" rid="B23">23</xref>] and D2RQ [<xref ref-type="bibr" rid="B24">24</xref>-<xref ref-type="bibr" rid="B26">26</xref>]. We have chosen D2RQ because this tool is open source, easy to use and all of the needed functionalities are free. In addition, some bioinformatics projects have successfully used D2RQ. With D2RQ, we can automatically generate a mapping file that provides an RDF view of the database schema.</p></sec><sec><title>RDF view description</title><p>The RDF view created by D2RQ can be seen as a mediator of a mediation system. It is used as an interface between the local schema of a database and the global schema defined by bio-ontologies. It is possible to detect all of the heterogeneous RDF views that are annotated with the same ontological term and then retrieve data from corresponding relational databases.</p><p>The RDF view generated by D2RQ contains the elements of the database schema: entities, attributes, keys (primary, foreign) and metadata, such as the database driver and host. The data contained in the relational databases are not included in the RDF view. Instances are retrieved directly from the databases. D2RQ API uses metadata from the RDF views to connect to the databases and to retrieve instances from them. The RDF view is queried with a SPARQL query; then, the D2RQ API transforms this query into an equivalent SQL query. Thus, there is no problem with keeping data up-to-date because the data are not physically exported.</p><p>In the RDF view, the database schema is represented by a graph. Each node corresponds to an entity or attribute in the database, and each edge defines a relationship between two nodes. In RDF format, namespaces are used to uniquely identify each node. Namespaces provide a prefix for each node name. For example, the <italic>map:marker</italic> node (Figure <xref ref-type="fig" rid="F4">4</xref>) indicates the “marker” concept from the “map” vocabulary used by D2RQ to uniquely identify one RDF view and to map relational elements to the RDF view.</p><fig id="F4" position="float"><label>Figure 4</label><caption><p><bold>Graph-based representation of annotated RDF views.</bold> Each graph is the RDF representation of some part of a relational database. The <italic>d2rq:belongsToClassMap</italic> property links a column to a table. The <italic>d2rq:primaryKey</italic> property defines the primary key of a table. The <italic>d2rq:property</italic> property links a node to a semantic annotation. The columns <italic>marker_name</italic>, from the table <italic>marker</italic>, and <italic>snp_name</italic>, from the table <italic>snp</italic>, are both annotated with the same term: <italic>genomicFeatureDetector</italic> from the GCP domain model ontology [<xref ref-type="bibr" rid="B27">27</xref>].</p></caption><graphic xlink:href="1471-2105-14-126-4"></graphic></fig></sec><sec><title>Automatic semantic enrichment of the RDF view with BioSemantic</title><p>The BioSemantic API automatically detects specific information related to the relational database schema and translates it into new properties that can be integrated into the RDF view. These metadata are then used for SPARQL query generation. This step can be seen as a semantic enrichment of the RDF view.</p><p>1. <italic>Association tables</italic></p><p>For this purpose, we have developed an algorithm that detects association tables.<disp-formula><graphic xlink:href="1471-2105-14-126-i1.gif"></graphic></disp-formula></p><p>2. <italic>Arity</italic></p><p>We can also detect the arity of association tables, i.e., the number of foreign keys that they possess. The algorithm labels association tables in the RDF view with the <italic>dr:associatedTo</italic> property and indicates the arity with the <italic>dr:arity</italic> property (Figure <xref ref-type="fig" rid="F5">5</xref>).</p><p>3. <italic>Inheritance, aggregation and composition</italic></p><fig id="F5" position="float"><label>Figure 5</label><caption><p><bold>Classification of the database table relationships.</bold> Each light node represents a table of the relational database. Here, we only show the tables, and the columns are not represented. The dark nodes represent the semantic annotations. Each edge represents a property that is shared between 2 nodes. The new properties added by our method, <italic>dr:associatedTo</italic>, <italic>dr:arity</italic> and <italic>rdf:subClassOf</italic>, are indicated in bold.</p></caption><graphic xlink:href="1471-2105-14-126-5"></graphic></fig><p>There are many ways to transform inheritance relationships from an object-oriented conceptual model to a relational model [<xref ref-type="bibr" rid="B28">28</xref>]. For our algorithm, we detect relationships that result from the transformation of each class in an inheritance hierarchy into a table. We also detect tables that result from aggregation or composition relationships by using the identifying algorithm from [<xref ref-type="bibr" rid="B29">29</xref>]. We label these relationships in the RDF view with the <italic>rdf:subClassOf</italic> property (Figure <xref ref-type="fig" rid="F5">5</xref>).</p></sec><sec><title>Manual annotation with bio-ontological terms</title><p>The D2RQ language allows elements of the mapping file to be annotated with bio-ontological terms, which can be interpreted as semantic flags. Such flags can be used directly to query the relational database without any prior knowledge of the database schema or can be used to locate corresponding elements across databases (Figure <xref ref-type="fig" rid="F4">4</xref>). The annotation of the RDF view is performed manually by adding triples to the RDF view using a text editor and must be conducted by an expert familiar with both the database and the bio-ontology. In the plant biology domain, some ontologies are implemented in OBO format and do not provide URLs, in contrast to OWL ontologies. For this reason, the terms used to annotate the RDF view can be explained as URIs that do not resolve. Nevertheless, according to W3C standard it is recommended to use URLs that resolve.</p></sec></sec><sec><title>Automatic generation of the Semantic Web Service</title><p>Semantic annotations are used to select the inputs and outputs of a query. We can find a path in one RDF view by linking the inputs to the outputs. If such a path is found in the RDF view, then it is used to create a SPARQL query. To automate the creation of SPARQL queries, we implement an algorithm that is a single-pair variant of the shortest-path algorithm. Given an input graph, a source node and a destination node, the algorithm returns a path linking the two nodes through the graph. We add conditions to our shortest-path algorithm according to the types of relationships between the nodes, which can be either of the following: <italic>(i)</italic> relationships that correspond to association tables; or <italic>(ii)</italic> relationships that result from inheritance, aggregation, or composition in an object-oriented conceptual model. These conditions correspond to the metadata that is added to the RDF view during the automatic semantic enrichment step that is taken by the BioSemantic API.</p><sec><title>Shortest-path algorithm with conditions</title><p>We parse the RDF view as though it were a graph, to find the shortest path linking two bio-ontological terms. These terms correspond to those selected as input and output for our WS.</p><p>We use a shortest-path detection approach based on the Dijkstra algorithm [<xref ref-type="bibr" rid="B30">30</xref>]. We add conditions to the weight path costs according to the properties classified in the previous step. In the weighting, we favour paths that correspond to binary associations. For the shortest paths that correspond to the <italic>rdf:subClassOf</italic> property (inheritance, aggregation or composition), we aggregate the different paths found. For example, in Figure <xref ref-type="fig" rid="F5">5</xref>, the <italic>rdf:subClassOf</italic> property allows a study to be considered a <italic>genotypingStudy</italic> or a <italic>phenotypingStudy</italic>. The data recorded in these two tables are complementary and are non-redundant. Indeed, the path linking <italic>gcpdm:study</italic> to <italic>gcpdm:germplasm</italic> is the combination of both paths:</p><p><bold><italic><underline>Path 1:</underline></italic></bold><italic>map:study- > map:genotypingstudy- > map:dnasamplegenotypingstudy</italic></p><p>- > map:dnasample- > map:germplasm</p><p><bold><italic><underline>Path 2</underline></italic></bold><bold><italic>:</italic></bold><italic>map:study- > map:phenotypingstudy- > map:germplasmphenotypingstudy</italic></p><p>- > map:germplasm</p><p>These paths are not stored; instead, they are dynamically detected and are used to create a SPARQL query.</p></sec><sec><title>Generation of SPARQL queries</title><p>The detected path contains all of the information that is required for the automatic creation of a SPARQL query. For a given set of input/output bio-ontological terms and a given RDF view, only one SPARQL query can be created. The query below corresponds to the link between <italic>gcpdm:study</italic> and <italic>gcpdm:germplasm</italic>. <italic>SELECT DISTINCT ?study_name ?germplasm_name WHERE {</italic></p><p>?study_id gcpdm:study ?study_name.</p><p>FILTER regex(?study_name,“^name_of_the_study$”).</p><p>{</p><p>?genotypestudy_id vocab:genotypingstudy_id_study ?study_id.</p><p>?key vocab:dnasamplegenotypingstudy_id_genotypingstudy ?genotypestudy_id.</p><p>?key vocab:dnasamplegenotypingstudy_id_dnasample ?dnasample.</p><p><italic>?dnasample vocab:dnasample_id_germplasm ?germplasm_id.</italic> <bold><italic><underline>Path 1</underline></italic></bold></p><p>?germplasm_id gcpdm:germplasm ?germplasm_name.</p><p>}</p><p>UNION {</p><p>?phenotypestudy_id vocab:phenotypingstudy_id_study ?study_id.</p><p>?key vocab:germplasmphenotypingstudy_id_phenotypingstudy ?phenotypestudy_id.</p><p><italic>?key vocab:germplasmphenotypingstudy_id_germplasm ?germplasm_id.</italic> <bold><italic><underline>Path 2</underline></italic></bold></p><p>?germplasm_id gcpdm:germplasm ?germplasm_name.</p><p>}</p><p>}</p><p>The first line of the query defines the attributes that correspond to the input and output of the WS. The third line is always a FILTER condition. This filter applies to the input attribute, which can be a literal or a regular expression. In our example, it is possible to retrieve the names of the germplasms that are used in a study by using names that begin with A and the regular expression “A.*”.</p></sec><sec><title>Automatic creation of the Semantic Web Service</title><p>The SPARQL query is automatically integrated into a WS template. The WS is annotated with the bio-ontological terms previously selected as input and output for the query. According to the recommendations of the EMBRACE project [<xref ref-type="bibr" rid="B31">31</xref>] and the W3C, we use the Semantic Annotations for WSDL (SAWSDL) [<xref ref-type="bibr" rid="B32">32</xref>] to add semantic annotations to the WSDL (Web Services Description Language) components. The use of SAWSDL offers three main advantages: <italic>(i)</italic> it is compatible with the WSDL standard; <italic>(ii)</italic> it is lighter than other computing standards (i.e., WSMO (Web Service Modeling Ontology) and WSDL-S (Web Service Semantics)); and <italic>(iii)</italic> it is recommended by the W3C. Indeed, the input/output of our SWS are annotated using the <italic>sawsdl:modelReference</italic> attribute, specifying the association between an WSDL component and a bio-ontological term (Figure <xref ref-type="fig" rid="F6">6</xref>).</p><fig id="F6" position="float"><label>Figure 6</label><caption><p><bold>SAWSDL annotation.</bold> The semantic annotation is represented in bold and tags the input of our Semantic Web Service with the GCP_GenotypeStudy term from the GCP domain model ontology.</p></caption><graphic xlink:href="1471-2105-14-126-6"></graphic></fig><p>One SWS is created for each detected SPARQL query. All of the SWS annotated with the same input/output concepts can be easily detected and used for data integration. After the SWS is created, it can be registered in Web Service registries, such as BioCatalogue [<xref ref-type="bibr" rid="B33">33</xref>].</p></sec></sec></sec><sec><title>Implementation</title><p>Our method is implemented in Java. The RDF views are created using the d2rq 0.7 library, and the RDF files are parsed using the Jena 2.5.7 library. The SWS are automatically deployed on a Tomcat 6.0 server using Axis2.</p></sec><sec sec-type="results"><title>Results</title><sec><title>Use case</title><p>We have created a use case integrating <italic>Oryza sativa</italic> (rice) data from distributed relational databases: Gramene [<xref ref-type="bibr" rid="B9">9</xref>], TropGene [<xref ref-type="bibr" rid="B34">34</xref>] and Ensembl [<xref ref-type="bibr" rid="B35">35</xref>]. Both the Gramene and TropGene databases have QTL data associated with traits, and these traits can be associated with concepts from the Trait Ontology. We wanted to compare the rice QTLs from the two resources, Gramene and TropGene, and to extract related genomic annotations from the Ensembl rice module.</p><p>We first used BioSemantic to create the SWS. We then used Taverna [<xref ref-type="bibr" rid="B4">4</xref>] to create a workflow by connecting BioSemantic SWS with external public WS. In this manner, we could verify the compatibility of BioSemantic SWS with standard WSDL WS. To increase the speed of querying over huge tables, we used a local copy of the Markers tables of Gramene; however, our example performed adequately using a remote access to the Gramene public database.</p><p>All automatic steps can be performed directly on the BioSemantic Web user interface (Figure <xref ref-type="fig" rid="F7">7</xref>).</p><fig id="F7" position="float"><label>Figure 7</label><caption><p><bold>BioSemantic form for automatic D2RQ RDF view creation.</bold> For RDF view creation, the user must fill in all fields of the form. The left menu, known as “Actions”, contains all available BioSemantic actions.</p></caption><graphic xlink:href="1471-2105-14-126-7"></graphic></fig><sec><title>Steps involving SWS creation and using the BioSemantic Web user interface</title><p>A simple form must be completed to configure database access and to automatically create RDF views for the TropGene and Gramene databases (Figure <xref ref-type="fig" rid="F7">7</xref>). The RDF views can then be downloaded to perform semantic annotations. In our example, we annotated RDF views using one concept from the EDAM ontology [<xref ref-type="bibr" rid="B31">31</xref>]. The elements of the RDF views were annotated with the same ontological concept, known as edam:1093. For readability, we choose to represent this concept by its name edam:sequence_accession in our example. This annotation is added to triples corresponding to the `marker`.`name` column of the RDF View of TropGene. The annotation is represented below in bold type.</p><p>map:marker_name a d2rq:PropertyBridge;</p><p>d2rq:column "marker.name";</p><p><italic>d2rq:property edam:sequence_accession;</italic></p><p>d2rq:belongsToClassMap map:marker;</p><p>An annotation with the same term is added to triples corresponding to the `marker`.marker_acc` column of Gramene. The annotation is represented below in bold type.</p><p>map:marker_marker_acc a d2rq:PropertyBridge;</p><p>d2rq:column "marker.marker_acc";</p><p><italic>d2rq:property edam:sequence_accession;</italic></p><p>d2rq:belongsToClassMap map:marker;</p><p>The same ontological term is then used to annotate different database schemas. The BioSemantic Web interface allows users to upload the annotated RDF views to visualise the list of available RDF views in the repository, to download one of the views in order to view/add/modify annotations and to visualise the list of ontology and concept terms currently used into the RDF repository. This interface also allows users to automatically add BioSemantic annotations to a pre-existing D2RQ RDF view. Some projects use D2RQ, which means that some RDF views are currently annotated with domain ontologies. This functionality allows users to return these RDF views to BioSemantic compatibility without manual steps.</p><p>After selection of the input/output bio-ontological terms (Figure <xref ref-type="fig" rid="F8">8</xref>), the BioSemantic application displays the list of RDF views containing these annotations (the red box in Figure <xref ref-type="fig" rid="F9">9</xref>). The checkbox before the name of an RDF view allows the user to select the SWS that he would like to create. By clicking on the radio button, the corresponding SPARQL query is displayed. It is then possible to validate the automatically generated query or to modify it (e.g., add more filters). A simple click on a button then creates SWS files and deploys them.</p><fig id="F8" position="float"><label>Figure 8</label><caption><p><bold>BioSemantic form for input/output concept selection.</bold> These concepts will be used to detect a path and to annotate the input/output of the SWS. The user can only select the prefix and concepts used to annotate a previously registered RDF view.</p></caption><graphic xlink:href="1471-2105-14-126-8"></graphic></fig><fig id="F9" position="float"><label>Figure 9</label><caption><p><bold>BioSemantic form for RDF view selection and query visualisation/edition.</bold> The red rectangle contains the name of the RDF views annotated with both input/output concepts. The checkbox before each name allows for the selection of a view for SWS creation. The radio button after the name of an RDF view allows for query visualisation/edition. When all desired RDF views are selected, a simple click creates the SWS.</p></caption><graphic xlink:href="1471-2105-14-126-9"></graphic></fig></sec><sec><title>Workflow creation</title><p>BioSemantic SWS can be obtained directly with their WSDL localisation. In this use case, we chose to compose SWS as a workflow in Taverna. Taverna makes it possible to easily create a workflow, to visualise the progress of the running workflow and to save the workflow for the purpose of sharing it.</p><p>Our workflow (Figure <xref ref-type="fig" rid="F10">10</xref>) contains 7 BioSemantic SWS (green boxes). Yellow and purple boxes correspond to bricks that transform the inputs/outputs of the SWS and then allow for composition. For a given trait and QTL maximum size, BioSemantic SWS retrieve the Gramene and TropGene accession numbers of the QTLs along with their mapping positions in <italic>Oryza sativa</italic>. We have created a Beanshell Taverna brick (orange box) to retrieve the Gramene and TropGene QTLs that are mapped in the same genomic region. Two other bricks allow for the compatibility of the BioSemantic SWS with the Ensembl BioMart WSs. Indeed, we added Ensembl BioMart WS (blue boxes) to retrieve genes that are present in the mapping genomic interval of a given QTL. The yellow and purple boxes are shims that are added in Taverna. The purples boxes allow Taverna to manipulate BioSemantic SWS input. They are created automatically by Taverna. The yellow boxes are XPath expressions that allow Taverna to be compatible with BioSemantic SWS output. All of the yellow boxes are identical, and their creation is fast. However, the presence of these shims does not allow automation of BioSemantic SWS compositions.</p><fig id="F10" position="float"><label>Figure 10</label><caption><p><bold>Use case workflow created with Taverna 2.</bold> The workflow contains BioSemantic SWS querying for both the TropGene and Gramene databases for QTL information retrieval and also contains BioMart WS querying EnSembl for gene information retrieval. This workflow also detects QTLs from TropGene and Gramene when both are annotated with the same TO term and have the same mapping position.</p></caption><graphic xlink:href="1471-2105-14-126-10"></graphic></fig><p>In brief, our workflow retrieves the following rice information from TropGene, Gramene and Ensembl:</p><p>Accession number of the QTLs associated with a given trait,</p><p>Pair-based position of the mapping of these QTLs,</p><p>All of the genes in the mapping interval of a given QTL, and</p><p>QTLs with a common mapping position between TropGene and Gramene.</p><p>This workflow can be downloaded in my Experiment [<xref ref-type="bibr" rid="B36">36</xref>].</p></sec></sec><sec><title>Available Semantic Web Services</title><p>We developed other SWS for our own databases, including TropGene and OryGenesDB, a database of functional rice genomics data [<xref ref-type="bibr" rid="B37">37</xref>], as well as from external databases such as Gramene and SINGER [<xref ref-type="bibr" rid="B38">38</xref>], a multi-crop germplasm database. We annotated the database schemas with concepts from the Crop Ontology [<xref ref-type="bibr" rid="B39">39</xref>], the GCP Domain Model [<xref ref-type="bibr" rid="B15">15</xref>], the Sequence Ontology [<xref ref-type="bibr" rid="B40">40</xref>] and the EDAM ontology [<xref ref-type="bibr" rid="B31">31</xref>]. Some of these generated WS are available in the BioCatalogue (Figures <xref ref-type="fig" rid="F11">11</xref> and <xref ref-type="fig" rid="F12">12</xref>).</p><fig id="F11" position="float"><label>Figure 11</label><caption><p>General information about the GetTropgeneMarkerSPARQL Web Service registered in the BioCatalogue.</p></caption><graphic xlink:href="1471-2105-14-126-11"></graphic></fig><fig id="F12" position="float"><label>Figure 12</label><caption><p><bold>BioCatalogue input/output annotations for the GetTropgeneMarkerSPARQL semantic Web Service.</bold> Our bio-ontological terms correspond to the input/output tags in the BioCatalogue.</p></caption><graphic xlink:href="1471-2105-14-126-12"></graphic></fig></sec><sec><title>Benchmarks</title><p>With regard to automatically generated SPARQL queries, we are aware that, in some cases, there are multiple possible paths, each of which can be semantically valid depending on the query semantics. Our system identifies the “best” shortest-path with conditions favouring binary table associations and combines the paths corresponding to inheritance, aggregation and composition. However, a manual validation test for the automatically generated SWS is still recommended. Indeed, the SWS that we generated and tested were all validated by the database managers and/or users. Regardless of the validation ability, the main benefit of our platform is that it enables the rapid creation of new and easily detectable SWS.</p><sec><title>SPARQL query generation</title><p>We have tested the speed of SPARQL query generation with two different biological databases: <italic>(i)</italic> TropGene, a relational database that contains 90 tables and 15 million records; and <italic>(ii)</italic> OryGenesDB, which contains 11 tables and 22 million records. Although SPARQL query generation is only performed during the first step of Web SWS generation and not during the SWS execution, we also measured the time required for this step. This time depends on the database schema but also strongly depends on the presence of inheritance relationships (Table <xref ref-type="table" rid="T1">1</xref>). In this table, when inheritance relationships are present, we include the lengths of the paths to be aggregated. The creation of a query without inheritance relationships takes less than 2 seconds. However, creating a query using the same database schema with 4 inheritance relationships takes 15 seconds. In general, complex SPARQL queries can be created in a matter of seconds.</p><table-wrap position="float" id="T1"><label>Table 1</label><caption><p>Estimating the time required for SPARQL query creation</p></caption><table frame="hsides" rules="groups" border="1"><colgroup><col align="center"></col><col align="center"></col><col align="center"></col><col align="center"></col></colgroup><thead valign="top"><tr><th align="center"><bold>Number of tables</bold></th><th align="center"><bold>Inheritance relationship</bold></th><th align="center"><bold>Length of the path</bold></th><th align="center"><bold>Time (seconds, ± 0.1)</bold></th></tr></thead><tbody valign="top"><tr><td align="center" valign="bottom">11<hr></hr></td><td align="center" valign="bottom">no<hr></hr></td><td align="center" valign="bottom">2 nodes<hr></hr></td><td align="center" valign="bottom">1.2<hr></hr></td></tr><tr><td align="center" valign="bottom">90<hr></hr></td><td align="center" valign="bottom">no<hr></hr></td><td align="center" valign="bottom">4 nodes<hr></hr></td><td align="center" valign="bottom">2.0<hr></hr></td></tr><tr><td align="center">90</td><td align="center">yes</td><td align="center">4-3-2-6 nodes</td><td align="center">14.6</td></tr></tbody></table></table-wrap></sec><sec><title>SPARQL query execution</title><p>The time required for query execution varies significantly for different databases and strongly depends on the number of records to be retrieved. Table <xref ref-type="table" rid="T2">2</xref> compares the time required for SQL query execution and SPARQL query execution. We did not compare with the time required for the querying RDF dump of a relational database because some databases can contain more than 100 million tuples. The RDF dump will then contain more than 100 million triples, and triplestore query performances decrease with the number of triples. When the triplestore contains more than 100 million triples, SPARQL to SQL approaches are fastest [<xref ref-type="bibr" rid="B41">41</xref>]. The time required for SQL query execution was measured in Eclipse using the <italic>java.sql</italic> library. The time required for SPARQL query execution was measured using the AJAX-based SPARQL Explorer tool of the D2R Server.</p><table-wrap position="float" id="T2"><label>Table 2</label><caption><p>Comparison of the time required for SQL and SPARQL query execution</p></caption><table frame="hsides" rules="groups" border="1"><colgroup><col align="center"></col><col align="center"></col><col align="center"></col><col align="center"></col><col align="center"></col><col align="center"></col></colgroup><thead valign="top"><tr><th align="center"><bold>Number of tables</bold></th><th align="center"><bold>Inheritance relationship</bold></th><th align="center"><bold>Length of the path</bold></th><th align="center"><bold>Number of results</bold></th><th align="center"><bold>SQL query (seconds, ± 0.1)</bold></th><th align="center"><bold>SPARQL query in D2R Server (seconds, ± 0.1)</bold></th></tr></thead><tbody valign="top"><tr><td align="center" valign="bottom">90<hr></hr></td><td align="center" valign="bottom">no<hr></hr></td><td align="center" valign="bottom">4<hr></hr></td><td align="center" valign="bottom">860<hr></hr></td><td align="center" valign="bottom">0.4<hr></hr></td><td align="center" valign="bottom">1.4<hr></hr></td></tr><tr><td align="center" valign="bottom">90<hr></hr></td><td align="center" valign="bottom">no<hr></hr></td><td align="center" valign="bottom">4<hr></hr></td><td align="center" valign="bottom">1456<hr></hr></td><td align="center" valign="bottom">0.4<hr></hr></td><td align="center" valign="bottom">1.4<hr></hr></td></tr><tr><td align="center" valign="bottom">90<hr></hr></td><td align="center" valign="bottom">no<hr></hr></td><td align="center" valign="bottom">2<hr></hr></td><td align="center" valign="bottom">2055<hr></hr></td><td align="center" valign="bottom">0.8<hr></hr></td><td align="center" valign="bottom">2.3<hr></hr></td></tr><tr><td align="center" valign="bottom">90<hr></hr></td><td align="center" valign="bottom">yes<hr></hr></td><td align="center" valign="bottom">4-3-2-6<hr></hr></td><td align="center" valign="bottom">8071<hr></hr></td><td align="center" valign="bottom">1.1<hr></hr></td><td align="center" valign="bottom">4.2<hr></hr></td></tr><tr><td align="center">90</td><td align="center">no</td><td align="center">3</td><td align="center">12302</td><td align="center">2.3</td><td align="center">4.8</td></tr></tbody></table></table-wrap><p>The SPARQL approach takes approximately 3-4 times longer to access data than a direct SQL query, but users can still retrieve more than 5000 results in a few seconds. The time required to display the SPARQL results in the AJAX-based SPARQL Explorer accounts, in part, for the differences in performance. Most of the overhead, however, comes from the transformation of SPARQL queries into SQL queries, which is performed using the D2RQ engine.</p></sec><sec><title>Semantic Web Services execution</title><p>Table <xref ref-type="table" rid="T3">3</xref> compares the time required for SWS execution using manually created SQL WS and our automatically generated SPARQL SWS. These Web Services query the TropGene database. Although manually created WS are faster than our automatically created SWS, the difference is not dramatic enough to affect the usability of our SWS.</p><table-wrap position="float" id="T3"><label>Table 3</label><caption><p>Comparison of the time required for Web Service execution using the SQL Web Services and automatically generated using the SPARQL Web Services</p></caption><table frame="hsides" rules="groups" border="1"><colgroup><col align="center"></col><col align="center"></col><col align="center"></col><col align="center"></col></colgroup><thead valign="top"><tr><th align="center"><bold>Query</bold></th><th align="center"><bold>Number of results</bold></th><th align="center"><bold>SQL Web Services (seconds, ± 0.1)</bold></th><th align="center"><bold>SPARQL Web Services (seconds, ± 0.1)</bold></th></tr></thead><tbody valign="top"><tr><td align="center" valign="bottom">retrieves genotyping studies<hr></hr></td><td align="center" valign="bottom">7<hr></hr></td><td align="center" valign="bottom">0.2<hr></hr></td><td align="center" valign="bottom">1.0<hr></hr></td></tr><tr><td align="center" valign="bottom">retrieves germplasms for selected studies<hr></hr></td><td align="center" valign="bottom">860<hr></hr></td><td align="center" valign="bottom">0.4<hr></hr></td><td align="center" valign="bottom">1.0<hr></hr></td></tr><tr><td align="center">retrieves markers for selected studies</td><td align="center">1456</td><td align="center">0.4</td><td align="center">1.0</td></tr></tbody></table></table-wrap></sec><sec><title>Validation of the SPARQL query results</title><p>We compared the data retrieval resulting from the three approaches (i.e., the Dijkstra algorithm, BioSemantic and a human SQL query builder) (Table <xref ref-type="table" rid="T4">4</xref>). We refer to a human SQL query as a query that is manually written by an expert with good knowledge of the database schema. A first general observation demonstrates that the number of results is identical for BioSemantic queries and the manual SQL queries. BioSemantic globally retrieves more results than the Dijkstra algorithm. The gap for Query1 is explained because of the inheritance relationships missed by the Dijkstra algorithm. Indeed, in that case, BioSemantic detects these relationships and regroups the subdivided paths into the final query. Furthermore, BioSemantic preferentially selects binary association tables that promote more data retrieval. Both Query2 and Query3 correspond to a short path without inheritance but with several paths having the same node numbers. In that case, weighting the BioSemantic path favours binary associations, whereas the Dijkstra algorithm chooses the first detected path having a minimum node number. For Query2, BioSemantic favours the detection of a more pertinent path, whereas the same paths are detected for Query3. For Query4, no equivalent path guides to the same results; in other words, both algorithms select the same path. In each case, we manually verified that the retrieved data were identical.</p><table-wrap position="float" id="T4"><label>Table 4</label><caption><p>Comparing the number of retrieved data from the three approaches: Dijkstra algorithm, BioSemantic and human SQL query builder</p></caption><table frame="hsides" rules="groups" border="1"><colgroup><col align="left"></col><col align="left"></col><col align="left"></col><col align="right"></col><col align="right"></col><col align="right"></col></colgroup><thead valign="top"><tr><th align="left"> </th><th align="left"><bold>Inheritance</bold></th><th align="left"><bold>Equivalent paths</bold></th><th align="right"><bold>Dijkstra</bold></th><th align="right"><bold>BioSemantic</bold></th><th align="right"><bold>Manual SQL</bold></th></tr></thead><tbody valign="top"><tr><td align="left" valign="bottom">Query 1<hr></hr></td><td align="left" valign="bottom">yes<hr></hr></td><td align="left" valign="bottom">no<hr></hr></td><td align="right" valign="bottom">1595<hr></hr></td><td align="right" valign="bottom">7212<hr></hr></td><td align="right" valign="bottom">7212<hr></hr></td></tr><tr><td align="left" valign="bottom">Query 2<hr></hr></td><td align="left" valign="bottom">no<hr></hr></td><td align="left" valign="bottom">yes<hr></hr></td><td align="right" valign="bottom">0<hr></hr></td><td align="right" valign="bottom">12302<hr></hr></td><td align="right" valign="bottom">12302<hr></hr></td></tr><tr><td align="left" valign="bottom">Query 3<hr></hr></td><td align="left" valign="bottom">no<hr></hr></td><td align="left" valign="bottom">yes<hr></hr></td><td align="right" valign="bottom">197<hr></hr></td><td align="right" valign="bottom">197<hr></hr></td><td align="right" valign="bottom">197<hr></hr></td></tr><tr><td align="left">Query 4</td><td align="left">no</td><td align="left">no</td><td align="right">2055</td><td align="right">2055</td><td align="right">2055</td></tr></tbody></table></table-wrap></sec><sec><title>Comparison with other SWS platforms</title><p>We compared BioSemantic with other SWS platforms, such as BioMoby [<xref ref-type="bibr" rid="B20">20</xref>], SADI [<xref ref-type="bibr" rid="B19">19</xref>] and SSWAP [<xref ref-type="bibr" rid="B18">18</xref>] (Table <xref ref-type="table" rid="T5">5</xref>). BioMoby adds semantic components to WSs by using an XML datatype ontology developed by WS developers. SSWAP is based on a five-class ontology allowing the definition of Web resources, inputs and outputs of the SWS, data structures and data providers. SADI is a set of fully standard-compliant SWS design patterns that simplify their publication. A SADI plugin has been developed. This plugin helps users to discover SADI SWS and to automatically compose them in workflows.</p><table-wrap position="float" id="T5"><label>Table 5</label><caption><p>Comparison with other SWS platforms</p></caption><table frame="hsides" rules="groups" border="1"><colgroup><col align="left"></col><col align="left"></col><col align="left"></col><col align="left"></col><col align="left"></col><col align="left"></col><col align="left"></col><col align="left"></col></colgroup><thead valign="top"><tr><th align="left"> </th><th align="left"><bold>Semantic Web Standard</bold></th><th align="left"><bold>Annotations</bold></th><th align="left"><bold>WSDL compliant</bold></th><th align="left"><bold>Platform specific</bold></th><th align="left"><bold>Reasoner</bold></th><th align="left"><bold>Creation/ deployment</bold></th><th align="left"><bold>Query creation</bold></th></tr></thead><tbody valign="top"><tr><td align="left" valign="bottom"><bold>BioMoby</bold><hr></hr></td><td align="left" valign="bottom">no<hr></hr></td><td align="left" valign="bottom">XML<hr></hr></td><td align="left" valign="bottom">yes<hr></hr></td><td align="left" valign="bottom">yes<hr></hr></td><td align="left" valign="bottom">no<hr></hr></td><td align="left" valign="bottom">semi-automatic<hr></hr></td><td align="left" valign="bottom">manual<hr></hr></td></tr><tr><td align="left" valign="bottom"><bold>SSWAP</bold><hr></hr></td><td align="left" valign="bottom">yes<hr></hr></td><td align="left" valign="bottom">OWL<hr></hr></td><td align="left" valign="bottom">no<hr></hr></td><td align="left" valign="bottom">yes<hr></hr></td><td align="left" valign="bottom">yes<hr></hr></td><td align="left" valign="bottom">manual<hr></hr></td><td align="left" valign="bottom">manual<hr></hr></td></tr><tr><td align="left" valign="bottom"><bold>SADI</bold><hr></hr></td><td align="left" valign="bottom">yes<hr></hr></td><td align="left" valign="bottom">OWL<hr></hr></td><td align="left" valign="bottom">yes<hr></hr></td><td align="left" valign="bottom">no<hr></hr></td><td align="left" valign="bottom">yes<hr></hr></td><td align="left" valign="bottom">semi-automatic<hr></hr></td><td align="left" valign="bottom">manual<hr></hr></td></tr><tr><td align="left"><bold>BioSemantic</bold></td><td align="left">yes</td><td align="left">SAWSDL</td><td align="left">yes</td><td align="left">no</td><td align="left">no</td><td align="left">automatic</td><td align="left">automatic</td></tr></tbody></table></table-wrap><p>In this comparison, we focused on the ability to create and use SWS because the other SWS approaches are not placed in the context of the automated creation of wrappers for relational databases.</p><p>We compared seven criteria: i) the exclusive use of SW standards; ii) the types of input and output annotation for SWS; iii) the compliance with SOAP/WSDL; iv) the constraint for clients to be platform specific; v) the ability of the platform to perform reasoning; vi) the degree of automation in the creation and deployment of SWS; and vii) the degree of automation of the query building.</p><p>All of the compared approaches use SW standards except for BioMoby, in which semantics come from the data type stored in an XML tree. In terms of output, SADI and SSWAP are based on OWL, and both developed their own SWS API to exploit OWL’s reasoning capabilities. BioSemantic uses the standard SAWSDL to semantically annotate the WSDL files.</p><p>BioMoby, SADI and BioSemantic are compliant with SOAP/WSDL protocols. Some of the approaches are platform specific (i.e., SSWAP and BioMoby), meaning that they require their own environment to process SWS. For example, SSWAP gains in speed and lightness but loses in genericity. BioMoby develops its own data type definition, allowing for an easy choreography of services, but requires clients to be compliant with the API. BioSemantic and SADI use standard clients to call their SWS.</p><p>In terms of reasoning abilities, SADI and SSWAP exploit OWL with semantic reasoners to highlight some relationships between classes. On the other hand, BioMoby exploits the taxonomic properties of XML to infer relationships between data types; however, BioMoby is less expressive than OWL. BioSemantic comes without reasoning capabilities. Initially, this task was to be performed by the SWS catalogue (i.e., BioCatalogue), but this function is not yet available.</p><p>The last two criteria define the degree of automation of these approaches. BioMoby and SADI allow for the creation and deployment of SWS skeletons without including core methods. BioSemantic is the only API that processes query creation. This automation is allowed by decoupling annotated RDF view creation and SWS creation. However, this automatic creation of SWS is still dependent on the manual RDF view annotation step performed by the data provider.</p></sec></sec></sec><sec sec-type="discussion"><title>Discussion</title><sec><title>Semantic limitations</title><sec><title>OBO ontologies</title><p>The development of an ontology is a long community-based task in which participants decide on a consensus basis about term definitions and relationships between those terms. Currently, a large number of bio-ontologies exist and cover a large spectrum of biological domains.</p><p>Most of these ontologies are not developed in an OWL format; instead, they are in an OBO format, which follows the OBO Foundry principles [<xref ref-type="bibr" rid="B42">42</xref>], such as unique URI or formatted term/concept names.</p><p>Regarding the amount of work that is necessary to create an ontology, we decided to allow the annotation of RDF view using terms from OBO ontologies. However, that strategy could raise problems, such as the possible lack of a URL that could resolve these ontologies. However, even if OBO Foundry principles only recommend using unique URIs, a lot of already existing OBO ontologies are associated to URLs. Furthermore, if OBO ontologies do not use URLs that currently resolve, it is still possible to register them with online tools such as BioPortal or Ontology Lookup Service (OLS). In our case, we deployed an instance of OLS allowing publishing ontologies on the Web.</p><p>In our approach, the major limit from OBO ontologies comes from the low number of classes possessing restrictions along with the low number of different properties used (e.g., BioPortal notes that 8 properties are used in the GO, which possesses more than 38000 classes). Therefore, using those ontologies has a strong impact on BioSemantic by significantly limiting its semantic component.</p></sec><sec><title>Manual SWS composition</title><p>The SWS BioSemantic composition requires the development of shims. This requirement is a limit to the workflow creation that could be overtaken by creating a Taverna plugin or by making the BioSemantic framework compatible with SADI. Moreover, SADI already possesses a Taverna plugin. Furthermore, that compatibility could take advantage of a stronger semantic without being platform specific.</p></sec><sec><title>No use of existing framework</title><p>In BioSemantic, we choose to not reuse already existing frameworks such as BioMoby, SSWAP or SADI. Indeed, the purpose of these frameworks is to better organise semantic components, whereas the main purpose of BioSemantic is to separate the steps of publishing relational schema and the creation of SWS and then to automate the step of SWS creation.</p><p>During our work, we did not focus on making our approach compatible with an already existing framework. The main reason was that we did not want to be affected by the technical or compatibility limits of other WS or by the success of our approach depending on a specific framework. However, SSWAP and SADI are based on OWL, which allows the creation of SWS with stronger semantics than BioSemantic. Using BioSemantic in those frameworks could increase widely the semantic component of SWS created by BioSemantic and therefore automate their composition.</p></sec><sec><title>Differences between semantic and data type</title><p>The use of bio-ontology terms to annotate input/output allows for easier detection of our SWS by searching services with a standard vocabulary.</p><p>Annotations are composed of adding a semantic flag on a component of a database schema, which requires choosing which component of a schema will be annotated.</p><p>That step is performed manually, and does not guarantee that the same annotation will be associated with similar data. For example, we used the term gcpdm:study to annotate the name of a study because the only identifier of a study existing in the TropGene database is an auto increment with no scientific sense. If another curator uses the same term to annotate an identifier, the data returned by the two different services would not be comparable even if the two services return information on a genotyping study. That limit prevents the automatic composition of our services into workflows.</p></sec></sec><sec><title>Shortest path algorithm</title><sec><title>One input and one output</title><p>The major limit of our query comes from the restriction to a single input concept and a single output concept. That restriction is because of the shortest path algorithm, which allows only the joining of a node of a graph to another node. That restriction implies that we create a query coming from a linear path in the graph that represents the database schema.</p><p>It would be interesting to modify our algorithm to find a path that links a number n of input nodes in our future query to n output nodes.</p></sec><sec><title>Retrieve one path</title><p>Currently, BioSemantic allows automatic query creations based on our shortest path algorithm. We plan to allow a user to choose between different paths. The visualisation of these paths, in which nodes correspond to database table names, will aid in user selection.</p></sec><sec><title>Self join detection</title><p>Furthermore, BioSemantic does not allow the creation of queries annotated with the same input and output concept as a consequence of using the Dijkstra algorithm. This functionality would be very interesting for orthologous or synonym detection for example.</p><p>We plan to implement a simple algorithm allowing the detection of all self joins that correspond with a given table. In fact, if a table has several self joins, then the path length found for each of them will be identical. For this reason, both the path visualisation in the graphical interface for the query creation and the algorithm of self join detection will overtake this limitation, allowing the user to select the name of the wanted association table, to link one table to itself and then to create the wanted query.</p></sec></sec><sec><title>Manual RDF view annotation</title><p>Future developments will concern the semantic annotation of RDF views, which is the only manual task in BioSemantic. This task could be a time-consuming task for database annotators if the database schema is large. Constraints for annotators arise many because they must be experts on database schemas and the ontology terms and must also manipulate RDF and D2RQ. We believe that this limitation could be partially overcome by creating a user interface for the annotation of RDF Views.</p><p>Our solution opens new perspectives for the development of SWS. However, we are still interested in adding more functionality, such as the automatic generation of links between database schemas and existing ontologies. We are currently exploring the use of automatic schema-matching tools developed in the context of the WebSmatch platform [<xref ref-type="bibr" rid="B43">43</xref>].</p></sec><sec><title>Performance problems with FILTER</title><p>Input variables of our services can be regular expressions or literal expressions. Those variables are detected when WS is used and will lead to the use of a different SPARQL FILTER. A regular expression used in a WS input could raise query problems, for example, it could create memory errors when querying tables that contain hundreds of thousands of tuples.</p></sec></sec><sec sec-type="conclusions"><title>Conclusions</title><p>BioSemantic is a framework that is designed to speed the development of Semantic Web Services for existing relational biological databases. This framework has the specific capability of separating the publishing step of the relational schema from the SWS creation. Data consumers can then create Semantic Web Services without knowledge of the resource schema. Currently, it automatically creates and semi-automatically annotates RDF views that enable the automatic generation of SPARQL queries. These queries are created by the following steps: <italic>(i)</italic> the selection of input and output ontological terms using a Web interface that is available in the BioSemantic API; <italic>(ii)</italic> the automatic detection of a path linking inputs to outputs; and <italic>(iii)</italic> the use of the path to automatically generate a SPARQL query. Semantic Web Services are also automatically created and deployed.</p></sec><sec><title>Availability and requirements</title><p>•<bold>Project name:</bold> BioSemantic</p><p>•<bold>Project home page:</bold><ext-link ext-link-type="uri" xlink:href="http://southgreen.cirad.fr/?q=content/Biosemantic">http://southgreen.cirad.fr/?q=content/Biosemantic</ext-link></p><p>•<bold>Operating system(s):</bold> Platform independent</p><p>•<bold>Programming language:</bold> java</p><p>•<bold>Restrictions on use by non-academics:</bold> no limitations</p></sec><sec><title>Competing interests</title><p>The authors declare that they have no competing interests.</p></sec><sec><title>Authors’ contributions</title><p>JW developed and tested the Java code. All of the authors contributed to the design of the software architecture and the development of the appropriate methods. All of the authors read and approved the final version of the manuscript.</p></sec></body><back><sec><title>Acknowledgements</title><p>We would like to acknowledge Isabelle Mougenot and Guilhem Sempere for their assistance.</p><p>This work was supported by Région Languedoc-Roussillon and CIRAD.</p></sec><ref-list><ref id="B1"><mixed-citation publication-type="journal"><name><surname>Tsesmetzis</surname><given-names>N</given-names></name><name><surname>Couchman</surname><given-names>M</given-names></name><name><surname>Higgins</surname><given-names>J</given-names></name><name><surname>Smith</surname><given-names>A</given-names></name><name><surname>Doonan</surname><given-names>JH</given-names></name><name><surname>Seifert</surname><given-names>GJ</given-names></name><name><surname>Schmidt</surname><given-names>EE</given-names></name><name><surname>Vastrik</surname><given-names>I</given-names></name><name><surname>Birney</surname><given-names>E</given-names></name><name><surname>Wu</surname><given-names>G</given-names></name><name><surname>D’Eustachio</surname><given-names>P</given-names></name><name><surname>Stein</surname><given-names>LD</given-names></name><name><surname>Morris</surname><given-names>RJ</given-names></name><name><surname>Bevan</surname><given-names>MW</given-names></name><name><surname>Walsh</surname><given-names>SV</given-names></name><article-title>Arabidopsis reactome: a foundation knowledgebase for plant systems biology</article-title><source>Plant Cell</source><year>2008</year><volume>20</volume><fpage>1426</fpage><lpage>1436</lpage><pub-id pub-id-type="doi">10.1105/tpc.108.057976</pub-id><pub-id pub-id-type="pmid">18591350</pub-id></mixed-citation></ref><ref id="B2"><mixed-citation publication-type="journal"><name><surname>Lysenko</surname><given-names>A</given-names></name><name><surname>Hindle</surname><given-names>MM</given-names></name><name><surname>Taubert</surname><given-names>J</given-names></name><name><surname>Saqi</surname><given-names>M</given-names></name><name><surname>Rawlings</surname><given-names>CJ</given-names></name><article-title>Data integration for plant genomics—exemplars from the integration of Arabidopsis thaliana databases</article-title><source>Brief Bioinform</source><year>2009</year><volume>10</volume><fpage>676</fpage><lpage>693</lpage><pub-id pub-id-type="doi">10.1093/bib/bbp047</pub-id><pub-id pub-id-type="pmid">19933213</pub-id></mixed-citation></ref><ref id="B3"><mixed-citation publication-type="journal"><name><surname>Stein</surname><given-names>LD</given-names></name><article-title>Towards a cyberinfrastructure for the biological sciences: progress, visions and challenges</article-title><source>Nat Rev Genet</source><year>2008</year><volume>9</volume><fpage>678</fpage><lpage>688</lpage><pub-id pub-id-type="pmid">18714290</pub-id></mixed-citation></ref><ref id="B4"><mixed-citation publication-type="journal"><name><surname>Goble</surname><given-names>C</given-names></name><name><surname>Stevens</surname><given-names>R</given-names></name><article-title>State of the nation in data integration for bioinformatics</article-title><source>J Biomed Inform</source><year>2008</year><volume>41</volume><fpage>687</fpage><lpage>693</lpage><pub-id pub-id-type="doi">10.1016/j.jbi.2008.01.008</pub-id><pub-id pub-id-type="pmid">18358788</pub-id></mixed-citation></ref><ref id="B5"><mixed-citation publication-type="other"><source>RDF/XML Syntax Specification (Revised)</source><comment><ext-link ext-link-type="uri" xlink:href="http://www.w3.org/TR/REC-rdf-syntax/">http://www.w3.org/TR/REC-rdf-syntax/</ext-link></comment></mixed-citation></ref><ref id="B6"><mixed-citation publication-type="other"><source>SPARQL Query Language for RDF</source><comment><ext-link ext-link-type="uri" xlink:href="http://www.w3.org/TR/rdf-sparql-query/">http://www.w3.org/TR/rdf-sparql-query/</ext-link></comment></mixed-citation></ref><ref id="B7"><mixed-citation publication-type="other"><source>OWL Web Ontology Language Overview</source><comment><ext-link ext-link-type="uri" xlink:href="http://www.w3.org/TR/owl-features/">http://www.w3.org/TR/owl-features/</ext-link></comment></mixed-citation></ref><ref id="B8"><mixed-citation publication-type="journal"><name><surname>Swarbreck</surname><given-names>D</given-names></name><name><surname>Wilks</surname><given-names>C</given-names></name><article-title>The Arabidopsis Information Resource (TAIR): gene structure and function annotation</article-title><source>Nucleic Acids Res</source><year>2008</year><volume>36</volume><fpage>D1009</fpage><lpage>D1014</lpage><pub-id pub-id-type="pmid">17986450</pub-id></mixed-citation></ref><ref id="B9"><mixed-citation publication-type="journal"><name><surname>Liang</surname><given-names>C</given-names></name><name><surname>Jaiswal</surname><given-names>P</given-names></name><article-title>Gramene: a growing plant comparative genomics resource</article-title><source>Nucleic Acids Res</source><year>2008</year><volume>36</volume><fpage>D947</fpage><lpage>D953</lpage><pub-id pub-id-type="pmid">17984077</pub-id></mixed-citation></ref><ref id="B10"><mixed-citation publication-type="journal"><name><surname>McLaren</surname><given-names>CG</given-names></name><name><surname>Bruskiewich</surname><given-names>RM</given-names></name><article-title>The International Rice Information System. A platform for meta-analysis of rice crop data</article-title><source>Plant Physiol</source><year>2005</year><volume>139</volume><fpage>637</fpage><lpage>642</lpage><pub-id pub-id-type="doi">10.1104/pp.105.063438</pub-id><pub-id pub-id-type="pmid">16219924</pub-id></mixed-citation></ref><ref id="B11"><mixed-citation publication-type="journal"><name><surname>Lawrence</surname><given-names>CJ</given-names></name><name><surname>Harper</surname><given-names>LC</given-names></name><article-title>MaizeGDB: The Maize Model Organism Database for Basic, Translational, and Applied Research</article-title><source>Int J Plant Genomics</source><year>2008</year><volume>2008</volume><fpage>1</fpage><lpage>10</lpage></mixed-citation></ref><ref id="B12"><mixed-citation publication-type="journal"><name><surname>Samson</surname><given-names>D</given-names></name><name><surname>Legeai</surname><given-names>F</given-names></name><article-title>GénoPlante-Info (GPI): a collection of databases and bioinformatics resources for plant genomics</article-title><source>Nucleic Acids Res</source><year>2003</year><volume>31</volume><fpage>179</fpage><lpage>182</lpage><pub-id pub-id-type="doi">10.1093/nar/gkg060</pub-id><pub-id pub-id-type="pmid">12519976</pub-id></mixed-citation></ref><ref id="B13"><mixed-citation publication-type="journal"><name><surname>Rubin</surname><given-names>DL</given-names></name><name><surname>Shah</surname><given-names>NH</given-names></name><article-title>Biomedical ontologies: a functional perspective</article-title><source>Brief Bioinform</source><year>2008</year><volume>9</volume><fpage>75</fpage><lpage>90</lpage><pub-id pub-id-type="pmid">18077472</pub-id></mixed-citation></ref><ref id="B14"><mixed-citation publication-type="journal"><name><surname>Chepelev</surname><given-names>LL</given-names></name><name><surname>Dumontier</surname><given-names>M</given-names></name><article-title>Semantic Web integration of Cheminformatics resources with the SADI framework</article-title><source>J Cheminform</source><year>2011</year><volume>3</volume><fpage>16</fpage><pub-id pub-id-type="doi">10.1186/1758-2946-3-16</pub-id><pub-id pub-id-type="pmid">21575200</pub-id></mixed-citation></ref><ref id="B15"><mixed-citation publication-type="journal"><name><surname>Bruskiewich</surname><given-names>R</given-names></name><name><surname>Senger</surname><given-names>M</given-names></name><name><surname>Davenport</surname><given-names>G</given-names></name><name><surname>Ruiz</surname><given-names>M</given-names></name><name><surname>Rouard</surname><given-names>M</given-names></name><article-title>The generation challenge programme platform: semantic standards and workbench for crop science</article-title><source>Int J Plant Genomics</source><year>2008</year><volume>2008</volume><fpage>369601</fpage><pub-id pub-id-type="pmid">18483570</pub-id></mixed-citation></ref><ref id="B16"><mixed-citation publication-type="journal"><name><surname>Goff</surname><given-names>SA</given-names></name><name><surname>McKay</surname><given-names>S</given-names></name><name><surname>Stapleton</surname><given-names>AE</given-names></name><name><surname>Hanlon</surname><given-names>M</given-names></name><name><surname>Mock</surname><given-names>S</given-names></name><name><surname>Helmke</surname><given-names>M</given-names></name><name><surname>Kubach</surname><given-names>A</given-names></name><name><surname>Noutsos</surname><given-names>C</given-names></name><name><surname>Gendler</surname><given-names>K</given-names></name><name><surname>Feng</surname><given-names>X</given-names></name><name><surname>Welch</surname><given-names>SM</given-names></name><name><surname>O’Meara</surname><given-names>B</given-names></name><name><surname>Brutnell</surname><given-names>T</given-names></name><name><surname>Leebens-Mack</surname><given-names>J</given-names></name><name><surname>Akoglu</surname><given-names>A</given-names></name><article-title>The iPlant collaborative: cyberinfrastructure for plant biology</article-title><source>Front Plant Sci</source><year>2011</year><volume>2</volume><fpage>34</fpage><pub-id pub-id-type="pmid">22645531</pub-id></mixed-citation></ref><ref id="B17"><mixed-citation publication-type="other"><name><surname>Wilkinson</surname><given-names>MD</given-names></name><name><surname>Vandervalk</surname><given-names>B</given-names></name><name><surname>McCarthy</surname><given-names>L</given-names></name><source>SADI Semantic Web Services – ‘cause you can’t always GET what you want!</source><series>Services Computing Conference, 2009 APSCC 2009 IEEE Asia-Pacific: 7-11 Dec. 2009</series><year>2009</year><fpage>13</fpage><lpage>18</lpage><pub-id pub-id-type="pmid">23612187</pub-id></mixed-citation></ref><ref id="B18"><mixed-citation publication-type="journal"><name><surname>Gessler</surname><given-names>D</given-names></name><name><surname>Schiltz</surname><given-names>G</given-names></name><article-title>SSWAP: A Simple Semantic Web Architecture and Protocol for semantic web services</article-title><source>BMC Bioinformatics</source><year>2009</year><volume>10</volume><fpage>309</fpage><pub-id pub-id-type="doi">10.1186/1471-2105-10-309</pub-id><pub-id pub-id-type="pmid">19775460</pub-id></mixed-citation></ref><ref id="B19"><mixed-citation publication-type="journal"><name><surname>Wilkinson</surname><given-names>MD</given-names></name><name><surname>Vandervalk</surname><given-names>B</given-names></name><name><surname>McCarthy</surname><given-names>L</given-names></name><article-title>The Semantic Automated Discovery and Integration (SADI) Web service Design-Pattern, API and Reference Implementation</article-title><source>J Biomed Semantics</source><year>2011</year><volume>2</volume><fpage>8</fpage><pub-id pub-id-type="doi">10.1186/2041-1480-2-8</pub-id><pub-id pub-id-type="pmid">22024447</pub-id></mixed-citation></ref><ref id="B20"><mixed-citation publication-type="journal"><name><surname>Wilkinson</surname><given-names>MD</given-names></name><name><surname>Senger</surname><given-names>M</given-names></name><name><surname>Kawas</surname><given-names>E</given-names></name><name><surname>Bruskiewich</surname><given-names>R</given-names></name><name><surname>Gouzy</surname><given-names>J</given-names></name><name><surname>Noirot</surname><given-names>C</given-names></name><name><surname>Bardou</surname><given-names>P</given-names></name><name><surname>Ng</surname><given-names>A</given-names></name><name><surname>Haase</surname><given-names>D</given-names></name><name><surname>Saiz Ede</surname><given-names>A</given-names></name><article-title>Interoperability with Moby 1.0–it's better than sharing your toothbrush!</article-title><source>Brief Bioinform</source><year>2008</year><volume>9</volume><issue>3</issue><fpage>220</fpage><lpage>231</lpage><pub-id pub-id-type="pmid">18238804</pub-id></mixed-citation></ref><ref id="B21"><mixed-citation publication-type="journal"><name><surname>Wilkinson</surname><given-names>M</given-names></name><name><surname>McCarthy</surname><given-names>L</given-names></name><article-title>SADI, SHARE, and the in silico scientific method</article-title><source>BMC Bioinform</source><year>2010</year><volume>11</volume><fpage>S7</fpage></mixed-citation></ref><ref id="B22"><mixed-citation publication-type="journal"><name><surname>Spanos</surname><given-names>D-E</given-names></name><name><surname>Stavrou</surname><given-names>P</given-names></name><name><surname>Mitrou</surname><given-names>N</given-names></name><article-title>Bringing relational databases into the Semantic Web: A survey</article-title><source>Semantic Web</source><year>2012</year><volume>3</volume><issue>2</issue><fpage>169</fpage><lpage>209</lpage></mixed-citation></ref><ref id="B23"><mixed-citation publication-type="other"><source>Mapping Relational Data to RDF in Virtuoso</source><comment><ext-link ext-link-type="uri" xlink:href="http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VOSSQLRDF">http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VOSSQLRDF</ext-link></comment></mixed-citation></ref><ref id="B24"><mixed-citation publication-type="other"><name><surname>Miles</surname><given-names>A</given-names></name><name><surname>Zhao</surname><given-names>J</given-names></name><name><surname>Klyne</surname><given-names>G</given-names></name><name><surname>White-Cooper</surname><given-names>H</given-names></name><name><surname>Shotton</surname><given-names>D</given-names></name><article-title>OpenFlyData: An exemplar data web integrating gene expression data on the fruit fly Drosophila melanogaster</article-title><source>J Biomed Inform</source><year>2010</year></mixed-citation></ref><ref id="B25"><mixed-citation publication-type="journal"><name><surname>Cheung</surname><given-names>KH</given-names></name><name><surname>Yip</surname><given-names>KY</given-names></name><name><surname>Smith</surname><given-names>A</given-names></name><name><surname>Deknikker</surname><given-names>R</given-names></name><name><surname>Masiar</surname><given-names>A</given-names></name><name><surname>Gerstein</surname><given-names>M</given-names></name><article-title>YeastHub: a semantic web use case for integrating data in the life sciences domain</article-title><source>Bioinformatics</source><year>2005</year><volume>21</volume><issue>Suppl 1</issue><fpage>i85</fpage><lpage>96</lpage><pub-id pub-id-type="doi">10.1093/bioinformatics/bti1026</pub-id><pub-id pub-id-type="pmid">15961502</pub-id></mixed-citation></ref><ref id="B26"><mixed-citation publication-type="journal"><name><surname>Lam</surname><given-names>HYK</given-names></name><name><surname>Marenco</surname><given-names>L</given-names></name><name><surname>Shepherd</surname><given-names>GM</given-names></name><name><surname>Miller</surname><given-names>PL</given-names></name><name><surname>Cheung</surname><given-names>K-H</given-names></name><article-title>Using Web Ontology Language to Integrate Heterogeneous Databases in the Neurosciences</article-title><source>AMIA Annu Symp Proc</source><year>2006</year><volume>2006</volume><fpage>464</fpage><lpage>468</lpage><pub-id pub-id-type="pmid">17238384</pub-id></mixed-citation></ref><ref id="B27"><mixed-citation publication-type="journal"><name><surname>Bruskiewich</surname><given-names>R</given-names></name><name><surname>Davenport</surname><given-names>G</given-names></name><article-title>Generation Challenge Programme (GCP): standards for crop data</article-title><source>OMICS</source><year>2006</year><volume>10</volume><fpage>215</fpage><lpage>219</lpage><pub-id pub-id-type="doi">10.1089/omi.2006.10.215</pub-id><pub-id pub-id-type="pmid">16901229</pub-id></mixed-citation></ref><ref id="B28"><mixed-citation publication-type="journal"><name><surname>Rahayu</surname><given-names>JW</given-names></name><name><surname>Chang</surname><given-names>E</given-names></name><article-title>A methodology for transforming inheritance relationships in an object-oriented conceptual model to relational tables</article-title><source>Inf Softw Technol</source><year>2000</year><volume>42</volume><fpage>571</fpage><lpage>592</lpage><pub-id pub-id-type="doi">10.1016/S0950-5849(00)00103-8</pub-id></mixed-citation></ref><ref id="B29"><mixed-citation publication-type="book"><name><surname>Tirmizi</surname><given-names>S</given-names></name><name><surname>Sequeda</surname><given-names>J</given-names></name><name><surname>Miranker</surname><given-names>D</given-names></name><article-title>Translating SQL Applications to the Semantic Web</article-title><source>Database and Expert Systems Applications. vol. 5181</source><year>2008</year><publisher-name>Springer Berlin / Heidelberg</publisher-name><fpage>450</fpage><lpage>464</lpage></mixed-citation></ref><ref id="B30"><mixed-citation publication-type="journal"><name><surname>Dijkstra</surname><given-names>E</given-names></name><article-title>A note on two problems in connexion with graphs</article-title><source>Numerische Mathematik</source><year>1959</year><volume>1</volume><fpage>269</fpage><lpage>271</lpage><pub-id pub-id-type="doi">10.1007/BF01386390</pub-id></mixed-citation></ref><ref id="B31"><mixed-citation publication-type="journal"><name><surname>Pettifer</surname><given-names>S</given-names></name><name><surname>Ison</surname><given-names>J</given-names></name><article-title>The EMBRACE web service collection</article-title><source>Nucleic Acids Res</source><year>2010</year><volume>38</volume><fpage>W683</fpage><lpage>W688</lpage><pub-id pub-id-type="doi">10.1093/nar/gkq297</pub-id><pub-id pub-id-type="pmid">20462862</pub-id></mixed-citation></ref><ref id="B32"><mixed-citation publication-type="journal"><name><surname>Kopecký</surname><given-names>J</given-names></name><name><surname>Vitvar</surname><given-names>T</given-names></name><article-title>SAWSDL: Semantic Annotations for WSDL and XML Schema</article-title><source>IEEE Internet Comput</source><year>2007</year><volume>11</volume><fpage>60</fpage><lpage>67</lpage></mixed-citation></ref><ref id="B33"><mixed-citation publication-type="journal"><name><surname>Bhagat</surname><given-names>J</given-names></name><name><surname>Tanoh</surname><given-names>F</given-names></name><name><surname>Nzuobontane</surname><given-names>E</given-names></name><name><surname>Laurent</surname><given-names>T</given-names></name><name><surname>Orlowski</surname><given-names>J</given-names></name><name><surname>Roos</surname><given-names>M</given-names></name><name><surname>Wolstencroft</surname><given-names>K</given-names></name><name><surname>Aleksejevs</surname><given-names>S</given-names></name><name><surname>Stevens</surname><given-names>R</given-names></name><name><surname>Pettifer</surname><given-names>S</given-names></name><article-title>BioCatalogue: a universal catalogue of web services for the life sciences</article-title><source>Nucleic Acids Res</source><year>2010</year><volume>38</volume><issue>Web Server issue</issue><fpage>W689</fpage><lpage>694</lpage><pub-id pub-id-type="pmid">20484378</pub-id></mixed-citation></ref><ref id="B34"><mixed-citation publication-type="journal"><name><surname>Ruiz</surname><given-names>M</given-names></name><name><surname>Rouard</surname><given-names>M</given-names></name><name><surname>Raboin</surname><given-names>LM</given-names></name><name><surname>Lartaud</surname><given-names>M</given-names></name><name><surname>Lagoda</surname><given-names>P</given-names></name><name><surname>Courtois</surname><given-names>B</given-names></name><article-title>TropGENE-DB, a multi-tropical crop information system</article-title><source>Nucleic Acids Res</source><year>2004</year><volume>32</volume><fpage>D364</fpage><lpage>D367</lpage><pub-id pub-id-type="doi">10.1093/nar/gkh105</pub-id><pub-id pub-id-type="pmid">14681435</pub-id></mixed-citation></ref><ref id="B35"><mixed-citation publication-type="journal"><name><surname>Flicek</surname><given-names>P</given-names></name><name><surname>Amode</surname><given-names>MR</given-names></name><name><surname>Barrell</surname><given-names>D</given-names></name><name><surname>Beal</surname><given-names>K</given-names></name><name><surname>Brent</surname><given-names>S</given-names></name><name><surname>Carvalho-Silva</surname><given-names>D</given-names></name><name><surname>Clapham</surname><given-names>P</given-names></name><name><surname>Coates</surname><given-names>G</given-names></name><name><surname>Fairley</surname><given-names>S</given-names></name><name><surname>Fitzgerald</surname><given-names>S</given-names></name><name><surname>Gil</surname><given-names>L</given-names></name><name><surname>Gordon</surname><given-names>L</given-names></name><name><surname>Hendrix</surname><given-names>M</given-names></name><name><surname>Hourlier</surname><given-names>T</given-names></name><name><surname>Johnson</surname><given-names>N</given-names></name><name><surname>Kahari</surname><given-names>AK</given-names></name><name><surname>Keefe</surname><given-names>D</given-names></name><name><surname>Keenan</surname><given-names>S</given-names></name><name><surname>Kinsella</surname><given-names>R</given-names></name><name><surname>Komorowska</surname><given-names>M</given-names></name><name><surname>Koscielny</surname><given-names>G</given-names></name><name><surname>Kulesha</surname><given-names>E</given-names></name><name><surname>Larsson</surname><given-names>P</given-names></name><name><surname>Longden</surname><given-names>I</given-names></name><name><surname>McLaren</surname><given-names>W</given-names></name><name><surname>Muffato</surname><given-names>M</given-names></name><name><surname>Overduin</surname><given-names>B</given-names></name><name><surname>Pignatelli</surname><given-names>M</given-names></name><name><surname>Pritchard</surname><given-names>B</given-names></name><name><surname>Riat</surname><given-names>HS</given-names></name><name><surname>Ritchie</surname><given-names>GRS</given-names></name><name><surname>Ruffier</surname><given-names>M</given-names></name><name><surname>Schuster</surname><given-names>M</given-names></name><name><surname>Sobral</surname><given-names>D</given-names></name><name><surname>Tang</surname><given-names>YA</given-names></name><name><surname>Taylor</surname><given-names>K</given-names></name><name><surname>Trevanion</surname><given-names>S</given-names></name><name><surname>Vandrovcova</surname><given-names>J</given-names></name><name><surname>White</surname><given-names>S</given-names></name><name><surname>Wilson</surname><given-names>M</given-names></name><name><surname>Wilder</surname><given-names>SP</given-names></name><name><surname>Aken</surname><given-names>BL</given-names></name><name><surname>Birney</surname><given-names>E</given-names></name><name><surname>Cunningham</surname><given-names>F</given-names></name><name><surname>Dunham</surname><given-names>I</given-names></name><name><surname>Durbin</surname><given-names>R</given-names></name><name><surname>Fernandez-Suarez</surname><given-names>XM</given-names></name><name><surname>Harrow</surname><given-names>J</given-names></name><name><surname>Herrero</surname><given-names>J</given-names></name><name><surname>Hubbard</surname><given-names>TJP</given-names></name><name><surname>Parker</surname><given-names>A</given-names></name><name><surname>Proctor</surname><given-names>G</given-names></name><name><surname>Spudich</surname><given-names>G</given-names></name><name><surname>Vogel</surname><given-names>J</given-names></name><name><surname>Yates</surname><given-names>A</given-names></name><name><surname>Zadissa</surname><given-names>A</given-names></name><name><surname>Searle</surname><given-names>SMJ</given-names></name><article-title>Ensembl 2012</article-title><source>Nucleic Acids Res</source><year>2011</year><volume>40</volume><fpage>D84</fpage><lpage>D90</lpage><pub-id pub-id-type="pmid">22086963</pub-id></mixed-citation></ref><ref id="B36"><mixed-citation publication-type="journal"><name><surname>Goble</surname><given-names>CA</given-names></name><name><surname>Bhagat</surname><given-names>J</given-names></name><name><surname>Aleksejevs</surname><given-names>S</given-names></name><name><surname>Cruickshank</surname><given-names>D</given-names></name><name><surname>Michaelides</surname><given-names>D</given-names></name><name><surname>Newman</surname><given-names>D</given-names></name><name><surname>Borkum</surname><given-names>M</given-names></name><name><surname>Bechhofer</surname><given-names>S</given-names></name><name><surname>Roos</surname><given-names>M</given-names></name><name><surname>Li</surname><given-names>P</given-names></name><name><surname>De Roure</surname><given-names>D</given-names></name><article-title><bold>myExperiment: a repository and social network for the sharing of bioinformatics workflows</bold></article-title><source>Nucleic Acids Res</source><year>2010</year><volume>38</volume><fpage>W677</fpage><lpage>W682</lpage><pub-id pub-id-type="doi">10.1093/nar/gkq429</pub-id><pub-id pub-id-type="pmid">20501605</pub-id></mixed-citation></ref><ref id="B37"><mixed-citation publication-type="journal"><name><surname>Droc</surname><given-names>G</given-names></name><name><surname>Périn</surname><given-names>C</given-names></name><article-title>OryGenesDB 2008 update: database interoperability for functional genomics of rice</article-title><source>Nucleic Acids Res</source><year>2009</year><volume>37</volume><fpage>D992</fpage><lpage>D995</lpage><pub-id pub-id-type="doi">10.1093/nar/gkn821</pub-id><pub-id pub-id-type="pmid">19036791</pub-id></mixed-citation></ref><ref id="B38"><mixed-citation publication-type="other"><source>Singer</source><comment><ext-link ext-link-type="uri" xlink:href="http://singer.cgiar.org/">http://singer.cgiar.org/</ext-link></comment></mixed-citation></ref><ref id="B39"><mixed-citation publication-type="journal"><name><surname>Shrestha</surname><given-names>R</given-names></name><name><surname>Arnaud</surname><given-names>E</given-names></name><article-title>Multifunctional crop trait ontology for breeders’ data: field book, annotation, data discovery and semantic enrichment of the literature</article-title><source>AoB Plants</source><year>2010</year><volume>2010</volume><fpage>plq008</fpage><pub-id pub-id-type="doi">10.1093/aobpla/plq008</pub-id><pub-id pub-id-type="pmid">22476066</pub-id></mixed-citation></ref><ref id="B40"><mixed-citation publication-type="journal"><name><surname>Eilbeck</surname><given-names>K</given-names></name><name><surname>Lewis</surname><given-names>S</given-names></name><name><surname>Mungall</surname><given-names>C</given-names></name><name><surname>Yandell</surname><given-names>M</given-names></name><name><surname>Stein</surname><given-names>L</given-names></name><name><surname>Durbin</surname><given-names>R</given-names></name><name><surname>Ashburner</surname><given-names>M</given-names></name><article-title>The Sequence Ontology: a tool for the unification of genome annotations</article-title><source>Genome Biology</source><year>2005</year><volume>6</volume><fpage>R44</fpage><pub-id pub-id-type="doi">10.1186/gb-2005-6-5-r44</pub-id><pub-id pub-id-type="pmid">15892872</pub-id></mixed-citation></ref><ref id="B41"><mixed-citation publication-type="journal"><name><surname>Bizer</surname><given-names>C</given-names></name><name><surname>Schultz</surname><given-names>A</given-names></name><article-title>The Berlin SPARQL Benchmark</article-title><source>Int J Semantic Web Inf Syst</source><year>2009</year><volume>5</volume><fpage>1</fpage><lpage>24</lpage></mixed-citation></ref><ref id="B42"><mixed-citation publication-type="other"><source>Open Biological and Biomedical Ontologies: current principles</source><comment><ext-link ext-link-type="uri" xlink:href="http://obofoundry.org/crit.shtml">http://obofoundry.org/crit.shtml</ext-link></comment></mixed-citation></ref><ref id="B43"><mixed-citation publication-type="other"><source>WebSmatch project: an environment for Web Schema Matching</source><comment><ext-link ext-link-type="uri" xlink:href="http://websmatch.gforge.inria.fr/">http://websmatch.gforge.inria.fr/</ext-link></comment></mixed-citation></ref></ref-list></back></pmc></record>Pour manipuler ce document sous Unix (Dilib)
EXPLOR_STEP=$WICRI_ROOT/Ticri/CIDE/explor/CyberinfraV1/Data/Pmc/Corpus
HfdSelect -h $EXPLOR_STEP/biblio.hfd -nk 0002720 | SxmlIndent | more
Ou
HfdSelect -h $EXPLOR_AREA/Data/Pmc/Corpus/biblio.hfd -nk 0002720 | SxmlIndent | more
Pour mettre un lien sur cette page dans le réseau Wicri
{{Explor lien
|wiki= Ticri/CIDE
|area= CyberinfraV1
|flux= Pmc
|étape= Corpus
|type= RBID
|clé=
|texte=
}}
| This area was generated with Dilib version V0.6.25. |  |