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.

There is clearly a grey area in choosing at what level you should start modelling an abstraction layer in your ontology. This line should be drawn at the point at which the things you are modelling fall into your domain - i.e. the boundary (contract) at which your internal systems would need to bind with your APIs and RDF.

the use of existing public domain ontologies in one’s own ontology allows us to publish RDF such that external consumers (machines or humans) will already know how to interpret and use the knowledge described therein.