Hello, I can see how changing TinkerPop in this way might be helpful to
your project but I don't have a positive feeling about this sort of change.
I assume you are talking about changes to our core interfaces
(Vertex/Edge/etc) when you suggest this so given the maturity of the code
base right now I can't imagine how we would manage such a thing. Aside from
the software logistics of this sort of change, I'm not really a fan of
hypergraphs. In my experience, users have enough trouble trying to reason
about schema options with simple property graph semantics. We threw in
multi/metaproperties for 3.x and it created even more confusion. Adding
edges to edges would only complicate modelling choices further and I don't
think favorably of that.
Personally, I think "Alternate mapping" approach you mentioned is the right
way to go and is likely what I would have suggested if you'd not mentioned
it yourself.
Thanks for sharing your project here by the way. It's always nice to hear
about what folks are doing with TinkerPop.
On Tue, Dec 4, 2018 at 1:47 PM Fred Eisele <fredrick.eisele@gmail.com>
wrote:
> Hi TinkerPop3 developers,
> I am planning on using TinkerPop3 to represent and store categories.
> And by categories I mean as defined by category theory
> <https://en.wikipedia.org/wiki/Category_theory>.
> In general graphnode = catobject and graphdir_edge = catarrow.
> I think this application is fairly straightforward but it does not work.
> A fundamental construct in category theory is the functor.
> A functor includes arrows constructed between other arrows.
> Thus every edge (arrow) is also a node (object).
> There are two obvious ways this may be handled.
>
> # TinkerPop 3 unchanged : Alternate mapping
>
> Rather than the obvious...
> * graphnode = catobject
> * graphedge = catarrow
> ... mentioned above.
> An approach similar to that used for hypergraphs can be adopted.
> * graphnode[Object] = catobject
> * graphnode[Arrow] = catarrow as catobject
> * graphnode[Arrow] + graphedge[Tip] + graphedge[Tail] = catarrow
>
> This approach is similar to that in RDF
> <
> https://en.wikipedia.org/wiki/Resource_Description_Framework#Statement_reification_and_context
> >
> .
> It can be implemented with TinkerPop 3 in its current form.
> It is what I am currently doing.
>
> # Property Graph Database as Categorical Database
>
> What is more interesting is extending ThinkerPop to be a categorical
> database API.
> The approach combines Node+Edge into a single class with some type of
> casting to switch to the other interface.
> I am looking into what would be entailed in implementing this in
> JanusGraph.
>
> If this is the correct forum I can supply diagrams to better illustrate the
> point.
> If this is not the correct forum please point me in the right direction.
>
> Thank you
> Fred Eisele
>
