RDF-star Use Cases and Requirements

This document describes use cases that justify the extension of RDF in the current work in RDF star community group. It is collaborative work and is a non-normative part of this group output.

This document is a community working draft.


This document collects together use cases and requirments for RDF-star. These use case were provided by members of the W3C RDF Community Group on the RDF-star mailing list and issues of the community's GitHub repository.

Contributing Use Cases and Requirements

Create a GitHub issue following the dedicated template. The suggested form is:

        WHO:  As an <actor>
        WHAT: I want a <feature>
        WHY:  So that <benefit>

This is not mandatory.

Submitted Use Cases

Similarity use case

Submitted Use Case

As a materials scientist working with ontologies. I want to enrich relationships between objects. For example "A --similar--> B" with a similarity measure of 0.5, So that I can identify the pairs of objects with relationships of certain "strength". Visualization of the edges with accordingly weighted thickness would be a huge plus.

distinguish interpretation from representation

Submitted Use Case

As a data service,
from an architectural perspective, interpretation should be distinct from and cleanly layered over representation - both abstract and concrete, in order to facilitate implementation and assure the ability to support future use cases as knowledge evolves over time.

From this perspective, the standard treatment of blank node labels is an anti-requirement, the lessons of which should dissuade from unnecessarily restrictive relations between interpretation and representation.

The situation with blank node labels is a case where the interpretation was fixed, to treat them as referentially opaque. that was a mistake. it would have been better to separate the interpretation from the representation and to allow alternatives.

Natural representation of PG data in RDF

Submitted Use Case

As a KG vendor, we want Stardog customers to have easy to use means to attach properties to edges in their RDF graph or load property graph data with edge properties. Here "easy" specifically means that neither the customer nor the database should have to wreck the data model (and queries) to use any of the workarounds available in plain RDF for that purpose (like the RDF reification). For example, if the customer has

:pavel :worksAt :Stardog

edge in the data and wants to add ... :since 2011 to it, neither they nor the database should have to transform it into a bunch of different triples like

            rdf:subject :pavel ; 
            rdf:property :worksAt ... 

(and then also rewrite queries so that ?s :worksAt :Stardog still returns :pavel).

Also we want to enable customers to store that annotated statement in any named graph they want so we don't want to use named graphs for representing statement-level metadata.

Meta-properties over properties

Submitted Use Case

As a data engineer,
I want to add meta-properties over properties, from an existing SQL-DB to a Graph-DB; that is for example for a node of type PERSON, with a property :birthDate='1985-01-20', I want to be able to say the property was created on '2020-11-10', by a user 'editor1' with the role 'writer'.

So that I do not need to transform the property into a relation plus yet another node.

Support Wikidata/Wikibase data model

Submitted Use Case

As a member of the Wikidata community,
I would like to see triple stores supporting the Wikidata/Wikibase data model as much as possible, so that provenance information etc. can be represented in a way which is pleasing to the mind and software-systems such as Wikibase.

UniProt: attributed/evidenced triples

Submitted Use Case

As an UniProt developer,
I want an easier way to talk about triples we have asserted. So that querying and parsing data-models from evidenced triples becomes simpler.

<P26948> up:annotation <P26948#SIPDB6A831D8E2E2D2A> .
<#_kb.P26948_up.annotation_A144DC8D56EA0928> rdf:type rdf:Statement ;
  rdf:subject <P26948> ;
  rdf:predicate up:annotation ;
  rdf:object <P26948#SIPDB6A831D8E2E2D2A> ;
  up:attribution <P26948#attribution-89AC1B682EEB440D50C4AEBB24FCA860> .

is a lot of bytes to type, and even worse the five joins are very expensive to perform.

Our use-case for RDFstar etc. is to allow us to talk about triples as we do now, but with a higher performance and lower barrier to entry.

We currently depend on the RDF/XML rdf:ID to easily parse this in our inhouse custom RDF parsers, and would like to keep this option open.

At the same time we deal with a lot of renaming (IRIs) for the same thing. e.g. a related database might use http://identifiers.org/uniprot/P05067 instead of http://purl.uniprot.org/uniprot/P05067. And a owl:sameAs is used to merge these datasets. Our attributions/evidences should be found no matter which IRI is used.

CSV and TSV results

Submitted Use Case

As an user,
I want a to be able to retrieve SPARQL results as CSV or TSV So that I can use different toolchains to analyze the results.

Full use case and proposal.

specify sh:message and sh:severity for individual constraints

Submitted Use Case

As an ontologist/schema developer using SHACL
I want to specify sh:message and sh:severity for individual constraints, e.g. attach to individual sh:minCount 1 triples because otherwise I would have to create an individual shape (subject) just for this information.

(This use case is already implemented in TopBraid EDG product)

attribute nodes in relations with additional detail

Submitted Use Case

As a data engineer
I want to attribute nodes in relations with additional detail so that details on the nodes is kept seperate from the property. E.g.: two persons meet at a certain time (which is an attribute of the relation) and one of them has a Covid-19 infection.

represent competing scenarios

Submitted Use Case

As an analyst
I want to represent competing scenarios so that I can compare predispositions and possible outcomes. As a dispatcher in an unfolding catastrophic event I want to integrate new information into a developing model of the event so that everybody can understand the dynamics and probable developments. Both scenarios can benefit from referential transparency but also faithful reproduction of source information.

annotate statements from other named graphs and datasets

