[esip-semantictech] Ontology portal recommendati

[John Graybeal]

This conversation is so on point. Thank you Ruth for being the poster child (alas) and explaining things so well. 

Comments in-line…

Sent from my iPhone

> On May 23, 2016, at 9:12 AM, Mcgibbney, Lewis J (398M) via esip-semanticweb <esip-semanticweb at lists.esipfed.org> wrote:
> 
> Hi Ruth,
> 
> 
>> On 5/23/16, 10:58 AM, "Ruth Duerr" <ruth.duerr3 at gmail.com> wrote:
>> 
>> Hi Lewis,
>> 
>> I hadn¹t forgotten that.
> 
> :)
> 
>> That may resolve the identifier issue (at least in the short term -
>> maybe) but not the question of where should the ontologies live and be
>> curated from for the long term and how does the field guarantee long-term
>> access?
> 
> Honestly I think that your particular case demonstrates that a) long term
> guarantees are difficult to find/achieve, and b) the ¹safest¹ tactic is
> probably compromiseŠ at least until we (ESIP Semantic Tech Committee) can
> agree on the platform through which to facilitate what you are after.

Yes, Committee needs to set a sustainable policy direction. Add to that (a) ESIP as a whole (committing to the repository) and (b) funding organizations (for ongoing support). 

>> Copies of my ontologies are both on github which is where Google migrated
>> them when they took Google Code down and in the ESIP semantic portal; but
>> what is the real "right solution?  Is github sufficient?
> 
> For source code management yes. For resolving URI¹sŠ No. You/we should be
> using a semantic data portal.
> 
>> If so, then does ESIP need a semantic repository?
> 
> Well, IMHO the semantic repository is more than just hosting ontologies.
> It is a critical piece of infrastructure which is topically relevant,
> supports development and collaboration and also enables community growth
> here @ESIP.

Concur. It also provides key semantic services (e.g., semantic search, versioning, resolution, mapping, and inferencing), and synergistic social network effects. 
> 
>> Do we need both (the ³Lots of Copies Keeps Stuff Safe" concept says
>> probably yes); but who is going to curate these and keep both copies in
>> sync for the long term.  Yes, I can do so now (though unfunded); but that
>> won¹t last forever.
> 
> I agree. Hence the reason that I say the comment grown aspect is critical.
> I would suggest that simple scripts are written to merely poll a Github
> master branch and pull in the most recent commit into the ESIP Semantic
> Repository. The ability to do this would either be standalone e.g. A local
> script, or else could be built in to the underlying Semantic Repository
> itself. 
> 
>> 
>> 
>> I submit that my experience to date says not to trust any external
>> provider even if they say that they are working to provide long term
>> support.  I mean really, I used Google code to make the ontologies public
>> and I used PURL¹s for all the URL¹s so that I could redirect the URL¹s if
>> the ontologies needed to be moved somewhere else.  The problem is that I
>> no longer can redirect them since OCLC is abandoning PURL.org.
> 
> Yes. Bloody frustrating indeed and to make it worse, the more code you
> write the more of a PITA this issue becomes.

Not all of your experience supports that. MMI's ORR still supports all its content and resolution, as does NCBO's BioPortal. But I agree that Google Code and purl.org (can't believe they'd let that fall down!) are object lessons, alas. 
> 
>> So this experiment in providing long term access to semantic resources
>> failed because none of the tools lasted longer than 3 yearsŠ  That
>> doesn¹t give great confidence that the concept of reusable semantic
>> resources has a chance of ever happening in the Earth sciences.
> 
> Well I think that GoogleCode, Github, PURL, etc are not under control of
> ESIP. It¹s understandably frustrating but not really ESIP or wider Earth
> Science communities fault.

Hmmm. Is the argument that if ESIP commits to a service we can be confident In its long-term (defined as?) survival? I like to think MMI's commitment is like that, of course. 

But what we'll really need is a permanent endowment dedicated to providing the ongoing funds indefinitely. This isn't crazy, but will take time, experience, and advocacy. 

Meanwhile, in a world with such short and driven technology cycles, we'll have to continue trying these experiments—on both client and server sides—to improve persistence and usability of data beyond our personal commitment to them. 

And you, and ESIP, both get kudos for experimenting so far. I've found all the input very helpful and constructive. The fact ESIP has a resourced semantic Committee puts it in a leadership position—I hope it is (we are) able to step up to that. 

John