py-brickschema and Oxigraph

[jansiroky]

We do have RDFs in the Oxigraph database and we want to use py-brickschema module for processing these data. I do have two questions:
1, I was able to obtain the content of the database using HTTP POST with a SPARQL query. I do have Python string with triplets formatted as CSV, XML, or JSON. How it can be imported into a Graph? Below is a code snippet using XML format that is not working. What is wrong here?

    headers =  {"Accept" : "application/sparql-results+xml", "Content-Type" : "application/x-www-form-urlencoded"}
    query = {"query" : 'select ?s ?p ?o where {  ?s ?p ?o . } limit 1000 '}
    response = requests.post(api_url, data=query, headers=headers)   
    g = Graph(load_brick=True)
    g.parse(data=response.content, format="application/rdf+xml")

2, Is there a way how to directly connect to the remote Oxigraph database from py-brickschema (instead of exporting triples using query as pointed out in 1,)?

[gtfierro]

Hi @jansiroky --- I didn't see a notification for this, so sorry for the delay in my reply! Let me look into this and get back to you

[jansiroky]

Hi @gtfierro do you have any solution to this issue? Thanks, Jan

[gtfierro]

For issue 1, you cannot use the graph.parse method because this is expecting the graph dump rather than the results of a SPARQL query -- they are formatted differently even though they have similar information. You will need to iterate over the triples returned by your SPARQL query and load them into your graph one at a time. Packages like https://github.com/RDFLib/sparqlwrapper/ can help with this

For issue 2, I'm not sure this is possible currently. py-brickschema can use https://pypi.org/project/pyoxigraph/ as a Store for the triples, but requires the underlying graph API to be implemented (.add(), etc) for its functionality to work. Can you give me some more details on what features of py-brickschema you'd like to use on a remote database?

[jansiroky]

Thank you for the reply.

Issue 1 - we were able to resolve it according to the suggested procedure.
Issue 2 - we do not see this as a priority since we do already have a working solution.