[description] An accession is a string value, assigned with dcterms:identifier and at least one data source in which the accession value is usually unique. Set bk:isAccessionAmbiguous to false to specify the accession is not necessarily unique.nnbk:Concept instances are associated to bk:Accession instances via dc:identifier (NOT dcterms:identifier).

[editorial note] Those used to the ONDEX model should note that we are mapping the 'concept type' relations straight to rdf:type and the ONDEX Concept Classes to rdfs:subClassOf, with this class on the top. We see this as a natural mapping of the ONDEX model to the RDF/RDF-S/OWL standards.n[description] A Concept is the a basic unit of information in the Bio Knowledge Network Ontology. The main type of knowledge in BioKNet consists of relations (either RDF triples based on bk:relationType, or bk:Relation instances) between bk:Concept instances.nnThe recommended way to use bk:Concept is:n - subclass bk:Concept with specific classes (eg, Protein, Gene)n - instance those specific classesn - optionally, but recommended in production environments like triple stores backing SPARQL, declare your new instance an instance of bk:Concept too. While this can be inferred, having explicit instances make things easier for applications.

[editorial note] Due to possible clashes with other identifiers, you should use the namespace bkds: http://www.ondex.org/bioknet/terms/dataSources/ to define new data source.

[description] This is an abstract container to factorise those individuals for which a minimum of description attributes can be defined.nnThese are:nn- dcterms:identifier, to provide a resource identifier. Note that this is possibly valid only within a given context. it is also recommended that it is unique/unambiguous under that context, however, that is not strictly prescribed.nn- rdfs:label, to provide a resource human-readable labelnn- dcterms:description, to provide a longer resource description.n[editorial note] [kNetMiner] these properties correspond to id, fullName, description in the ONDEX model.

[editorial note] Due to possible clashes with other identifiers, you should use the namespace bkev: http://www.ondex.org/bioknet/terms/evidences/ to define new evidence types.

[editorial note] [TODO] to be completed, using VoID, pav, etc.n[description] A biological knowledge network can be grouped together into a graph. This is typically a named graph as well and used in triple stores like Virtuoso to identify networks/subsets.

