rdf-star and reasoning

[VladimirAlexiev]

As a semantic developer who uses rdf-star

• I want some reasoning to be standardized
• So that annotations on some triples are carried over to annotations on inferred triples,
• So I can have "consistency" (and peace of mind)

As a semantic repository vendor

• I want some reasoning to be standardized
• So we can implement it for the benefit of our customers
• Who already ask what reasoning can be used with rdf-star

Example: if x p y and p owl:inverseOf q and there are annotations <<x p y>> s o,
shouldn't there be some annotations on <<y q x>>?

Related UC: OWLstar of @cmungall (see #148, compact-serialization-of-owl-graphs.

Eg here are some simple proposals to start people thinking (I'd guess these may be controversial):

# Annotations of inverse props are copied over since "inverse" is a hard/simple logical relation

<<?x ?p ?y>> ?s ?o. 
?p owl:inverseOf ?q 
=> 
<<?y ?q ?x>> ?s ?o


# OWLstar interpretation "SomeValuesFrom" of transitive props is copied over.
# Doesn't necessarily apply to (combinations of) other interpretations

<<?x ?p ?y>> owlstar:hasInterpretation owlstar:SubClassOfSomeValuesFrom.
<<?y ?p ?z>> owlstar:hasInterpretation owlstar:SubClassOfSomeValuesFrom.
?p owl:TransitiveProperty
=>
<<?x ?p ?z>> owlstar:hasInterpretation owlstar:SubClassOfSomeValuesFrom.

# Multiplying probabilities of "fuzzy" statements

<<?x ?p ?y>> :probability ?p1.
<<?y ?q ?z>> :probability ?p2.
?r owl:propertyChainAxiom (?p ?q)
=>
bind(?p1*?p2 as ?p3)
<<?x ?r ?z>> :probability ?p3
# since ?r could be supported in some other way as well, maybe we should express >= instead of equality?

[afs]

@VladimirAlexiev

You may be interested in this text in the published draft:

https://w3c.github.io/rdf-star/cg-spec/2021-07-01.html#ref-opacity-owl-entailment

Given the inference system you describe if always present, we lose other uses cases where quoting is important (i.e the exact triple used, not triples due to local conclusions).

In other words, inference is to be used carefully.

[josd]

Indeed and it is good to be explicit for instance using N3 rules.
I tried things a little bit at https://github.com/josd/eye/blob/master/reasoning/rdf-star-reasoning/test.n3
and get the following answers https://github.com/josd/eye/blob/master/reasoning/rdf-star-reasoning/answer.n3

[VladimirAlexiev]

@afs

inference is to be used carefully

I agree.
This issue is posted just to gather feedback and use cases on reasoning.

rdf-star was motivated as a response to LPG.
But one of the most important benefits of RDF compared to LPG is reasoning (the others are ontologies/shapes and URIs as global identifiers).
If a client asks "what reasoning can be used with rdf-star" and we can only answer "none" or "not standardized", then we lose this benefit of RDF.

@hartig What do you think?

[VladimirAlexiev]

About: https://w3c.github.io/rdf-star/cg-spec/2021-07-01.html#ref-opacity-owl-entailment:
it gets even worse because both of these are false:

select
  (<https://dbpedia.org/resource/Linköping> = <https://dbpedia.org/resource/Link%C3%B6ping> as ?foo)
  (sameTerm(<https://dbpedia.org/resource/Linköping>, <https://dbpedia.org/resource/Link%C3%B6ping>) as ?bar)
{}

[afs]

That's an encoding problem?

[hartig]

I agree that it would be good to allow users to have reasoning with RDF-star for the cases in which it makes sense to the users. To this end, it would be important to have something that enables the users to make such cases explicit. Take, for instance, your first example:

<<?x ?p ?y>> ?s ?o.
?p owl:inverseOf ?q
=>
<<?y ?q ?x>> ?s ?o

You may probably not want to have that as a general rule (for the same reasons as to why the current semantics of RDF-star treat embedded triples as referentially opaque, see Sec.6.4.4 of the draft). Perhaps, you want it only for specific predicates in the position of ?s. To enable users to be explicit about such cases it might be possible to introduce a vocabulary via which they can identify such predicates, which also requires defining the semantics of this vocabulary by means of reasoning rules for the different entailment regimes.

Note that there are already long discussions of such a vocabulary for locally overriding the opaque semantics of embedded triples, making them transparent in some contexts. See #170

it gets even worse because both of these are false:

select
(https://dbpedia.org/resource/Linköping = https://dbpedia.org/resource/Link%C3%B6ping as ?foo)
(sameTerm(https://dbpedia.org/resource/Linköping, https://dbpedia.org/resource/Link%C3%B6ping) as ?bar)
{}

But this has nothing to do with RDF-star per se.

[hartig]

PR #209 provides a proposal to support selective referential transparency, which can be a basis for the reasoning capabilities discussed above.

[pchampin]

[about the inference rule with ow:inverseOf]
Another example showing that you do not always want to do that:

    <#location1> :connectedTo <#location2> {| :distanceInKm 12; :elevationGainInM 15  |}.

    :connectedTo a owl:SymmetricProperty.
    # equivalent to :connectedTo owl:inverseOf :connectedTo .

While the rule above makes sense for :distanceInKm, it clearly does not for :elevationGainInM...

[VladimirAlexiev]

A great example! Which shows that asymmetric qualifiers on a symmetric relation may be problematic.

I'm starting to think that qualifiers on any prop instance that is subject to inference may be problematic. Because you pick just one instance to attach the qualifiers to, but that instance is interdependent with other instances...

[pchampin]

I came to a realization lately : there is actually a tension between

• the need for referential transparency and reasoning on RDF-star quoted triples, and
• the need to be able to distinguish different "occurrences" of RDF-star quoted triples.

Advocates of referential transparency wish that, because :alice :marriedTo :bob and :alice :marriedTo :robert have the same meaning (assuming that :bob owl:sameAs :robert), they would share the same annotations.
Advocates of multiple occurrences wish that two mentions of :alice :marriedTo :bob are sometimes treated as two distinct triples, each with their own annotations.
Obviously, :alice :marriedTo :bob has the same meaning as itself, so both wishes can not be granted at the same time!

This reinforces my opinion that we did the right thing: both behaviors remain possible locally, but need to be explicitly enabled (with TEPs for referential transparency, and with additional nodes for multiple occurrences).

[TallTed]

I came to a realization lately : there is actually a tension

YES! This has been the underlying cause of much of our discussion on list, calls, etc.

The challenge is how to achieve both without "modes". Only time will tell whether the draft solutions we've arrived at will serve for all live deployments.

[afs]

Yes! It is going to be important to get recognition that "occurrences" and "exactly what the triple is" can be important as well as the transparency and reasoning cases.

[ericprud]

Is it worth documenting different rdf-star idioms that meet @pchampin's conflicting use cases?

[TallTed]

Is it worth documenting different rdf-star idioms that meet @pchampin's conflicting use cases?

It seems unlikely to hurt ... and may well be helpful ... but I can't guess at how much time this would take, nor how valuable it might be (e.g., by revealing something significant we haven't already thought through).

[afs]

We can add entries to the UCR document. Even if these are short items, it will be useful to have them for the future. I'm sure the WG will discuss these matters.

[VladimirAlexiev]

@pchampin Could you include this in https://github.com/w3c/rdf-star/blob/main/UCR/rdf-star-ucr.html as per @afs above?

[afs]

@VladimirAlexiev - could you put in a PR and tag it "use case" please?

(I'm not sure what the status of the UCR document is for the Working Group - the CG isn't likely to be active while the WG is running)