Questions about SPARQL Graph

[Robert-Adelard]

I have been trying to construct some complex queries using SPARQL Graph and would appreciate some help. Is there any documentation available? The SemTK Advanced Queries page is helpful, but it mainly talks about UNION and doesn't explain how MINUS works.

For example, suppose I have constructed a query that returns all the requirements that satisfy a certain property. How would I invert this query to return all the requirements that don't satisfy the property? Is it possible to do something like

All requirements MINUS All requirements that satisfy property

Or is this the wrong way to think about the query?

More generally, how do you compose queries to build more complex queries?

Thanks.

[cuddihyge]

It sounds like you have it right. In the SPARQL language, MINUS specifies a section of the query which must not be satisfied in order for a pattern to match.

Since SPARQL is a W3C standard (not ours) there are lots of examples and tutorials out there. Do note that SPARQLgraph doesn't yet support the entire language, but a big chunk of it.

This might help: stackoverflow: select the negative of a sparql query

RACK ships with a couple queries (they have "without" in their names) that use MINUS. Consider "query Requirements without Tests":

This one finds all REQUIREMENTS that are not verified by a TEST. Two subtlties:

• since the identifier of TEST is selected, technically this query looks for a REQUIREMENT with an identifier that is not verified by a TEST with an identifier. So, technically this would match a REQUIREMENT that is verified by a TEST without an identifier.
• something unique to our user interface is the concept of "reverse" minus. This simply means the MINUS works in the opposite direction across the object property. In this example since verifies points towards the REQUIREMENT, we use reverse. Without the reverse, the query would find all TESTS that do not verify a REQUIREMENT\

Hope this helps

[Robert-Adelard]

Thanks - I have a reasonable understanding of SPARQL from reviewing some of the tutorials and examples out there, but isn’t always obvious how to express them using SPARQLGraph, which is why I asked if there was any SPARQLGraph documentation available.

[Robert-Adelard]

In principle, I would like to use MINUS between two sub-graphs, but I'm not sure this is consistent with SPARQL syntax and it doesn't seem to be allowed by SPARQLGraph, which only allows MINUS to be applied to a property or a relationship.

As a simple example, consider the query "All Requirements whose identifier is not HLR-2" (the actual query is more complex).

I could write this in SPARQL as follows:

select distinct ?identifier
		FROM <http://rack001/data>
		FROM <http://rack001/model>
 where {
	?REQUIREMENT a ?REQUIREMENT_type .
	VALUES ?REQUIREMENT_type { REQUIREMENTS:REQUIREMENT DevelopmentPlan:HighLevelRequirement DevelopmentPlan:SystemRequirement DevelopmentPlan:LowLevelRequirement  } .
	?REQUIREMENT PROV_S:identifier ?identifier .
	minus {
		?REQUIREMENT PROV_S:identifier ?identifier .
			FILTER ( ?identifier IN ('HLR-2', 'HLR-2'^^XMLSchema:string ) )  .
	} 
}

However, when I tried to construct this query in SPARQL Graph using MINUS, I got this query, which returns nothing:

select distinct ?identifier
		FROM <http://rack001/data>
		FROM <http://rack001/model>
 where {
	?REQUIREMENT a ?REQUIREMENT_type .
	VALUES ?REQUIREMENT_type { REQUIREMENTS:REQUIREMENT DevelopmentPlan:HighLevelRequirement DevelopmentPlan:SystemRequirement DevelopmentPlan:LowLevelRequirement  } .
	minus {
		?REQUIREMENT PROV_S:identifier ?identifier .
			FILTER ( ?identifier IN ('HLR-2', 'HLR-2'^^XMLSchema:string ) )  .
	} 
}

I'm not sure if this behaviour is a bug or a feature of SPARQL Graph.

[Robert-Adelard]

Thank you for yesterday's discussion, which was helpful. I appreciate that there are other ways to write this query but I still feel that SPARQL Graph's behaviour in this case is incorrect.

The basic problem is that if you tick the Return box you are expecting the result of the query to return a value for that property. Therefore, the query should include a match for that property regardless of any FILTER or MINUS that follows - you are effectively saying "Return this property unless / if it matches any additional condition I have specified".

In other words, if I tick the Return box, I would expect SPARQL Graph to generate the first query, but if I unticked the Return box, I would expect SPARQL Graph to generate the second query. However, providing at least one other property is selected, unticking the Return box has no effect on the query - this cannot be correct. Changing the node group should change the query.

[cuddihyge]

In SPARQL, the MINUS keyword means that the overall query will not match if an instance of this data property exists.
The return checkbox indicates whether the value of the data property should be returned by the query.
Checking the return checkbox when MINUS is selected will cause an empty column to be returned.
This may not be useful, but it is valid SPARQL and not a bug of any sort.
Checking and un-checking the return box while MINUS is selected does indeed generate different SPARQL. The list of returned variables at the top of the query changes. If you have a specific counter-example, please send it along.

[Robert-Adelard]

My apologies - I thought I did have a counter-example, but you're right, the list of returned variables at the top of the query changes when you check and un-check the return box, even though the body of the query remains unchanged.

However, I still think that SPARQL Graph is constructing the wrong query for my example. This isn't about whether the query is valid SPARQL or whether it returns sensible results, but whether the query is what the user expects the query to be, in other words, whether the semantics of SPARQL Graph queries is natural.

I also think your characterisation of MINUS is incorrect - as I understand it, MINUS is used to subtract one graph from another. So MINUS applies to graph patterns, not individual terms. This is at the root of our disagreement.

The issue is whether RETURN takes precedence over MINUS, in other words, whether RETURN applies to the left hand graph as well as the right hand graph. I think this is a reasonable interpretation of the graphical query, particularly given that RETURN is above MINUS in the layout of the query boxes, so I think that SPARQL Graph should translate "RETURN MINUS identifier" as

	?HighLevelRequirement PROV_S:identifier ?identifier .
	minus {
		?HighLevelRequirement PROV_S:identifier ?identifier .
	} 

This returns exactly the same as your query, so there's no difference in behaviour for the simple case. However, when you add in a FILTER, the query works more naturally:

        ?HighLevelRequirement PROV_S:identifier ?identifier .
	minus {
		?HighLevelRequirement PROV_S:identifier ?identifier .
			FILTER ( ?identifier IN ('HLR-2', 'HLR-2'^^XMLSchema:string ) )  .
	} 

This returns what I would expect, namely all the identifiers that do not match HLR-2.

Note that it is necessary to match identifier on both sides of the MINUS because the two sub-graphs are independent and have their own set of bindings. Otherwise, you would end up with the following query, which has a very unexpected result:

        ?HighLevelRequirement PROV_S:identifier ?identifier .
	minus {
			FILTER ( ?identifier IN ('HLR-2', 'HLR-2'^^XMLSchema:string ) )  .
	} 

See the discussion of the relationship between NOT EXISTS and MINUS in the w3c specification:

https://www.w3.org/TR/sparql11-query/#neg-notexists-minus