[esip-semantictech] proposed practices for the Semantic Portal - versioning

[John Graybeal]

Regarding Line's BioPortal questions:
- yes, it is possible for the administrator to change the owner of an ontology. (I think is easy, can check on my return from vacation.)
- BioPortal will track ontology versions (called submissions in BioPortal) and let them be downloaded later. 

I'm not sure I answered all the concerns though, so let's talk offline to follow up. 

John

Sent from my iPhone

> On May 24, 2016, at 2:58 AM, Pouchard, Line C <pouchard at purdue.edu> wrote:
> 
> Dear all:
> 
> These have been very useful discussions about the portals and the sustainability of infrastructure in general.  It’s great to see adult discussions around this topic, as it means that ESIP is maturing and evolving into providing a supporting capability for the community at large.
> 
> For reference, the research data repository at Purdue, based in the Libraries, and with institutional commitment and thought-out policies, only guarantees preservation of the data for 10 years.  We are now in the third or fourth year so there is not real experience with this.  The plan is that after 10 years, data will be submitted to weeding following libraries collection development policies.  Data downloaded on a regular basis, would be kept for a longer period.
> 
> First a response to Ruth’s trouble with updating the sea ice ontologies in the Esip Semantic Portal.  This is frustrating indeed.  But the portal requires login for this sort of operations.  At the last migration and at Ruth’s request, we had uploaded the ontologies in the portal for her.  So now, Ruth, your login, if you have one, does not allow updating the ontologies.  When I tried this feature on an early version of the portal, I had updated the metadata, but not the ontologies, which presumably would be sufficient for your desired operation.  
> 
> Updating the ontologies themselves raises issues of versioning.  This can always be solved by uploading a new version as a new ontology, which is far from ideal.  If John (in his role of manager for the Bioportal code base on which our portal is based, and not in his role of manager for the MMI early version), could enlighten the community and let us know if the current version of the portal supports a better versioning system, this would be fantastic.  If not, maybe you can let us know if there is a development plan for this functionality.
> 
> I hope that this helps people understand the issues surrounding versioning of ontologies.  IMHO, this is something we should think about when ESIP Semantic Technologies committee is preparing to support the Semantic Portal capability more fully.
> 
> Line
> 
> 
> From: esip-semanticweb <esip-semanticweb-bounces at lists.esipfed.org> on behalf of John Graybeal via esip-semanticweb <esip-semanticweb at lists.esipfed.org>
> Reply-To: John Graybeal <jbgraybeal at mindspring.com>
> Date: Tuesday, May 24, 2016 at 12:42 AM
> To: ESIP Semantic Web Committee <esip-semanticweb at lists.esipfed.org>
> Cc: Carlos Rueda <carueda at gmail.com>
> Subject: [esip-semantictech] proposed practices for COR
> 
> Hi everyone, 
> 
> Last month I proposed we finalize some "conditions of operations" for the COR service at ESIP. It seems too soon to make final final decisions, but I want to propose a prototype deployment configuration that we might agree on.
> 
> First, we would keep the URI as esipsw.org, so a particular locally-hosted* ontology will resolve at http://esipsw.org/ont/<authority>/<ontname>, with URIs for terms adding '/<termID>'. (These match the current COR practice.)
> 
> Then, if we could agree to keep these practices unchanged for an evaluation period of at least 6 months, I can take down the red warnings and encourage people to start trying it out without worrying their work might get lost. 
> 
> My dream would be to get approval for these operational practices on the call tomorrow, since I think they are not controversial for the prototype deployment of COR. 
> 
> Thoughts welcome. 
> 
> John
> 
> * "Locally hosted" ontologies in COR are ones whose primary URIs are created by COR in its local domain (esipsw.org). Remote-hosted ontologies specify their own URIs in some other domain for all their terms, and COR creates secondary URIs to resolve these terms.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.deltaforce.net/pipermail/esip-semanticweb/attachments/20160524/beecb291/attachment.html>