You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Even if I gave very detailed context prior to putting forward the question...
---ChatGPT cannot consistently generate the right SPARQL.
The possible way to solve it is:
using python to get GPT's API and prompt it to
(1)run a SPARQL query on an SPARQL endpoint and get the error report and "introspect" the results;
(2)generate more than one SPARQL results for comparison...
(3)... or enhance the interaction of "question-answer" with users to ensure more accurate and context-aware responses.
(4)Extract classes and properties from the natural language question and then assemble them as a "sub graph" of the graph of the whole ontology. Then examine the connectivity of the sub graph. That's why I set up the issue DDMAL/linkedmusic-datalake#162
If the sub graph is well connected, it means the question is executable against the database.
...
We don't have to avoid the ontology which "essentially won't interfere with the extendibility and flexibility of RDF graph." See: DDMAL/linkedmusic-datalake#169.
For now, ChatGPT doesn't need to generate the correct answer every time. Users of ChatGPT are learning that sometimes you need to ask ChatGPT several times before getting the correct answer. Also, ChatGPT is improving at an amazing rate!
Even if I gave very detailed context prior to putting forward the question...
---ChatGPT cannot consistently generate the right SPARQL.
The possible way to solve it is:
using python to get GPT's API and prompt it to
(1)run a SPARQL query on an SPARQL endpoint and get the error report and "introspect" the results;
(2)generate more than one SPARQL results for comparison...
(3)... or enhance the interaction of "question-answer" with users to ensure more accurate and context-aware responses.
(4)Extract classes and properties from the natural language question and then assemble them as a "sub graph" of the graph of the whole ontology. Then examine the connectivity of the sub graph. That's why I set up the issue DDMAL/linkedmusic-datalake#162
If the sub graph is well connected, it means the question is executable against the database.
...
We don't have to avoid the ontology which "essentially won't interfere with the extendibility and flexibility of RDF graph." See: DDMAL/linkedmusic-datalake#169.
See the draft https://github.com/DDMAL/linkedmusic-queries/blob/main/LLM2SPARQL_TheSession_WikiData_MusicBrainz/trial.py.
The text was updated successfully, but these errors were encountered: