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

[brandon whitehead]

I may be in the minority, but I think this topic is more than appopriate
for this list ( and it is long overdue ).  As such, I would prefer the
conversation stay *online* if possible.

That said, I do realise conversations can be much more efficient.  If there
are offline chats, could someone please provide a summary via email or a
link to a summary page on the ESIP wiki?  It would be a shame if interested
parties were accidentally left out of the loop.

Many thanks,
/Brandon

On Tue, May 24, 2016 at 8:46 PM, John Graybeal via esip-semanticweb <
esip-semanticweb at lists.esipfed.org> wrote:

> 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.
>
>
> _______________________________________________
> esip-semanticweb mailing list
> esip-semanticweb at lists.esipfed.org
> http://lists.deltaforce.net/mailman/listinfo/esip-semanticweb
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.deltaforce.net/pipermail/esip-semanticweb/attachments/20160524/bb4a4792/attachment-0001.html>