Skip to content

Rationale

Arno Klein edited this page Mar 3, 2020 · 1 revision

Table of Contents

RDF vs. property graphs

Support of Negation

Because of the “Open World” assumption, SPARQL doesn’t support “negation” well, this means expressing "negation" in SPARQL is not easy.

  • Find all persons who is Bob’s friends but doesn’t know Java
  • Find all persons who know Bob but doesn't know Alice

Rebuttal 1: Negation is expressed in multiple forms in sparql

Rebuttal 2 (@shnizzedy): Depending on the use case, this type of grammar can be more accurate, i.e., "Find all persons who are Bob's friends but we don't know if they know Java" or "Find all persons who know Bob but we don't know if they know Alice" rather than assuming that anything not articulated is untrue.

Support of path expression?

In SPARQL, expressing a variable length path is not easy.

  • Find all posts written by Bob’s direct and indirect friends (everyone reachable from Bob)

Rebuttal: Expressing variable length paths just requires a plus sign

Predicates cannot have properties?

This may be a RDF limitation that SPARQL inherits. Since RDF represents everything in Triples. It is easy to implement properties of a Node using extra Triples, but it is very difficult to implement properties in Edges. In SPARQL, there is no way to attaching a property to a “predicate”.

  • Bob knows Peter for 5 years

Rebuttal: Qualified relations (to apply properties to predicates)

RDF inference rule?

Inference rules are built around RDFS and OWL which is focusing mainly on type and set relationships and is implemented using a Rule: (conditions => derived triple) expression. But it is not easy to express a derived triples whose object’s value is an expression of existing triples.

  • Family income is the sum of all individual member’s income

Question: I assume you could write a sparql query with CONSTRUCT and SUM to create an rdf triple that computes this for a given set of triples, but doesn't this statement seem like something that should go in an ontology?

Support of fuzzy matches with ranked results?

SPARQL is based on a boolean query model which is designed for exact match. Express a fuzzy match with ranked result is very difficult.

  • Find the top 20 posts that is “similar” to this post ranked by degree of similarity (let's say similarity is measured by the number of common tags that the 2 posts share)

Question: Wouldn't this be a sparql query that performs a LIMIT on a SORT of the intersection of tags for all posts with the given post?

subClassOf vs. broader

rdfs:subClassOf vs. skos:broader

Generally speaking, skos:Concepts are definitional abstract concepts whereas rdfs:Classes are the classes of actualized concepts. For the most part, rdfs:Classes and their relationships are what we want.

The rdfs:domain of rdfs:subClassOf is rdfs:Class. The rdfs:range of rdfs:subClassOf is rdfs:Class.

rdfs:subClassOf

S18 skos:semanticRelation, skos:broader, skos:narrower, skos:related, skos:broaderTransitive and skos:narrowerTransitive are each instances of owl:ObjectProperty.

S19 The rdfs:domain of skos:semanticRelation is the class skos:Concept.

S20 The rdfs:range of skos:semanticRelation is the class skos:Concept.

S21 skos:broaderTransitive, skos:narrowerTransitive and skos:related are each sub-properties of skos:semanticRelation.

S22 skos:broader is a sub-property of skos:broaderTransitive, and skos:narrower is a sub-property of skos:narrowerTransitive.

S23 skos:related is an instance of owl:SymmetricProperty.

S24 skos:broaderTransitive and skos:narrowerTransitive are each instances of owl:TransitiveProperty.

S25 skos:narrower is owl:inverseOf the property skos:broader.

S26 skos:narrowerTransitive is owl:inverseOf the property skos:broaderTransitive.

Class & Property Definitions

See Also