BioKNO, The Biological Knowledge Network Ontology
BIOlogical KNowledge Network Ontology (BioKNO, pronounced "bio-know") is a lightweight ontology, aimed at representing biological-related knowledge networks. We use it to power the KnetMiner project.
Further information on the ontology and where it fits in KnetMiner is available from our IB2018 article.
At the most basic level, it provides simple modelling for very general entities, such as concepts, relationships and attributed-attached reified relationships.
In addition to that, entities such as structured accessions, data sources and evidence-tracking predicates are defined.
At a more specific level, the core definitions are extended with common biological entities, such as Protein, Gene, or the 'encodes' relation.
Suitable mappings are also given, in order to map the knowledge networks modelled by means of BioKNO to common linked data standards, both general ones (e.g., SKOS, OWL) and life science-specific (e.g., bioschemas).
We use/are using/plan to use BioKNO in the KnetMiner project to perform various operations, ranging from data import/integration, to graph-based queries and building of APIs.
WARNING: sometimes these views might be outdated with respect to the last versions of the original ontology files that they are based on.
The two main classes in BioKNO are
bk:Relation. The latter is related to the RDF object property
bk:relatedConcept, which of main sub-property is
Typically, the entities you want to talk about in a BioKNO knowledge network are indirect (i.e., transitive) instances
bk:Concept, while Concepts are linked together by some sub-property of
A first instance about a biological pathway, taken from our WikiPathway example:
<http://www.wikipathways.org/id1> # A pathway, a predefined class in bk_ondex.owl. This is a subclass of bk:Concept, which subclasses skos:Concept a bk:Path ; bk:evidence bkev:IMPD ; # Imported from database, a predefined constant on bk_ondex.owl # bk:prefName maps to skos-x:prefLabel bk:prefName "Bone Morphogenic Protein (BMP) Signalling and Regulation"^^<xsd:string> . bkr:TOB1 a bk:Protein ; dc:identifier bkr:TOB1_acc ; # A simplified link, hiding BioPax pathwayComponent -> BioChemicalReaction|Complex -> Protein bk:participates_in <http://www.wikipathways.org/id1> ; bk:prefName "TOB1"^^<xsd:string> . # Structured accession, allow for linking of identifier and context. bkr:TOB1_acc a bk:Accession ; dcterms:identifier "TOB1"^^<xsd:string> ; bk:dataSource bkds:UNIPROTKB; # instance of bk:DataSource. We have a list of predefined data sources. bk:is_annotated_by obo:GO_0030014.
As you can see, we have predefined entities like
bk:Path, subclassing core entities like
bk:Concept. Moreover, the
original link chains between pathways and proteins present in the BioPax data are simplified by means of the
Another example, about the gene ontology term referred by above:
obo:GO_0030014 a bk:GeneOntologyTerms ; dc:identifier obo:GO_0030014_acc ; bk:is_a obo:GO_0044424 , obo:GO_0043234 ; bk:prefName "CCR4-NOT complex" . obo:GO_0044424 a bk:GeneOntologyTerms ; dc:identifier obo:GO_0044424_acc ; bk:is_a obo:GO_0044464 ; bk:prefName "intracellular part" . obo:GO_0030015 a bk:GeneOntologyTerms; dc:identifier obo:GO_0030015_acc ; bk:is_a obo:GO_0044424, obo:GO_0043234 ; bk:part_of obo:GO_0030014; bk:prefName "CCR4-NOT core complex" .
As you can see, original URIs about external RDF data can be reused (in OWL-2, this is possible thanks to
punning). Morever, relations like
bk:part_of are more informal
than OWL/OBO relations, which might simplify the modelling. For instance, the fact that a CCR4-NOT core complex is part
of a CCR4-NOT complex is a simple direct relation, where, in OWL terms must be an axiom like "part of some CCR-NOT
Under the top-level
bk:attribute property, BioKNO provides a number of OWL datatype properties, which can be attached
to concepts and relations. For instance:
bkr:20068231 a bk:Publication ; dc:identifier bkr:20068231_acc ; bka:PMID "20068231" ; bka:YEAR "2010"^^xsd:gYear ; bka:abstractHeader "Quantitative phosphoproteomics reveals widespread full phosphorylation site occupancy during mitosis." ; bk:evidence bkev:IMPD , bkev:NAS ; bk:prefName "20068231" .
Attributes can have any suitable range and we made sensible choices for the ranges of our predefine attributes.
Attributes can be associated to relations too. Since RDF structurally supports binary relations/statement only, attributed relations must be modelled through reification:
# For practical reasons, we always expect that the straight triple is asserted, with the reified version optionally added to it. bkr:TOB1 bk:published_in bkr:20068231. bkr:citation_TOB1_15489334 a bk:Relation ; bk:relTypeRef bk:published_in; # the same relations used for straight triples bk:relFrom bkr:TOB1 ; # This is the protein in the examples above bk:relTo bkr:15489334 ; # And this is the publication above bka:Score 0.95 ; bk:evidence bkev:TM. Both attributes and object properties can be linked to a reified relation.
As you can see, a reified relation is an instance of
bk:Relation and its main properties are a pointer to the
type (which is the same object property appearing in the direct relation, and typically a sub-property of
We require that a reified relation is asserted by means of both its "straight", common RDF statement version and as an
bk:Relation. That ease certain use cases. For instance, if one has to search for the existence of a given
relation, independently on the possible attributes it might have, it's easier to search the straight version, without
having to deal with both types.