Hi, Recently, I have seen a few uses of the namespace prefix urn:ogf:network. While I think a common namespace is a good idea, I just like to emphasis that this is not an official namespace. Or not yet. URN allocated by IANA: http://www.iana.org/assignments/urn-namespaces/ "urn:" is a formal namespace, and registration requires IETF consensus action. Currently, urn:ogf is not even registered, so urn:ogf: or urn:ogf:network must not be used. As I see it, we have two options: 1. Use urn:ogf:network. This first requires IETF consensus action to allocate urn:ogf to the OGF (it is not yet!), then OGF consensus action to allocation urn:ogf:network to the NML-WG. 2. Use the URI ogf.org/network as namespace. This is what is done in RDF (in RDF, http://ogf.org/network would be used, even though the HTTP protocol is not involved in any way) and does not require a standardization action. Given the status of the OGF, I have a very slight preference for the first option. However, I don't know how much more work this means. I am not present at the current OGF, but I would be interested to hear others opinions -- either those in the workgroup and the OGF at large (since option 1 requires OGF action). Note: Ronald van der Pol et al. recently created a document "Global Lightpath Identifiers Proposal", http://www.glif.is/list-archives/all/msg00062.html which discuss a similar naming problem in the GLIF organization. It is a short read and gives some insight into the available options for namespaces (even though it discusses a whole different type of identifiers). Regards, Freek
Hi, I have a strong preference for using URNs. Of course this is subject to OGF applying for and getting the top level urn:ogf from IANA. We have successfully got urn:geant for the our community [id 31; RFC4926] and we find that the sub-delegation model creates an easy to use, easy to manage and powerful distributed naming scheme. After having read the GLIF document I think we should press the relevant people in OGF to ask for one. It also has has a good PR value to use own 1. If we get a NO for OGF applying for urn:ogf then I would stay with the URI in option2 stated below. We could also use a sub-delegated existing urn (see 2c below). 2. If we get a YES for OGF applying for urn:ogf, then the question is what do we do meanwhile. 2a. Use URN under the assumption that OGF will eventually get it 2b. Use URI meanwhile 2c. Another option (though may not be politically correct) would be to use a sub-delegation from an existing URN (mace, geant). This can then be moved to an OGF urn once urn:OGF is allocated (subject to no production use of the sub-delegated values) regards, - anand. Freek Dijkstra wrote:
Hi,
Recently, I have seen a few uses of the namespace prefix urn:ogf:network. While I think a common namespace is a good idea, I just like to emphasis that this is not an official namespace. Or not yet.
URN allocated by IANA: http://www.iana.org/assignments/urn-namespaces/
"urn:" is a formal namespace, and registration requires IETF consensus action. Currently, urn:ogf is not even registered, so urn:ogf: or urn:ogf:network must not be used. As I see it, we have two options:
1. Use urn:ogf:network. This first requires IETF consensus action to allocate urn:ogf to the OGF (it is not yet!), then OGF consensus action to allocation urn:ogf:network to the NML-WG.
2. Use the URI ogf.org/network as namespace. This is what is done in RDF (in RDF, http://ogf.org/network would be used, even though the HTTP protocol is not involved in any way) and does not require a standardization action.
Given the status of the OGF, I have a very slight preference for the first option. However, I don't know how much more work this means.
I am not present at the current OGF, but I would be interested to hear others opinions -- either those in the workgroup and the OGF at large (since option 1 requires OGF action).
Note: Ronald van der Pol et al. recently created a document "Global Lightpath Identifiers Proposal", http://www.glif.is/list-archives/all/msg00062.html which discuss a similar naming problem in the GLIF organization. It is a short read and gives some insight into the available options for namespaces (even though it discusses a whole different type of identifiers).
Regards, Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
Anand Patil wrote:
Of course this is subject to OGF applying for and getting the top level urn:ogf from IANA. We have successfully got urn:geant for the our community [id 31; RFC4926]
Thanks for the pointer! If there is consensus that we indeed should use URNs for identifiers, The way forward, it seems is: 1. Decide if we really like to use URNs. (If not, the OGF can still ask for delegation of urn:ogf, but I probably am less inclined to give it much effort). 2. Ask the OGF standardisation area director for his opinion (Chris Smith and David Snelling) and/or infrastructure area directors ( 3. Involve the OGF liaison to the IETF (Cees de Laat) 4. Get people to write an Internet draft and/or OGF document describing its use). I'm willing to contribute, but only if we decide on using URNs. So first things first: - Do we want to use URNs (e.g. urn:ogf:network or urn:ogf:nml) for identifiers of the classes we define? - If not, do we want to use URIs as identifier? - If not, are there other potential identifiers to use? Note: I'm explicitly talking about the identifiers of the classes (e.g. "network", "layer"), not about identifiers for instances. So far, we have a small "yes" from me, and a large "yes" from Anand. Martin, Jeroen, Aaron, John, Victor, others: what do you think?
2. If we get a YES for OGF applying for urn:ogf, then the question is what do we do meanwhile. 2a. Use URN under the assumption that OGF will eventually get it
My preference. I don't think our schema will be finished much earlier than the delegation, so I rather not add an additional transition. I don't have reason to suspect that the delegation request will fail. Regards, Freek
Freek Dijkstra wrote:
Martin, Jeroen, Aaron, John, Victor, others: what do you think?
I would rather have a URL-like URI for the classes, following the RDF common practice. This provides an easy reference to explanation of the standard. This may not be that important to us right now, but will become more important once you start combining descriptions of different kinds of resources. So far I have not seen any compelling arguments why we should choose URNs over URLs. Jeroen.
On Sep 22, 2008, at 9:13 AM, Freek Dijkstra wrote:
Anand Patil wrote:
Of course this is subject to OGF applying for and getting the top level urn:ogf from IANA. We have successfully got urn:geant for the our community [id 31; RFC4926]
Thanks for the pointer!
If there is consensus that we indeed should use URNs for identifiers, The way forward, it seems is: 1. Decide if we really like to use URNs. (If not, the OGF can still ask for delegation of urn:ogf, but I probably am less inclined to give it much effort). 2. Ask the OGF standardisation area director for his opinion (Chris Smith and David Snelling) and/or infrastructure area directors ( 3. Involve the OGF liaison to the IETF (Cees de Laat) 4. Get people to write an Internet draft and/or OGF document describing its use). I'm willing to contribute, but only if we decide on using URNs.
So first things first: - Do we want to use URNs (e.g. urn:ogf:network or urn:ogf:nml) for identifiers of the classes we define? - If not, do we want to use URIs as identifier? - If not, are there other potential identifiers to use?
Note: I'm explicitly talking about the identifiers of the classes (e.g. "network", "layer"), not about identifiers for instances.
So far, we have a small "yes" from me, and a large "yes" from Anand. Martin, Jeroen, Aaron, John, Victor, others: what do you think?
For the class definitions themselves, I think it makes sense to use URIs a la namespaces so we could put some documentation at the specified URL. For the identifiers for individual instances, I think the URNs make more sense since it doesn't imply a specific method of access to get information about the element.
2. If we get a YES for OGF applying for urn:ogf, then the question is what do we do meanwhile. 2a. Use URN under the assumption that OGF will eventually get it
My preference. I don't think our schema will be finished much earlier than the delegation, so I rather not add an additional transition. I don't have reason to suspect that the delegation request will fail.
*concurs* Cheers, Aaron
Hi Aaron, Aaron Brown wrote:
Martin, Jeroen, Aaron, John, Victor, others: what do you think?
For the class definitions themselves, I think it makes sense to use URIs a la namespaces so we could put some documentation at the specified URL.
Just to make this absolutely clear: by "URIs a la namespaces" you mean to use a URL, abbreviated as a namespace? (So "nml:Node" where the namespace nml has been defined previously). It's a little bit confusing because both URNs and URLs are URIs...
For the identifiers for individual instances, I think the URNs make more sense since it doesn't imply a specific method of access to get information about the element.
Now this I do not agree with, because it would mean that the OGF starts administrating its urn:ogf namespace, and handing out specific subsets to domains, with all associated registration and possible squatting problems. Domains already have a domain name, so why not use that? Jeroen.
Aaron Brown wrote:
So first things first: - Do we want to use URNs (e.g. urn:ogf:network or urn:ogf:nml) for identifiers of the classes we define? - If not, do we want to use URIs as identifier? - If not, are there other potential identifiers to use?
For the class definitions themselves, I think it makes sense to use URIs a la namespaces so we could put some documentation at the specified URL.
I don't understand "URIs a la namespaces". I take it that you mean "URL", e.g. http://ogf.org/ns/network#device which -as Jeroen said- has the added benefit that you can also put the schema at http://ogf.org/ns/network. So that is now 1.5 "vote" in favour of URN versus 2 "votes" in favour of URL. My reason for chosing URN is that I think it is closer to an identifier than a URL. The underlying reason is that I dislike the implied information that a URL carries. One one hand, I strongly prefer URI (either URN or URL) over anything else -- UUID, integers and other IANA-managed namespaces. URI have the benefit of being readable and do not suffer from exhaustion (like AS-numbers and IP-numbers do). On the other hand, I also advocate a URI that is basically an opaque string. I don't want to "interpret" it. So I very much dislike e.g. "http://ogf.org/ns/network#device?type=router" to both signify a device, and the type of device. This means I also dislike the fact that e.g. "http://ogf.org/ns/network#device" implies that there is a schema (or more information) available at "http://ogf.org/ns/network". I simply dislike that an identifier carries implied information, so I have a slight preference for a URN over a URL, since that carries fewer implied information (the only implied information is that it is a standard defined by the OGF if we use the urn:ogf: namespace).
For the identifiers for individual instances, I think the URNs make more sense since it doesn't imply a specific method of access to get information about the element.
I think this is a completely different discussion, despite that it is also about identifiers. I like your argument that we -for the time being- should not imply a specific method of access. Therefor, to me it is an opaque string. Either URN, URL, UUID or some other gooblygook ;-) I agree with Jeroen that whatever the identifier *for instances* is, it should be in some kind of namespace "owned" by the owner of the instance (e.g. the owner of a domain should give it an identifier that is part of his own namespace, not an identifier, part of the OGF namespace) -- I don't assume you were implying that, did you? Regards, Freek
Freek Dijkstra wrote:
So first things first: - Do we want to use URNs (e.g. urn:ogf:network or urn:ogf:nml) for identifiers of the classes we define? - If not, do we want to use URIs as identifier? - If not, are there other potential identifiers to use?
So that is now 1.5 "vote" in favour of URN versus 2 "votes" in favour of URL.
What is the status of this vote about class and property identifiers? The resource identifiers is an interesting discussion, but we independent of the outcome of that discussion, we can take a decision on this issue. Jeroen.
On Sep 25, 2008, at 7:29 AM, Jeroen van der Ham wrote:
What is the status of this vote about class and property identifiers?
The resource identifiers is an interesting discussion, but we independent of the outcome of that discussion, we can take a decision on this issue.
I didn't really think that this was on the table. We've been considering class identifiers to be the URL style of URI from the beginning haven't we? Who is disagreeing? martin
Martin Swany wrote:
On Sep 25, 2008, at 7:29 AM, Jeroen van der Ham wrote:
What is the status of this vote about class and property identifiers?
The resource identifiers is an interesting discussion, but we independent of the outcome of that discussion, we can take a decision on this issue.
I didn't really think that this was on the table. We've been considering class identifiers to be the URL style of URI from the beginning haven't we? Who is disagreeing?
We agreed that it would be at least URI style, AFAIK we never decided on URN or URL.... Jeroen.
Hi, I was away for a week and am joining this discussion a little late. There seem to be two distinct issues: (1) class identifiers (2) instance identifiers IMO the class identifiers are in scope for NML-WG and we are in complete control of this issue. The instance identifiers are also in scope for NML-WG but I do not think we are the only stake holders here. This is a larger issue and needs wider discussion with different groups to arrive at a conclusion. I would like to split the discussion into two threads: For (1) we do need to discuss the pros and cons of URNs versus URLs. This is what the GLIF document that Freek pointed out was trying to do. URNs answer the question 'What' whereas URLs answer the question 'Where'. URNs are supposed to be location independent persistent identifiers. What do we want the class identifiers for? My preference for URNs is because there is a formal documented process of (sub) delegation and ensuring uniqueness. While URLs can also be unique there is no formal process defined. For (2) summarising the discussion so far: - Everyone agrees that 'Identifiers are globally unique strings' - There is no consensus on whether identifiers should be opaque or contain (a little or a lot of) information. - There seems to be some consensus on 'need to know where to find more information (which phonebook?) - We need more dialogue with other interested parties. regards, - anand. Jeroen van der Ham wrote:
Martin Swany wrote:
On Sep 25, 2008, at 7:29 AM, Jeroen van der Ham wrote:
What is the status of this vote about class and property identifiers?
The resource identifiers is an interesting discussion, but we independent of the outcome of that discussion, we can take a decision on this issue.
I didn't really think that this was on the table. We've been considering class identifiers to be the URL style of URI from the beginning haven't we? Who is disagreeing?
We agreed that it would be at least URI style, AFAIK we never decided on URN or URL....
Jeroen. _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
Hi all Deliverable #1 (context of work) is now ready. In attachment to this email and online at: https://forge.gridforum.org/sf/go/doc14679?nav=1 I will wait till Wednesday (Jan.28 ) for reactions from the group. Then I will submit to formal channels. Regards, Paola
Dear Paola, Sorry for the delay, but it seems to me that references to GRID5000 is missing in the reference section. Could you please add the following? [GRID5000a] Franck Cappello, Frederic Desprez, Michel Dayde, Emmanuel Jeannot, Yvon Jegou, Stephane Lanteri, Nouredine Melab, Raymond Namyst, Pascale Vicat-Blanc Primet, Olivier Richard, Eddy Caron, Julien Leduc, and Guillaume Mornet. Grid5000: a nation wide experimental grid testbed. in International Journal on High Performance Computing Applications, 2006. [GRID5000b] : http://www.grid5000.fr Thanks a lot Pascale Vicat-Blanc Primet Le 22 janv. 09 à 14:19, Paola Grosso a écrit :
Hi all
Deliverable #1 (context of work) is now ready.
In attachment to this email and online at: https://forge.gridforum.org/sf/go/doc14679?nav=1
I will wait till Wednesday (Jan.28 ) for reactions from the group. Then I will submit to formal channels.
Regards, Paola <NML-WG-D1- Context-20092201.pdf>_______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
Hi Pascale Pascale VICAT-BLANC wrote:
Dear Paola, Sorry for the delay, but it seems to me that references to GRID5000 is missing in the reference section. Could you please add the following?
[GRID5000a] Franck Cappello, Frederic Desprez, Michel Dayde, Emmanuel Jeannot, Yvon Jegou, Stephane Lanteri, Nouredine Melab, Raymond Namyst, Pascale Vicat-Blanc Primet, Olivier Richard, Eddy Caron, Julien Leduc, and Guillaume Mornet. *Grid5000: a nation wide experimental grid testbed*. /in International Journal on High Performance Computing Applications/, 2006.
[GRID5000b] : http://www.grid5000.fr
Sure, I just need to understand from Franco and Richard how we do this, given the document is under review. As it is not a 'structural' change I assume there should be no issues with this. Best regards, Paola
Thanks a lot Pascale Vicat-Blanc Primet
participants (7)
-
Aaron Brown -
Anand Patil -
Freek Dijkstra -
Jeroen van der Ham -
Martin Swany -
Paola Grosso -
Pascale VICAT-BLANC