RE: [codelist-comment] Relationship with ISO 11179

["Peter F Brown" <peter@pensive.eu>]

Tony:
Thanks for the detailed reply.

One "obvious connection" for me was, for example, between:

"A data element concept may be associated with different value domains as needed to form conceptually similar data elements. There are many ways to represent similar facts about the world, but the concept for which the facts are examples (the extension of the concept) stays the same. For example, ISO 3166 – Country Codes, contains seven different representations for countries of the world. Each one of these representations contains a set of values that may be used in the value domain for a data element. For each representation of the data, the permissible values for the data element, the data type, the representation class, and possibly the units of measure, are altered."
(from the ISO standard)

and

"for each distinct entry in a code list, there are many possible associated values (we use the term distinct entry to express the idea that we are talking a single item that needs to be represented in the code list, rather than about the code value(s) that can be used to identify that item). Some of those associated values are suitable for use in code lists, some are not. This leads to a tabular model, where each row of the table represents a conceptual code, and each column represents an associated value (code list metadata)"
(from the OASIS draft spec)

I agree with you about the limitations of ISO11179 but we should acknowledge:
- that it has a very clear conceptual model (of "conceptual domain" and "representation domain", in part 1 of the standard) and
- that this conceptual model - intentionally or not - is strongly reflected in the proposed spec.
Credit where credit is due, is all.

I think your points about why ISO11179 *isn't* useful highlight precisely why references to it should be made: to make and strengthen the case for why OASIS is coming up with such a spec. ISO11179 deliberately doesn't propose a format for code lists, it offers rather a framework and guidelines: it is in this sense that I suggested that the proposed spec might be an "implementation".

The bottom line for me is: there is no harm and potentially benefits in making the link; but there is potential harm if the ISO standard is simply ignored with the risk that someone either levels an accusation of plagiarism (which I do not think is the case myself) or of bad faith by turning a blind eye.

Regards,

Peter

-----Original Message-----
From: Anthony B. Coates (Miley Watts) [mailto:abcoates@mileywatts.com] 
Sent: 19 May 2007 00:24
To: Peter F Brown; codelist-comment@lists.oasis-open.org
Subject: Re: [codelist-comment] Relationship with ISO 11179

[This is a personal reply, not an official reply of the Code List  
Representation TC.]

Dear Peter,

> The model and approach used seems to be an implementation of Parts 1 and
> 2 of ISO 11179, and yet no mention is made in the draft recommendation
> of this provenance.

Really?  I don't see an obvious connection between the two, not myself.

> -          if it is intended to be an implementation of ISO 11179 Parts
> 1 and 2, why is no mention made? Could you point to how and where the
> specification coincides with or differs from the ISO standard?

It is not an implementation of ISO 11179.

> -          if it is not intended to implement or leverage ISO 11179, was
> this standard at least examined in the course of the TC's work? what
> were the reasons for not explicitly working with it?

Speaking for myself, I don't find ISO 11179 particular interesting as a  
format for code lists.  It is interesting as a general data and metadata  
format, and I am involved with a number of standards (UN/CEFACT CCTS and  
ISO 20022) that make use of ISO 11179 concepts.  ISO 11179 can be applied  
to many data representation situations, and as such you can apply to  
representing code lists, but I don't think that is any more helpful than  
saying that you can use an XML Schema to represent an enumeration even if  
you don't plan to use it for validation.  While you can press many formats  
into service for representing your code lists, I think there is a need for  
a code list format that is only designed to represent code lists, and not  
more general data/metadata.

A reason that XML Schemas enumerations aren't seen as a good way to encode  
code lists is because, if you receive an XML Schema, there could be any  
amount of non-code-list data structures in it, and that forces you to  
check whether what you have received is just code list information or  
not.  The same principle applies to any format that allows for more  
complex data structures than are needed for code lists.  I hope that  
illustrates the point I'm trying to make here, at least in part.

Perhaps I should also mention that genericode is also not intended to  
compete with RDF/OWL (or ISO Topic Maps), so its design is focussed on the  
needs of users of flat code lists, not on the needs of users of  
hierarchical taxonomies and ontologies.

> Our primary concern is to establish what the advantages and issues would
> be for an implementer to use the proposed specification rather than ISO
> 11179 and/or - if  they are not orthogonal - what the relationships
> between them are.

Genericode is intended as an interchange format for code lists  
specifically, and I would hope that people will use the information to  
populate

* XML Schema enumerations;
* programming language enumerations classes (e.g. Java/C#);
* database code tables;
* metadata repositories, such as ebRIM repositories (which are based on  
ISO 11179);
* any other systems they use for run-time code list checking.

These are important targets, let me be clear about that.  Genericode isn't  
about replacing any of them, only about helping to populate and  
synchronise them.

I hope that helps in positioning genericode.

Cheers, Tony.
-- 
Anthony B. Coates
Senior Partner
Miley Watts LLP
Experts In Data
+44 (79) 0543 9026
Data standards participant: genericode, ISO 20022 (ISO 15022 XML),  
UN/CEFACT, MDDL, FpML, UBL.
http://www.mileywatts.com/