Contents

The RDF/XML format for biositemaps.rdf

A biositemap is an RDF file that conforms to the RDF Schema defined in the Biomedical Resource Ontology. Each biositemap is a collection of resource descriptions describing your tools.

The anatomy of an RDF Biositemap

The following example shows a simple RDF biositemap describing a single resource.

	<desc:Resource_Description rdf:about="http://www.bioontologies.org/biositemaps/NCBO.owl#BioPortal">
<desc:resource_name>BioPortal</desc:resource_name>
<desc:authors>Benjamin Dai, Misha Dorf, Nick Griffith</desc:authors>
<desc:description> A Web portal to a virtual library of ontologies and ontology tools </desc:description>
<desc:URL>http://www.bioontology.org/ncbo/faces/index.xhtml</desc:URL>
<desc:license>Mozilla</desc:license>
<desc:keywords>Web portal, ontologies</desc:keywords>
<desc:organization>NCBO</desc:organization>

<!-- The reference to resource types defined in the BRO ontology -->
<!-- Each resource can have more than one of these -->
<!-- The value must be one of the classes defined in the BRO ontology -->
<desc:resource_type>
<BRO:Ontology_Development_and_Management/>
</desc:resource_type>
<!-- End of the reference to the resource type -->

<!-- Version information is a nested object -->
<desc:version_information>
<desc:Version_Information>
<desc:development_stage>production</desc:development_stage>
<desc:release_date rdf:datatype="http://www.w3.org/2001/XMLSchema#date"> 2/1/2007 </desc:release_date>
<desc:version>1</desc:version>
</desc:Version_Information>
</desc:version_information>
<!-- End of the version information object -->
</desc:Resource_Description>

We can now look at the elements of this definition in detail.

The definition starts with the declaration that it is a Resource_Description and an identifier of the resource. The definition is closed by the closing tag for the Resource_description:

	<desc:Resource_Description rdf:about="http://www.bioontologies.org/biositemaps/NCBO.owl#BioPortal">

<!--Resource description goes here-->
</desc:Resource_Description>

Between the opening and the closing tags are the simple fields describing the resource:

		<desc:resource_name>BioPortal</desc:resource_name>
<desc:authors>Benjamin Dai, Misha Dorf, Nick Griffith</desc:authors>
<desc:description> A Web portal to a virtual library of ontologies and ontology tools </desc:description>
<desc:URL>http://www.bioontology.org/ncbo/faces/index.xhtml</desc:URL>
<desc:license>Mozilla</desc:license>
<desc:keywords>Web portal, ontologies</desc:keywords>
<desc:organization>NCBO</desc:organization>

We list all the fields that are defined in the BRO below. Note that each specific resource description does not have to specify values for all the fields. Each description can also have additional fields (but the tools processing biositemaps may not be able to process information in these additional fields). If a field has more than one value, you can specify it several times, or list the values separated by commas.

The reference to the resource type is one of the key parts of the definition. This reference indicates what type of resource--among the ones defined in the Biomedical Resource Ontology--your resource is. This reference has the following format:

		<desc:resource_type>
<BRO:Ontology_Development_and_Management/>
</desc:resource_type>

The value (appearing in red in the box above) must be a class name from the BRO. If the value is not a class name in BRO, the tools may not be able to display your resource among search result for any BRO resource types. Your resource description would still be valid RDF though. You can have more than one resource type for a resource.

Finally, you can describe the version of your resource:

		<desc:version_information>
<desc:Version_Information>
<desc:development_stage>production</desc:development_stage>
<desc:release_date rdf:datatype="http://www.w3.org/2001/XMLSchema#date"> 2/1/2007 </desc:release_date>
<desc:version>1</desc:version>
</desc:Version_Information>
</desc:version_information>

The RDF file has a preamble that defined the namespaces and imports the BRO ontology and a closing statement that

