Page MenuHomePhabricator

Support transitive queries
Closed, ResolvedPublic

Description

Author: emw.wiki

Description:
Transitive properties have wide use in Wikidata. Examples include basic membership properties like instance of (P31), subclass of (P279) and part of (P361); and genealogical properties like mother and father. The P31 and P279 properties are based on W3C recommendations for representing information in the Semantic Web -- rdf:type and rdfs:subClassOf.

The ability to draw conclusions from transitive properties is possible with RDFS query inference engines that implement SPARQL. A list of SPARQL implementations is available at http://www.w3.org/wiki/SparqlImplementations. Handling the simple entailments implied by P31 and P279 seems to be a core feature of querying in the Semantic Web.

http://meta.wikimedia.org/wiki/Wikidata/Technical_proposal#Optional_extensions_to_phase_3 mentions the first optional goal as "Develop and prepare a SPARQL endpoint to the data". While support for transitive properties presumably (and understandably) would not be part of Wikidata's initial support for SPARQL, a bit down the line it would be very helpful to have support for general transitive properties in Wikidata SPARQL queries, or at least the more limited and core feature of handling inferred claims for the rdf:type and rdfs:subClassOf (P31 and P279) properties.

Magnus Manske has also inquired about support for this kind of feature in http://meta.wikimedia.org/wiki/Talk:Wikidata/Development/Queries. An earlier version of this feature request is available at http://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Archive/2013/04#Transitive_properties_and_SPARQL.

There are important details that would need to be worked out with conflicting sources and qualifiers, but I'm filing this here so there's a place to track this feature request at a high level.


Version: unspecified
Severity: enhancement

Details

Reference
bz50911

Related Objects

StatusSubtypeAssignedTask
ResolvedNone
DeclinedLydia_Pintscher
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
InvalidLydia_Pintscher
ResolvedNone
InvalidLydia_Pintscher
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
InvalidLydia_Pintscher
DeclinedNone
DeclinedNone
DuplicateNone
ResolvedNone
ResolvedNone
InvalidLydia_Pintscher
InvalidLydia_Pintscher
ResolvedNone
ResolvedNone
InvalidLydia_Pintscher
InvalidLydia_Pintscher
Invalid csteipp
Invalid csteipp
ResolvedNone
Declinedhoo
InvalidLydia_Pintscher
InvalidNone
InvalidNone
ResolvedNone
InvalidLydia_Pintscher
DeclinedNone
Invalidthiemowmde

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:55 AM
bzimport set Reference to bz50911.
bzimport added a subscriber: Unknown Object (MLST).

We are currently not planning to provide a SPARQL interface. Our query interface will be much less flexible, and much more geared for direct use in Wikipedia articles. Others are of course welcome to import our data and provide a SPARQL interface (still have to finish the RDF mapping though). I have hopes that perhaps the DBpedia and/or OpenLink folks will do that.

That being said: supporting transitive evaluation of (some) properties is indeed something we have tentatively planned, though the details are still hazy. I suggest to re-word this feature request to not ask about SPARQL in particular, but any way to query transitive relationships.

  • This bug has been marked as a duplicate of bug 59680 ***

@Lydia: How is 50911 a duplicate? Transitive queries may be necessary for, or tangentially related to, subproperties, but the two bugs are very different requests.

In terms of what the actual request is the work that needs to be done is very similar.

emw.wiki wrote:

Lydia, I agree with Steven Rawson. This issue does not seem like a duplicate of 59680.

All subproperties are transitive, but not all transitive properties are subproperties. This ticket seems to be a prerequisite for the ticket it was closed as a duplicate of. That is, I think issue 59680 should be marked as depending on this one.

This ticket was also created several months earlier. If there is an issue that should be resolved as a duplicate, I'd think it would be the one that describes the more narrow case and was filed after the original.