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?

[klinovp]

No, I only meant that we do not want to use the graph IRI on the statement level to link edge properties to that since in most cases we see it's already used for named graphs. Grouping triples together and adding properties to individual triples are different use cases for us most of the time.
But to answer your question, we regularly see overlapping named graphs in customer data. Since one wants to store the same triple in different NGs, I see no reason why they may not sometime want to attach different edge properties to them in each NG (or why it should be prohibited).

[lisp]

No, I only meant that we do not want to use the graph IRI on the statement level to link edge properties to that since in most cases we see it's already used for named graphs. Grouping triples together and adding properties to individual triples are different use cases for us most of the time.

yet, is it not true that, any distinction between those use cases notwithstanding, the graph identifier will have to either qualify the identity of the triple, in which case one is annotating quads, or otherwise qualify the scope over which the reference applies, which amounts to the same?

[klinovp]

I am not sure I understand the question and also I don't think this ticket was created to discuss use cases but to list them. So we should probably stop and continue wherever each use case is going to be discussed.

[pchampin]

We have a number of use-cases already in this thread, which is great!
But as @akuckartz and @klinovp pointed out, this thread is becoming hard to follow. Indeed, the initial idea was to list the use-cases rather than to discuss them, but on the other hand, the comments are the natural way to discuss about them.

So I created a label use-case and an issue template (following @afs's template at the top of this issue).

@afs @gatemezing @HolgerKnublauch @lisp @akuckartz @mospring @rat10 @blake-regalia @klinovp
Would you be so kind as to copy-pase your use-cases above into individual issues, with the appropriate tag? Sorry for the duplicate work.

[afs]

Just to say thank you to everyone who has put a use case on this issue and also that it won't be forgotten even if not made a separate issue.

[afs]

It helps keeping track of the submissions if we can use GH labels.

I've put all the use cases into the doc

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

including ones that only on this issue (subject to editorial mistakes of course).

Now that hey are captured, this issue shouldn't be used for new use cases.
Thanks.

[TallTed]

It seems that this issue should be closed, with an advisory template for creation of new issues, each new issue to contain one new use case, for the initial work of clarification and de-duplication if/as needed; and an equally important advisory link to the UCR doc source against which additional issues and PRs may be logged, toward the output report/doc?

(It's unclear to me what the relationship between that and EasierRDF-RDFStarUCandRequirements.html; perhaps that could be clarified as well?)

[afs]

@TallTed : templates already done.

And please read:
https://w3c.github.io/rdf-star/UCR/rdf-star-ucr.html#previous-material

[TallTed]

@afs --

re: previous-material -- please see #54

re: templates -- I was suggesting that the new-UCR-issue template (#29 (comment)) be repeated in a closure post to #29, which post should also include a link to the current UCR doc.

Idea being, minimize the detective work new participants/contributors/visitors need to do to figure out those things.