Generic response for empty URL key

[pbuttigieg]

Some records are "metadata only" and don't have landing pages and thus the top-level url property is empty

This means that clicking on the search result title/link will send users no where

For example :

https://api.search.oceaninfohub.org/source?id=http%3A%2F%2Fportete.invemar.org.co%2Fchm%2Fapi%2Foih%2Ffindid%2Fvessel%2F6b86bafde9894e2bfcd0db5deaeb12a6b57bceaea9bf0835639bc59628c544c9

Could we have a default behaviour for this scenario ?

A page that says - "This is a metadata only record" and then displays the JSON in a pretty-print form ?

[dev-marcoC]

Good morning @pbuttigieg , while I was trying to test the implementation of the functionality you requested, I noticed that the example you sent contains a not empty URL. However, the URL doesn't work, so it's not possible to see the expected behavior with that type of result.

If I try to force an empty URL from the code, this is what I get when clicking on it. The JsonLD is also interactive.

As you can see:

https://oih.trust-it.it/record/id=f5c5469c3dbff9e4b92ecd6f4b869a9d

[pbuttigieg]

Good morning @pbuttigieg , while I was trying to test the implementation of the functionality you requested, I noticed that the example you sent contains a not empty URL. However, the URL doesn't work, so it's not possible to see the expected behavior with that type of result.

The URL property is empty

If I try to force an empty URL from the code, this is what I get when clicking on it. The JsonLD is also interactive.

I'm not sure what you mean. The URL to the record is fine, but the url property in the record is empty. The latter is what should trigger the metadata only display.

As you can see:

https://oih.trust-it.it/record/id=f5c5469c3dbff9e4b92ecd6f4b869a9d

That looks good. If all records with empty (or - if you can implement easily - that return 404, 503, etc) url properties show a page like that, this issue is done.

[dev-marcoC]

I'm sorry Pier Luigi, but there has been a misunderstanding, let me explain it better.

Let's start with the premise that the information contained in the JsonLd and that returned by Solr are represented differently, as you can see from these screenshots.

jsonld:

solr: (where txt_url is not present)

What confused me in this case is that in the code regarding the URL, I found this code:

var url =
    result["type"] === "Person" || result["type"] === "Organization"
      ? resolveAsUrl(result["id"])
      : result["txt_url"] || resolveAsUrl(result["id"]);

From this, I deduced that in most cases, the "URL" being referred to was the ID that came from the response of the call.

Upon further consideration, I have now replaced the previous piece of code with this:

var url =
    result["type"] === "Person" || result["type"] === "Organization"
      ? resolveAsUrl(result["id"])
      : result["txt_url"] || "";

This way, it will assign an empty URL when txt_url is not present, and therefore the example provided by you will behave correctly.

The changes will be included in the next push.

Sorry again for the misunderstanding.

[pbuttigieg]

@dev-marcoC thanks for finding the missing link, I didn't realise that SOLR did this. Yes, that code looks right.

[pbuttigieg]

To be clear, this should apply to all types, not only Person or Organization. I know that was only example code, but just in case.

Also, the only property that should be triggered when a result title in the UI is clicked, is the top-level url property. the @id property in the JSON is for more complex tasks (jumping to another JSON-LD/schema.org file. I'm not sure if that's the same as the "id" you mention above. @jmckenna ?