No results for inverse properties with virtual graph

Hi everyone,

I am using a virtual graph (via SMS) in combination with SSN/SOSA (Semantic Sensor Network Ontology) for describing sensor measurements, metadata, etc. I have no Problems with mapping individuals from the RDB to the model (I think). When I query the virtual graph (within the database where the model is hosted), I have some problems when reasoning is involved. It may be that the query is stated incorrect, the dataset is too extensive (a few million data sets) or there is a misunderstanding about the reasoning capabilities, my mapping is wrong or something completely different.

Within the ontology, there are some inverse object properties stated (sosa:hasResult & sosa:isResultOf, sosa:hosts & sosa:isHostedBy). I now want to get e.g. all observations with a timestamp and the respective result (as well as the sensor which produced the result).

Within my mapping for creating the virtual graph, I only stated, that result "isResultOf sosa:Observation" and therefore I would expect when running the query with reasoning I would get the respective results also for sosa:hasResult (it is declared as an inverse). But it only works when only asking for the results, not in combination with the observation-individuals. Here are some small examples (queries are done in the database where SSN/SOSA is hosted):

This is working (without reasoning):

prefix sosa: <...>
select *
where {
graph virtual://tables4
{?s a sosa:Observation ;
sosa:resultTime ?time . } }

This here also works as a "standalone"-query:
prefix sosa: <..>
select *
where {
graph virtual://tables4
{?s sosa:hasResult ?value . } }

When running this query, I do not get any results (with or without reasoning):

prefix sosa: <...>
select *
where {
graph virtual://tables4
{
?s a sosa:Observation ;
sosa:resultTime ?time ;
sosa:hasResult ?value . } }

I did not make SSN/SOSA a named graph, is that incorrect? It's really confusing right now, therefore I would be really grateful, if you could help me out here!

Thanks a lot!
Cheers,
Sonja

You’ve got a lot of moving parts there so we should probably get started by asking a few questions about what you’re doing. I’m sure we’ll be able to sort out the confusion. Feel free to follow up with anything you still find confusing once we work out your immediate problem.

What version of Stardog are you running and what operating system are you running it on?

What relational database are you using?

How did you create your database and what options did you choose?

What license are you using? Community, 30-day trial, enterprise?

What data did you add to your database and how did you load it? Can you share that data?

Can you share your mappings?

For the query that didn’t return any results with and without reasoning did you expect results without reasoning?

Hi Zachary,

thanks for your reply.

