Change base URI to something that allows OWL file to resolve

[hlapp]

Right now the base URI is http://phyloinformatics.net/phyloref.owl, which does not resolve (phyloinformatics.net redirects to informatics.nescent.org).

I could make phyloinformatics.org to redirect instead to a place where we can serve the ontology from, but that seems like a bad idea, even if it would preserve the original URI of the ontology. (It would also break various other past uses of the domain.)

If a more generic domain, then we should probably use evoio.org, or purl.obolibrary.org. The latter would allow creating a metadata record that includes specifying patterns for redirects, but the ontology I don't think is mature enough yet for registration with the OBO Foundry (and we don't comply with its policies either yet, importantly for example the identifier policy).

So I'm leaning to just using our own domain, probably under a subdomain so as to build in a level of abstraction to make future redirection easy:

• vocab.phyloref.org (Phenoscape uses vocab.phenoscape.org for its ad-hoc vocabularies and ontologies)
• purl.phyloref.org (following purl.obolibrary.org as the lead)
• ns.phyloref.org (my favorite; the W3C uses this too but as part of the path)

@phyloref/project-personnel - any thoughts?

[ncellinese]

I support this thought :-)

On Oct 13, 2017, at 9:40 PM, Hilmar Lapp notifications@github.com wrote:

Right now the base URI http://phyloinformatics.net/phyloref.owl http://phyloinformatics.net/phyloref.owl, which does not resolve (phyloinformatics.net redirects to informatics.nescent.org).

I could make phyloinformatics.org to redirect instead to a place where we can serve the ontology from, but that seems like a bad idea, even if it would preserve the original URI of the ontology. (It would also break various other past uses of the domain.)

If a more generic domain, then we should probably use evoio.org, or purl.obolibrary.org. The latter would allow creating a metadata record that includes specifying patterns for redirects, but the ontology I don't think is mature enough yet for registration with the OBO Foundry (and we don't comply with its policies either yet, importantly for example the identifier policy).

So I'm leaning to just using our own domain, probably under a subdomain so as to build in a level of abstraction to make future redirection easy:

vocab.phyloref.org (Phenoscape uses vocab.phenoscape.org for its ad-hoc vocabularies and ontologies) purl.phyloref.org (following purl.obolibrary.org as the lead) ns.phyloref.org (my favorite; the W3C uses this too but as part of the path) @phyloref/project-personnel https://github.com/orgs/phyloref/teams/project-personnel - any thoughts?

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/phyloref/phyloref/issues/3, or mute the thread https://github.com/notifications/unsubscribe-auth/ACaXwT3dVzqV9o_Fdn6N0rBfEUqTZ9Prks5ssBEmgaJpZM4P5NrE.

[gaurav]

Making that URL resolvable would be great, so we don't have to download phyloref.owl every time we need to use it! I think we'd also eventually like all our ontologies to resolve, such as the URLs to individual phyloreferences, trees and nodes in the test suite.

I think purl.obolibrary.org should definitely be our eventual goal, once the ontology has solidified more. For current work, here are my preferences, in order from favourite to least favourite:

1. vocab.phyloref.org: I love the idea of a dedicated "ad hoc" space, where very early RDF content can be released with a version URL and so on! Also, "vocab" just sounds cool :). This would also work for permanent URLs to phyloreference ontologies, such as http://vocab.phyloref.org/phyloreferences/combined.owl#PHYREF_0000004.
2. purl.phyloref.org: A bit geeky, but otherwise fine. I like how it's more flexible than "vocab", which might make it more appropriate to provide URLs for individual nodes or trees, which aren't really vocabulary items.
3. ns.phyloref.org: I think an acronym for "namespace" is a little too geeky, but I could live with it!
4. evoio.org: I think using our own subdomain gives us more flexibility in trying out different schemes, so we shouldn't go for this unless there's a compelling reason to combine our work with other EvoIO projects.

[hlapp]

After some more deliberation, I've come to the following conclusions:

• purl.phyloref.org should really be a server (for redirecting, i.e., resolving phyloref PURLs), not the domain for serving a static content fron a Github repo.
• vocab.phyloref.org, if it's not a server (which is 'purl'), implies that there would be many ontologies and/or vocabularies. If served as static Github Pages content, that would mean (i) the content is aggregated from different repos (requires cumbersome deploy process), or (ii) the content is all hosted in the same repo (can get unwieldy quickly for issue tracking etc), or (iii) content is aggregated using submodules (not pretty, has lots of its own issues).
• I agree we should probably stick with our own domain, or alternatively use purl.obolibrary.org right off the bat (which we said we aren't ready to).

So I think this leaves two options that get to the same end result (though one much later than the other):

1. Set up purl.phyloref.org right away, and use it to redirect e.g. http://purl.phyloref.org/phyloref.owl#has_Sibling to https://raw.githubusercontent.com/phyloref/phyloref-ontology/master/phyloref.owl#has_Sibling.
   • Pro: We'll need this anyway, might as well do it now. Easy to record releases through release tags.
   • Con: Need to setup, configure, test a purl.obolibrary.org instance, for at this point essentially only 2 ontologies. Smells like overengineering. Maybe we never need this before migrating to purl.obolibrary.org IRIs.
2. Serve this ontology (and ancillary ones managed here, such as examples) as static content out of this repo under docs/ under a custom domain ontology.phyloref.org.
   • Pro: Straightforward to do, and accomplishes the minimum goal of stable resolvable identifiers (e.g., http://ontology.phyloref.org/phyloref.owl#has_Sibling). Can become the redirection target when moving to purl.obolibrary.org IRIs.
   • Con: No possibility to ensure the right content-type being served (most clients do not seem to be bothered by this, however). Would need to repeat this kind of setup for other repos hosting ontologies of ours.

Overall I think (2) wins on grounds of simplicity and least amount of effort to reach the concrete goal. If you disagree, shout now.

[gaurav]

I agree that purl.phyloref.org is overkill for us right now, and with any luck we'll never need to use it before it's time to think about purl.obolibrary.org URLs. So (2) sounds great to me! However, I'm not sure why we need a custom domain. What's the downside to placing the file at https://www.phyloref.org/phyloref-ontology/phyloref.owl?

The issue with the content-type appears to be because Github Pages uses mime-db, which doesn't include .owl as a known extension. I've created a pull request to add it (jshttp/mime-db#137).

[hlapp]

However, I'm not sure why we need a custom domain. What's the downside to placing the file at https://www.phyloref.org/phyloref-ontology/phyloref.owl?

The downside is that this works naturally only under the assumption that both the ontology and the website are served either from the same server, or from Github Pages. A custom domain decouples that.

Also, a custom domain costs nothing if it's a custom subdomain of the domain we're already using.

[gaurav]

Ah, I see what you mean now by looking at the docs/ and CNAME setup in #21. That sounds great!