Nested IRI not being handled correctly

[carueda]

(moved from https://github.com/mmisw/orr-portal/issues/167 as this is an issue on the COR machine instance)

@lewismc entered:

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.

---

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

[carueda]

@lewismc I think we need to update the apache rule to only use pyLODE for ontologies, not terms . Let me try that.

[carueda]

@lewismc

(I noted the triple store was empty (probably some recent restart of the containers?); I just reloaded it. )

I changed the rule so pyLODE is dispatched only for ontologies

• http://sweetontology.net/matrWater

while terms are dispatched via the COR as before:

• http://sweetontology.net/matrWater/Hydrate

Content-negotiation involving semantic serialization should continue to work as usual, eg:

$ curl -i -H 'Accept: text/turtle' http://sweetontology.net/matrWater

$ curl -i -H 'Accept: text/turtle' http://sweetontology.net/matrWater/Hydrate

(btw, no need to send any Content-Type header as no payload is being included in the request.)

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

This is interesting ... I'll see if I can adjust the "term" rule so it takes advantage of this, assuming it is a feature in pyLODE.

[carueda]

No luck trying to take advantage of the "hash feature" in pyLODE (assuming that's what it is). What I tried is commented out in /etc/httpd/conf.d/sweetontology.conf (on the previous amazon instance).

So, for now, the change remains that (under the HTML case), ontologies are dispatched via pyLODE, and everything else via COR.

[lewismc]

@carueda this issue is now resolved. Thanks for updating the rules.

No luck trying to take advantage of the "hash feature" in pyLODE...

The <h3> element uses the rdfs:label, which is lowercase.

http://sweetontology.net/matrWater#hydrate

[lewismc]

Excellent work @carueda

[kaiiam]

Looks better, great that it's it's now resolving! I still think some terms are missing definitions but that's a separate issue.

-Kai

[carueda]

The <h3> element uses the rdfs:label, which is lowercase.

http://sweetontology.net/matrWater#hydrate

Ah I see, thanks for the clarification. So, maybe not worth trying to enable any automatic redirection for that as any rule here would be rather weak (not general); in particular, it would assume that the value of rdfs:label is exactly as the piece after the slash (ignoring case).