search

NCEAS / oboe

OBOE: Extensible Observation Ontology
30 stars 5 forks source link

Discuss: Redirect OBOE URIs to BioPortal for web clients #22

Closed amoeba closed 4 years ago

amoeba commented 4 years ago

Short summary: We redirect the OBOE base URI and all term URIs to the raw OWL file and we could probably do a bit better, like we do with ECSO. Please take a read and offer thoughts on my proposal here. I'd especially like feedback from @mbjones @mpsaloha @mobb and @stevenchong but all is welcome.

Non-short summmary:

@mpsaloha and the rest of the Arctic semantics team have discussed wanting OBOE URIs (especially "contains measurements of type" since we're using that more now) to resolve to human-readable landing pages. They are currently resolving to an inlined OWL file. For example, visit http://ecoinformatics.org/oboe/oboe.1.2/oboe-core.owl#containsMeasurementsOfType in a web browser.

It's important for the base ontology and term URIs to be resolvable to OWL (i.e, application/rdf+xml) for ontology tools and things like external references to work (i.e., given a term, which ontology is this from?). But it's also important for people that have a term URI in front of them to be able to find out more information about the term without specific experience with ontologies.

BioPortal's got a really nice ontology user interface so we'd like to point everyday users (i.e., scientists) at that interface for more information rather than at a raw OWL file. Using their interface is an alternative to building/installing something on our end. To do this, we could redirect the OBOE base and term URIs to BioPortal (as we do for ECSO). However, a universal redirection to BioPortal for all clients means clients that expect to get back application/rdf+xml will get back HTML because BioPortal doesn't do content-negotiation.

Current state: The OBOE base URIs (e.g., http://ecoinformatics.org/oboe/oboe.1.2/oboe-core.owl, etc.) and all term URIs (e.g., http://ecoinformatics.org/oboe/oboe.1.2/oboe-core.owl#containsMeasurementsOfType) redirect all clients to http://ecoinformatics.org/oboe/oboe.1.2/oboe-core.owl.

Proposed change:

Some notes:

  1. I don't propose we redirect text/html requests for term URIs to their individual page on BioPortal because BioPortal doesn't support permalinks (links you can open in a new tab) for term URIs, just class URIs. I didn't know this when I initially expressed enthusiasm for this idea.
  2. We could also do detection based upon user agent headers but that's a little fuzzier. Detecting based upon text/html will redirect the major web browsers but will also redirect any other clients setting their Accept headers to include text/html.
  3. Instead of redirecting clients requesting text/html to BioPortal, we could redirect to https://github.com/NCEAS/oboe and link to BioPortal from there. This lets us retain a bit more control.
stevenchong commented 4 years ago

Thanks for putting this together, Bryce. I agree that having users end up in BioPortal is much better than sending them to the OWL file. For your proposed changes, when a user clicks on http://ecoinformatics.org/oboe/oboe.1.2/oboe-core.owl#containsMeasurementsOfType they will get redirected to the list of properties at http://bioportal.bioontology.org/ontologies/OBOE/?p=properties ?

In Note 3, would the link from Github to BioPortal be automatic or would it require another click by the user? If it's the former I would vote for this option.

amoeba commented 4 years ago

Hey @stevenchong , thanks for chiming in.

For your proposed changes, when a user clicks on http://ecoinformatics.org/oboe/oboe.1.2/oboe-core.owl#containsMeasurementsOfType they will get redirected to the list of properties at http://bioportal.bioontology.org/ontologies/OBOE/?p=properties ?

No, since we don't know whether a URI for an OBOE term is a class or a property or something else. They'd get the BioPortal "landing page".

In Note 3, would the link from Github to BioPortal be automatic or would it require another click by the user? If it's the former I would vote for this option.

Another click.

mbjones commented 4 years ago

Your proposal sounds great to me.

Have you, @mpsaloha, and @stevenchong evaluated using COR rather than Bioportal? Its more in our discipline, and I think might have greater uptake among earth science repository users. But its pretty new, and 'm not sure if it has all of the features of BioPortal. Worth considering though.... http://cor.esipfed.org/ont/#/

mbjones commented 4 years ago

I just noted that it has, for example, the GeoLink ontology in there: http://cor.esipfed.org/ont?iri=http://schema.geolink.org/1.0/base/main

amoeba commented 4 years ago

I did evaluate it for the group and we ultimately decided to stick with BioPortal for now and look at COR again as it matures. There are two relevant aspects:

Since we aren't talking about changing primary hosting for OBOE to BioPortal or COR, does it hurt to load OBOE into COR anyway?

mbjones commented 4 years ago

Probably doesn't hurt. Let's discuss with @mpsaloha . It would also be nice to writeup our rationale for using BioPortal over COR for our application, and share that with the ESIP semantics group as they would probably be interested and it could affect future directions.

mpsaloha commented 4 years ago

Hi folks,

It would be nice to align with COR, but as Bryce notes, we did examine and discuss COR's functionality as of recent weeks, and it pales next to Bioportal. At the last ESIP and in subsequent telecons we've expressed some of these concerns about COR developing more features that are human-relevant, and Lewis and Carlos seemed receptive to this. But I'm not sure if these are top priorities-- the features we want don't exist now, and may not for a while. HOWEVER, no harm done in loading OBOE into COR? That would enable us to explore some of its features.

Bryce, that is a bummer how BioPortal only nicely dereferences to a human-useful presentation of Class URIs, and not Property URIs. For now, just placing at the top of the Object Property tree might suffice? Is there some way that if someone clicks on any of our Obj Props it goes to: http://bioportal.bioontology.org/ontologies/OBOE/?p=properties ?

Steven asked this question, and I think you answered in the negative, but I wonder if there is some workaround whereby we "cheat" on the PURI for Object Properties, and send these to the above URI (for now)?

I quickly checked how some other Onto browsers dereference Object Properties, and (no surprise)-- Ontobee does the best.

E.g., check out how this object property "contains", from RO, dereferences

http://purl.obolibrary.org/obo/RO_0001019

Ironically, EnvO uses yet another term visualizer internally-- the OLS framework, that gives a decent representation when you are browsing for a term, but the associated PURI's then dereferences canonically to Ontobee!

To see what I mean, type "contains" in the search window at:

http://environmentontology.org/Browse-EnvO

I regret I didn't see this email thread yesterday, as Pier and I were hanging out together until late last night, discussing various semantic projects and their merits. If I see him again, I'll ask him about this.

It would be nice if there were some sanity to how: BioPortal, Ontobee, COR, and the OLS lookup were deployed for term visualization/exploration among our various projects!!

Thanks!

aloha, Mark

On Thu, Sep 19, 2019 at 3:28 PM Matt Jones notifications@github.com wrote:

Probably doesn't hurt. Let's discuss with @mpsaloha https://github.com/mpsaloha . It would also be nice to writeup our rationale for using BioPortal over COR for our application, and share that with the ESIP semantics group as they would probably be interested and it could affect future directions.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NCEAS/oboe/issues/22?email_source=notifications&email_token=ABHLL6MOSYVNAPWZTO52DJ3QKP4I7A5CNFSM4IYFQFRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7FADBI#issuecomment-533332357, or mute the thread https://github.com/notifications/unsubscribe-auth/ABHLL6MLNV64VS5RLP4FHXLQKP4I7ANCNFSM4IYFQFRA .

amoeba commented 4 years ago

Thanks for those thoughts, @mpsaloha !

Is there some way that if someone clicks on any of our Obj Props it goes to: http://bioportal.bioontology.org/ontologies/OBOE/?p=properties ?

We can do that in contexts where we know they're clicking on an object prop, yeah. For example, if we're showing a tooltip on a webpage for an EML semantic annotation's propertyURI, we can assume the URI is a property and send them the right direction.

Steven asked this question, and I think you answered in the negative, but I wonder if there is some workaround whereby we "cheat" on the PURI for Object Properties, and send these to the above URI (for now)?

Yeah, I guess we could do this. Under the current proposal, it'd mean someone de-referencing a class URI would end up on the properties page. In this case, I'd rather just dump everyone on the main page rather than pre-supposing. I was going to reach out to BioPortal to mention this just in case they can find time to implement and solve our woes.

It would be nice if there were some sanity to how: BioPortal, Ontobee, COR, and the OLS lookup were deployed for term visualization/exploration among our various projects!!

Fair. Maybe this can be a topic for discussion on the next arctic semantics call.

For now, I think we have a strong consensus on:

amoeba commented 4 years ago

Okay the main task here is done: Clients requesting http://ecoinformatics.org/oboe/oboe.1.2/oboe-core.owl or related 1.2 terms/properties with an Accept header of text/html (i.e., web browsers) are now redirected to BioPortal. All others get the OWL as text/plain. I'll make other issues to track the remaining items here.