Какой самый канонический способ представления отношений в GraphEngine?

Question

Я пытаюсь выяснить, как лучше всего моделировать мои данные в моем TSL. В примере Friends отношения подразумеваются путем сохранения идентификатора ячейки (или списка идентификаторов ячеек) в связанных узлах. В примере Freebase, однако, есть понятие [GraphEdge], которое было введено. Я надеялся на документацию (и, возможно, здесь), мы могли бы получить четкое представление о том, как правильно моделировать отношения / ребра, используя GraphEngine.

Answer 1

Насколько мне известно, не существует такого стандартного способа в соответствии с документами, и лучшая практика также зависит от наших собственных требований, например, производительности или удобства. Вот мой выбор в разных ситуациях:

1. Для ориентированного немаркированного графа, который является очень распространенной ситуацией, я просто использую идентификаторы соседних ячеек (список смежности) в качестве поля. И я считаю, что это очень эффективно для большинства операций с графами;
2. Для ориентированного графа со свойствами по краям есть два варианта: использовать список значений, определенных пользователем. structили установите отдельную ячейку для ребер и соедините ребра с ячейками исходного / целевого узлов. Первый из них практически быстрее второго для большинства операций с графами. Но цена заключается в том, что он не позволяет получить доступ к границе без посещения ячейки узла, что является преимуществом последней;
3. Для неориентированного графа без свойств на ребрах для каждого ребра (u, v) я помещаю их идентификаторы ячеек в списки смежности друг друга;
4. Для неориентированного графа со свойствами на ребрах для каждого ребра создается отдельная реберная ячейка, в которой хранится вся информация, включая связанные с ней узлы и свойства;
5. Для гиперграфа, где ребро может соединять более одного узла, мой выбор такой же, как 4.

Введенное понятие [GraphEdge] используется для распознавания краев с помощью Language Integrated Knowledge Query (LIKQ), однако это не повлияет на наше использование, если наши приложения не построены поверх LIKQ.