Three C’s Of Ontology Engineering / quote 1 of 3
Don't bind internal systems to public ontologies
if the Acme Company data architect models his domain using purely public domain ontologies he is enforcing an early and tightly bound contract of his internal systems (APIs and their underlying SPARQL queries) to them. If he models people and relationships using pure FOAF then Acme’s internal systems are effectively bound to a FOAF contract. If in the future FOAF goes out of fashion and becomes less widely used, and a new public domain ontology replaces it as the gold standard, then it may be a costly exercise to remodel and rebuild Acme’s internal systems to use the new ontology, as the contract binding is FOAF based. If the Acme data architect defines his own ontology classes and properties to represent People and relationships, while inheriting from FOAF (e.g. acme:Person rdfs:subClassOf foaf:Person), and then engineers internal systems using the Acme ontology, then Acme’s internal systems and APIs become less tightly bound to the public domain ontology and the interface contract is with Acme’s proprietary ontology.