Semantic — многофункциональная информационная система полного цикла, осуществляющая сбор, представление, обработку, хранение и передачу информации разной степени структурированности.
/ в скобках указаны классы, соответствующие понятиям /
Уровень данных состоит из реальных объектов (NodeInstance) и взаимоотношений между ними (EdgeInstance). Его можно представить в виде графа: объекты будут соответствовать вершинам графа, отношения между ними — рёбрам. Элементы данных могут обладать свойствами (PropertyInstance).
Уровень схемы, перечисляющий, задающий ограничения и увязывающий между собой классы объектов-вершин, классы отношений-рёбер и классы свойств, делится на два подуровня: графовый — модель и классовый — фундаментальная модель.
Уровень фундаментальной модели перечисляет классы объектов — концепты (NodeClass), классы взаимоотношений — функции (EdgeClass) и классы свойств (PropertyClass). В качестве идентификатора класса используется его название (например, Человек — для класса объекта; Дружит — для класса отношений; Возраст — для класса свойства). Фундаментальная модель описывает наборы свойств (PropertyRelation) у концептов и функций, определяет типы данных у свойств.
Уровень модели опосредованно оперирует концептами и функциями. Модель состоит из правил, описывающих возможные отношения между объектами данных, и представима в виде графа, где вершинами являются концепты (ModelNode), а рёбрами — связи (EdgeRelation).
Лучше постичь разницу между Fundamental и ModelGraph поможет файл schema.json, лежащий в корне проекта. Он немного отличается от того, как данные представляются в коде проекта, но тем не менее наглядно отражает суть вышеозначенных понятий.
Графы, как и другие структуры, поддерживают изменения: добавление ребра, удаление вершины и другие. У самих элементов можно менять свойства. Этим изменениям соответствуют события Event. Для редактирования графа с автоматическим созданием событий нужно использовать фреймы (для графа данных — DataGraphFrame).
Класс Mutation содержит в себе список событий. Этот список должен быть оптимизированным: в списке не должно быть AddEvent, ChangeEvent и RemoveEvent, касающихся одного и того же элемента. Если элемент был создан, а затем изменён, в списке событий нужно держать AddEvent, сообщающий о создании уже изменённого элемента. Если элемент был изменён, а затем удалён, в списке событий нужно держать только RemoveEvent. Если элемент был создан, а затем удалён, в списке событий не нужно держать ничего.
Сейчас в поле events класса Mutation находятся все события, которые мы передаём в конструкторе. Нужно реализовать оптимизацию этого списка при инициализации Mutation. В файле shared/src/commonTest/kotlin/MutationTest.kt лежит тест adding, changing and removing element, который должен проходиться. Желательно написать ещё несколько тестов на разные кейсы событий. Считать, что в Mutation есть только события для данных.
- «А есть ли в проекте такая функция, которая <...>?»
- «А какой смысл у класса/интерфейса/функции <...>?»
- «А почему сделано <так>, а не <иначе>?»
- другие.
Semantic Core использует систему сборки Gradle. После скачивания нужно имортировать проект как Gradle-проект.