Submitted Use Case

As a knowledge worker
I want to annotate statements from other named graphs and datasets where I might not even have write access so that I can make statements about statements on the web of data like about any other entity.

annotate commit deltas

Submitted Use Case

I want to annotate commit deltas to an RDF graph, e.g.:

r:47e1cf2 a :Commit ; 
     :delete <<:bob :age 23>> ;
     :add <<:bob :age 24>>, <<:bob :gender :male>> .

so that a triple can be searched for across commit history in SPARQL-star.

SPARQL-star/RDF-star and RDFS support

Submitted Use Case

As a user, I want to express facts as triple statements `{:s :p :o}` within a triplestore. Later on I realise I want to add facts about this fact. However the {:s :p :o} triple has already been asserted in the triplestore, so I need to add a reification.

          :key rdf:subject :s ; rdf:predicate :p ; rdf:object :o .

Now I can add facts about the fact:

          :key :uom :cm ; :accuracy ".32" .

So far 'standard' reification.

However, as a user I want to add some RDFS 'referential' integrity to help manage the use of additional predicates such a :uom and :accuracy. Since the rdfs:domain of rdf:subject, rdf:predicate, and rdf:object, it can be inferred that :key is a rdf:Statement. This then implies that the rdfs:domain of :uom and :accuracy is also rdf:Statement. Thus if I continue reifying other statements, any predicates associated with the reified statement must have a rdfs:domain of rdf:Statement.

So as a user who wants to add some RDFS-based control over the model, I would introduce a rdfs:subClassOf so that predicates associated with this subClass have a rdfs:domain of this subclass


          :Peter :married :Beth

Reified Triple:

        :marriageKey rdf:subject :Peter ; rdf:predicate :married ; rdf:object :Beth .

        :marriageKey a :Marriage ;
                :when "1980" ;
    		        :where "Kelby" .

with the following RDFS assertions:

          :Marriage rdfs:subClassOf rdf:Statement .
        :when rdfs:domain  :Marriage .
        :where rdfs:domain  :Marriage .

The benefits are that I can combine triple reification with RDFS providing the same benefits that rdfs offers to rdfs:Class to rdf:Statement.

Time-sensitive data use case

Submitted Use Case

As a Big Data and & AI platform-product owner
I want the capacity to describe and query relations in the graph with the dimension of temporal entity-events.

So that we could extract more power from the Graph, using relationships over time in stuff like job-assignment, seasonal events, and so on. In a website with a lot of annotated entities in each page and with the users navigating in that contents over time, we could also look into the user and its semantics data over time too.

So we could ask the RDF-star this kind of quotes:

Uncertainty representation

Submitted Use Case

As a Ph.D. student working on uncertainty,
I want to use RDF* to represent uncertainty values for RDF statements, using the mUnc ontology. This offers the possibility to evaluate the reliability of statements in a specific context.

See mUnc (Metadata with UNCertainty) OWL ontology for describing uncertainty information.

Compact Serialization of OWL Graphs

Submitted Use Case

As an OWL ontology provider who is responsible for providing multiple large biomedical ontologies, many including rich graph structures (partonomies, lineage hierarchies),

I want a compact OWL serialization that avoids generating 4 triples for each existential axiom, whilst retaining semantic rigor.

So that users of my ontologies can naturally traverse ontology graphs using simple triples, and optionally look up the OWL semantics of each triple.

This use case is outlined in more detail in my blog post: Proposed strategy for semantics in RDF* and Property Graphs.

The core idea is that instead of 4 triples for a TBox graph edge, as we have now:

Finger owl:subClassOf [
  a owl:Restriction ;
  owl:onProperty :part_of owl:someValuesFrom :Hand

we would have a triple linking finger to hand, with the OWL semantics of the triple specified as triples on the core triple:

<<:finger :part-of :hand>> owlstar:hasInterpretation owlstar:SubClassOfSomeValuesFrom .

The proposed vocabulary is here https://github.com/cmungall/owlstar.

Note I have phrased this use case as a provider of biomedical ontologies (I provide some of the major ones, including GO, Uberon, Mondo, and am part of the Open Bio Ontologies team), but I believe this would be broadly useful. In particular I think this would be useful in Wikidata, which already provides existential axioms as simple triples.

Previous Material

From EasierRDF-RDFstar/RDFStarUCandRequirements.html .

Annotations of triples that are not in the graph

Richard Cyganiak.

I want to be able to annotate triples that are not in the graph

As an web user, I want to be able to annotate any triples, regardless of whether they are in the same graph or not. Then I can annotate triples in a graph elsewhere on the web.

Annotations of triples where the triples are in another graph of the same RDF Dataset

Andy Seaborne

As an information engineer, I want to be able to manage annotation triples separately from the data triples themselves. I wish to have a separategraph in the same RDF dataset. This will make data management more convenient - e.g. publishing without annotations; e.g. querying the data without the annotations visible.

Combination of RDF-star and graph-level metadata (named graphs)

Dan Brickley

I want to use an RDF-star triple to capture something like, e.g., "the graph denoted by IRI ex:mygraph contains the edge/triple (ex:Bob, foaf:knows, ex:Alice)."

Combining TriG / Named Graphs / RDF-star

Ghislain Atemezing

I want to combine TriG notation / Named Graph / RDF-star all together. What is feasible or not with RDF-star?

Asserting Annotated Arcs

Jeff Lerman