search

w3c / rdf-star

RDF-star specification
https://w3c.github.io/rdf-star/
Other
120 stars 23 forks source link

rdf-star and reasoning #200

Open VladimirAlexiev opened 3 years ago

VladimirAlexiev commented 3 years ago

As a semantic developer who uses rdf-star

As a semantic repository vendor

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

That's an encoding problem?

hartig commented 3 years ago

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 commented 3 years ago

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

pchampin commented 2 years ago

[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 commented 2 years ago

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 commented 2 years ago

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

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

TallTed commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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

afs commented 1 year ago

@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)