yes of course we can do the same thing , that we can do in sql server and oracle server because sql query language is the same query some syntax have different

sql stand for structured query language like, sql we can do these statements

1. INSERT

2. CREATE

3. UPDATE

4. DELETE

5. SELECT

Adnan Majeed Agreed. Thanks for your reply.

Try to automatically generate ontologies using existing relational databases

First I would split the issue you mention in at least 3 independent elements (considering just the directly related software side of what you mentioned, disregarding operational system or hardware):

• Data type/Concept: Ontologies
• Querying language: SQL
• Data store: Some relational database

Considering that those are totally independent elements and that the feature set delivered by ontologies is clear, you are free to mix and match the lower layers to provide a solution with acceptable access times.

For instance, as relational databases where designed with some specific transactional behaviour in mind, probably they are not the best choice for storing your data.

Something on the Hadoop ecosystem will be more appropriate, where we are usually talking about petabytes of data with very acceptable response times.

Also, that does not mean you need to change your query language as there are projects on that ecosystem that add SQL on top of it, but again, given the very specific format of the data you will be dealing with, maybe some other graph-oriented syntax would be more appropriate.

At the end it will all depend on your specific situation (regarding aspects as architecture, data size, retention, budget for servers or cloud, licenses to proprietary tools or use of open source, decision to write very specific, custom made components or just reusing as much as possible what is in the market, and so on and so forth)

In summary, IMHO it is not a question of ontology vs relation databases but just a matter of what is the recommended architecture for your specific scenario.

Oswaldo Cavalcanti Dantas Júnior Thanks for reply. Yes, it depends on the scenario.

Without knowing much about what you are doing ...

Relational databases are good for extracting known deductive truth from well-constructed queries generating syllogisms about the truthful propositions residing in the truth tables as rows in your SQL tables.

Relational databases hate queries that invert everything against everything, in a search for any possible truth in your data that might make an interesting point. This makes them go into a resource hang as they try to make a galactic join work, or simply die with a WTF message.

That is why we have map reduce, to explore as many possibilities as you want without blowing up. But you need a large number of servers to get the answer back in your lifetime.

Charles Johnson Agreed. I am also worried about the delay in executing SPARQL queris.

The long tail of map reduce is unavoidable due to Kolmogorov's zero–one law:

https://en.wikipedia.org/wiki/Kolmogorov%27s_zero%E2%80%93one_law

This means that even without the impact of an event, like a switch jamming up because the head-of-line item is destined for an over-subscribed server, and you are behind that guy continually as the retries keep blocking you on the switch until the QoS drops that retry packet, on the way to the next retry blocking packet from TCP ...

Even without that traffic accident, you can get traffic jams just from the size of the in-flight population under the Gaussian curve ... the statistics causes an inability to predict when long tail events will occur, just know that the bigger the in-flight, the higher the frequency of long tail events.

Most people doing web queries or analytics realize that the internet is not consistent, so just truncating the long tail does not degrade the quality of the answers to the query. If you can live with that unbounded uncertainty, truncate.

If you look at the Pareto figure on page 16 of:Conference Paper Information and Communications Technologies and Power

You can see that once the slope starts to flatten (delta-epsilon continuity approaching zero in the limit) you can truncate any time. So just counting answers received over unit time of multiple seconds, after the peak drops off significantly (say a factor of 5 or so from peak) and then starts to give similar answers in succession, you're done. Remember to kill off all the reduce nodes and any remaining slow map nodes.

I agreed with your comments. Thanks for your reply. Charles Johnson

为什么不用知识图谱？

Dedjun Hsu Yes, KG is better than ontology, but can we create knowledge graph without conceptualization of domain (creating ontology)?

SQL Server and ORACLE database have same functionality

Adnan Majeed Yes. I want to ask about ontology Vs DBMS (any)

Please have a look at Michael K. Bergman, The Open World Assumption: Elephant in the Room. In: AI3:::Adaptive Information blog, December 21, 2009, https://www.mkbergman.com/852/the-open-world-assumption-elephant-in-the-room/. This paper describes pros and contras on database vs. ontology, and major fiascos in big database projects.

Igor Toujilov Thanks. This article helps me.