VIVO-1746: Create reasoner plugin to allow for reasoning across SKOS concepts

[chenejac]

Don Elsborg (Migrated from VIVO-1746) said:

Currently SKOs broader/narrowers aren't inferenced. It would be beneficial to allow for SKO's hierarchies to be inferenced and materialized.

[chenejac]

Benjamin Gross said:

I'm curious if this is an inferencing or display adjustment, or a combo. To clarify, if you had

person vivo:hasResearchArea concept_b .
concept_b skos:broader concept_a . 

would like the inferencer to create

person vivo:hasResearchArea concept_a

? And/or if you also had

concept_b skos:broader concept_a

, would you like the inferencer to create

concept_c skos:broader concept_a .

[chenejac]

Don Elsborg said:

yes for the first question regarding the person.

the second question I'm assuming you meant that if: concept_b skos:broader concept a . concept_c skos:broader concept_b .

then

concept_c skos:broader concept_a

yes to having the reasoner materialize this in the inference graph

[chenejac]

Mike Conlon said:

And this needn't be a plug-in?

That is, if an authorized external agent is able to query your triple store and create the materialized triples, it could then do a SPARQL update?

[chenejac]

Mike Conlon said:

Any authorized agent that can run SPARQL can use an INSERT to generate the necessary triples.  Suppose we start with: 

PREFIX ex: <http://example.org/>
PREFIX vivo: <http://vivoweb.org/ontology/core#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
INSERT DATA {
 ex:Don vivo:hasResearchArea skos:VIVO .
 skos:Semantics skos:broader skos:VIVO .
 skos:InformationTheory skos:broader skos:Semantics .
}

We can use:

PREFIX ex: <http://example.org/>
PREFIX vivo: <http://vivoweb.org/ontology/core#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
INSERT {?s vivo:hasResearchArea ?b}
WHERE {
 ?s vivo:hasResearchArea ?a .
 ?b skos:broader ?a .
}

To create the inferred triple:

ex:don skos:hasResearchArea ex:Semantics

Running the same INSERT again to pick up the second order inference creates the triple 

ex:Don skos:hasResearchArea ex:InformationTheory

Repeating the INSERT will generate any depth of inference.  Repeating it when there are no more inferences to be made does not generate an error – no new triples are added.

I think this INSERT does exactly what we want.  It does have to be run multiple times to generate all the inferences.

I believe this will be very fast at scale.  The SPARQL query is fully indexed.

[chenejac]

Don Elsborg said:

This then leads me to ask why we even have the inference/reasoner? Why reason across some of the OBO properties to make everybody be a continuant, but we don't reason across skos in the inferrencer. 

Yes, we can all manually construct the things we need if we need to. The purpose of this ticket is that I think it's valuable to have the reasoner materialize the  skos broader/narrower inferences automatically in the inference graph. I was stunned years ago when I put some hierarchical keywords in a VIVO and found that the inferences weren't materialized.  

[chenejac]

Benjamin Gross said:

I think it may have been rhetorical, but here's one reason I find the reasoner very handy: Say you add a new class, "Temporary Adjunct." If you make this new class a subclass of foaf:Person, the editing and display interface is automatically tuned to foaf:Person because the reasoner adds the foaf:Person type to the graph. 

In the absence of a messaging system or queue, I think it makes more sense to do this within VIVO to avoid having to rebuild the inferences completely every time you add a new one. 

Do you think making these inherited hierarchal statements about research areas is safe from a faculty rebellion if the inferred statements are given the same status as the asserted ones? E.g., is it safe to say somebody with a researchArea of 'mutiny' also has a researchArea of 'naval offenses' and 'civilization' (progressively broader terms in the loc)? I don't think I would be happy, personally. I would be fine with it if they were relegated to a separate list in the display.

[chenejac]

Don Elsborg said:

That second question is one I've been pondering too. I think the key is to keep these inferred statements in the inference graph. That would allow developers to pull the name of the graph in with the queries and then present options to the GUI for assertions in the inference graph. So for things like the capability map, one could display an option "Would you like our AI system to expand research terms?".  If they click yes it will hit the inference graph.