Currently we are only loading the RDF data of single plays to the triple store. For the DraCorOS project we need to develop the "DraCor Open Knowledge Graph" that can build on the already partly existing mechanisms of populating the triple store with the API. The functions currently available in the RDF module only handle loading of plays, but have very general function names, e.g.

• drdf:fuseki (https://github.com/dracor-org/dracor-api/blob/main/modules/rdf.xqm#L501-L540) to store RDF data (but this function builds the name of the graph it stores the data to based on the corpusname + does not take the new structure of storing data in the database into account, e.g. see tokenize function used at https://github.com/dracor-org/dracor-api/blob/main/modules/rdf.xqm#L506).
  I already changed this function and added an additional parameter graph that holds the URI of the named graph the data is stored to.
• The functions drdf:update and drdf:update($url as xs:string) implicitly generate graph names based on the corpusname and only handly plays. I will rename them to drdf:update-play and drdf:update-plays but this is a breaking change because these functions are called when an ingest of data is triggered. So I would have to change code in other core modules apart from rdf.xqm

Question: @cmil what do you think about renaming these functions and making explicit that they only handle plays?

I would need some other ways to load RDF data to the triple store. @cmil do you have any preferences on how to implement the needed API endpoints?

• I would like to be able to have a generic way to POST or PUT arbitrary RDF to a given named graph in the /dracor database in the Triple Store. The API function would rely on the rewritten drdf:update function or a new function using a similar mechanism.
• A generic function to delete a given named graph in the /dracor database using the DELETE http method.

Logically these functions would need some sort of admin-like credentials to perform these updates and would be grouped in the admin-tagged section of the API, see https://dracor.org/doc/api#/admin
@cmil do you have any preferences regarding the routes? Shall I introduce a new pattern similar to the dts functions following the route level /dts/collection ... e.g. /lod/... ?