BACKGROUND
data integration across disparate datasources is a common problem, not limited to the sphere of bioinformatics, and has been addressed in many ways  <cit> .
cross indexing and hypertext linking of resources has historically been used for accessing bioinformatics data  but is curation intensive and does not adequately address different datatypes found in the distributed datasources.
however, cross referencing is widely used and forms the basis of the highly successful entrez data retrieval system  <cit> .
a common approach for integrating bioinformatics data is to warehouse data according to a shared data schema .
data in the individual data sources must be mapped to the shared schema, capturing both the syntax of the data structure and the semantics of what the data objects represent.
the warehousing approach therefore incurs heavy data curation costs in creating and maintaining the warehouse and requires extensive computing resources; the alternative approach of federating the warehouse introduces further problems in distributing queries across the underlying distributed resources.
an alternative recent approach involves attempting to integrate data semantically through the use of defined ontologies describing a particular data domain.
in addition to the widely used gene ontology  <cit>  which provides a controlled vocabulary for annotating gene and gene function attributes that can then be used in index based retrieval systems, other formal ontologies are actively being developed to support bioinformatics, particularly under the obo umbrella .
well-defined, detailed ontologies have been created representing common concepts used across the bioinformatics domain, e.g.
for sequence features  and common concept relationships  and also more specific concepts for particular domains, e.g.
the amphibian gross anatomy  <cit> .
these ontologies provide excellent controlled terminologies for data description and annotation, but do not provide data transport protocols and provide neither the structure nor semantics required for data integration.
consequently, whilst ontology based descriptions of data objects can be compared across data sets – two objects with similar annotations may share similar properties – these annotations do not capture or assert actual relationships between the data objects.
technologies developed to support the 'semantic web' such as owl, the 'web ontology language' provide an approach for exposing and integrating semantically consistent datasources  and the potential for semantic web integration of bioinformatics resources is being actively explored .
recently we have been involved in the comparagrid project which aims to integrate genomic data by mapping data sources to a shared owl ontology for genomic information, thus facilitating semantic integration and query  <cit> .
however, such an approach is computationally expensive and as yet difficult to implement using available semantic ontology tools.
a more lightweight and arguably more practical approach for data exchange is to encourage the curators of data resources to provide data export facilities in a common simple exchange format, which both captures the data structure and provides a degree of semantic clarity to the exported data, without providing the exacting constraints of a formal ontology.
xml has long been recognized as a useful data structure with which to implement formal exchange formats  <cit> .
such an approach allows application developers to develop their integration systems against the common data format, where the structure of the data is unambiguous, and the semantics are sufficiently defined for usability.
here we present our approach of using a simple structured xml schema  to define the data exchange structure for genetic mapping information, an approach successfully used for integrating data in other bioinformatics domains  and also for specifying standards defining the key information to include when reporting experimental results .
use of common exchange schemas to define data structures allows users  to parse the data syntax into semantically described data objects.
our genomic mapping data  schema allows common information types for our domain  to be represented in a syntactically defined structure, thus enabling gmd conformant data documents to be programatically parsed into meaningful genetic information.
furthermore, the gmd schema is extendable to handle additional datatypes.
extension may be achieved not only by evolution of the schema, but simply by using datatypes defined elsewhere, for example by importing additional schemas to the data document, or referring to controlled vocabularies or external ontologies.
to illustrate how the schema can be used we have built web services which export data from the arkdb genomic mapping resource using our exchange format.
we also illustrate how additional defined terms can be imported from a second schema which defines common data relationships relevant to the genomic mapping domain.
we demonstrate how the taverna workbench can consume these web services into workflows to harvest and use mapping data for bioinformatics tasks.
this is possible because taverna can parse the xml data structure of the data documents provided as web service responses in the context of the defined data format .
RESULTS
schema design
one approach for developing a shared schema for data exchange in a given information domain is to initiate a consultation and prototyping cycle amongst interested parties .
however, this 'design by committee' approach is frequently protracted and contentious.
in order to 'kick start' development of a usable standard for genomic mapping data we have developed a candidate exchange schema that seeks to capture the important core data concepts and relationships, whilst being potentially expandable to incorporate additional requirements if necessary for wider use.
to encourage adoption, a generic, unambiguous and semantically 'neutral' schema is desirable.
indeed many of the common data objects in the genomic mapping domain cannot be defined unambiguously across user groups .
therefore the schema avoids precise semantic definition of concepts and leaves interpretation to individual data providers and applications.
however, the structured syntax of the schema allows any important 'relationships' between concepts to be fully represented.
furthermore, because xml data documents can reference multiple schemas, users can further define their information by reference to additional external schemas.
the generic nature of our mapping schema allows any type of map to be represented, allowing integration of the many types of data found in genetic resources.
for example the representation of genetic linkage maps and sequence maps is conceptually and syntactically the same: the positioning of mapped objects on a map object using a coordinate system.
the prototype schema genomicmappingdata.xsd, , includes in-line descriptive annotations.
example data exchange documents conforming to the schema are provided as additional files  <dig> and  <dig> , and afford examples of the data structures decribed below.
we are also hosting an interactive wiki site  <cit>  to provide further guidance on best practice for schema usage, and as a forum for discussion of schema refinement and evolution by interested data providers and users.
the structure of our gmd schema aims to be clear and logical, but is primarily designed for unambiguous data storage and programmatic parsing rather than 'human readability'.
the root element of the document is <dataset>, which is itself defined as a 'complex type', thus allowing this 'type'  to be referenced in other xml documents that import the gmd schema.
for example, this allows a web service description document  to specify a return type of 'gmd:dataset' for a particular web service, thus enabling parsing of returned result documents by a web service client  according to the defined schema structure .
the children of the <dataset> root element are multiple, single-copy containers for the data objects  and for binary data relationships, assertions about data , third-party datasources such as pubmed or ensembl, references to these  and a <metadata> container for information about the provenance of the dataset document.
all the main data elements in the schema have an 'id' attribute, which might typically be the source database id.
an 'id' attribute should be unique within a document, but this is not enforced in the schema.
these data objects represented by elements with an 'id' attribute can be reused by 'foreign key' reference in the document by various 'reference type' elements.
these have an 'idref' attribute, which should reference an extant 'id' attribute of another element .
for example, a <species> element with 'id = x', can be referenced by a <speciesref> element with 'idref = x', in this case efficiently allowing multiple objects to declare that they pertain to a particular organism.
similarly, various mapping objects may reference a particular <analysis>  through an <analysisref>, providing important contextual information.
in addition, the top level containers are allowed document unique 'id' attributes of type 'xsd:id'.
in practice, this greatly assists programmatic parsing of the document as such elements can be obtained from a document model by their 'id' value.
the information about each data object is held in subsidiary elements.
in designing the schema, elements were preferred over attributes for data storage in order to allow the built-in taverna parser  to access data values.
in order not to overly constrain schema users, most data elements are 'optional' apart from where required for structural association.
for example, a <chromosome> element optionally contains <chromosomename>, <dbidentifier>, <dataaccessmethod>, <speciesref> and <externalreferencerefs> whilst a <relationship> element logically must contain <objectref>, <subjectref> and <relationshiptype> elements .
'terminal' data elements generally have content of type 'xsd:string' or 'xsd:double', whilst those of reftype contain only an 'idref' attribute .
several elements such as <units>, <qtldetails>, <otherdata> and the <'object'type> child elements  are allowed content defined as being of 'xsd:anytype', allowing any data structure , or perhaps as a type from the obo units of measurement ontology  <cit> , by using the owl class url .
this external type could be represented by a single element of type xsd:string or xsd:anyuri, a type structure defined or not by schema import, or might be of gmd:reftype and point at an externalreference element in the document itself .
allowing <units> to be defined as any type permits a generic representation of any map type data in schema-compliant dataset documents.
of course inclusion of xsd:anytype extensions only allows defined client parsing if the extended types are referenced by import of an external xsd schema.
structural nesting of elements is used where logical, for example the <mappings> that lie on a given <map> are nested under that <map>, and a sequence associated with a particular <marker> or <clone> may be nested as a <sequenceref> reference under that object.
however, any data relationship may alternatively be stored as a binary relationship .
rather than provide multiple subsumption-typed versions of data objects such as map, sequence or marker, which would cause gross schema inflation when accounting for all users' requirements, such elements contain optional child elements to record a specific 'objecttype' for the object  and are also allowed content of 'xsd:anytype', which, as described above, could hold a string value such as "linkage map", "radiation hybrid map", "est", "genomic".
in order to promote data consistency within a user group, permitted string values might derive from enumerated  lists, or from more controlled defined vocabularies, or indeed types could be imported from external sources .
this semantically 'loose' mechanism enables a 'marker' object to be interpreted generically as an 'undefined genetic marker' or, as a specific type of marker  if such objecttypes are provided and documented by the data provider and are relevant to the consumer application.
an important feature of the dataset schema is the provision of full data provenance and data access protocols; only by providing this information can reliable data integration be achieved.
to this end an optional element <dbidentifier> is allowed for most data elements which can be used to record the identifier or accession number for that object in the datasource .
in addition, the optional <dataaccessmethod> element can detail how to actually access a record of this object from the source datatabase .
providing this information enables programmatic expansion of datasets, for example where one dataset provides details of markers found on a particular map, and each marker provides its access method, a client program could fetch the full record for each marker, which might detail every map that this marker is associated with, its relationships to other markers or sequences and any external datasource links.
in order to facilitate integration across datasources most data elements in the schema may include external references to third party data repositories.
this is provided by <external reference> elements which detail an external datasource name/location and a specific object id therein.
these are referenced internally in the document by optional <externalreferenceref> child elements for a given data element, which point to a <external reference> element.
for example this could allow a sequence in the dataset to be explicitly linked to a sequence in genbank by its genbank accession.
the client can then use this genbank id to retrieve the original record for this sequence.
this allows integrative workflows to be composed, for example using the taverna workbench .
representing data relationships
a part of the knowledge domain that is typically hard to capture is represented by <relationship> elements, which capture  relationships between two data objects .
in order to capture the nature of the relationship each <relationship> must be 'typed' via a <relationshiptype> child element .
ultimately, use and interpretation of relationships will be dependant on a shared interpretation by data users and providers.
again data interpretation and consistency might be assisted by provision of a controlled 'vocabulary' of possible types  or defined terms or types could be imported from external sources .
however, precise semantic definition of relationship types across the whole potential user domain is perhaps overly ambitious, and controlled vocabularies for particular sub-domains or 'user groups' may prove more pragmatic.
by way of demonstration, we have defined a relationship type schema, genomicdatarelationship.xsd, .
this schema defines complex types that represent real data relationship types in genomic datasets .
the datatypes are derived by extension of parent types to represent the inheritance/subsumption hierarchy of relationship types.
in order to visualize the relationship type inheritance in gdr, a global element is declared for each type, and the schema places these elements in a hierarchy mirroring the inheritance pattern of the types .
these types can be included in a gmd:dataset document by import as types for <relationshiptype> and <sequencerelationship> elements  or by adding content elements .
an important feature of <relationship> elements, in common with other data elements, is that they can record the provenance of the assertion through <externalreference> elements, allowing users to validate and accept or reject these relationships.
arkdb web services
roslin institute curates an integrated genomic mapping database for farm animal genetics, arkdb  <cit> .
mapping data can be accessed by an open access web application with data being displayed textually or explored graphically as aligned maps.
however, users would benefit from the provision of bulk data export facilities to allow reuse of the mapping data for their own analyses and applications, for example integrating arkdb data with their own data, and potentially with data from third-party data sources.
the semantic complexity of the genomic data held in arkdb is beyond that of existing genomic exchange formats, typically delimited flat-file formats which have been designed primarily to accommodate sequence annotation information  or ad hoc lightweight data serialisation formats such as yaml  <cit> .
in order to accommodate the full diversity of information held in arkdb we have built a suite of web services  which return mapping data structured as gmd validating documents.
services are built and deployed on the xfire platform  <cit> , with auto generation of service wsdls.
the services are exposed singly and as an aggregated wsdl service.
this aggregated wsdl has been modified to import the gmd schema and to specify that all of the services return data of type gmd:dataset  with the genomicmappingdata.xsd schema).
services and wsdls are exposed at  .
the wsdl at  uses the same services but specifies that returned documents conform to the gmd schema.
individual services take a number of query parameters  such as: a species or chromosome name or a database identifier.
and return the response information as a dataset document.
the services are implemented using the arkdb web application's java model and api, and serialize ark objects to xml.
each individual service returns an internally consistent document filled in with appropriate data element values for that query.
for example, the speciesservice provides a single getallspecies method that returns a document with limited details of all the species represented in the arkdb, i.e.
only the metadata and speciescontainer elements contain data.
on the other hand, the karyotypeservice provides a method to getallspecieskaryotypes which additionally fills in chromosome data in the chromosomes container, where each chromosome cross references the source species.
further methods allow karyotypes to be retrieved by species name or arkdb accession number.
a more complicated service such as mapservice provides more extensive information to the returned gmd document.
for example, the getmapsforchromosome takes speciesname and chromosomename parameters, and return data about species, chromosomes, maps and analyses.
the actual mappings on a map are returned by a method in the mappingsservice, which returns mappings data as well as data about the mapped markers, clones, sequences or other objects.
these returned xml documents necessarily expand in size, but the xfire soap api efficiently handles data compression and transfer.
the service designer controls the level of detail provided in each request, with the ability to 'drill down' provided by chaining data parsed from the results of one request as input parameters to the next.
for example, full details on an individual marker discovered on a mappingservice request can be obtained by querying the markerservice which will return not only mapping data about that marker, but also any relationships held about that marker in the database, which for example might include known associations with other markers, genes or sequences and cross references to third party data resources.
taverna workflows using the arkdb web services
the structure of the arkdb web services described above allows requests to be chained together in a workflow to drill down and query through the data held in the database.
both the gmd schema and the web services were designed to be compatible with the taverna workbench application  <cit> .
taverna is an open-source workflow tool that allows users to construct analysis workflows from components located on both local and remote machines, and run these workflows incorporating their own data or query parameters.
we have used methods from the arkdb web services as external components in workflows and used the taverna 'xmlsplitter' processor and java xpath 'widget' to parse through the structure of the returned documents to extract the data fields desired.
in this manner it is possible to chain web services together, by extracting the required value from one web service response and using it as the input of a subsequent query.
in an example workflow we join two service methods 'fetchnamedspecieskaryotype' and 'fetchmapsforchromosome' by extracting all the chromosome names from the first response and chaining into an iteration over the second service, passing in the parsed chromosome name from the first result set together with original species name.
the workflow is shown in figure  <dig> and the workflow document is available as additional file 5: demoworkflow <dig> xml.
when initiated with the input parameter species name 'pig' the resulting output is a set of  <dig> dataset documents which are conformant with the gmd schema, each containing details of the maps found on one of the chromosomes.
the level of detail for each map is determined by the 'fetchmapsforchromosome' service and includes species, chromosome, map, and analysis data.
the details of genetic entities mapped on these maps could be obtained by parsing out each map accession, again using the taverna xml splitter, and passing this as the input mapaccession parameter for the 'fetchmappingsformap' service.
additional taverna processors could be added as widgets to the workflow that could generically parse any result document, because they all conform to the same xsd schema.
for example it would be trivial to add an xslt processor or java dom processing bean to combine multiple result sets into a single dataset document.
the use of additional widgets to join third party datasources is demonstrated in figure  <dig>  the workflow document is available as additional file 6: demoworkflow <dig> xml, and the resulting data document is available as additional file 3: demo2result.xml.
in this workflow, details of a single marker are retrieved and any external references to pubmed or genbank sequence resources are parsed using the taverna xpath widget.
the xml records for these are then retrieved from ncbi using taverna widgets that connect to ncbi web services.
the results of running this workflow with the input markeraccession = 'arkmkr00023953' include two pubmed documents, a genbank sequence document and the details of mappings of this marker on four maps in arkdb.
because taverna is able to 'scavenge'  publicly available web services, in particular any service described by a wsdl document, workflows can access and therefore integrate data held in a wide range of bioinformatics resources.
if further genomic mapping resources provided wsdl accessible data – formatted according to our proposed schema – then semantically meaningful data integration across resource and species boundaries would be possible using the tools currently available in taverna.
CONCLUSIONS
we have developed a data exchange standard for genomic mapping data that allows us to define the structure and general semantics of data exported via web services from our in house genomic mapping resources.
data exported in our data exchange standard can then be meaningfully integrated into workflows created using the taverna workbench.
adoption of this exchange format  by further data providers will allow integration of mapping data from distributed data resources, either by incorporation of wsdl described web services into taverna workflows, or by any bespoke web service client application.
our exchange format provides several important features to facilitate its generic use by a wide community of data providers and consumers.
we have aimed for a relaxed semantic definition of the data objects found in the mapping world.
this should simplify the data mapping process, both that performed by the data provider  and between data resources when data users integrate data from multiple sources.
we provide extensibility within the schema, both to allow additional information to be included in gmd conformant documents, and to include specific datatypes from third party sources such as ontologies or other data schemas.
we provide an external reference mechanism to carry references to third party data resources; obvious uses for this are for pubmed citations, genbank accessions or ensembl gene ids.
we provide a structure to record any type of relationship between two data objects, thus not constraining the document format to the common mapping relationships with which we are familiar.
we provide mechanisms to record the provenance of data: by detailing the datasource  and by allowing reference to external datasources both for individual data elements and any for individual data relationships and assertions.
we provide a mechanism for recording ad hoc assertions about data objects which should allow flexibility in representing nuanced observations about the data, for example third party comments that a particular piece of data is obsolete or incorrect.
authors' contributions
al conceived of the study, and participated in its design and coordination.
tp designed the data transfer schema, implemented the arkdb webservices, the demonstration workflows and drafted the manuscript.
both authors read and approved the final manuscript
supplementary material
additional file 1
genomicmappingdata.xsd.
proposed genomicmappingdata xml schema  for exchange of genomic mapping data.
click here for file
additional file 2
demo1result <dig> xml.
one of  <dig> gmd conformant data documents generated by executing demoworkflow <dig> in taverna.
click here for file
additional file 3
demo2result.xml.
the gmd conformant data document generated by executing demoworkflow <dig> in taverna .
click here for file
additional file 4
genomicdatarelationships.xsd.
example xml schema  for defining relationships between genomic mapping data.
click here for file
additional file 5
demoworkflow <dig> xml.
example taverna workflow .
click here for file
additional file 6
demoworkflow <dig> xml.
example taverna workflow .
click here for file
additional file 7
fig <dig> pdf.
full graphical representation of the taverna workflow summarized in figure  <dig>
click here for file
additional file 8
demoworkflow <dig> xml.
example taverna workflow .
click here for file
additional file 9
appendtofile.xml.
nested taverna workflow referenced in demoworkflow <dig> xml .
click here for file
additional file 10
listfromfile.xml.
nested taverna workflow referenced in demoworkflow <dig> xml .
click here for file
acknowledgements
the authors would like to thank members of the comparagrid project  <cit>  for useful experience in exploring the issues of semantically controlled data integration.
this work was funded by the bbsrc grant number bbs/b <dig>

 data integration across disparate datasources is a common problem, not limited to the sphere of bioinformatics, and has been addressed in many ways. cross indexing and hypertext linking of resources has historically been used for accessing bioinformatics data but is curation intensive and does not adequately address different datatypes found in the distributed datasources. however, cross referencing is widely used and forms the basis of the highly successful entrez data retrieval system. a common approach for integrating bioinformatics data is to warehouse data according to a shared data schema. data in the individual data sources must be mapped to the shared schema, capturing both the syntax of the data structure and the semantics of what the data objects represent. the warehousing approach therefore incurs heavy data curation costs in creating and maintaining the warehouse and requires extensive computing resources; the alternative approach of federating the warehouse introduces further problems in distributing queries across the underlying distributed resources. an alternative recent approach involves attempting to integrate data semantically through the use of defined ontologies describing a particular data domain. in addition to the widely used gene ontology which provides a controlled vocabulary for annotating gene and gene function attributes that can then be used in index based retrieval systems, other formal ontologies are actively being developed to support bioinformatics, particularly under the obo umbrella. well-defined, detailed ontologies have been created representing common concepts used across the bioinformatics domain, e.g. for sequence features and common concept relationships and also more specific concepts for particular domains, e.g. the amphibian gross anatomy. these ontologies provide excellent controlled terminologies for data description and annotation, but do not provide data transport protocols and provide neither the structure nor semantics required for data integration. consequently, whilst ontology based descriptions of data objects can be compared across data sets – two objects with similar annotations may share similar properties – these annotations do not capture or assert actual relationships between the data objects. technologies developed to support the'semantic web' such as owl, the'web ontology language' provide an approach for exposing and integrating semantically consistent datasources and the potential for semantic web integration of bioinformatics resources is being actively explored. recently we have been involved in the comparagrid project which aims to integrate genomic data by mapping data sources to a shared owl ontology for genomic information, thus facilitating semantic integration and query. however, such an approach is computationally expensive and as yet difficult to implement using available semantic ontology tools. a more lightweight and arguably more practical approach for data exchange is to encourage the curators of data resources to provide data export facilities in a common simple exchange format, which both captures the data structure and provides a degree of semantic clarity to the exported data, without providing the exacting constraints of a formal ontology. xml has long been recognized as a useful data structure with which to implement formal exchange formats. such an approach allows application developers to develop their integration systems against the common data format, where the structure of the data is unambiguous, and the semantics are sufficiently defined for usability. here we present our approach of using a simple structured xml schema to define the data exchange structure for genetic mapping information, an approach successfully used for integrating data in other bioinformatics domains and also for specifying standards defining the key information to include when reporting experimental results. use of common exchange schemas to define data structures allows users to parse the data syntax into semantically described data objects. our genomic mapping data schema allows common information types for our domain to be represented in a syntactically defined structure, thus enabling gmd conformant data documents to be programatically parsed into meaningful genetic information. furthermore, the gmd schema is extendable to handle additional datatypes. extension may be achieved not only by evolution of the schema, but simply by using datatypes defined elsewhere, for example by importing additional schemas to the data document, or referring to controlled vocabularies or external ontologies. to illustrate how the schema can be used we have built web services which export data from the arkdb genomic mapping resource using our exchange format. we also illustrate how additional defined terms can be imported from a second schema which defines common data relationships relevant to the genomic mapping domain. we demonstrate how the taverna workbench can consume these web services into workflows to harvest and use mapping data for bioinformatics tasks. this is possible because taverna can parse the xml data structure of the data documents provided as web service responses in the context of the defined data format.  schema design one approach for developing a shared schema for data exchange in a given information domain is to initiate a consultation and prototyping cycle amongst interested parties. however, this'design by committee' approach is frequently protracted and contentious. in order to'kick start' development of a usable standard for genomic mapping data we have developed a candidate exchange schema that seeks to capture the important core data concepts and relationships, whilst being potentially expandable to incorporate additional requirements if necessary for wider use. to encourage adoption, a generic, unambiguous and semantically'neutral' schema is desirable. indeed many of the common data objects in the genomic mapping domain cannot be defined unambiguously across user groups. therefore the schema avoids precise semantic definition of concepts and leaves interpretation to individual data providers and applications. however, the structured syntax of the schema allows any important'relationships' between concepts to be fully represented. furthermore, because xml data documents can reference multiple schemas, users can further define their information by reference to additional external schemas. the generic nature of our mapping schema allows any type of map to be represented, allowing integration of the many types of data found in genetic resources. for example the representation of genetic linkage maps and sequence maps is conceptually and syntactically the same: the positioning of mapped objects on a map object using a coordinate system. the prototype schema genomicmappingdata.xsd,, includes in-line descriptive annotations. example data exchange documents conforming to the schema are provided as additional files and, and afford examples of the data structures decribed below. we are also hosting an interactive wiki site to provide further guidance on best practice for schema usage, and as a forum for discussion of schema refinement and evolution by interested data providers and users. the structure of our gmd schema aims to be clear and logical, but is primarily designed for unambiguous data storage and programmatic parsing rather than'human readability'. the root element of the document is <dataset>, which is itself defined as a'complex type', thus allowing this'type' to be referenced in other xml documents that import the gmd schema. for example, this allows a web service description document to specify a return type of'gmd:dataset' for a particular web service, thus enabling parsing of returned result documents by a web service client according to the defined schema structure. the children of the <dataset> root element are multiple, single-copy containers for the data objects and for binary data relationships, assertions about data, third-party datasources such as pubmed or ensembl, references to these and a <metadata> container for information about the provenance of the dataset document. all the main data elements in the schema have an'id' attribute, which might typically be the source database id. an'id' attribute should be unique within a document, but this is not enforced in the schema. these data objects represented by elements with an'id' attribute can be reused by'foreign key' reference in the document by various'reference type' elements. these have an'idref' attribute, which should reference an extant'id' attribute of another element. for example, a <species> element with'id = x', can be referenced by a <speciesref> element with'idref = x', in this case efficiently allowing multiple objects to declare that they pertain to a particular organism. similarly, various mapping objects may reference a particular <analysis> through an <analysisref>, providing important contextual information. in addition, the top level containers are allowed document unique'id' attributes of type'xsd:id'. in practice, this greatly assists programmatic parsing of the document as such elements can be obtained from a document model by their'id' value. the information about each data object is held in subsidiary elements. in designing the schema, elements were preferred over attributes for data storage in order to allow the built-in taverna parser to access data values. in order not to overly constrain schema users, most data elements are'optional' apart from where required for structural association. for example, a <chromosome> element optionally contains <chromosomename>, <dbidentifier>, <dataaccessmethod>, <speciesref> and <externalreferencerefs> whilst a <relationship> element logically must contain <objectref>, <subjectref> and <relationshiptype> elements.'terminal' data elements generally have content of type'xsd:string' or'xsd:double', whilst those of reftype contain only an'idref' attribute. several elements such as <units>, <qtldetails>, <otherdata> and the <'object'type> child elements are allowed content defined as being of'xsd:anytype', allowing any data structure, or perhaps as a type from the obo units of measurement ontology, by using the owl class url. this external type could be represented by a single element of type xsd:string or xsd:anyuri, a type structure defined or not by schema import, or might be of gmd:reftype and point at an externalreference element in the document itself. allowing <units> to be defined as any type permits a generic representation of any map type data in schema-compliant dataset documents. of course inclusion of xsd:anytype extensions only allows defined client parsing if the extended types are referenced by import of an external xsd schema. structural nesting of elements is used where logical, for example the <mappings> that lie on a given <map> are nested under that <map>, and a sequence associated with a particular <marker> or <clone> may be nested as a <sequenceref> reference under that object. however, any data relationship may alternatively be stored as a binary relationship. rather than provide multiple subsumption-typed versions of data objects such as map, sequence or marker, which would cause gross schema inflation when accounting for all users' requirements, such elements contain optional child elements to record a specific'objecttype' for the object and are also allowed content of'xsd:anytype', which, as described above, could hold a string value such as "linkage map", "radiation hybrid map", "est", "genomic". in order to promote data consistency within a user group, permitted string values might derive from enumerated lists, or from more controlled defined vocabularies, or indeed types could be imported from external sources. this semantically'loose' mechanism enables a'marker' object to be interpreted generically as an'undefined genetic marker' or, as a specific type of marker if such objecttypes are provided and documented by the data provider and are relevant to the consumer application. an important feature of the dataset schema is the provision of full data provenance and data access protocols; only by providing this information can reliable data integration be achieved. to this end an optional element <dbidentifier> is allowed for most data elements which can be used to record the identifier or accession number for that object in the datasource. in addition, the optional <dataaccessmethod> element can detail how to actually access a record of this object from the source datatabase. providing this information enables programmatic expansion of datasets, for example where one dataset provides details of markers found on a particular map, and each marker provides its access method, a client program could fetch the full record for each marker, which might detail every map that this marker is associated with, its relationships to other markers or sequences and any external datasource links. in order to facilitate integration across datasources most data elements in the schema may include external references to third party data repositories. this is provided by <external reference> elements which detail an external datasource name/location and a specific object id therein. these are referenced internally in the document by optional <externalreferenceref> child elements for a given data element, which point to a <external reference> element. for example this could allow a sequence in the dataset to be explicitly linked to a sequence in genbank by its genbank accession. the client can then use this genbank id to retrieve the original record for this sequence. this allows integrative workflows to be composed, for example using the taverna workbench. representing data relationships a part of the knowledge domain that is typically hard to capture is represented by <relationship> elements, which capture relationships between two data objects. in order to capture the nature of the relationship each <relationship> must be'typed' via a <relationshiptype> child element. ultimately, use and interpretation of relationships will be dependant on a shared interpretation by data users and providers. again data interpretation and consistency might be assisted by provision of a controlled'vocabulary' of possible types or defined terms or types could be imported from external sources. however, precise semantic definition of relationship types across the whole potential user domain is perhaps overly ambitious, and controlled vocabularies for particular sub-domains or'user groups' may prove more pragmatic. by way of demonstration, we have defined a relationship type schema, genomicdatarelationship.xsd,. this schema defines complex types that represent real data relationship types in genomic datasets. the datatypes are derived by extension of parent types to represent the inheritance/subsumption hierarchy of relationship types. in order to visualize the relationship type inheritance in gdr, a global element is declared for each type, and the schema places these elements in a hierarchy mirroring the inheritance pattern of the types. these types can be included in a gmd:dataset document by import as types for <relationshiptype> and <sequencerelationship> elements or by adding content elements. an important feature of <relationship> elements, in common with other data elements, is that they can record the provenance of the assertion through <externalreference> elements, allowing users to validate and accept or reject these relationships. arkdb web services roslin institute curates an integrated genomic mapping database for farm animal genetics, arkdb. mapping data can be accessed by an open access web application with data being displayed textually or explored graphically as aligned maps. however, users would benefit from the provision of bulk data export facilities to allow reuse of the mapping data for their own analyses and applications, for example integrating arkdb data with their own data, and potentially with data from third-party data sources. the semantic complexity of the genomic data held in arkdb is beyond that of existing genomic exchange formats, typically delimited flat-file formats which have been designed primarily to accommodate sequence annotation information or ad hoc lightweight data serialisation formats such as yaml. in order to accommodate the full diversity of information held in arkdb we have built a suite of web services which return mapping data structured as gmd validating documents. services are built and deployed on the xfire platform, with auto generation of service wsdls. the services are exposed singly and as an aggregated wsdl service. this aggregated wsdl has been modified to import the gmd schema and to specify that all of the services return data of type gmd:dataset with the genomicmappingdata.xsd schema). services and wsdls are exposed at. the wsdl at uses the same services but specifies that returned documents conform to the gmd schema. individual services take a number of query parameters such as: a species or chromosome name or a database identifier. and return the response information as a dataset document. the services are implemented using the arkdb web application's java model and api, and serialize ark objects to xml. each individual service returns an internally consistent document filled in with appropriate data element values for that query. for example, the speciesservice provides a single getallspecies method that returns a document with limited details of all the species represented in the arkdb, i.e. only the metadata and speciescontainer elements contain data. on the other hand, the karyotypeservice provides a method to getallspecieskaryotypes which additionally fills in chromosome data in the chromosomes container, where each chromosome cross references the source species. further methods allow karyotypes to be retrieved by species name or arkdb accession number. a more complicated service such as mapservice provides more extensive information to the returned gmd document. for example, the getmapsforchromosome takes speciesname and chromosomename parameters, and return data about species, chromosomes, maps and analyses. the actual mappings on a map are returned by a method in the mappingsservice, which returns mappings data as well as data about the mapped markers, clones, sequences or other objects. these returned xml documents necessarily expand in size, but the xfire soap api efficiently handles data compression and transfer. the service designer controls the level of detail provided in each request, with the ability to'drill down' provided by chaining data parsed from the results of one request as input parameters to the next. for example, full details on an individual marker discovered on a mappingservice request can be obtained by querying the markerservice which will return not only mapping data about that marker, but also any relationships held about that marker in the database, which for example might include known associations with other markers, genes or sequences and cross references to third party data resources. taverna workflows using the arkdb web services the structure of the arkdb web services described above allows requests to be chained together in a workflow to drill down and query through the data held in the database. both the gmd schema and the web services were designed to be compatible with the taverna workbench application. taverna is an open-source workflow tool that allows users to construct analysis workflows from components located on both local and remote machines, and run these workflows incorporating their own data or query parameters. we have used methods from the arkdb web services as external components in workflows and used the taverna'xmlsplitter' processor and java xpath'widget' to parse through the structure of the returned documents to extract the data fields desired. in this manner it is possible to chain web services together, by extracting the required value from one web service response and using it as the input of a subsequent query. in an example workflow we join two service methods'fetchnamedspecieskaryotype' and'fetchmapsforchromosome' by extracting all the chromosome names from the first response and chaining into an iteration over the second service, passing in the parsed chromosome name from the first result set together with original species name. the workflow is shown in figure and the workflow document is available as additional file 5: demoworkflow xml. when initiated with the input parameter species name'pig' the resulting output is a set of dataset documents which are conformant with the gmd schema, each containing details of the maps found on one of the chromosomes. the level of detail for each map is determined by the'fetchmapsforchromosome' service and includes species, chromosome, map, and analysis data. the details of genetic entities mapped on these maps could be obtained by parsing out each map accession, again using the taverna xml splitter, and passing this as the input mapaccession parameter for the'fetchmappingsformap' service. additional taverna processors could be added as widgets to the workflow that could generically parse any result document, because they all conform to the same xsd schema. for example it would be trivial to add an xslt processor or java dom processing bean to combine multiple result sets into a single dataset document. the use of additional widgets to join third party datasources is demonstrated in figure the workflow document is available as additional file 6: demoworkflow xml, and the resulting data document is available as additional file 3: demo2result.xml. in this workflow, details of a single marker are retrieved and any external references to pubmed or genbank sequence resources are parsed using the taverna xpath widget. the xml records for these are then retrieved from ncbi using taverna widgets that connect to ncbi web services. the results of running this workflow with the input markeraccession ='arkmkr00023953' include two pubmed documents, a genbank sequence document and the details of mappings of this marker on four maps in arkdb. because taverna is able to'scavenge' publicly available web services, in particular any service described by a wsdl document, workflows can access and therefore integrate data held in a wide range of bioinformatics resources. if further genomic mapping resources provided wsdl accessible data – formatted according to our proposed schema – then semantically meaningful data integration across resource and species boundaries would be possible using the tools currently available in taverna.  we have developed a data exchange standard for genomic mapping data that allows us to define the structure and general semantics of data exported via web services from our in house genomic mapping resources. data exported in our data exchange standard can then be meaningfully integrated into workflows created using the taverna workbench. adoption of this exchange format by further data providers will allow integration of mapping data from distributed data resources, either by incorporation of wsdl described web services into taverna workflows, or by any bespoke web service client application. our exchange format provides several important features to facilitate its generic use by a wide community of data providers and consumers. we have aimed for a relaxed semantic definition of the data objects found in the mapping world. this should simplify the data mapping process, both that performed by the data provider and between data resources when data users integrate data from multiple sources. we provide extensibility within the schema, both to allow additional information to be included in gmd conformant documents, and to include specific datatypes from third party sources such as ontologies or other data schemas. we provide an external reference mechanism to carry references to third party data resources; obvious uses for this are for pubmed citations, genbank accessions or ensembl gene ids. we provide a structure to record any type of relationship between two data objects, thus not constraining the document format to the common mapping relationships with which we are familiar. we provide mechanisms to record the provenance of data: by detailing the datasource and by allowing reference to external datasources both for individual data elements and any for individual data relationships and assertions. we provide a mechanism for recording ad hoc assertions about data objects which should allow flexibility in representing nuanced observations about the data, for example third party comments that a particular piece of data is obsolete or incorrect. authors' contributions al conceived of the study, and participated in its design and coordination. tp designed the data transfer schema, implemented the arkdb webservices, the demonstration workflows and drafted the manuscript. both authors read and approved the final manuscript supplementary material additional file 1 genomicmappingdata.xsd. proposed genomicmappingdata xml schema for exchange of genomic mapping data. click here for file additional file 2 demo1result xml. one of gmd conformant data documents generated by executing demoworkflow in taverna. click here for file additional file 3 demo2result.xml. the gmd conformant data document generated by executing demoworkflow in taverna. click here for file additional file 4 genomicdatarelationships.xsd. example xml schema for defining relationships between genomic mapping data. click here for file additional file 5 demoworkflow xml. example taverna workflow. click here for file additional file 6 demoworkflow xml. example taverna workflow. click here for file additional file 7 fig pdf. full graphical representation of the taverna workflow summarized in figure click here for file additional file 8 demoworkflow xml. example taverna workflow. click here for file additional file 9 appendtofile.xml. nested taverna workflow referenced in demoworkflow xml. click here for file additional file 10 listfromfile.xml. nested taverna workflow referenced in demoworkflow xml. click here for file acknowledgements the authors would like to thank members of the comparagrid project for useful experience in exploring the issues of semantically controlled data integration. this work was funded by the bbsrc grant number bbs/b 
