Dsp-js sources, versions, naming, error handling

Hello everybody,

I am trying to code an angular app using knora-api-js-lib

1. naming

How should it be called? knora-api-js-lib, @dasch-swiss/dsp-js, @knora/api

the current read npm pakage @knora/api points to the https://github.com/dasch-swiss/knora-api-js-lib repo.

This repo’s README is titled @dasch-swiss/dsp-ui but I’m pretty sure that it is a typo.

2. install

what is the preferred way to install it? fresh code from github and local registry or npm official @knora/api package?

3. knora-api version requirements

the first test that I do points to an error in deserializing lastModificationDate being Not of expected type xsd:dateTimeStamp, I remember having seen that on a knora-api release:

what are the versions requirements between knora-api-js-lib and knora-api releases?

4. error handling

I call a KnoraApiConnection.v2.search.doExtendedSearch(gravsearchQuery)

and process the result with:

.subscribe(
      (resource: ReadResourceSequence) => {
        this.things = resource.resources;
        console.log(resource);
      },
      (error: ApiResponseError) => {
        console.log(error);
      }
    );
  }

but the error is not called, despite a console showing:

ERROR TypeError: "ajaxError.request is undefined" core.js:6185:19
    fromAjaxError api-response-error.js:54
    handleError endpoint.js:133
    getOntology ontologies-endpoint-v2.js:61
    RxJS 7
    Angular 13
    Angular 4
    RxJS 5
    Angular 11

what do I do wrong there?

We are about to change the name in the next published RC. However, for now use https://www.npmjs.com/package/@knora/api/v/1.0.0-rc.1.

https://www.npmjs.com/package/@knora/api/v/1.0.0-rc.1 is compatible with knora-api v13.0.0-rc.3

Hard to say not knowing your setup.

Could you add @knora/api rc.1 to your project’s package.json and run npm i?

If you are using @knora/api directly, you have to install RxJS yourself, since it is a peer dep.

thanks Tobias (@t.schweizer)

So, for now, official npm registry and @knora/api/v/1.0.0-rc.1 for which I have to upgrade my knora set-up to v13-rc3

that’s a lot of RCs do we have estimation dates for the releases?

Thanks again!

I am investigating this now …

You found a bug in the error handling code (second order bug)! :slight_smile:

Here: https://github.com/dasch-swiss/knora-api-js-lib/blob/7c38e545ec026e1707482152668a7b3e76183f83/src/models/api-response-error.ts#L56

I will make a PR for this and you can review it then!

I am happy to do so :+1:

regarding this RC, so it is going to change soon, as I understand client knora-api/1.0.0-rc1 is not backward compatible with server knora-api v11. Now we have some code using client knora-api/0.2.0, will moving the server from v11 to v13 will break it?

Hello Tobias,

for a project that requires a web app, we are using knora-api/1.0.0-rc1 and I set up a matching knora stack for it (knora-api v13.0.0-rc.3), but I get very strange results.

I put up a demo for it:

when ran as is, facing a knora v11 stack, it seems to work fine, switching to my knora v13-rc3 (with ng serve -c test2), it gets a strange error.

here is the gravsearch query that is sent:

PREFIX knora-api: <http://api.knora.org/ontology/knora-api/v2#>
      PREFIX theatre-societe: <http://api-test2.unil.ch/ontology/0103/theatre-societe/v2#>
      CONSTRUCT {
        ?mainRes knora-api:isMainResource true .
      } WHERE {
        ?mainRes a knora-api:Resource .
        ?mainRes a theatre-societe:Representation .
      }
      OFFSET 0

and the error message that I get:

Error: "Invalid resource class Iri http://api-test2.unil.ch/ontology/0103/theatre-societe/v2#Representation"

and the strangest thing is that when the request (without the OFFSET) is pasted on the knora-app of that knora-v13-rc3 stack, it works fine too.

Unfortunately the knora-v13-rc3 stack is behind a firewall hidding it.

I have no clue if it is a sign of a bigger problem or if it is not worth investigating with the forthcoming releases.

But let me know if I can do something.

Could you look at https://github.com/dasch-swiss/knora-api-js-lib/pull/194?
This fixes the problem with ajaxError.request is undefined.

Could you try this with a full resource request (not Gravsearch)?

Ontologies in Gravsearch need to be configured correctly. Could you see what you get back when you request a whole ontology (domain, port)? If the domain or port are not correct, Gravsearch will throw an error. This has nothing to do with the JS lib.

just to be more clear, the request is sent to knora, which answers with a page of 25 matches and knora-api-js-lib does not recognize the IRI as a valid one.

knora returns a value like:

