Problems registering prefix wfo - Id 'wfo-0001047937' does not exist in 'https://list.worldfloraonline.org/wfo-0001047937'

[rogerhyam]

I'm trying to register WFO for the World Flora Online but can't get through the registration form.

I get the error message:

"Id 'wfo-0001047937' does not exist in 'https://list.worldfloraonline.org/wfo-0001047937'"

Looks like it does to me!

When I have the fields set:

Regex Pattern -> ^wfo-[0-9]{10}$ Sample Id -> wfo-0001047937 URL Pattern -> https://list.worldfloraonline.org/{$id}

I'm a little confused as to how the namespace will work as our identifiers are of the form wfo-0001047937. We don't want to start using wfo:1234567890 and wfo:wfo-0001047937 seems redundant but presume the API will turn wfo-0001047937 into https://list.worldfloraonline.org/wfo-0001047937

I've tried doing it as

Regex Pattern -> ^wfo-([0-9]{10})$ Sample Id -> wfo-0001047937 URL Pattern -> https://list.worldfloraonline.org/wfo-{$id}

Doesn't work either.

Our current API details are here https://list.worldfloraonline.org/

Thanks

[renatocjn]

Hello @rogerhyam,

Sorry for the delay in handling this issue. It seems that the error message here is hiding the actual exception that happens during the request. Sorry about that, I will be fixing that in the following update.

What is happening there is that the URL pattern that you are using seems to redirect to http://www.worldfloraonline.org/taxon/{?id}, so I would recommend that you use that one instead of the one you wrote in the issue since we generally block URLs that further redirect users when IDs are resolved.

In short, the error message is not useful, this will be changed later. Please use the pattern http://www.worldfloraonline.org/taxon/{?id}.

Thank you for using identifiers.org

[rogerhyam]

Thanks @renatocjn

The trouble is the https://list.worldfloraonline.org/ type URIs handle the content negotiation. The http://www.worldfloraonline.org based URIs are "just" the human readable form you are redirected to if you don't ask for a particular serialisation through the content type header. i.e. it presumes you are a human.

Following W3C semantic web best practice the URI of a non serializable object (in this case a taxon or name) should always respond with a 303 redirect to a serialized representation of that object. Content negotiation should decide which serialized resource you are redirected to.

If the identifiers.org service does not follow redirects then it can't be used to link into well designed semantic web URIs. It should at least follow 303 redirects.

What would the workflow be to retrieve data (e.g. JSON) rather than HTML from an identifiers.org or is it only intended for humans to use?

[renatocjn]

Very good point. As far as I know, we welcome both human and non-human readable formats.

My understanding of the best practices was that redirections were not enforced and are simply a way to implement the content negotiation. I would love to read on that if you can reference this information.Could you also provide examples of how your API offers the same content under different formats?

I will reopen the issue for now since there is more to discuss.

[rogerhyam]

There is a description in the Cool URIs document here https://www.w3.org/TR/cooluris/#conneg

I document the supported content types for our URIs here: https://list.worldfloraonline.org/

Here are some example curl calls with redirect for WFO data https://list.worldfloraonline.org/wfo-0000615907

curl -I https://list.worldfloraonline.org/wfo-0000615907

303 -> http://www.worldfloraonline.org/taxon/wfo-0000615907 = the human readable form by default

curl -I -H "Accept: application/json" https://list.worldfloraonline.org/wfo-0000615907

303 -> https://list.worldfloraonline.org/wfo-0000615907/json = redirect to JSON representation of resource.

200: with json data

Example with double redirect on WikiData for stable URI https://www.wikidata.org/entity/Q230791

curl -I -H "Accept: application/json" https://www.wikidata.org/entity/Q230791

303 -> https://www.wikidata.org/wiki/Special:EntityData/Q230791

curl -I -H "Accept: application/json" https://www.wikidata.org/wiki/Special:EntityData/Q230791

303 -> https://www.wikidata.org/wiki/Special:EntityData/Q230791.json

curl -H "Accept: application/json" https://www.wikidata.org/wiki/Special:EntityData/Q230791.json

200: with JSON data

Documentation on wikidata https://www.wikidata.org/wiki/Wikidata:Data_access/en