Spatial indexing fixes

When a binary data is spatially indexed, its bounding box is stored in the index. That way precision is lost but it assures the search can be performed quickly even if the original geometry consists of thousands of non-intersecting elements.

Auth fixes

Public user authorization fixes

* Auth: expose information if the authenticated user is just the public
  role and advertise the authorization on deny-for-public-role
* UserApi: ban the public role from modyfying itself

Ported from EasyRdf to RdfInterface

5.0.0

composer.json: add sweetrdf/simple-rdf

Emit HTTP 401 instead of 403 when no credentials are provided

4.1.0

SearchTest: adjust to arche-lib 5.6.2

Fix Access-Control-Allow-Headers CORS header value

4.0.1

RestController::handleRequest(): include arche-core headers in Access…

AMQP handlers API reworked and FTS search tuning

Backward-incompatible changes

• /search REST API endpoint - full text search highlighting parameter reworked:
  • All fts* parameters are now arrays (e.g. ftsQuery[], ftsStartSel[], etc.). This allows to specify multiple full text search highlighting queries with their own configuration.
    • The ftsProperty[] parameter can be double-nested just like the property[] and value[] once.
    • It's worth noting that because of the way PHP supports array request parameters and the internal implementation of the arche-lib, passing non-array parameters (e.g. ftsQuery, ftsProperty, etc.) still works.
  • Each highlighted result is now described by three technical triples in the RDF output ({N} goes from 1 to the number of higlighted results):

    <{resourceId}> <{repoCfg}$.schema.searchFts{N}> "higlighted result"
    <{resourceId}> <{repoCfg}$.schema.searchFtsProperty{N}> <RDFpropertyOfTheCorrespondingHihglightedResult>
    <{resourceId}> <{repoCfg}$.schema.searchFtsQuery{N}> <FTShighlightQueryOfTheCorrespondingHihglightedResult>
    

  • As a result two new mappings have to be defined in the config.yaml schema section: the searchFtsProperty and the searchFtsQuery
• The AMQP handlers can now indicate error and error message (like PHP ones already could) but this required changing the format of the AMQP message returned by the handler. Now it should be a JSON object with at least status property. status: 0 indicates successful handler run while any other status is interpreted as an error. In such a case the status property value is used as the HTTP response status code and an optional message property is put as the response body (if not provided, a generic error message is used). Is status equals 0 and the event was triggered by a repository resource (and not a transaction), then the JSON object returned by the handler should also contain the metadata property with resource final metadata serialized as application/n-triples

Other changes

• If the number of triples in the metadata output fits the metadata output cache size (the rest.outputTriplesCache configuration property), the triples are sorted by subject and predicate to produce a nicer output (particularly important for the text/turtle serialization).

3.8.0

• Metadata output rewritten to the quick-rdf-io library providing much better performance and lower memory usage for RDF/XML and JSON-LD formats (see the test results here).
• Fixed the REST API response when a non-existing transaction id is supplied by a request.

Minor enhancements

The acdhOeaw\arche\core\MetadataGui generates HTML output with triple subjects being links.

Bugfixes

acdhOeaw\arche\lib\util\Spatial::fromGeojson() honors the CRS specified in the geoJSON file.

Bugfixes

* BinaryPayload::updateFts(): use the temporary file location
* SearchTest: adjust expected results to new set of technical properties