Re: Use Cases: proposed use case process

> On 9. Feb 2023, at 20:24, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> I propose the following use case process. 
> 
> Anyone can submit a use case.

Great :-)

> To be considered by the working group the use case needs to be about quoted triples in RDF or SPARQL.
> To be considered by the working group a working group member needs to support the use case.
> To be considered by the working group the use case has to have a minimum amount of information, including
> what the use case is about;
> a rationale that the use case cannot be handled without quoted triples;

> a rationale that the use case is effectively handled by quoted triples.
> how quoted triples need to behave to support the use case;
> and a fully worked out example that supports the entire use case, not just a part of it.

I understand the need to keep the flood gates closed, but this sounds more like test cases than use cases.  I miss a hint at comparisions of the RDF-star approach to alternative approaches or enhancements, like RDFn for instance. Also in principle anything can be modeled with n-ary relations, blank nodes and standard reification, so "a rationale that the use case cannot be handled without quoted triples" will not be easy to come by.

Irrespective of the legalese of the Charter (which I never read) in my understanding the driving spirit of this standardization effort is to bridge the gap between RDF and Property Graphs (LPG) and the main feature missing from RDF to enable expressing LPG is concise and sound statement annotation. So how about a focus on just that: statement annotation. There are two main applications:
- administrative metadata (popular in RDF)
- qualifying detail (popular in LPG)
Use cases should center on these or explicitly make a case for other uses of statement annotation. Use cases have to be solvable with quoted triples, or it has to be surprising that they can’t be solved with quoted triples.

Best,
Thomas

> 
> A use case editor examines the use case and determines whether there is sufficient information in it for it to be considered by the working group.  (This decision can be appealed to the working group as a whole.)
> The working group then either
> accepts the use case as one that should be supported by the working group's recommendations;
> rejects the use case as either out of scope entirely or one that will not be supported by the recommendations;
> defers a decision until later;
> or asks for changes to the use case or more information about the use case.
> 
> 
> A new repository is created for the use cases, to support the creation of a working group note.
> The note starts out with information about the use case process.
> As use cases are submitted the note points to them, appropriately categorized.
> Discussion on a use case occurs in a repository issue created for the purpose.
> 
> Use cases are created as wiki entries in the repository in a format suitable for automatic insertion into a note.
> The repository wiki home entry contains information about how to create a wiki entry for a use case.
> 
> 
> 
> 
> 
> peter
> 
> 
>

Received on Friday, 10 February 2023 12:40:24 UTC