[question] overlap in Graph functionality across microservices

[rbrugaro]

Hi,
Currently we have multiple ways to perform graph extraction and graph querying.
On one hand we have datraprep microservices like neo4j and arangodb that provide the text to graph creation.
Also have retriever microservices like neo4j and arangodb that provide the text to cypher query capability

In v1.3 three separate microservices are introduced:

• Struct to Graph: Supported transforming structured data to graphs using Neo4j graph database. (GenAIComps#1502)
• Text to Graph: Supported creating graphs from text by extracting graph triplets. (GenAIComps#1357, GenAIComps#1472)
• Text to Cypher: Supported generating and executing Cypher queries from natural language for graph database retrieval. (GenAIComps#1319)

I believe the Text to Graph and Text to Cypher overlap with the dataprep and retriever microservices.

From a developer perspective I would like to understand:

1. What's the design benefit of deploying Text to Graph/ Text to Cypher microservices vs. a Dataprep/retriever microservices like the above?
2. If there is a design benefit then, should Text to Graph , Text to Cypher, Struct to Graph be refactored to have the abstraction for multi vendor integration (neo4j, arangodb, falkordb...) and not tightly coupled with neo4j? That's the current design philosophy followed in dataprep, retriever and OpeaStore, that with a single argument a developer can switch among vendor integrations.
3. For Struct to Graph for client db interactions I think OPEAStore class could be reused.

@aMahanna, @intelsharath, @ftian1 any thoughts?

[CICD-at-OPEA]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[rbrugaro]

From discussing with Arango DB:

1. They will not introduce integrations for text2graph, text2kg, struct2graph… because the functionality is already in comp/dataprep and there will be lots of code duplication.
2. Regarding text2cypher, txt2sql.. Arango could contribute a text2AQL (arango query language) but OPEA should consider what's the preference: 1) to take the approach of one microservice definition per vendor/query language or 2) one unified text2query and then have integrations implementing methods for cypher, sql, AQL..
   @ftian1 and @mkbhanda have expressed option 2 as preferred option.
   @aMahanna is there any interest from your side to contribute such text2query abstraction or just the Arango query language implementation for it?

[aMahanna]

@aMahanna is there any interest from your side to contribute such text2query abstraction or just the Arango query language implementation for it?

Happy to contribute the AQL implementation but unfortunately will not be able to commit resources on the text2query abstraction for the foreseeable future

[CICD-at-OPEA]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[CICD-at-OPEA]

This issue was closed because it has been stalled for 7 days with no activity.