RDF* 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* (RDF Star). These use case were provided by members of the W3C RDF Community Group on the RDF* 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*.

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* and graph-level metadata (named graphs)

Dan Brickley

I want to use an RDF* 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*

Ghislain Atemezing

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

Asserting Annotated Arcs

Jeff Lerman