It is proposed to use hypergraphs with hybrid schema mode for the contraction of a Semantic Network. OrientDB may be used as database here because it is simple and optimized for graph traversals.
It is really a challenge to create good ontology at once. In many Sciences there are different alternative classifications that intersect and may be suitable for different purposes. So the best choice is to allow having multiple ontologies and belonging to different classes.
In order to achieve this we may use so called "duck typing". We may have several ontologies for any domain. Each class of the Ontology is represented as a node containing names of the properties and conditions they must satisfy (i.e. according to ontology "vehicles" class car must have mandatory string property name, relationships to engine, wheels etc,) In order to say that this object is of "class A' or 'class B' we just load with class description and see its demands. If the node satisfies them, we may say that this hypernode belongs to the specified class.
Of course it is computationally intensive to make such evaluations every time, that is why we may store inside the hypernode references to the classes and ontologies it belongs to and make evaluations only on some specified events (like manual assignment, property deletion, etc.)
Ontologies can be stored and edited like ordinary hypernodes but with more with more stringent rules for editing.
Alternative classifications are normal for most sciences. Sometimes intersections of different alternatives classifications are also very important. As we try to model Science we need to deal with this.
The node must have relationships (references) to the classes from different ontologies it belongs to. Most of the properties have different names in different classes and ontologies so it is not hard to figure out having class descriptions. In the case of the same names we must explicitly tell that this property is for class A of Ontology No. 1 and this is for Ontology No. 2. Hypergraphs are perfectly suitable for such a task.
It will work like this, you write info to the class in a schema-less mode. You will know that ontologies may give additional features to the objects. for instance via auto-suggestions. In class descriptions we may write not only mandatory fields and relationships but also possible fields. So if you have an object of the car class and editing it you are getting auto-suggestions taken from the ontology (create a link to the producer, specify the number of the car, etc.). Then you push (make my object a car). Then the system evaluates all the properties, checks if satisfies its demands. If yes, it assigns the link to the class and now you can use the new features. If no it tells what properties should b added or changed. This is duck typing. Duck typing in Programming is generally are great idea. Having it also during Ontology Engineering is an superior feature. However it is also challenging. It needs to be dealt with same names of properties, clustering etc.). In the same time it is better to have it in the system from the very beginning for architectural and flexibility reasons.
Schema-less provides full flexibility, while schema-full gives additional querying and auto-suggestions as well as other powers. They may even be combined. You may start schema-less and convert it to schema-full, you can also add to schema-full objects some additional properties (like comments) that are not part of the ontology but unless there is no conflict with class descriptions it will work fine.