User Tools

Site Tools


igsn:29_august_2014_friday_namespace_allocation_call

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
igsn:29_august_2014_friday_namespace_allocation_call [2014/08/29 15:53]
lhsu
igsn:29_august_2014_friday_namespace_allocation_call [2015/05/05 15:30] (current)
lhsu
Line 23: Line 23:
       - We May need to set up a namespace subcommittee (mentioned in the text)       - We May need to set up a namespace subcommittee (mentioned in the text)
       - One of the flowcharts is out of date for the Namespace Approval Procedure, if not rejected right away, there is an appeals period. (vs. an approval period). If the IGSN e.V. membership does not react, is an approval. If we seek an approval, we need a vote for all cases, but if it is an appeals period then it goes through unless there is a rejection. The persons who would appeal would be the persons that objected.       - One of the flowcharts is out of date for the Namespace Approval Procedure, if not rejected right away, there is an appeals period. (vs. an approval period). If the IGSN e.V. membership does not react, is an approval. If we seek an approval, we need a vote for all cases, but if it is an appeals period then it goes through unless there is a rejection. The persons who would appeal would be the persons that objected.
-      - A top level namespace can only be given to a new allocating agent. Or, an existing allocation agent serves a new community and wants another top level namespace. For Example: IEDA is building sample registration system for the critical zone observatories. The will ask for the top level namespace CZ. It's agreed, that the top level namespaces are under the responsibility of the Allocating Agent to adhere to the rules of the handbook. AA: that may be something that does not happen in a month. Check: are they a member? Does it conflict with anything else? That can be done in a month. But we need to make sure that the allocation agent is functioning in the way that we envision they are. +      - A top level namespace can only be given to a new allocating agent. Or, an existing allocation agent serves a new community and wants another top level namespace. For Example: IEDA is building sample registration system for the critical zone observatories. The will ask for the top level namespace CZ. It's agreed, that the top level namespaces are under the responsibility of the Allocating Agent to adhere to the rules of the handbook. AK: that may be something that does not happen in a month. Check: are they a member? Does it conflict with anything else? That can be done in a month. But we need to make sure that the allocation agent is functioning in the way that we envision they are. 
     - **Rules and Responsibilities of members**     - **Rules and Responsibilities of members**
       - CC: in the invoicing letter, we wanted to tell members what the rules and responsibilities are. Must adhere to the namespace policies. What happens if members don't use their namespace, then what? Membership rules refer to the statutes. But something else about the rules of the procedures should be included. If members don't come to the meetings (are not active), then after a warning, they may not be members anymore. If There is a member that pays their dues and attends the meetings, and they propose a namespace, at that point there is not much else besides saying that the namespace is unique and conforms to the understood rules. But after that, what happens if the group doesn't act on the namespace for 1-2-3 years, OR if they start breaking the syntax. Then what? Also, how do we even monitor that? The registry would have to control the syntax of IGSNs being registered at the registry. It will increase the burden of the organization running the registry and would require some resources.        - CC: in the invoicing letter, we wanted to tell members what the rules and responsibilities are. Must adhere to the namespace policies. What happens if members don't use their namespace, then what? Membership rules refer to the statutes. But something else about the rules of the procedures should be included. If members don't come to the meetings (are not active), then after a warning, they may not be members anymore. If There is a member that pays their dues and attends the meetings, and they propose a namespace, at that point there is not much else besides saying that the namespace is unique and conforms to the understood rules. But after that, what happens if the group doesn't act on the namespace for 1-2-3 years, OR if they start breaking the syntax. Then what? Also, how do we even monitor that? The registry would have to control the syntax of IGSNs being registered at the registry. It will increase the burden of the organization running the registry and would require some resources. 
