Implementation Details

From NCBO Wiki
Revision as of 15:55, 13 October 2008 by Noy (talk | contribs) (New page: Note: These notes are for BioPortal developers only and are not critical in understanding the BioPortal approach to metadata representation. This page provides pseudo code for using the P...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Note: These notes are for BioPortal developers only and are not critical in understanding the BioPortal approach to metadata representation.

This page provides pseudo code for using the Protege API to access and edit the metadata instances.

Dealing with instance data

Currently, BioPortal represents the class information in a ClassBean.You will probably need an InstanceBean, similar to the ClassBean, to pass around information about the instances. In fact, you can simply have a ResourceBean that does just that (unless there is special handling of superclass relation in the ClassBean). Perhaps, we will also need an AnnotationBean to encapsulate information about a particular marginal note or review.

Initializing variables that refer directly to BioPortal Metadata Ontology

At the time the server starts up, we should initialize variables of types OWLModel, OWLClass and RDFProperty corresponding to the BioPortal Metadata ontology and classes and properties in the Metadata ontology. Implementations of most API calls will refer to these variables and having them cached will speed up the queries significantly. Any time a metadata ontology is updated (doesn’t happen often of course), these will need to be re-initialized. The classes and properties that we initialize are the only ones that developers must keep intact when they custom-tailor metadata in their own BioPortal installation.

Accessing BioPortal Metadata Ontology

The knowledge base variable bioportalMetadataOntology that points to the Metadata ontology (with its instances). We create all new metadata instances in this ontology.

OWLModel bioportalMetadataOntology = new JenaOWLModel …  // however you initialize an OWL Model in BP

Classes to access ontology metadata

OWLClass virtualOntologyClass = bioportalMetadataOntology.getOWLNamedClass (“VirtualOntology”); // the class "Virtual Ontology"
RDFProperty currentVersionProperty = bioportalMetadataOntology.getRDFProperty("currentVersion"); // the property pointing to the latest version of the ontology (attached to the individuals of the VirtualOntology class)

We need to list the core properties somewhere and access them. This list can be represented somewhere in the ontology, but for now, we can have it initialized statically in the code:

	public static final String [] CORE_PROPERTY_NAMES = new String [] {

"OMV:name", "OMV:acronym", "OMV:creationDate", "OMV:description", "OMV:documentation", "OMV:endorsedBy", "OMV:domain", "OMV:ontologyLanguage", "OMV:keyClasses", "OMV:keywords" };

public static final String [] SUMMARY_PROPERTY_NAMES = new String [] { "OMV:name", "OMV:creationDate" };

We can then use these lists to initialize the ordered list of RDFProperty objects to go through:

coreProperties = new ArrayList<RDFProperty> (); for (int i = CORE_PROPERTY_NAMES.length - 1; i >= 0; i--) { String nextName = CORE_PROPERTY_NAMES [i]; RDFProperty nextProperty = bioportalMetadataOntology.getRDFProperty(nextName); coreProperties.add (nextProperty); }

The same for summaryProperties

The properties versionsProperty and viewsProperty provide access from the instance of a VirtualOntology class to the instances representing its versions and views, respectively:

versionsProperty = bioportalMetadataOntology.getRDFProperty("hasVerisons"); viewsProperty = bioportalMetadataOntology.getRDFProperty("hasViews");