[description] Relations in BioKNet are created in two ways:nn- as straight RDF statements between instances of Concept, and using subclasses of the relatedConcept property.nn- as instances of Relation, with links from the Relation instance to the relation source (relFrom property), target (relTo property) and predicate (relTypeRef property). This way to define relations is well-known as reification and it is necessary when further properties/links need to be associated to a statement.nnA reified relation can have attributes attached (bk:attribute property).nnWARNING: We strongly recommend that, if an instance of Relation (i.e., a reified relation) exists in a data set, then the corresponding plain triple exists too. For instance, if this is defined:nnnex:r0 a bk:Relation;n bk:relTypeRef ex:encodes;n bk:relFrom ex:gene0;n bk:relTo ex:prot0.nnnwe recommend to also define the triple ex:gene0 ex:encodes ex:prot0. This is to ease queries and start them from a base representation that is compliant with RDF principles.nnThe opposite (i.e., to create a bk:Relation for each bk:Concept triple based on subproperties of bk:relatedConcept, even when there aren't further properties to attach to the triple) is less important, however, we recommend to introduce this redundancy, for the same sake of easy-to-write queries and performance.nnWe suggest to base the identifiers of reified relations on the IDs (or URIs) of its three parts, e.g., MD5 ( gene0 + encodes + prot0 ). This makes it easier to find the reified version of a relation once you have the components of its identifiers. WARNING: this should be considered an application facility and never be assumed as a reliable rule.

[description] A bk:Relation, or the corresponding BioKNet triple, is composed mainly of two bk:Concept instances and a relation type. The bk:RelationElement is a convenience common container for such components.

[description] When a bk:attribute property is associated to a unit by means of this property, literal values of that property are measure values expressed in the associated unit.n[editorial note] Note that the domain of this property is a subclass of bk:attribute. This is specified by means of schema:domainIncludes, in order to keep OWL correctness.

[editorial note] All ONDEX/kNetMiner relations should go under this property.n[description] This is a top-level container, which is used to define specific relations of interest between between bk:Concept instances. See bk:Relation for a detailed description of how concept relations are model in BioKNet.nnThis property should never be used directly, a concept/concept relation of interest should always be instance of some specific subproperty of this one (TODO: closure axiom).

[editorial note] [TODO] Align to PAV and alike.n[description] The source from which an entity comes from, or was imported or alike.

[description] Links an entity, such as a concept or a relation, to the type of evidence that prove it exists, such as 'imported from database', evidence codes, 'inferred from literature'.

[editorial note] The fact that the values of this should be subclasses of bk:relationType is documented by means of schema:rangeIncludes. We don't use rdfs:range bk:relationType, because this tends to confuse ontology editors and libraries (i.e., Protege and OWL-API), which infer bk:relationType is also a clsass. It shouldn't be a big deal to link to bk:relationType using an owl:objectProperty like this, since OWL-2 should deal with this through punning (TODO: check).

[description] A generic reference to a conceptnnThis is used to attach a cross-reference of type bk:Concept to another concept or a bk:Relation.nnThis is used to relate a relation element with a non better-specified relation (which might mean things like 'see also', 'cross reference').n[editorial note] In the ONDEX/kNetMiner software, this corresponds to the concept and relation's property 'tags'.

[description] Just a test relation.

[editorial note] Note that the way units are modelled is different than other structured value models (e.g., schema.org, good relations), where units can be specified for each value. Here, units are linked to an attribute property, to specify once for all the unit to which all that property values refer to.n[description] An attribute is a literal property associated to a concept or a relation.nnSpecific attribute types (e.g., pValue, geneBegin) should be defined as subproperty of this one and proper annotations (rdfs:label, dcterms:description) attached. The new properties should also specify their range via rdfs:range and preferrably using an XSD type. Hierarchical attribute type relations should be defined via rdfs:subPropertyOf.nnNote that attributes can refer to measure values, in which case you should associate a unit to the corresponding bk:attribute subproperty.nnNote that bk:attribute is considered an abstract property container: rather than using it directly, you should always define a specific attribute subproperty to represent attributes properly.n[editorial note] Due to possible clashes with other identifiers, you should use the namespace bka: http://www.ondex.org/bioknet/terms/attributes/ to define new attributes.n[editorial note] This property is conceptually equivalent to AttributeName in ONDEX. It doesn't look correct to call it name.

[description] a property of this type provides summary figures for the contents of a graph, such as the number of concepts or relations.

[editorial note] TODO: we need to clarify what this is exactly. How can an accession be ambiguous? Examples?

[editorial note] Compared to the ONDEX model, we use bk:prefName to represent a name that has the preferred flag set to true, bk:altName to represent all the other names, bk:name for generic names. This is simpler than having a class just to store an additional flag.n[description] In bio-databases a name is often meant as something more specific than a title or a label (being more official and often shorter) and not as unique as accessions.

[description] Just a test attribute. created to show how attribute properties should be used in BioKNet.

[description] Just a test attribute. created to show how attribute properties should be used in BioKNet.

[description] Just a test relation.

[description] This is a test unit, which shows how attributes and their units are modelled in BioKNet.

[description] TODO: description.

[description] This is used in the ONDEX project to tell that entities like attributes have to be indexed in systems like Lucene.n[editorial note] This should be done at type level, eg, bk:attribte subproperty and not the single attribute value, as it is done in ONDEX. We simplify things this way (compared to ONDEX), since it doesn't make much sense to specifiy the indexing at value level (and it's not being done in the current indexing components).

[description] A class or property marked with this flag tells that, if there are equivalent classes or individuals with multiple inheritance, this entity should be used as the preferred one for the internals of the ONDEX and kNetMiner projects.nnThisi is particularly useful for managing mappings to standard ontologies.

[editorial note] This is extracted from ondex_metadata.xml, usually attributes only defines their datatype ranges.n[description] This is internal to the ONDEX project, used to track the original ONDEX datatype or range for an attribute or relation. We transform some of these types during translation of original ONDEX metadata into OWL (e.g., 'character' => 'string'), so this property is used to retrofit datatypes after editing of OWL ontologies.