-      - AA: every year at the General Assembly, then we will get some summary of what has happens. There is a summary once per year. Total, new IGSNs assigned per year. (1) Looking at the activity is something that DataCite does as well, to give a people an overview of what is happening. (2) If a namespace is not being used, for one year, then it should be revoked. There could also be a warning period.+      - AK: every year at the General Assembly, then we will get some summary of what has happens. There is a summary once per year. Total, new IGSNs assigned per year. (1) Looking at the activity is something that DataCite does as well, to give a people an overview of what is happening. (2) If a namespace is not being used, for one year, then it should be revoked. There could also be a warning period.
     - **IGSN Syntax beyond the suggested syntax**     - **IGSN Syntax beyond the suggested syntax**
       - KL: Does there need to be an approval process for changing the syntax of IGSN, and to what level should this be controlled? It's easy to control 9 digits. If someone wants 11 digits, then something would need to be implemented at the top level registry that allows 11 digits for that allocating agent. Maybe you suggest deviations from 9 characters, you need to provide the resources to do the checks. JK: at the moment the system checks if you are allowed to register in that namespace and the webspace, it doesn't check anything else. We could check the format, but do we really want to do that? the hierarchical delegation pattern is good because then you can leave those business processes to the agents and trust that they do things right. KL: but we would also like to make sure they are doing things right as opposed to just trusting them  If there are all sorts of syntax modifications, then it will ultimately increase the risk of failure to the system. If someone wants to make changes to the syntax, they can do that, but they should present the changes to the IGSN e.V. to be approved then we reduce the risk of crazy extensions. JK:  There seems to be agreement that if it is 9 characters and uses approved characters, then that is fine. But otherwise you must present a case.        - KL: Does there need to be an approval process for changing the syntax of IGSN, and to what level should this be controlled? It's easy to control 9 digits. If someone wants 11 digits, then something would need to be implemented at the top level registry that allows 11 digits for that allocating agent. Maybe you suggest deviations from 9 characters, you need to provide the resources to do the checks. JK: at the moment the system checks if you are allowed to register in that namespace and the webspace, it doesn't check anything else. We could check the format, but do we really want to do that? the hierarchical delegation pattern is good because then you can leave those business processes to the agents and trust that they do things right. KL: but we would also like to make sure they are doing things right as opposed to just trusting them  If there are all sorts of syntax modifications, then it will ultimately increase the risk of failure to the system. If someone wants to make changes to the syntax, they can do that, but they should present the changes to the IGSN e.V. to be approved then we reduce the risk of crazy extensions. JK:  There seems to be agreement that if it is 9 characters and uses approved characters, then that is fine. But otherwise you must present a case. 
-      - The Original use case works fine with 9 characters. There are other use cases (very large repositories) that cannot use only 9 characters. But if IGSN e.V. allows allocating agents to do //anything//, then people will do anything. The standard length is 9, and if you as an allocation agent wants to use more, then make a case to the IGSN e.V.. AA: why would the system break with longer IGSNs? We are uniquely identifying samples so they can be linked in databases and etc. KL: But investigators will not want to use very long, cumbersome IGSNs in their tables and etc. The first paper with IGSNs in it, already had an example where there was an IGSN with a missing characters, so that IGSN did not resolve. Jens: Elsevier should check to see if the URL resolves. +      - The Original use case works fine with 9 characters. There are other use cases (very large repositories) that cannot use only 9 characters. But if IGSN e.V. allows allocating agents to do //anything//, then people will do anything. The standard length is 9, and if you as an allocation agent wants to use more, then make a case to the IGSN e.V.. AK: why would the system break with longer IGSNs? We are uniquely identifying samples so they can be linked in databases and etc. KL: But investigators will not want to use very long, cumbersome IGSNs in their tables and etc. The first paper with IGSNs in it, already had an example where there was an IGSN with a missing characters, so that IGSN did not resolve. Jens: Elsevier should check to see if the URL resolves. 
       - There seems to be agreement that the capacity to have longer names needs some logic behind it and it needs to be discussed by the IGSN e.V. group. i.e. There are lengths that are "reasonable" to accommodate larger systems but there are unreasonable lengths that are unnecessary and may risk the success of the IGSN.       - There seems to be agreement that the capacity to have longer names needs some logic behind it and it needs to be discussed by the IGSN e.V. group. i.e. There are lengths that are "reasonable" to accommodate larger systems but there are unreasonable lengths that are unnecessary and may risk the success of the IGSN.
     - **Does there need to be a Quorum to decide on namespaces?** - Decided there does not need to be a quorum, but result should be announced. (We basically have this now, but it still requires a manual dimension, it is not fully automated. But it should not happen too often.)     - **Does there need to be a Quorum to decide on namespaces?** - Decided there does not need to be a quorum, but result should be announced. (We basically have this now, but it still requires a manual dimension, it is not fully automated. But it should not happen too often.)
igsn/29_august_2014_friday_namespace_allocation_call.1409327601.txt.gz · Last modified: 2014/08/29 15:53 by lhsu