{
  "@graph" : [ {
    "@id" : "http://rdfh.ch/0103/-3RfLeJGTHmqSYiEOYLz-w",
    "@type" : "theatre-societe:Representation",
    "knora-api:arkUrl" : {
      "@type" : "xsd:anyURI",
      "@value" : "http://ark.dasch.swiss/ark:/72163/1/0103/=3RfLeJGTHmqSYiEOYLz=wB"
    },
    "knora-api:attachedToProject" : {
      "@id" : "http://rdfh.ch/projects/0103"
    },
    "knora-api:attachedToUser" : {
      "@id" : "http://rdfh.ch/users/user-unil-fiona-baumann"
    },
    "knora-api:creationDate" : {
      "@type" : "xsd:dateTimeStamp",
      "@value" : "2018-08-07T13:27:18.518Z"
    },
    "knora-api:hasPermissions" : "CR knora-admin:ProjectAdmin|D knora-admin:Creator|M knora-admin:ProjectMember|V knora-admin:KnownUser,knora-admin:UnknownUser",
    "knora-api:lastModificationDate" : {
      "@type" : "xsd:dateTimeStamp",
      "@value" : "2019-10-13T10:38:13.479915Z"
    },
    "knora-api:userHasPermission" : "V",
    "knora-api:versionArkUrl" : {
      "@type" : "xsd:anyURI",
      "@value" : "http://ark.dasch.swiss/ark:/72163/1/0103/=3RfLeJGTHmqSYiEOYLz=wB.20191013T103813479915Z"
    },
    "rdfs:label" : "06–06–1750 | Hôtel de la rue Traversière (Lieu) | Mahomet (Voltaire, Arouet, François-Marie, dit (Personne)) (Oeuvre)"
  },

[...]

 ],
  "knora-api:mayHaveMoreResults" : true,
  "@context" : {
    "theatre-societe" : "http://api-test2.unil.ch/ontology/0103/theatre-societe/v2#",
    "rdf" : "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "knora-api" : "http://api.knora.org/ontology/knora-api/v2#",
    "rdfs" : "http://www.w3.org/2000/01/rdf-schema#",
    "xsd" : "http://www.w3.org/2001/XMLSchema#"
  }
}

Here is a stack trace:

Error: "Invalid resource class Iri http://api-test2.unil.ch/ontology/0103/theatre-societe/v2#Representation"   endpoint.js:123
    getResourceClassDefinition OntologyCache.js:81
    createReadResource ResourcesConversionUtil.js:76
    createReadResourceSequence ResourcesConversionUtil.js:41
    createReadResourceSequence ResourcesConversionUtil.js:41
    doExtendedSearch search-endpoint-v2.js:133
    RxJS 7
    Angular 13

Looking up the ontology:

the knora server’s port is added, so the following lines look for http://api-test2.unil.ch:23333/ontology/ where the entity is http://api-test2.unil.ch/ontology/0103/theatre-societe/v2#Representation

so you think it’s a problem with the port config in getOntologyIriFromEntityIri?

that’s what debug shows, what does you test say on the line below?

Is Knora running on port 80? Is port 23333 forwarded to port 80?

I assume that the problem is that Knora runs on port 80 but JS lib is configured to communicate with Knora on port 23333.

When Knora serves http://api-test2.unil.ch/ontology/0103/theatre-societe/v2#Representation it should have port 23333.

Couldn’t you simply configure Knora to run on port 23333?

knora runs on default 3333 and I map it to 23333 as there are several instances running there:

    Name                   Command               State                Ports
----------------------------------------------------------------------------------------
test2_api_1     bin/webapi -Dconfig.file=/ ...   Up      0.0.0.0:23333->3333/tcp

I am really not the expert for productive settings. When I run Knora locally, I get

http://0.0.0.0:3333/ontology/0001/anything/v2#

So I think the port has to be included in project ontologies (not knora-api).

@subotic Could you confirm that or is this not how it works?

3333 being the port I use in my JS lib settings: new KnoraApiConfig('http', '0.0.0.0', 3333, undefined, undefined, true);

so there would be a config switch that tells gravsearch to either include or exclude from the ontology, the port knora-api listens to?

I can’t find it, could it be a side effect? for example of not using 0.0.0.0?

looking at api.test.dasch.swiss it runs locally on port 3333, with config:

KS_API_PROTOCOL=https
KS_API_HOST=api.test.dasch.swiss
KS_API_PORT=443

it is accessed by https://api.test.dasch.swiss/v2/searchextended

and gravsearch ontologies are named without https or port number (taken from https://app2.test.dasch.swiss/search/expert default search):


PREFIX knora-api: <http://api.knora.org/ontology/knora-api/simple/v2#>
PREFIX incunabula: <http://api.test.dasch.swiss/ontology/0803/incunabula/simple/v2#>

CONSTRUCT {
    ?book knora-api:isMainResource true .
    ?book incunabula:title ?title .

} WHERE {
    ?book a incunabula:book .
    ?book incunabula:title ?title .
}

There was such a setting for ontologies (https://github.com/dhlab-basel/beol/blob/81792bb82d6567e288613cc44fdde4953a5a993d/src/config/config.prod.json), but I think @subotic would be the right person to answer that question. Maybe this is not necessary anymore.

I remember that this caused a lot of configuration problems when deploying.