mcoenca / obo-relations

Automatically exported from code.google.com/p/obo-relations
0 stars 0 forks source link

PURL for 'preceded by' does not resolve #45

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
RO's 'preceded by' has IRI: http://purl.obolibrary.org/obo/BFO_0000062

Should resolve to Ontobee: 
http://www.ontobee.org/browser/rdf.php?o=RO&iri=http://purl.obolibrary.org/obo/B
FO_0000062

It's in BFO's ID space, but they don't seem to be using it.

Original issue reported on code.google.com by ja...@overton.ca on 9 Feb 2015 at 3:18

GoogleCodeExporter commented 9 years ago
I just checked, and it seems to be working now.

Original comment by ja...@overton.ca on 10 Mar 2015 at 1:23

GoogleCodeExporter commented 9 years ago
Reopening.

I'm getting 404 'Term not found' on Ontobee for 
<http://purl.obolibrary.org/obo/BFO_0000062> 'preceded by'. It's pointing to 
BFO, but it should be pointing to RO.

I thought it was working before, but now it's not.

On purl.obolibrary.org I see some other BFO IDs redirected to RO on Ontobee, 
such as /obo/BFO_0000066. I don't see a redirect for /obo/BFO_0000063 
'precedes' but it *is* being redirected properly.

I might have permissions to add a PURL for BFO_0000062 but I'm hesitant to make 
any changes until I understand how this is supposed to work.

Original comment by ja...@overton.ca on 25 Mar 2015 at 2:21

GoogleCodeExporter commented 9 years ago
all the OBO purls first redirect to bbop, which controls the /obo domain are 
rewritten to 

/obo/NS/about/xxx

Then the partial redirect for /obo/NS/about/ is set to redirect to either 
ontobee or the pages chosen by the ontology developers.

There is an in-place redirect for BFO.

If any BFO purls are not being redirected, the most likely problem is monkeying 
around at bbop. Apparently that monkeying around is to redirect some BFO_ uris 
to RO_. I speculate it is buggy.

There is no formal mechanism, at the moment, to redirect a term from one 
namespace to another on ontobee. The proposed solution was the addition of 
rdfs:isDefinedBy or some other relation that expresses that the term is under 
the management of a particular ontology, stop specifying the ontology in the 
redirect, and have ontobee use the management relation to decide how to display 
the term.

status: Approved

id: /obo/BFO/about/ Modify record Show history
type: partial
target: 
http://www.ontobee.org/browser/rdf.php?o=BFO&iri=http://purl.obolibrary.org/obo/
maintainers: dosumis,ALANRUTTENBERG,girlwithglasses,CMUNGALL

Original comment by lori.f.r...@gmail.com on 25 Mar 2015 at 3:35

GoogleCodeExporter commented 9 years ago
Documentation of how PURLs work:
http://code.google.com/p/obo-foundry-operations-committee/wiki/OBOPURLDomain

Original comment by lori.f.r...@gmail.com on 25 Mar 2015 at 4:05

GoogleCodeExporter commented 9 years ago
Thanks for the explanation.

So what needs to be done to fix this? Some BFO IDs should redirect to RO on 
Ontobee, and BFO_0000062 is one of them (see the RO wiki on ROAndBFO)

It sounds like we need someone at BBOP to add an exception for this term, like 
the other BFO terms that RO has adopted. I have authorization to change some of 
purl.obolibrary.org but I don't have access to the BBOP Apache configuration.

Original comment by ja...@overton.ca on 31 Mar 2015 at 6:59

GoogleCodeExporter commented 9 years ago
The redirect lives at the OCLC level. I think I added, but may need time to 
percolate.

/obo/BFO_0000062
=>
http://www.ontobee.org/browser/rdf.php?o=RO&iri=http://purl.obolibrary.org/obo/B
FO_0000062

Original comment by cmung...@gmail.com on 3 Apr 2015 at 1:10

GoogleCodeExporter commented 9 years ago
Thanks!

Original comment by ja...@overton.ca on 3 Apr 2015 at 1:17