四分之一的草莓和机器翻译的其他功能：要向自动化厨房迈出新的一步，您需要教授一种技巧，以理解用人类语言和人类逻辑编写的食谱。 为此，需要对其进行转换。 在切口下，文字反映了在讨论相关主题期间因一杯咖啡而产生的问题。
自动化厨房。 必要阶段
智能厨房电器使烹饪过程更加轻松，但是人们仍然可以完成大部分工作：清洗，切割并放入食物，搅拌等。 就像我要说的那样：“锅煮”，这样所有东西都可以洗净，切碎，混合，用户只需要等待声音信号就可以吃饭了。
现在，自动厨房仅以工业规模出现，但这很快就会达到家庭水平。 为此，您需要解决几组问题，并且这些解决方案应该是可以承受的。
第一组任务是使厨房能够独立于用户执行操作。
例如，可以通过在厨房中引入
机械手系统 ，
传送带来解决此问题。
第二组任务是在厨房中引入计算机视觉和传感器系统，以自动确定碗碟或其一部分的准备程度。
第三组任务是管理界面。 可以通过智能手机上的应用程序以及语音助手来实现该任务。
最后，第四组-厨房行为逻辑的任务。 如何教厨房做饭？ 例如，机器人厨师是由一个人-专业厨师来训练的。 他将传感器放在手上，然后慢慢显示如何操作。 然后机器将动作重现至最小细节，甚至握手。 当然，在处理过程中，应该去除多余的动作，但是如果程序员错过了一些事情，那么机器人大厨将停止一天的时间来划伤他不存在的鼻子。
另外，为了教给机器人一个方法，必须重复几次动作。 即使您教机器人可以组合的单个动作，这样的训练时间也将花费大量时间。 更不用说最严格地遵守食谱以及显然是经过校准的成分了：使机器人能够从土豆中挑出眼睛是一项单独的复杂工程任务。 并且在烹饪之后，您仍然必须清洗炉灶和餐具。
配方是代码。
如果您现在回到事态-即 考虑到问题的经济因素，发展困难等，很明显，在可预见的将来，我们只能教智能家用电器如何阅读和应用该食谱。 这需要将配方转换为代码。 但是经典软件Java或C在这里并不适用-它们可以描述配方，但是如果用户想要对其进行任何更改，则他要么必须联系技术支持，要么注册以学习编程课程。 此外，经典代码过于正式。 例如，如果配料说“干蘑菇”，那么新鲜的就不会烹饪。 使任务复杂化的事实是，民族美食的食谱以不同的自然语言呈现。
但是我想让用户有机会在网络上找到他感兴趣的食谱，下载它以及使用机器人厨房-正确地解释并应用它。 最大的任务是根据用户的烹饪偏好，自行厨房的搜索和提供选项的能力。 好的烹饪食谱不仅应包括原料和烹饪方法的清单，还应包括产品生长的环境条件。 根据许多标准，一道菜属于国家美食，包括特定的烹饪方法，器皿，工具等。 将所有这些数据转换成适当的数字形式，或者很有可能将其解释为一项艰巨的任务。
那么，哪些语言可以用来制作食谱？
RDF
用于形式化表示知识的现有技术分为几类结构。
其中包括带有
OWL和
RDF技术的语义Web方法。 使用语义Web工具在线收集相关数据集也称为链接数据。 最近在哈布雷（Habré）上有
一篇文章专门讨论这个概念，因此我们将不再关注它。 许多数字化项目都是围绕使用一些
高级本体的想法而建立的，
本体专家可以在特定知识领域扩展这些
本体 。
考虑使用和应用这些工具对国家美食进行数字化的情况。 RDF的主要思想是，互联网正在远离仅由人类感知的信息存储，而已成为交互过程的全球网络。 顾名思义，RDF是表达资源信息的基础。 首先，关于Web文档和各种组织。 他的形式主义基于静态类和属性的思想。 出现了一个问题：将配方视为一个实体，而不是将其视为包含参数，时间计算，传入子流程等的复杂过程是多么合理。对于配方而言，这显然是不够的。
Schema.org
第二种方法是
Schema.org计划，这是在线社区的共同努力，旨在创建，维护和推广用于在Internet上构造数据的方案。 该计划旨在为发布在网络资源上的常见元数据提供标准化的词汇表。 与烹饪相关的网络资源可以使用通过
引用存储的Recipe类元数据。 以下是Google提供的示例食谱代码：
<script type=> { : http: //schema.org/, : , : , : [ https: //example.com/photos/1x1/photo.jpg ], : { : , : }, : , : , : { : , : , : }, : , : , : , : { : , : , : , : }, : [ , , , , , , , , , ], : } </script>
Schema.org所采用的词汇和格式主要集中于Web文档中高级元数据的表示。 但是，正确规范化的语义图需要概念的更明确表示。
Schema.org字段中的大多数字符串值都是需要人工
识别的自然文本。 如果没有特殊的
自然语言处理工具（通常易于出错），数字系统将无法直接读取此类文本。 举例说明，在上述食谱示例中，Google机器翻译适用于配料列表中的一个订单项：
'fresh strawberries, quartered'
俄语翻译给出的语义是完全错误的：
' , '
用“房屋”一词来表示“驻扎”，如“我们的部队设在波士顿”，而不是“切成四个”。
缺少对象的明确定义的角色和方法的明确标识，使得配方的机器翻译任务变得更加困难。
对于我们未来的数字食谱任务-机器人机器可以遵循烹饪说明的情况，简单的文本行不能解决。
考虑对成分的典型描述：
'8 Granny Smith apples — peeled, cored and sliced'
显然，该文本行包含许多分类信息：作为一类的原始成分，特定种类的苹果，件数，为正常使用该成分而应应用于各部分的方法列表：去除种子，去皮，将物体切成一定的部分形式。
Schema.org的形式主义表现力不足，无法将烹饪过程写入某些程序代码。 为了正确数字化用于机器人烹饪的食谱，我们需要将成分的描述与逻辑分开
第三种方法是认知配方建模。
编写食谱的传统方法是从必须完成的配料和操作开始。 这种顺序和描述方式称为命令式或过程式。 描述性或功能性描述流程逻辑的方式通常从执行金字塔的顶部开始，这是我们想要实现的预期有用结果。
考虑以下经典俄罗斯蘑菇汤食谱的简化介绍。 箭头指示父流程所需的子流程（有时是替代流程）。
即使我们尝试定义配方，认知解释也可能会造成混淆。 术语“食谱”具有几种上下文含义。 可以将其定义为获得期望结果的一种方式。 当用于烹饪时，它表示准备烹饪菜肴的一组说明。 因此，可以将此概念视为具有某些属性（例如必需的成分和时间）的对象。 作为替代方案，可以将其视为具有一些初始数据，经过一系列必须完成的步骤并产生一定结果的技术过程。 食谱还包括完成步骤所需的时间以及必要用具的说明。
自2006年以来，为了开发一种表达自然语言复杂语义的最佳形式主义，创建了
Knowdy项目，重点是管理图形数据。
知识项目
Knowdy是圣彼得堡语言研究小组的一个开源软件项目，致力于超快速图形数据库的开发，该数据库可让您绕过任何中间视图（例如SQL表）直接且有效地使用概念图。 数据库引擎以C语言实现，可以用作网络服务，也可以用作嵌入式环境的独立库。
经过几年的研究和开发，研究和开发团队为Knowdy DB提出了一种特殊的数据格式，称为GSL（简称通用语义语言）。 GSL经过优化，可以紧凑地存储概念图。 它用于存储数据，发送消息和交换信息。 这种格式并不像XML那样过于冗长，而且比JSON紧凑。 该语言接受Lisp S表达式的某些功能，但是对语义进行了很大的修改，因为您需要牢记图形不是列表。 GSL中带括号的描述特别重要，它使用户不仅可以表达多级分组，还可以表达数据库存储系统中的CRUD操作。
在GSL描述中，该过程被编码为第一类的函数，可以被命名或可以是匿名的，支持从基本函数的继承，具有可并行工作的参数和子过程。 下面的过程描述了俄罗斯蘑菇汤相同配方的一些逻辑。
{!proc prepare mushroom soup mix [_gloss {ru }] {is cooking by boiling} {arg cut-mushrooms {do prepare mushroom mix}} {arg cut-potatoes {do prepare potato mix}} {arg cut-onions {do prepare onion mix}} {do _put [_gloss {ru .}] {obj _all} {target-loc container}}} {!proc prepare mushroom mix [_gloss {ru }] {arg clean-mushrooms {do clean mushrooms}} {do _cut [_gloss {ru .}] {obj clean-mushrooms} {form slice {size 1.5 {unit cm}}}}}
R4S使用第三种方法。 它使您能够想象一种具有必要程度的形式主义的食谱，以描述其本质和作用。 以这种方式写入数据库的配方可以通过该技术快速下载和应用。 在我们支持配方的设备中，它们以GSL格式记录。 该计划是训练神经网络来记录世界各国人民的食谱，这将简化食谱的交换，并为成熟的自动化厨房提供技术基础。
我们经常遇到看似微不足道的任务，执行起来并不那么简单。 您认为哪种语言可以用来编写食谱，一方面可以被世界各地的用户访问，另一方面可以被机器理解和解释？