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".