Create V2 for Search

[tobiasschweizer]

This makes a start at implementing #530. The rest will be done in subsequent pull requests.

[mrivoal]

I am not sure whether this is relevant at this stage, but as for the design of V2 API, I just want to be sure that the requirements to run queries throughout various (and customed) properties of 2 resource classes will be taken into account (such as expressed here: #227).

This is just a reminder that @loicjaouen has begun to work on an graphic interface (as a proposition for Salsah 1.5/V1 API but with Salsah 2.0 and V2 API in mind), but unfortunately, he hasn't had much time to dedicate to it yet.

[tobiasschweizer]

We have to do that together, absolutely.

As for now, I am trying to have a prove of concept at the end of the week for the fulltext search v2. The Response format should be JSON-LD.

I was fighting with responder manager conf ...

[tobiasschweizer]

@benjamingeer @subotic Hey masters of disaster, does this setup for v2 look reasonable to you?

sorry, I mentioned the wrong geer

[benjamingeer]

We need a naming convention or package name convention to separate internal messages from API messages: #424

In RouteUtilV2, we should get rid of the Knora-specific status code returned in the API response; the HTTP status code is enough. If an exception is thrown, the Knora-specific status code in V1 comes from KnoraExceptionHandler. I guess this means that KnoraExceptionHandler should become KnoraExceptionHandlerV1 and KnoraExceptionHandlerV2.

We should make a UserProfileV2 and clean it up. No reason to have something like UserDataV1 as a separate class. I think means that most of what's in usermessages needs to be shared by V1 and V2.

[tobiasschweizer]

PREFIX knora-base: <http://www.knora.org/ontology/knora-base#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
CONSTRUCT { 
	?matchingSubject ?matchingProperty ?literal .
    ?matchingSubject knora-base:attachedToUser ?valueCreatorMatchingSubject ;
            knora-base:hasPermissions ?valuePermissionsMatchingSubject .
    ?matchingSubject a ?typeMatchingSubject .
    
    ?resource ?prop ?matchingSubject .
    ?resource rdfs:label ?label .
    ?resource a ?typeResource .
    ?resource knora-base:attachedToUser ?valueCreatorResource ;
            knora-base:hasPermissions ?valuePermissionsResource .
}

WHERE {
    
    ?matchingSubject ?matchingProperty ?literal .
    ?literal <http://www.ontotext.com/owlim/lucene#fullTextSearchIndex> 'Zeitglöcklein' .
    
    GRAPH <http://www.ontotext.com/explicit> {
        ?matchingSubject ?matchingProperty ?literal .
        ?matchingSubject a ?typeMatchingSubject .
    }
    
    ?matchingSubject knora-base:isDeleted false .
    
    ?matchingSubject knora-base:attachedToUser ?valueCreatorMatchingSubject ;
    	knora-base:hasPermissions ?valuePermissionsMatchingSubject .
    
    
    OPTIONAL {
    	?resource knora-base:hasValue ?matchingSubject .
    
    	GRAPH <http://www.ontotext.com/explicit> {
        	?resource ?prop ?matchingSubject .
            ?resource a ?typeResource .
    	}
    
    	?resource knora-base:isDeleted false .
    
        ?resource rdfs:label ?label .
        
        
        
        ?resource knora-base:attachedToUser ?valueCreatorResource ;
        	knora-base:hasPermissions ?valuePermissionsResource .
    }
}

[loicjaouen]

For info: here is the first mockup to make a search form we did some time ago (it doesn't include suggested improvements that we collected):
https://platec.unil.ch/test/xtdsrch/

You can click on Persons and Works to list the items you can play with.
The simple search, select Person or Work depending what you look for, type ez press search and you get a list of results.
The extended search allows to do search by exploring the graph, like saying works from authors who published in 1912 (change it to 1916 and the final result changes quite a bit):

[benjamingeer]

Some notes on how to generate V2 search SPARQL for Fuseki or for another triplestore where we can't use inference:

Here's a comparison of what we do for V1 extended search on GraphDB vs. Fuseki.

Matching a property of a resource

We want to match the property and its subproperties.

GraphDB

?resource <@searchCriterion.propertyIri> ?valueObject@index .

Fuseki

?p@index rdfs:subPropertyOf* <@searchCriterion.propertyIri> .
?resource ?p@index ?valueObject@index .

Matching a link to another resource

We match:

• The user-supplied link property and its subproperties.
• The corresponding link value property and its subproperties.

We find out the actual link property, and we use it to match the knora-base:LinkValue.

GraphDB

?resource <@searchCriterion.propertyIri> ?targetResource@index .
?resource <@{searchCriterion.propertyIri}Value> ?valueObject@index .

GRAPH <http://www.ontotext.com/explicit> {
    ?resource ?linkProperty@index ?targetResource@index .
}

?targetResource@index rdfs:label ?literal@index ;
    knora-base:isDeleted false ;
    knora-base:attachedToUser ?targetResourceCreator@index ;
    knora-base:attachedToProject ?targetResourceProject@index ;
    knora-base:hasPermissions ?targetResourcePermissions@index .

?valueObject@index rdf:type knora-base:LinkValue ;
    rdf:subject ?resource ;
    rdf:predicate ?linkProperty@index ;
    rdf:object ?targetResource@index .

Fuseki

?linkProperty@index rdfs:subPropertyOf* <@searchCriterion.propertyIri> .
?resource ?linkProperty@index ?targetResource@index .
?linkValueProperty@index rdfs:subPropertyOf* <@{searchCriterion.propertyIri}Value> .
?resource ?linkValueProperty@index ?valueObject@index .

?targetResource@index rdfs:label ?literal@index ;
    knora-base:isDeleted false ;
    knora-base:attachedToUser ?targetResourceCreator@index ;
    knora-base:attachedToProject ?targetResourceProject@index ;
    knora-base:hasPermissions ?targetResourcePermissions@index .

?valueObject@index rdf:type knora-base:LinkValue ;
    rdf:subject ?resource ;
    rdf:predicate ?linkProperty@index ;
    rdf:object ?targetResource@index .

Matching the class of a resource

GraphDB

?resource a <@restypeIri> .

Fuseki

?resClass rdfs:subClassOf* <@restypeIri> .
?resource a ?resClass .

[benjamingeer]

We're going to merge this PR as is, because the basic API v2 infrastructure is now needed for other PRs. We'll make another PR to finish the v2 search functionality.