<?xml version="1.0"?>
<!-- The preamble defines the relevant namespaces and opens the RDF block in the XML file -->
<rdf:RDF
xmlns:BRO="http://bioontology.org/ontologies/BiomedicalResourceOntology.owl#"
xmlns:xsp="http://www.owl-ontologies.com/2005/08/07/xsp.owl#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:desc="http://bioontology.org/ontologies/biositemap.owl#"
xmlns="http://www.bioontologies.org/biositemaps/NCBO.rdf#"
xml:base="http://www.bioontologies.org/biositemaps/NCBO.rdf"> <!-- The last two lines in the preamble above define the namespace for your biositemap.--> <!-- The rest of the URLs should be exactly as above -->

<!-- Import the BRO ontology: this step is required in order to use the vocabulary defined in the BRO -->
<owl:Ontology rdf:about="">
<owl:imports rdf:resource="http://bioontology.org/ontologies/BiomedicalResources.owl"/>
</owl:Ontology> <!--A list of resource descriptions goes here--> </rdf:RDF>

Extending Biositemaps

A biositemap is an RDF file and each description in a biositemap is an RDF Resource. Thus, developers can make additional statements about these resources and add new categories of resources. Here are the details of some of the ways in which developers can extend their biositemaps while preserving their conformance to the BRO Information Model:

Add new properties to the resource descriptions: For example, a developer wants to add an internal name to a resource that is defined in a biositemap (there is no "internal_name" property in the Information Model). The developer needs to add the following statements to the biositemap:


   <!-- Define the new property -->
   <rdf:Property rdf:ID="internal_name">

   <!-- Use the new property with the resource description that was defined elsewhere -->	
   <desc:Resource_Description rdf:about="http://www.bioontologies.org/biositemaps/NCBO.owl#BioPortal">
      <internal_name>NCBO BioPortal</internal_name>
   </desc:Resource_Description>

Add new classes to extend the Biomedical Resource Ontology: For example, a developer wants to add a new class of resources that is not present in the BRO and add this class of resources to describe his own resource:

   	
   <!-- Define the new class as a subclass of an appropriate class in the BRO:Resource hierarchy -->
   <rdfs:Class rdf:ID="Ontology_Mapping">
      <rdfs:subClassOf rdf:resource = "BRO:Software"/>
   </rdfs:Class>
	 
   <!-- Use the new class to add a resource type to the resource description that was defined elsewhere -->	
   <desc:Resource_Description rdf:about="http://www.bioontologies.org/biositemaps/NCBO.owl#BioPortal">
      <desc:resource_type>
         <BRO:Ontology_Mapping/>
      </desc:resource_type>
   </desc:Resource_Description>
	

Note that any tool that processes the biositemap and looks for subclasses of BRO:Resource will also bring up the resource that we have just defined because its resource type is a subclass of a BRO class (BRO:Software).

Define alternative names for the properties in the Information Model: Suppose a developer wants to use a different name for a property (e.g., "author" instead of "desc:contact_person"). He can define a new property, and then declare it to be equivalent to one of the properties in the Information Model. Then, any time he uses the new property, a reasoner can infer that it is the same as the equivalent property:


   <!-- Define the new property -->
   <rdf:Property rdf:ID="author">

   <!-- Declare it to be equivalent  -->
   <rdf:Property rdf:about="author">
      <owl:equivalentProperty rdf:resource = "desc:contact_person"/>
   </rdf:Property>
	

Biositemap and BRO Backward Compatibility

It is recognized that the Biositemaps initiative, in order to remain current, needs to evolve by adding and occassionally deprecating properties and BRO classes. The following policy applies to backward compatibility of the biositemaps Information Model and BRO:

  • I. All Biositemap API software must gracefully handle any deprecated or unknown classes and/or properties. The existence of deprecated or unknown classes should not prevent the client from using any Biositemap API or user interface.
  • II. A deprecated BRO class will be moved to a DEPRECATED sub-class within the BRO, along with annotation recommending alternate classes if available.