Trying to Find all Properties Based on Two Restrictions

Question

I am trying to compile (an excerpt of) a list of all properties in a triple store via a SPARQL endpoint. Each of the following two queries yields promising results:

A:

SELECT DISTINCT ?prop
WHERE {
  [] ?prop [].
}
LIMIT 25

B:

SELECT DISTINCT ?prop
WHERE {
  ?prop a rdf:Property.
}
LIMIT 25

As expected/hoped for, there are some items that appear in the result sets of both queries. Hence, combining the restrictions should, based on my current understanding of SPARQL, yield those items again:

C:

SELECT DISTINCT ?prop
WHERE {
  [] ?prop [].
  ?prop a rdf:Property.
}
LIMIT 25

But actually, this query hardly yields any results. Why is that?

I do not recognize what I am doing wrong, and answers to this question as well as to that question seem to suggest an analogous technique of combining those two (theoretically redundant, in very tidy ontologies) restrictions as the way to go.

---

Test cases:

• DBpedia: Queries A and B both return 24 properties such as !bgcolor, !logo or #FuelElements. Yet, the result set of query C is empty.
• A Short Biographical Dictionary of English Literature (RKBExplorer): Queries A and B return 9 results each, 5 of which are contained in both result sets (rdfs:comment, rdfs:subClassOf, rdfs:subPropertyOf, rdfs:label, rdfs:isDefinedBy). Query C yields only rdfs:comment.

Interestingly, the SPARQL endpoints by JES & Co. and by the Alpine Ski Racers of Austria behave like I would expect and the result set of query C is non-empty and filled (to the LIMIT I imposed) with properties that are returned by queries A and B.

So: Why isn't what should be the intersection of two result sets actually the intersection? Are the described endpoints that buggy (unlikely ...), or is my understanding of SPARQL flawed there (likely)?

Answer 1

DBpedia: Queries A and B both return 24 properties such as !bgcolor, !logo or #FuelElements. Yet, the result set of query C is empty.

It could be due to DBpedia having timeouts.

WHERE {
   [] ?prop [].
   ?prop a rdf:Property .
}

is potentially a quite expensive query, depending on execution stragtegy. The first part says "get all triples". When just

SELECT DISTINCT ?prop
WHERE {
  [] ?prop [].
}
LIMIT 25

the results are a restricted stream. When you add the ?prop a rdf:Property there is a DB join needed to find the ?prop in common. As it's a rather unusually pattern, there may be less support from the optimizer.

At the moment, I get timeouts on

SELECT  ?prop
WHERE {
   ?prop a rdf:Property .
   [] ?prop [].
}
LIMIT 1