Differences

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

--- igsn:29_august_2014_friday_namespace_allocation_call [2014/08/29 15:40]
lhsu
+++ igsn:29_august_2014_friday_namespace_allocation_call [2015/05/05 15:30] (current)
lhsu
@@ Line 19: / Line 19: @@
       - The last section of the handbook should give some guidance of how allocating agents assign IGSNs
       - CC: all namespaces should be associated with someone who is a member of IGSN (and that is the way it is). In other words, groups or Allocating Agents have a supernamespace, like IE, IE takes care of all clients with subnamespaces (up to IEDA). But there could be cases where people have a supernamespace and only use it once.
-      - Note: It is a bit confusing with the 10273 in the handbook. Define the toplevel namespaces - IGSN assigned to 10273 is sort of confusing - especially to include into this document, this is for a completely different use.
+      - Note: It is a bit confusing with the 10273 in the handbook. Define the toplevel namespaces - IGSN assigned to 10273 is sort of confusing - especially to include into this document, this is for a completely different use. Response: There is a cultural difference of how people understand the terms, (informed by cultural practices), this text "prefix", "namespace", etc.) has been around for a long time, tries to explain the pattern of hierarchical thing and how to get from an IGSN name to a resolvable URL. KL: some things are more generic than they need to be in the document. There could be confusion if 10273 never changes. Sugestion: When talking about 10273, put that in the section describing where to resolve IGSNs. In the next section, it could be about the IGSN itself, and remove the handle section information. That would be more clear to focus just on IGSN. CC: could use a specific example, like the IE case.
-      - There is a cultural difference of how people understand the terms, (informed by cultural practices), this text has been around for a long time, tries to explain the pattern of hierarchical thing and how to get from an IGSN name to a resolvable URL. KL: some things are more generic than they need to be in the document. There could be confusion if 10273 never changes.
-      - When talking about 10273, put that in where to resolve. In the next section, it could be about the IGSN itself, and remove the handle section information. That would be more clear to focus just on IGSN. CC: could use a specific example, like the IE case.
       - KL: can we define a "top level namespace"
       - 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.
-      - 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**
-      - 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 people 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 people 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**
-      - 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 registry that allows 11 digits. Maybe 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 as opposed to just trust). 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 are certain characters allowed and that there are 9 characters allowed. 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. 9 characters okay, but anything else needs approval.
+      - 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.
-      - Original use case - 9. There are other use cases that cannot use 9, so if you say you can do anything, then people can do anything. The standard length is 9, and if you as an allocation agent wants to use more, then make a case. AA: why would the system break? 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.
-      - The capacity to have longer names needs some logic behind it and it needs to be discussed by the group.
+      - 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 - 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.)
       - The only cases to object to namespaces is (1) someone is thinking of that namespace already (2) the namespace is inappropriate in some language.
     - CC: wants to look at the handbook and can make concrete suggestions about wording.

DataWiki

User Tools

Site Tools

Differences

Page Tools