mmisw / orr-portal

ORR Frontend component
Apache License 2.0
8 stars 5 forks source link

Nested IRI not being handled correctly #167

Closed lewismc closed 4 years ago

lewismc commented 4 years ago

Kai Blumberg reported the following

...Unfortunately as far as I can tell, SWEET terms ... and their id’s which should be URLS e.g., http://sweetontology.net/matrWater/Hydrate don’t seem to resolve.

I can verify that whilst the nested http://sweetontology.net/matrWater/Hydrate URI does not resolve (HTTP 500 internal server error) that the parent URI (physically the parent file) does resolve http://sweetontology.net/matrWater.

What is more, the following GET is fine

curl -i -H "Accept: text/turtle" -H "Content-Type: text/turtle" "http://sweetontology.net/matrWater"

... whereas although the following returns HTTP 200 with the TTL prefixes...

curl -L -i -H "Accept: text/turtle" -H "Content-Type: text/turtle" "http://sweetontology.net/matrWater/Hydrate"
...

HTTP/1.1 200
Date: Wed, 17 Jun 2020 20:40:50 GMT
Server: Apache/2.4.43 (Amazon)
Content-Type: text/turtle;charset=UTF-8
Content-Length: 761
X-Frame-Options: sameorigin
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Access-Control-Allow-Origin: *

@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix err: <http://www.w3.org/2005/xqt-errors#> .
@prefix fn: <http://www.w3.org/2005/xpath-functions#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix fti: <http://franz.com/ns/allegrograph/2.2/textindex/> .
@prefix keyword: <http://franz.com/ns/keyword#> .
@prefix nd: <http://franz.com/ns/allegrograph/5.0/geo/nd#> .
@prefix ndfn: <http://franz.com/ns/allegrograph/5.0/geo/nd/fn#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix xs: <http://www.w3.org/2001/XMLSchema#> .

...no other data is included in the response I expect to see the TTL relations for the Class.

It would therefore appears that file-level content is being returned not other logic contructs e.g. owl:Class or owl:ObjectProperty are!

I don't think that this was always the case and this may simply relate to some of the HTTPD virtual host rules that we have set up on the COR machine but this ticket enables us to investigate it.

lewismc commented 4 years ago

We now also have a rather confusing situation where if the client wishes to Accept: text|application\/html they CAN obtain an HTML response if they reference the Label which appears as an <h3> element on the page e.g. http://sweetontology.net/matrWater#hydrate

lewismc commented 4 years ago

@carueda any idea here? I haven't looked at this since last week.

carueda commented 4 years ago

Issue moved to https://github.com/ESIPFed/cor/issues/63