Smart ontologies
The semantic web technologies introduced interesting ideas like RDF and semantic reasoning with OWL. We can produce new facts from old facts.
–
A Django ontology is just one kind of specification of an ontology It's used to create databases and generate ORM queries.
Infinity family has a rich ontology because it can be used to execute business. Business software like ERP has a complicated ontology.
Multiple kinds of things can be considered to be ontologies.
There are other technologies such as RDF and OWL which allows reasoning over relationships. There is an application I recommend called Protege which is very good for automated reasoning.
I can say that a mother is a female human with a child and then I can generate a fact when a woman is a mother.
Having knowledge graphs allows for powerful automated reasoning and automation opportunities.
In my fact collector project I use Prolog to do sime reasoning.
Inference means a query and find the free variable, such as X. Logic is a statement that is true. Here I ask two questions (1) who am I mutually friends with and (2) who am I friends with but who doesn't consider me a friend.
"Logic likes(sam, john).",
"Logic likes(sam, peter).",
"Logic likes(john, sam)."
"Inference and(likes(sam, X), likes(X, sam)).",
"Inference and(likes(sam, X), \+(likes(X, sam))).",
]
The answer to the first question is john. So the answer to the second question is peter
We need a rich specification of data relationships to create instances of ontologies.
With ontologies that define steps or temporal relationships like Datalog we can create automated workflow systems or automated interoperability
With ontologies we can traverse the system itself.
https://stackoverflow.com/questions/10263970/traversing-recording-matched-predicates
Create a polycontext metasymbol, and overcome the fact that standardization does not generalize.
本體推理是數據集查詢的一個特例，大多數數據庫只是專門的本體，針對某些類型的查詢進行了優化。一些數據庫，如三重存儲，可能會被優化或邏輯推理。
您正確地注意到 Infinity 家族本體從商業意義上講是務實的。事實上，我曾經研究過 Odoo（以前是 OpenERP），這是一個類似 Wordpress 的企業運行框架，我想（回到2010) -- AI 增強型公司已經在發生，所以，我們需要一個系統，使它們能夠對社會透明，而且，由於公司只是人的總和，我認爲，必須存在共同點個人、公司，甚至政府都在運作，事實上，Infinity 家族本體是試圖從 第一原則 中達到共同點的嘗試，描述於關於方程模型的論文。更具體的版本是 NRV（網絡資源詞彙），其思想是引入類似響應的 HTTP 響應代碼編號，而是數據對象的語義代碼。
從理論上講，爲了使系統易於理解，我們可以繞過所有系統（例如每個應用程序）和數據包（例如互聯網流量），並將它們投射到人類語義空間中——通過將這些代碼附加到他們的表格、請求和響應——使人類理解所有系統，甚至使它們在數學上易於處理。
Reasoning on ontologies is a special case of querying of datasets, and most databases are just specialized ontologies, optimized for certain types of queries. Some databases, like triple-stores, may be optimized or logical inferences.
You're correctly noticing that Infinity family ontology is pragmatic from the business sense. In fact, I had worked on Odoo (previously OpenERP), which is a Wordpress-like framework for enterprises to run, and I thought (back in 2010) -- that AI-augmented corporations are already happening, so, we need a system that would enable them to be transparent with the society, and, since companies are just sums of people, I thought, there must exist common denominator between how individuals, companies, and even governments operate, and in fact, the Infinity family ontology is an attempt at arriving to that common denominator from the first principles, described in the paper on the equation model. A more concrete version of that, is the NRV (network resource vocabulary), the idea of which is to introduce something like HTTP response code numbers to responses, but rather, semantic codes to data objects.
In theory then, to make systems understandable, we can go around all the systems (such as each app) and data packets (such as the internet traffic), and project them in the human semantic space, -- by having such codes attached to their tables, requests and responses -- make all systems understood to humans, and even make them mathematically tractable.
擁有計算機本體以及文件、進程、線程、容器、權限等之間的關係會很好
然後我們將有一個簡單的數據結構，用於所有沒有實現定義的東西。
Would be nice to have an ontology for computers and relationships between files, processes, threads, containers, permissions etc
Then we would have a simple data structure for everything that wasn't so implementation defined.
我不知道推理引擎是如何工作的，但我認爲它是 modus ponens 的複製應用
如果您在數據庫中內置了一個引擎或在數據庫中內置了一個 prolog 引擎，那就太好了。您可以根據數據庫數據生成事實，例如如果某人年齡在 25 歲以下，他們僅使用 Gmail 作爲其郵件提供商。
I don't know how reasoning engines work but I think it's a replicated application of modus ponens
It would be nice if you had one built into a database or a prolog engine built into a database. You could generate facts like if someone is aged under 25 they only use Gmail as their mail provider based on database data.
它不只是計算（虛擬）屬性到“由所需屬性互連的對象集”（組合虛擬對象）嗎？
舉一個計算屬性的例子，我們可以想到
“如果某人年齡在 25 歲以下，他們僅根據數據庫數據使用 Gmail 作爲他們的郵件提供商”
作爲單個計算布爾屬性，即
Object.use_only_gmail(age): age < 25 => True ? False，對於具有“年齡”屬性的對象。 含義 可以被視爲只是一個屬性計算。置信水平也可以通過簡單地計算屬性來描述，並觀察到，實際上這個陳述只涵蓋了 95% 的情況。對於組合虛擬對象的示例，請考慮以下查詢：
“搜索這樣的案例，在不到 1 天的時間內，恰好 2 個 25 歲以上的物體搭配產生了 2 個 1 歲以下的活體。”
假設“產生 2 個對象”和“搭配”的出現不是數據庫自然跟蹤的東西，計算這樣的屬性將涉及創建“組合虛擬對象”（例如，觀察到具有搭配的跨越對象的圖形模式的事件） ，然後計算這些虛擬對象的布爾屬性，回答正好生成了 2 個對象。
我不明白爲什麼我們不再需要三元組存儲：僅使用計算屬性及其由查詢指定的模式就更自然了。模式只是一個“組合虛擬對象”，因此，查詢只是“模板虛擬對象”的構造（實際上，我已經在“目的性”關於所需數據屬性的部分，當補充有元格式時）。這將能夠查詢任何可以想象的模式。
Isn't it just computed (virtual) properties to "sets of objects interlinked by desired properties" (a combined virtual object)?
For an example of computed properties, we can think of
"if someone is aged under 25 they only use Gmail as their mail provider based on database data"
as a single computed boolean property, namely
Object.use_only_gmail(age): age < 25 => True ? False, to the objects that have "age" property. An implication can be viewed as just a property computation. The confidence level can be described, too, by simply computing the property, and observing that, in actuality this statement covers just 95% of cases.For an example of a combined virtual objects, consider the below query:
"Search for the cases, where collocation of exactly 2 objects aged above 25 had spawned 2 living objects aged below 1 during a period of less than 1 day."
Assuming that the occurrences of "spawning 2 objects" and "collocation" is not something that the database naturally tracks, computing such property would involve creating "combined virtual object" (say, an occurrence where graph pattern of spanning objects with collocation is observed), and then computing the boolean property to such virtual objects, answering that exactly 2 objects were spawned.
I don't see why we'd need triplets stores anymore: it's all more naturally doable with just computed properties and their patterns specified by queries. A pattern is just a "combined virtual object", so, a query is just a construction of a "template virtual object" (in fact, I've explained that in "purposefulness" section about desired data properties, when supplemented with metaformat). This would enable to query for any patterns imaginable.
編程語言中計算屬性的問題 - 在數據庫之外是它們效率不高。您將需要真相維護，如果天真地實施，這可能會很昂貴。
Blazegraph（已被亞馬遜收購）和 Jena Fuseki 是具有真實維護功能的三聯商店。
不要打折三聯商店帶來的東西。
如果數據庫可以具有在數據庫內部實現的虛擬屬性——也可以在任何插入或更改數據時更新——那麼是的，它可能是有效的。
The problem with computed properties in programming language - outside the database is that they're not very efficient. You would need truth maintenance which can be expensive if naively implemented.
Blazegraph (since acquired by Amazon) and Jena Fuseki are triple stores have truth maintenance features.
Don't discount what triple stores bring to the table.
If a database could have virtual properties that were implemented inside the database - also updated on any insert or changing data - then yes it could be efficient.
這個例子也是一個推斷規則。 25 歲以下的人使用gmail 是數據庫根據數據得知的。
它是每條數據與其他每條數據的相關性。可以用一個簡單的循環和相關函數來實現
Also that example was an inferred rule. The age less than 25 people use gmail is something that is learnt by the database based on the data.
It's a correlation of every piece of data with every other piece of data. Could be implemented with a simple loop and correlation function
嗯，三元組是多餘的，因爲元組就足夠了：
(a, b, c) = ((a, b), (b, c))(point (video) 我在一封電子郵件中發送給 [Telmo])。因此，我們可以將三重存儲視爲語義索引。索引加速查詢，是的，但除此之外，它們是多餘的。那麼，當涉及到語義索引時，不僅在更流行的圖節點之間，而且在超圖節點之間（進行 power-set indexing .org/wiki/Power_set）在大多數情況下可能會耗盡計算資源）。
文獻中是否有“語義索引”這樣的概念？似乎沒有人爲數據庫調用“製作三重存儲”——“語義索引”。
Well, triples are redundant, because tuples are enough:
(a, b, c) = ((a, b), (b, c))(the point (video) I made in an e-mail to [Telmo]).Thus, we can think of triple stores as just semantic indices. Indices speed up querying, yes, but but otherwise, they are redundant. When it comes to semantic indexing, then, it would make sense to make such said "triples" not just between more popular graph nodes, but hypergraph nodes as well (doing the power-set indexing would likely exhaust computational resources in most cases).
Is there at all such concept of "semantic indexing" in the literature? It seems nobody calls "making triple stores" for a database -- "semantic indexing".