Right now, I'm using the 30-day Trial-Version, but only for reasons of convenience if I need to shut down the Server (I can't do that to our enterprises' Server, I don't have the rights, therefore localhost is more convenient). Both should be 5.2.2 (not completely sure about the server's Version but >5.0). Running the localhost on Windows.
Relational Database originally is DB2 but via a Data Virtualisation Machine (Denodo).
I did not Change any Settings when creating the Database, so reasoning SL. You can find the ontologies here: http://www.w3.org/ns/ssn/, http://www.w3.org/ns/sosa/, they are from W3C. From the RDB, I added the measurement results to the results class, the timestamps as properties to observations, etc. via the mapping:

@prefix ...

sosa:{"observation"}{"observation_id"} a sosa:Observation ;
sosa:resultTime "{"result_time"}"^^rdfs:literal ;
sosa:madeBySensor "{"sensorname"}
{"sensor_id"}" ;
sm:map [
sm:table ""dsb..."."observations"" ;
] .

sosa:{"sensorname"}_{"sensor_id"} a sosa:Sensor ;
sm:map [
sm:table ""dsb..."."sensors"" ;
] .

sosa:{"result"} a sosa:Result ;
sosa:isResultOf "{"observation"}_{"observation_id"}" ;
sm:map [
sm:table ""dsb..."."results"" ;
] .

And no, I did not expect the query to give any answers without reasoning, I just tried it anyway ^^

Did you load the ontology into your Stardog database? Do you see the inverseOfaxiom in the output of the reasoning schema command for that datatbase?

Thanks for the detailed response. One question I forgot. Are there any errors or warnings in stardog.log?

Yes, I loaded the ontology into my database.
If I query for all Statements with ?s owl:inverseOf ?o then the respective properties are stated. If you mean if that are stated somewhere else (e.g. Settings?) I don't know, could you be more specific? I'm using the webinterface for launching the queries btw, if that makes a difference.

I do not get an Error but some warnings and maaaaany Infos (included one info here, and all the warnings).

Apparently there are some Problems caused by the ontology itself?

I tried to Launch only the first part of the query with reasoning

      ?s a sosa:Observation ;
           sosa:resultTime ?time .

excluding: sosa:hasResult ?value .

And I found out it only works without reasoning. So could there be a contradiction involved somewhere since the complete query is not supposed to give a Response without reasoning?

I hope you can work with my explanations I'm pretty new to this field.
Thanks for the help!

Follow-up Remark to your question concerning the asiom owl:inverseOf:
If I want all triples involving "sosa:hasResult ?p ?o" then the list of results does not state that there is an inverseOf declared. But if I include the Axiom in the query: "sosa:hasResult owl:inverseOf ?o" then I get the correct answer. Is that correct? Protégé gives me the same result, so should be...

You’ve mapped the observation as an iri which is correct but the object of isResultOf as a string. It’s enclosed in double quotes:

sosa:{“observation”}{“observation_id”} a sosa:Observation ;

sosa:{“result”} a sosa:Result ;
sosa:isResultOf “{“observation”}_{“observation_id”}” ;

You need to change the object of the isResultOf mapping to an iri:

sosa:{“result”} a sosa:Result ;
sosa:isResultOf sosa:{“observation”}{“observation_id”}

Hi Sonja,

Can you share the tables4.properties file that you used (with sensitive information removed) that you used to add the virtual database using the stardog-admin virtual add command?

I’m interested in the JDBC driver that you used to connect to Denodo. I’m assuming it uses com.denodo.vdp.jdbc.Driver packaged in denodo-vdp-jdbcdriver.jar. If that is the case I’m surprised that your working queries work at all because we do not test with Denodo.

One thing that could help is EXPLAIN-ing your queries:

 stardog query explain your_db 'prefix sosa: <http://www.w3.org/ns/sosa/> select * where { graph <virtual://tables4> { ?s a sosa:Observation ; sosa:resultTime ?time . } }'

That should return something like this:

The Query Plan:

Projection(?s, ?o) [#1]
`─ VirtualGraphSql<virtual://tables4> [#1] {
   +─    SELECT "observation" AS "F_0", "observation_id" AS "F_1", "result_time" AS "F_2"
   +─    FROM "dsb…"."observations"
   +─    WHERE "result_time" IS NOT NULL
   }

You can prove that the SQL that is returned in the output is correct by sending it to Denodo directly using a SQL client.

It could be that the SQL that we generate using our default dialect works with Denodo for simple queries but not for more complicated ones involving joins.

Thanks,
-Paul

Hi Paul,

yes, I use those Drivers you mentioned. My .properties Looks as follows:

parser.sql.quoting=ANSI
jdbc.url=jdbc:vdb:///
jdbc.username=***
jdbc.password=***
jdbc.driver=com.denodo.vdp.jdbc.Driver

You have to insert the denodo-vdp-jdbcdriver.jar manually into Stardog HOME \server\dbms but you probably knew that. Is there a different way to connect a virtual graph to Denodo?

I tried the EXPLAIN function, if I have the error “unsatisfiable query” is it more likely to be a Problem of the database or the mapping / Stardog? We will try the SQL-verification in the next days. I think you could be right about the joins or more complex level, because the query often (always?) seems to fail if there is more than one Interface of Denodo involved. Is there another Data Virtualisation machine you can use with Stardog?

Thx for the Reply, I probably will get back to you when I further checked out the Denodo-SQL-queries.

Cheers,
Sonja

Thanks, Jess, I did not notice that beginner’s mistake. Since it is still not working, I went with Paul’s advise and will further look into the Stardog-SPARQL-SQL-Denodo relationship and the structure of my Interfaces which I created with Denodo.

Hi Sonja,

The unsatisfiable query occurs when you are attempting a query for which there is no mapping. See Jess’ comment about the mappings.

Cheers,
-Paul

Thanks for the reminder of query explain, it gave me all the clues. It was a mixture of these problems: Denodo was returning an almost endless amount of rows and a namespace problem. When SPARQL queries are transformed into SQL queries the URI-ending is interpreted ID. Since I combined my URI-ending out of two columns it was always checking for the {“observation”}{“observation_id”} which of course can never be found in an ID-column.
But so far there are no problems when using Denodo with Stardog, I think.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.