Handle purls from IDO extensions or which are under control of an ontology other than the one in which they were created

[alanruttenberg]

IDOBRU is an extension of IDO and as such uses IRIs from the IDO namespace. The issue, then, is to have ontobee know to look for IDOBRU's ids in Ontobee's IDOBRU ontology.

Melanie made the suggestion, based on the allocation of IDO ids to IDOBRU that this be handled in the current BBOP apache redirect.

The rules are
 ## INHERIT:
## OBO Redirect from Alan
 RewriteRule ^/ontologies/(\w+)_(\d+)
http://purl.obolibrary.org/obo/$1/about/$1_$2  [R=303,L]

## Fallthough OBO catch.
   ## If the rewrite below ends back up at us, then use the stand-in
   ## page on ontobee.
   RewriteRule ^/ontologies/\S+/about/(\S+)_(\d+)
http://www.ontobee.org/browser/rdf.php?o=$1&iri=http://purl.obolibrary.org/obo/$1_$2

Could we add a rule before the OBO catch to say

   RewriteRule ^/ontologies/IDO/about/(IDO_01(\d+)
http://www.ontobee.org/browser/rdf.php?o=IDOBRU&iri=http://purl.obolibrary.org/obo/IDO_01$1

Recently Oliver asked if we should proceed using that idea.

My comment:

It should work as for this case, but isn't a favored solution for the long run because it depends on numbering convensions in the idspace, which is something we want to avoid when possible, and because there will be more cases of terms that originate in one ontology that move to be managed in another. For example it may make sense for OBI and IAO to swap management of some terms.

Recall the current scheme is:

1. purl.org partial redirect on /obo/ for all OBO IRIs,
2. Berkeley redirection to /obo//about/
3. If there is a purl defined for /obo//about/ then it is used (when ontobee it sets the "o" parameter explicitly)
4. Otherwise back to Berkeley which redirects to Ontobee (when ontobee it computes and specifies the "o" parameter)

Instead I would like to suggest we start using rdfs:isDefinedBy, initially for IDOBRU. During transition, while it is not being used in all ontologies the following protocol should work.

• In steps 3 and 4 above, do not supply the "o" parameter when linking to ontobee. Internal links can still redirect to ontology specific versions from their imports closure, though longer term I would like to see that go away as well (another thread)
• In rdf.php, if the "o" parameter is specified (hence this is a click from ontobee itself) then display the term in that ontology.
• if not, do a sparql query to check if the term in question has a refs:isDefinedBy assertion (in any graph)
• If there is a rdf:isDefinedBy value then display the term from the defining ontology
• If not then compute the ontology from the iri parameter (everything up to but not including the last "_" in the localname - what the apache currently does) and then display the term from the defining ontology

One more change is required. When generating links back to ontobee, the check for rdfs:isDefinedBy should be done for any term in the same namespace as the source and the o parameter set as appropriate. For example, when browsing an IDOBRU term, which is in the IDO namespace, and IDO_ url could be either from IDOBRU or from IDO. If we assume "o" is computed from the IRI, then would get o=IDO, which would be correct for IDO terms, but incorrect for the IDOBRU terms. If we use o=IDOBRU then the IDOBRU terms get the right href, but the IDO terms don't.

To minimized which ontologies MUST use rdfs:isDefinedBy, I suggest that ontobee compute "o" from the IRI. In the case of IDOBRU, which will use rdfs:isDefinedBy, the SPARQL check will find it and fix "o". If we had the default the other way, then both IDO and IDOBRU would both need to implement rdfs:isDefinedBy.

If any of this isn't clear I can do a short teleconference to clarify and answer questions.

-Alan

ps. If there is any performance worry, the following optimization can be made.

do a query for all rdfs:definedBy assertions where the target is not the one that would be computed by default.
Save these in a hash
Instead of using SPARQL to probe for the refs:isDefinedBy assertion, consult that hash.