Gather the Use Case and Requirements for RDF*

[afs]

This issue is to collect together the use cases for RDF*.

Please add use cases you are aware of as comments below.

The document started in EasierRDF has been copied into this repo and is visible as HTML at:

https://w3c.github.io/rdf-star/UCR/

Recording a UC&R is not a promise by the CG to address that use case.

A useful format is:

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

[gatemezing]

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+ yet another node.

[HolgerKnublauch]

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 our TopBraid EDG product)

[lisp]

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.

[akuckartz]

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.

Could you please explain the use case in a way I can immediately understand? Thanks ;-)

[lisp]

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.

• https://lists.w3.org/Archives/Public/semantic-web/2009Nov/0040.html
• https://www.slideshare.net/PatHayes/blogic-iswc-2009-invited-talk
• http://videolectures.net/iswc09_hayes_blogic/ (which, just now, did not work)

[akuckartz]

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.

See:

• https://www.mediawiki.org/wiki/Wikibase/DataModel
• https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format
• https://phabricator.wikimedia.org/T206560

[mospring]

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 relationsships of certain "strength". Visualization of the edges with accordingly weighted thickness would be a huge plus.

[rat10]

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.

[rat10]

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.

[rat10]

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.

[lisp]

I want to annotate statements from other named graphs and datasets ...

does this require that you be able to annotate quads?

[rat10]

I want to annotate statements from other named graphs and datasets ...
does this require that you be able to annotate quads?

I assume so, yes

[blake-regalia]

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*.

[klinovp]

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 them into a bunch of different triples like [] rdf:subject :pavel ; rdfs:predicate :worksAt ... (and then also rewrite queries so that ?s :worksAt :Stardog still returns :pavel). Also we want the customer to be able 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.

[lisp]

Also we want the customer to be able 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.

does this intend the that, beyond the "in any name graph" requirement, you intend to be able to distinguish between otherwise identical triples in distinct named graphs?