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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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
Triple:
: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 .
and
: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.
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:
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.
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.
From EasierRDF-RDFstar/RDFStarUCandRequirements.html .
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.
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.
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)."
Ghislain Atemezing
I want to combine TriG notation / Named Graph / RDF-star all together. What is feasible or not with RDF-star?
Jeff Lerman