OASIS Code List Representation TC

Looking at the list-level meta data in genericode, here is an example 
from the UBL project:

If I understand your meaning, Ken, you are suggesting standardised values  
for the "LongName/@Identifier" attribute (and if I don't understand your  
meaning, please reply and just ignore whatever I've written from here  
onwards).  I thought about this when I originally drafted together, and my  
thinking at the time is that you have to draw a line on identification  
somewhere.  I knew I could take it further, especially around types of  
long names, but I thought that it would be a diminishing return.

We could certainly propose some values for common purposes, a starting  
list that it not intended to be exhaustive, but I don't think it needs to  
be URNs, some plain old short token values would be sufficient, I would  
suggest.  When a code list is already identified by its canonical URIs as  
being a CEFACT list, I don't such a lot of extra gain in having a long  
name identifier that yet another CEFACT URI.

Additionally, I wasn't confident about being able to adequately pick the  
right set of long name identifier values, or even a good enough set, so I  
was prepared to let people be driven by common usage.  That was my  
personal thinking, anyway.

Cheers, Tony.

On Sat, 18 Apr 2009 18:41:23 +0100, G. Ken Holman  

At 2009-04-26 22:06 +0100, Anthony B. Coates (DES) wrote:
>If I understand your meaning, Ken, you are suggesting standardised values
>for the "LongName/@Identifier" attribute (and if I don't understand your
>meaning, please reply and just ignore whatever I've written from here
>onwards).

Yes, that is it exactly.

For each of the UN/CEFACT supplementary components, the listID= 
attribute is the one that has no corollary in genericode, other than 
it is a long name just as the title is a long name.

But every user of UN/CEFACT supplementary components who looks to 
genericode without looking at the decision made by UBL will make a 
different choice of @Identifier attribute to use for the listID= attribute.

That is what worries me ... multiple uses of genericode for UN/CEFACT 
and they don't interoperate.  I cannot pick up and use a genericode 
file written by someone else for a UN/CEFACT list if they chose a 
different Identifier= to identify this UN/CEFACT construct.

>I thought about this when I originally drafted together, and my
>thinking at the time is that you have to draw a line on identification
>somewhere.  I knew I could take it further, especially around types of
>long names, but I thought that it would be a diminishing return.

I can understand that.

>We could certainly propose some values for common purposes, a starting
>list that it not intended to be exhaustive, but I don't think it needs to
>be URNs, some plain old short token values would be sufficient, I would
>suggest.

Fine then.

>When a code list is already identified by its canonical URIs as
>being a CEFACT list, I don't such a lot of extra gain in having a long
>name identifier that yet another CEFACT URI.

Except that more users of instance-level meta data in supplementary 
components will be using listID= rather than

>Additionally, I wasn't confident about being able to adequately pick the
>right set of long name identifier values, or even a good enough set, so I
>was prepared to let people be driven by common usage.  That was my
>personal thinking, anyway.

And I'll take that.

Should there, then, be an informative annex in genericode with 
"suggested" values for Identifier= attributes?  So that when other 
users of genericode choose to map to UN/CEFACT supplementary 
components, the same conventions will be used?  For completeness, 
that annex could list all of the UN/CEFACT supplementary components 
and document what the CLRTC offers as mappings to genericode.

But could we consider having:  

On Sun, 26 Apr 2009 22:20:06 +0100, G. Ken Holman  

Just a couple of minor details. I have just been referencing the genericode spec in some work I am doing. In Version 1.0 28 December 2007 (http://www.oasis-open.org/committees/download.php/26818/oasis-code-list-representation-genericode.pdf), I noticed:

The "latest approved version" links are broken. So readers cannot check they have the latest version.

In the title, "Genericode" has an upper case "G". Should it be lower case (I know it is a title, but it is not the first word of the title, and is in brackets)?

The three "This Version" links are all labelled ".pdf". The first two should be ".html" and ".odt".

These seem like minor editorial changes that can be fixed without a formal release, although the capitalisation of "genericode" could be debated ad nauseam.

Regards

Paul