CCO domain name and its ownership (and PURL Server) #336
Replies: 1 comment
-
@jimschoening1 As the CCO Governance Board and developers move toward a next release of CCO, we would like to use this issue tracker solely for technical comments and concerns regarding CCO and begin using the discussion feature for other conversations. For this reason, I am closing this thread. Please feel free to start more open-ended discussions or recommend future directions (e.g. regarding use of an existing or future PURL server) here: https://github.com/CommonCoreOntology/CommonCoreOntologies/discussions There are a number of distinct issues in this conversation with @alanruttenberg. Three comments: First, regarding configuration management of CCO now and moving forward, this would be a matter to take up with the CCO Governance Board who manages CCO. The CCO Governance Board holds frequent meetings and working sessions, but could also schedule a break out session. If a dedicated conversation on any matter here is desired, I recommend coordinating with @johnbeve or @mark-jensen regarding a time that works for us to meet. Second, for discussions regarding any updates to the license of CCO, please see #215 where these issues will now be discussed. The Governance Board will, of course, be coordinating directly with IEEE; CUBRC, Inc.; and other parties regarding any recommendations. Third, CCO will be adopting new IRIs that include opaque local ids in a single future release and socializing this in advance for stakeholders; however, no decision has yet been reached regarding the namespace or other elements of these IRIs and we will be discussing this with you and others going forward. Presently, this is planned to follow the upcoming release, resulting in a 2.0 release. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
This moved from Issue 105 starting at #105 (comment)
I (Jim) wrote:
I believe this means: CCO IRI http://www.ontologyrepository.com/CommonCoreOntologies/ would be replaced by the PURL https://purl.ieee.org/sa/cco/, which would point to that class in the latest version of CCO at https://opensource.ieee.org/cco/CommonCoreOntologies/
I believe this deprecates use of http://www.ontologyrepository.com, which I don't see we need anymore.
Alan responded:
@jimschoening1 The reason to keep www.ontologyrepository.com (or some other domain that is controlled by the developer community) is that while IEEE, like any organization, has the best of intentions stuff happens in organizations and down the road it may come a time where they no longer host the PURL server. By having the ontology developers/steering committee own the domain that eventuality can be handled by standing up an alternative PURL server and directing the domain to that.
This is not a theoretical concern. OCLC, who ran the PURL server OBO initially used, was an equally reputable and trustworthy organization, but due to internal decisions we were not privy to stopped supporting it. The only thing that let our PURLs continue to be resolved was the forethought in deciding to own our own domain name, and our negotiation with OCLC to be able to use it as a CNAME for their PURL server.
Please don't try to reassure me that IEEE would never do this. It's a big complicated organization and our involvement with them is a tiny thing. Shit happens.
The cost of a domain name is negligible and the protection it gives in the face of unforeseeable changes is very valuable.
Jim responded: Alan, I agree IEEE is not perfectly trustworthy, but who is this developer group and are they a more trustworthy entity? If IEEE decided to defund the PURL server, I believe OSWG members (Are not We the developer group?) would find a way to keep it going. Ron owns the domain now. If we kept it, shouldn't IEEE own it?
Alan: The people who are most invested in making sure the ontology works are the developers and users. There will be a steering committee for Common Core and they are the ones that should control the domain. Certainly we could have IEEE as one of the administrators. But having them own it puts the domain in the same situation as an IEEE domain. If things go to hell, getting back control is dicey
Jim responded: "Alan: But key CCO (plus domain extensions) stakeholders are voting members of IEEE Ontology Standards Work Group (OSWG). Could OSWG own the domain name (whether it is ontologyrepository or purl.ieee.sa/cco/? OSWG has time-tested Policies and Procedures (P&P) with higher levels of governance. Would that not be more trustworthy than the emerging CCO Governance Board? I realize BFO set up their own governance structure, but members of it can't join ISO as individuals. Also, even if IEEE management (who admittedly has little stake in CCO) were to defund the PURL server, the URL (purl.ieee.org/sa/cco/...) is still stable, since IEEE would have no reason to turn off the subdomain. CCO stakeholders could use that URL to stand up our own PURL server, probably under the ultimate control of IEEE, but not requiring their time or budget. In fact, that was the original request to IEEE, for us to set up a PURL server, but their IT team leader said he could do it for us. We might want to get more control of that server, which we could do a Risk Management chart to show the risk of loss of budget for the PURL Server, and show the risk mitigation that we have volunteers who have demonstrated we can run it if needed. The IT Team Leader would fight us, but I chair the IEEE PURL Server Subgroup and could take this over his head."
Alan responded:
"You wouldn't be able to use purl.ieee.org in the case that IEEE decomissioned the server because that's a subdomain of ieee.org. Subdomains are managed with records attached to the primary domain. To change the ip address of purl.ieee.org would require IEEE to execute that. In the scenario I am talking about having IEEE do anything related to the PURL breaks down. Moreover large organizations won't want their subdomains pointing to resources outside their control.
As I said, I have the most confidence in the developers and active users of the ontology having the right incentives to make resolution work in the long term, and so they should be in control of the domain. The setup would be to have at any time 3 designated members who are able to manage the domain records. Payment is cheap and we've always found someone who is is willing to pay the $15 or $20 to renew the domain yearly. If at some point it seems like there's no responsible party within the community then we can always find a new steward at that point.
I have less confidence in the overarching OSWG lasting as long as the ontologies under it last.
We're going back and forth on this. What I suggest has precedent and has worked for over a decade at OBO, so it's a tested solution. I don't understand why there is so much resistance. Technical setup is trivial."
Jim responded: "Alan, It sounds like you don't object to moving to opaque identifiers ;) These other points are off topic, but deserve further discussion, so I will break them out as new issues."
Alan responded: "Nope. But if there's going to be a change in domain as well both changes ought to be done in one release."
Beta Was this translation helpful? Give feedback.
All reactions