describe reification mechanisms declaratively (PRV plus)

[VladimirAlexiev]

Spun off from #122 (cc @hartig @afs @TallTed @pchampin @HolgerKnublauch):

@HolgerKnublauch on dash:reifiableBy says:

Regardless of which specific reification implementation is chosen, the information above can be exploited by tools to drive and validate user input.

So the idea is for dash:reifiableBy to specify constraints on triple annotations, but allow the reification and annotation to be implemented by different lower-level mechanisms (though I believe the "binding" of these mechanisms is not specified in Holger's doc).

The above illustrates 2 ways of doing reification: rdf:Statement and rdf-star. But there are many other ways:

• The study Reifying RDF: What works well with Wikidata? included 5 mechanisms, including more exotic ones like "singleton props" (i.e. per-statement prop URLs)
  • GraphDB RDF-star and SPARQL-star describes them briefly and includes a comparison table
• schema.org has a generic class Role that can split any prop in "two halves" (see second diagram)
  • to query for direct triple or indirect statement eg: ?team s:athlete/s:athlete? ?player
  • to query for details (annotations aka qualifiers): ?team s:athlete ?role. ?role a s:Role; s:athlete ?player; ?qualifier ?value
• the Wikidata implementation uses a similar idea, but multiple prop URLs per prop. For any prop Pnnn:
  • wdt:Pnnn is used for the "direct claim"
  • p:Pnnn is the "first half" from subject to reified Statement
  • ps:Pnnn is the "second half" from reified Statement to object
  • (pq:Pnnn is used when the prop is used as a qualifier)
  • (pr:Pnnn is used when the prop is used in a reference)
  • the "direct claim" is always present so one can query like this:
    • ?subj wdt:Pnnn ?obj: returns claims having "BestRank"
    • ?subj p:Pnnn ?stmt. ?stmt ps:Pnnn ?obj; ?qualifier ?value: returns all claims, together with statement qualifiers (and potentially a reference node)
• PROV includes numerous Unqualified (direct) vs Qualified (reified) pairs, eg for Influence, Derivation, Generation, Association, Attribution, Delegation...

The PropertyReificationVocabulary (PRV) by Jiří Procházka, Richard Cyganiak, Toby Inkster and Bob Ferris in Feb 2011 to capture various reification mechanisms declaratively.

• Gives examples of reification from various domains
• Eg see its application to the Cognitive Characteristics Ontology
• Also see w3c PRV wiki page
• Gives rules for inferring direct triple from reified node and vice versa, and integration with rdf:Statement
• Allows declarative discovery of a reification mechanism, i.e. which class and props make it up
• It was created way before Wikidata and rdf-star, so it doesn't cover them
• To capture a generic pattern like schema's prop -> Role -> prop or Wikidata's p:Pnnn -> Statement -> ps:Pnnn one would have to instantiate PRV declarations for every such prop

Does it make sense to revive the PRV idea to represent declaratively the various reification mechanisms?

• Given that Modifications to SHACL to incorporate RDF-star #122 discusses a SHACL vocabulary for constraining reification annotations
• Given that some repos and tools include conversions between the different mechanisms
• Conversely, should we demonstrate how all the above mechanisms would be represented in rdf-star?

[afs]

It would be good to see such document as a separate document to the one this group is finishing up.

That can be done in RDF-DEV independently of the RDF-star work and could start now.

One area to expand upon is that RDF-star is not RDF reification.
You can RDF reify a statement multiple times with different triples attached.

RDF-star is lower level - it provides the building block and relies on correct modelling to capture multiple independent claims about the triple.

For example:
https://lists.w3.org/Archives/Public/public-rdf-star/2020Jun/0006.html

This isn't specific to RDF-star - the same happens with inappropriate modeling on time ranges and many other cases where each set of claims is itself multiple triples.

[VladimirAlexiev]

https://douroucouli.wordpress.com/2020/09/11/edge-properties-part-1-reification/ by @cmungall has more examples of reification mechanisms, including great advice about them. In particular:

• OWL Annotation vs RDF Reification, and how the two don't work together with current tooling.

@afs

RDF-star is lower level

I think rdf-star is (or can be) higher level because it captures a "reification API" that could admit multiple implementations. I think this matches the position of @HolgerKnublauch (see above) and @cmungall (see below):

"RDF* can be seen as an alternative or it can be seen as syntactic sugar and/or a layer of abstraction over existing RDF reification"

---

Andy, what do I need to do to initiate this work in RDF-DEV? I don't suppose this issue is enough?
I think it's a very important issue but my thoughts on it are quite muddled.
We need experts like you, Chris Mungall, Holger Knublauch, Olaf Hartig, P.A.Champin, Tim Finin, PFPS, etc who've eaten a pound of salt on the pros and cons of various mechanisms, to step in.
Maybe formulate it as a task like this:

Given the latest developments in Wikidata and rdf-star, revisit https://www.w3.org/TR/swbp-n-aryRelations/ and PRV and refresh them to capture more use cases and provide recommendations

[afs]

I think rdf-star is (or can be) higher level because it captures a "reification API" that could admit multiple implementations.

I can't reconcile "reification API" with RDF-star because RDF-star has defined syntax and semantics.

Anything that encapsulates or describes multiple different approaches will expose or allow for differences, because each has unique features and benefits, and some are focused on specific capabilities, not general use.

[afs]

what do I need to do to initiate this work in RDF-DEV

(I am not W3C)

What you need is people to be active, and a shared goal.

An issue here may get discussion (and you've pinged those people). To go further than discussion and have an effect needs a bit more.

You could start a CG at W3C. Anyone can propose one and if it gets 5 supporters (individuals, not companies), it gets created -- https://www.w3.org/community/groups/propose_cg/ -- there are no technical or process barriers of any significance. (You don't even need to ask your W3C AC rep!)

Here (rdf-star) is a bit unusual because it is not a separate CG, it's part of the RDF-DEV CG and publishes its drafts and the final report that way. (I don't why it is this way - it did cause a bit of extra work at one point to deal with IP.)

A CG gives you a well-used framework for producing a report (e.g. it deals with the IP and copyright issues).

So you could just get together and start a doc (github wiki?) then morph into a CG.
Or publish on the web anyway the group of people wishes to

Summary - start with some people wanting to do a thing. The rest is detail.

[TallTed]

• (pq:Pnnn is used when the prop is used as a qualifier)
• (pq:Pnnn is used when the prop is used in a reference)

It seems that these prefixes should differ, else you'd have used one bullet and said something like "(pq:Pnnn is used when the prop is used either as a qualifier or in a reference)".

[VladimirAlexiev]

@afs Your remarks are well received! You're basically saying "this is out of scope for rdf-star" and I guess I agree. But I couldn't start a CG to work on this, maybe others can lead such work...

@TallTed thanks, fixed above. Here's the WD "meta-ontology" (how it lays out its whole data):

[pchampin]

Thanks @VladimirAlexiev for raising this. Updating PRV and/or TR/swbp-n-aryRelations looks indeed like a useful thing to do.

I also agree that this is kind of out-of-scope for the RDF-star "subgroup". Like @afs, I don't see RDF-star as an API that could unify the various reification design pattern -- I see it as yet another design pattern, with its pros and cons.

[pfps]

Part of any WG to add something like RDF* to RDF should be discussion of just what sort of reification should be added and buy-in from the major players in the RDF ecosystem. Without such discussion and buy-in I feel that the WG will not succeed. (It might produce recommendations but they will not be widely implemented.)

So it is worthwhile to keep track of alternatives, both alternatives to RDF* and alternatives within RDF*. It appears to me that right now the RDF* documents not only do not include any information about alternatives but they also hide some of the effects of the choices made in RDF*.

[TallTed]

@VladimirAlexiev -- I do wish the text in the png above, which has terrible font vs background contrast ratios, were presented as text instead of pixels. I strongly advise replacing the png, or at least supplementing it, with codefenced text, whether it gets fancy syntax highlighting or not. (Syntax highlighting color choices that deliver poor contrast can at least be worked around by copying and pasting such text into an unhighlighted tool, which cannot be done with the png.)