this schema represents the various types of data objects commonly described across mapping datasources and provides a mechanism for recording relationships between data objects. we have built demonstration web services that export data from our arkdb database according to the gmd schema, facilitating the integration of data retrieval into taverna workflows. web services retrieving gmd-compliant mapping data demonstrate that use of this exchange standard provides a practical mechanism for achieving data integration, by facilitating syntactically and semantically-controlled access to the data. the data exchange standard we present here provides a useful generic format for transfer and integration of genomic and genetic mapping data. genomic analysis, particularly for less well-characterized organisms, is greatly assisted by performing comparative analyses between different types of genome maps and across species boundaries. the schema is extensible via the inclusion of additional datatypes, which can be achieved by importing further schemas, e.g. consequently data integration and comparison must be performed in an ad hoc manner. it also provides mechanisms for recording data provenance and for cross referencing external datasources.
 genomic analysis, particularly for less well-characterized organisms, is greatly assisted by performing comparative analyses between different types of genome maps and across species boundaries. various providers publish a plethora of on-line resources collating genome mapping data from a multitude of species. datasources range in scale and scope from small bespoke resources for particular organisms, through larger web-resources containing data from multiple species, to large-scale bioinformatics resources providing access to data derived from genome projects for model and non-model organisms. the heterogeneity of information held in these resources reflects both the technologies used to generate the data and the target users of each resource. currently there is no common information exchange standard or protocol to enable access and integration of these disparate resources. consequently data integration and comparison must be performed in an ad hoc manner.  we have developed a simple generic xml schema to allow export and exchange of mapping data in a common lightweight xml document format. this schema represents the various types of data objects commonly described across mapping datasources and provides a mechanism for recording relationships between data objects. the schema is sufficiently generic to allow representation of any map type. it also provides mechanisms for recording data provenance and for cross referencing external datasources. the schema is extensible via the inclusion of additional datatypes, which can be achieved by importing further schemas, e.g. a schema defining relationship types. we have built demonstration web services that export data from our arkdb database according to the gmd schema, facilitating the integration of data retrieval into taverna workflows.  the data exchange standard we present here provides a useful generic format for transfer and integration of genomic and genetic mapping data. the extensibility of our schema allows for inclusion of additional data and provides a mechanism for typing mapping objects via third party standards. web services retrieving gmd-compliant mapping data demonstrate that use of this exchange standard provides a practical mechanism for achieving data integration, by facilitating syntactically and semantically-controlled access to the data. 